小米大树part3:产品进度之痛

这是小米大树系列第三部分,前两部分见:

http://2014.54chen.com/blog/2016/08/06/mi2/ 《小米大树part2:测试之痛》

http://2014.54chen.com/blog/2016/08/01/mi1-dot-5/ 《小米大树part1.5:基础架构之痛答疑》

http://2014.54chen.com/blog/2016/07/29/mi/ 《小米大树part1:基础架构之痛》

一直想写一系列的笔记,记录整个小米六年的研发工作中实际遇到的困难,以及这一大群人如何不可避免的走向大公司氛围,又如何慢慢打破定势。

作为开发人员,实在是难以启齿吐槽产品经理,以至于很久没有补上第三篇。--题记

引子

十年前的互联网公司,大多数还没有这个岗位。如今人人都是产品经理的年代,烂大街的灵光一现的点子,不知所谓的需求描述,不着边际的实际操作,无人问津的后续跟进,直接造就了产品太烂、进度缓慢的各种局面。

一句话需求

A君是产品,从业多年,下过海创过业,身经百战。

A:我们的用户经常在这里出现了问题,我觉得要把这里拿掉,做成xxx的。

开发B:好啊,我觉得也是。

一个月过去了,A君遇到用户投诉,问B:当时说过的xxx怎么没有做啊?

B一脸懵B:纳尼,我以为你只是随口说说。

好的产品,不会提一句话需求,落实到文档到交互到协调到执行,才是好产品。

老板的需求

C君刚从某211高等学府毕业,茫然投身于产品事业,从业一段时间发现开发同学很懒,需求经常被开发追问为什么。

一次偶然机会C君发现只要说需求来自x总,开发基本不再问,效率很高,久而久之,来自y总、来自z总就成了基本功了。

C:这个需求是z总提的,我也不知道为什么。

开发D:z总提的,你也需要知道为什么呀,z总也是用户,你这样的实现是不是真的解决了用户的问题?不要做传话筒。

好的产品,不会把老板的需求挂在嘴边,会进一步挖掘用户真正的需求,据理力争。

忘记了的需求

产品E君,身兼数职,事情太多。

E:这个需求的详细文档在xxx,分析也比较清楚,开发时间也已经给出,剩下就看大家的了。

然后就没有然后了。

一段时间过去了,无人再问津。

突然有一天有人问起,xxx需求怎么还没做出来。

做出来了,因产品太忙无人验收这个需求,一直没有合主干。。。

一个好的产品,绝不会忘记自己提过的需求。

让步的需求

x功能,由于对系统架构改动太大,迟迟没有动工。

产品对需求丝毫不让步,和开发天天讨论不休,却没有结论。

产品F:这个需求只是为了试一试,谁也不知道有没有人用,我们先按简单的方案来搞吧。

一个好的产品,一定会区分“试一试需求”和“all in需求”,并且提前告知开发。

无人验收的需求

一个y功能,不知道哪个产品君提出的,开发做完了,由于赶时间测试也马虎通过了。

线上发现了问题,回滚,重新改逻辑,重新找bug,重新上线,浪费了大量的人员和时间。

这一点,是产品的意识问题,互联网产品如果承担一部分测试工作(我们叫做验收功能),从越早环节发现问题影响越小、成本越低。

后记

黑猫白猫,好产品坏产品,只要是从用户出发的产品,都不孬。


原创文章如转载,请注明:转载自五四陈科学院[http://www.54chen.com]

捐款订阅54chen
捐赠说明

Comments