做不了,谁的错

原文刊载于《程序员》2012年第6期,请勿转载。

文/邱岳

不论是多么伟大的产品经理设计的多么伟大的产品,若最终无法落地成型并递送到最终用户手里接受市场的检验,则都是纸上谈兵,毫无用处。而工程师则恰是这最重要的一步中最重要的角色。在把蓝图变为最终产品的过程中,产品经理最担心的就是看到工程师摇摇头,说出类似“数据量太大,同步做不了”、“并发量太高,服务器撑不住,做不了”或者干脆就是简单的“做不了”这样的话来。遇到这样的情况,产品经理该如何应对呢?本文从三个方面分析一些常见的场景,并根据经验给出可能的解决方案。

一、清楚的需求、价值和目标描述

众所周知,产品经理更靠近市场和用户,他们对产品的设计来源于对用户需求的把握和对市场前景的判断。在与工程师沟通的过程中,产品经理应该把产品设计的来龙去脉都说清楚,而不仅仅是交代产品功能需求,甚至给出方案。在这一方面,产品经理不妨问自己以下两个问题。

1.

有没有说清楚项目的目标和价值?如果产品经理只愿意展示图纸,却不屑于对工程师讲述用户需求、开发产品的动机以及项目的商业目标,那么工程师很有可能没有透彻理解产品的价值或压根儿就不赞同产品创意,以一句“做不了”来搪塞也不意外,这背后的台词可能是“做这个有什么用”或“现在做这个就是浪费时间”。

产品经理在任何时刻都必须与工程师紧密合作,把产品创意、开发产品的动机及对市场的判断等跟工程师交代清楚,让工程师理解产品功能需求背后的故事——为什么要做这样的事情(商业目标)以及为什么要现在做这样的事情(优先级)。这样做不但能减少一些“做不了”的回答,同时也可以让工程师对全景有清晰的理解,不论是设计还是编码时,都能准确地拿捏有度,符合产品经理的设计期望,满足用户需求。

2.

描述的是实现方案还是原始需求?有时,出于各种原因,产品经理可能会试图越俎代庖,越过对需求的描述而根据自己的设想直接描述“实现”。比如,产品经理会要提出要“一匹时速100公里的马”,工程师的回答自然是“做不到”。若产品经理将需求描述为“更快到达目的地”,工程师或许会告诉你,他掌握了一门叫“制造汽车”的技术,看来可以满足需求。

不论是出于对工程师的不信任,还是过度膨胀的责任感,类似的情况都是不可取的。产品经理的职责是准确描述需求,虽然可以对实现提出一些建议,但不论如何,设计和实现产品还是应该交给更专业的工程师来完成。

二、资源和限制

平心而论,这世上可能真没有什么是“绝对做不了”的,更多的是对“投入产出比”的权衡。下面举三个经常在我们周围发生的场景。

1.

“不值得做”=“做不了”。工程师有时候会把“投入产出比低”说成“做不了”,比如产品经理可能提出“在IE、Safari、Chrome、Opera和Firefox等几种浏览器的各版本中保证视觉、交互效果一致”这样令人发指的需求。虽说这并不是无法完成的,但为了类似的需求却要花费很大的代价。这时工程师所说的做不了,其实是对“投入产出比”的不认同。

对于产品经理来说,这时应该首先主动解释清楚“产出”,即提出这样需求的目的,然后再跟工程师探讨“投入”,即要实现这一功能的成本。如果对成本有争执,可以试着咨询一下其他的工程师,看看是不是有更好的解决方案可以降低实现成本。如果真的没有,那产品经理要能准确权衡需求点的价值,从商业的角度判断“投入产出比”,对功能点进行取舍。例如上面的浏览器兼容需求,产品经理不妨查看数据或做一下潜在用户分析,选几款市场占有率较高的浏览器进行支持。

不过话说回来,产品经理很大一部分职责就是要根据各个功能需求“投入产出比”排定产品迭代节奏,这时产品经理应该敢于决策,不要被工程师对“投入产出比”的判断误导。

此外,我建议产品经理能主动了解点技术,虽然不需要钻得太深,但要能大概判断一件事情的成本,或最起码在跟工程师沟通时能快速理解关键点就够了。

2.

历史遗留系统或既定的技术框架。大部分工程师都喜欢盖房子,不愿意维护房子。因为在历史遗留系统上进行升级、维护,或者在既定的技术框架上开发产品时,难免会遇到很多技术限制。比如,我曾经提出个性化表单验证的一系列需求,但事实上我当时负责的系统使用的框架规范了所有表单校验过程,无法实现我要求的定制化需求。

我觉得这种问题的处理方法与上面说到的“投入产出比之争”的处理方法类似。首先,产品经理与工程师一起找到对遗留系统或框架最熟悉的人,咨询是否有实现方案。如果没有很好的办法,转而评估“投入产出比”。若不做此产品需求,公司的明天岌岌可危,那么宁可重构系统或更换框架也在所不辞。但如果没那么严重,不妨想想别的办法。比如上面说到的个性化表单验证需求,就是在分析了时机和需求价值后,修改了交互流程,选择了一种框架支持的方式。

3.

被污染的系统。还有一种可能,是由于系统代码被长期的“紧急”需求所污染而导致的“做不了”。这类需求通常是商业优先级极高的,面对这类需求,产品经理经常会要求工程师“越快上线越好,不用去管设计模式,也不用去管代码规范”。

做互联网产品,“快”绝对没错,但必须要有节奏感,这些被类似的代码不断污染后的系统会留下许多陷阱,同时也会为未来的产品功能升级设置很多障碍,基于这些陷阱和障碍,很容易得到“做不了”这样的回答。

我认为不论产品经理还是项目经理,一定要有意识地规避这样的风险,防微杜渐,确保工程师有足够的时间经常审查设计,并保证持续重构,使每次为了“快”而做出的设计牺牲得到及时的修正,否则不但未来的产品发展会受到影响,而且工程师也会因为总在救火而越来越疲惫,导致效率降低。

三、环境和人

除了上述的各种原因,还有一些原因是与“人”相关的,很多时候我们的环境让沟通很难有结果,比如下面提到的两种情况。

1.

局部利益之争。如果你在大公司工作,这种事情很可能会发生,就是不同部门之间的边界、利益之争。有些需求,A、B部门互相推诿,都说“做不了”;而另一些需求,A、B两部门抢着做主要模块,都不想做周边功能,在评估系统实施时,各个部门可能会倾向于说这些周边功能他们“做不了”。

这样的问题,我建议产品经理尽量不要在A和B之间过度沟通斡旋,防止由此产生的立场对立甚至矛盾升级,恐怕最好的办法就是去找系统架构师,从整个系统的角度给出专业的意见。

2.

还有要特别补充一点的是,如果你碰到的是胸无大志、只想混混日子的工程师对你说“做不了”,那最好的办法是不要浪费时间,直接换个人再问问。

但如果对方是技术功底还不太扎实,经验不太丰富的工程师,那应该带着他一起去向更资深的工程师去请教,不但事关尊重,而且更是帮助工程师快速提高能力,尽快肩负起更大责任的好方法。

顺利的产品实现过程都差不多,做不了的情况却各有各的不同。“做不了”,并不是谁的“错”,我认为只是产品经理和工程师的配合问题。

当产品经理面临“做不了”的挑战时,应该主动与工程师沟通,从客户价值出发,一起合作解决问题,确保信息对称。只有这样才能保证高效地开发出满足客户需求的产品。

 

2 Comments

发表评论

电子邮件地址不会被公开。 必填项已用*标注

评论审核已启用。您的评论可能需要一段时间后才能被显示。