产品经理捅死开发的九把刀

       产品经理和开发人员前世是冤家，在此生商定互相折磨。在笔者的工作经历中，鲜有和谐共处的时候，绝大多数都是针尖对麦芒，视对方为傻叉。甚至有些情况下，发展成为了人身攻击和物理伤害。

        回过头仔细想想，产品经理和开发人员能有什么仇什么怨？都是一条绳上的蚂蚱，并不是第敌人。很多时候冲突的起因，只不过是工作方式、思维方式的差异而已。本文从开发人员的角度总结总结哪些让人为难的场景，也算是为世界和平做出点贡献。

1. “独裁者”沟通方式

       产品经理和开发人员大部分情况下是一个链条上的两种分工，并不存在上下级关系，只有上下游关系。产品经理为需求负责，开发人员为实现负责。倘若产品以“经理”的姿态去沟通，往往结果适得其反。“这个需求我拍板，出了问题我负责”，姑且不谈能否能真的负责，这种姿态，也基本把开发人员的优化意见拒之门外，长此以往，得不偿失。常言道，“听人劝，吃饱饭”，不妨听听开发人员的想法，认真思考思考，没准能让方案锦上添花。

2. 一句话需求

       这种情况很常见。笔者曾经接到过一个需求，PRD文档删减掉“转化”、“抓手”之类的词语外，就剩一句话加一个按钮：实现支付功能，至少支持微信。至于商品怎样管理，价格怎样管理，售前售后有什么需求，如何对帐，怎样退款，一概不提。

       一句话需求的本质是，产品经理没有付诸更多的精力去形成方案，只是把这个过程抛给了开发人员。不出问题，反而很奇怪。

3. 拍脑门定需求

       笔者遇到过少量靠谱的产品经理，需求的提出有着比较完善的逻辑分析和数据支撑，同时还有清晰的目的，在这种情况下，不论设计方案有多违背直觉，对于开发人员而言，也是心悦诚服的。可惜，多数情况下不是这样。

       在某个项目中，在开发过程中评审下版本需求，发现，还处在开发中的界面在新版中完全变样，开发提出疑问后，答案是，更改后更好看。在这个案例中，开发中的和新需求至少有一个是拍脑门的产物。未上线的需求白白白费了大量资源，很多重要的需求被挤压，形成了技术债务。

4. 需求不分主次，全都要

       开发资源在一段时间内是有限的，实践中通常按照重要性和紧急程度制订优先级进入开发流程。道理很简单，做到却很难。

       同样是在某APP迭代中的案例：新版本中添加了新题型，PRD中对于交互方式的形容非常酷炫，大概一款益智游戏的效果一样吧，什么气泡大小按照内容适配，还需要随机移动，气泡消除时，再加个爆炸效果… 结局大家大概能想到，产品研发争吵一番后，不了了之。在这个案例中，新题型的支持是刚需，算是重要且紧急，酷炫效果却不是。对于一帮并不是做游戏的程序员而言，开发酷炫效果的时间成本非常高，远远超过功能本身。最关键的是，根据客户量和使用场景预估，这个需求覆盖到的客户可能最多也就两位数，占比约等于0。

       除此之外，一个版本在工作量远远超支的情况下，所有功能点的优先级都是P1；很长一段时间内数据量基本保持在个位数的情况下，需要支持模糊搜索等也是常见的主次不分。

       需求主次不分的本质起因大概是：产品设计时未充分考虑产品的定位，客户的真实需求以及现实条件，同时，贪婪。

5. 越俎代庖给方案

       无论是产品经理还是开发人员，都是专业化程度比较高的岗位。生活中大多数产品经理都是没有开发背景的，在这种情况下，带着所谓的“技术方案”去和开发人员沟通需求，很难会有好的结果。

       在没有开发背景的情况下，这些“技术方案”哪来的？对于计算机专业出身的产品经理，很有可能来自于当年课堂上的学习的理论；而对于完全行外的产品经理来说，基本上都是从搜索引擎上获取的。

        至少在软件工程领域，课堂所授已经远远落后于实践，指导意义可想而知。而在搜索引擎上获取的方案，无法做到所有的外部条件都和当前一致，也只能在某些技术点上有些用而已。

       一个合适的“技术方案”需要充分考虑整个项目的节奏、人力调配、后续迭代、架构变动等，所以，尽可能的信任开发人员吧。

6. 盲人摸象或者多米诺骨牌需求

       一生都生活在一个屋子里的人，是无法了解“房屋”这一实体的。产品经理在提需求时，经常会仅形容需求本身，而忽略了所处的业务环境。

       盲人摸象式需求忽略了新功能在整个业务中的地位，多米诺骨牌需求则忽略了新需求对于其余功能的反作用。这两种需求较为相似。

       还是上文中提到的”支付功能”需求，在不形容商品、定价、权益交付等业务逻辑的情况下，仅仅形容支付本身，会让开发人员一脸懵逼。这是典型的盲人摸象式需求。

       在k12教育业务中，客户归属地是一个很重要的信息。项目初期，客户归属地通过班级学校等关系间接获取。当上线支付功能后，发现一个严重的问题：支付功能的使用场景中，客户是不具有班级学校关系的，权益增加出现了严重的问题。经过紧急研究后，增加了客户归属地的直接属性。 衍生问题紧接着就来了：新的归属地逻辑和旧的归属地获取逻辑在某些情况下会产生冲突，导致旧功能出现异常。这个案例我们仅从多米诺骨牌的角度解读，新的逻辑变更并未同步考虑旧逻辑兼容问题，造成了严重的数据混乱以及二义性。

7. 空中楼阁式需求

       无论是产品设计还是架构设计，绝大部分时间都是在处理实体与实体间关系的问题。我们经常遇到这种情况，需求点在有显著上下业务依赖的情况下，跨越依赖业务的设计，直接奔向“空中楼阁”。

       同样在支付系统中，没有对商品管理、购物车等前置业务进行设计的情况下，直接“收钱”，业务的坍塌只是时间问题。

       另外一种经常遇到的场景是，需求中没有表现是关系还是属性。可以这样认为，有明确的取值范围，且足够简单，可以作为属性解决，例如客户的性别、出生年月，无需单独创立业务实体，使用特定值作为属性就可。假如新添加信息需要单独维护，甚至有可能有附加信息，则需要采用关系的方式进行解决，例如学生的班级。问题经常出现在从前者到后者变更的时候。

       举个例子：原设计中，客户的性别只有男、女，分别定义为两个数字，1、2；需求变更后，性别需要能够单独维护，比方自由增加“心理男”、“心理女”等性别定义，此时，就需要将性别设计为实体，客户需要与性别建立关系；分歧由此产生，对于开发者而言，从属性到关系的转变，工作量骤增，对于产品经理而言，不就是添加了一个对已有信息维护的需求，怎样需要这么久。

8. 前后矛盾的需求

        这种需求很容易了解，就不再举例了。当产品经理需求去问开发人员旧版本设计方案时，就需要警惕前后矛盾的需求了。至于产生起因，不在本文范畴。

9. 要求“灵活”的需求

       “灵活”是一个很宽泛的词语，每个人的了解都不一样。一旦某个需求，提出了“灵活性”的要求后，基本上相当于把开发人员一脚踢到了地狱，未来任何调整遇到困难时，都会归咎于“实现不灵活”。

       一个典型的需求形容：“xx功能需要具有灵活扩展的能力”。相信我，对于这句话，开发人员和产品经理对于“灵活扩展”的了解是一定不一样的。倘若更换成，“题库系统未来2月需要能够支持完形填空、阅读了解等包含子题目题型的接入，半年内需要支持自己设置题型接入”，会更清晰少量。起码将“灵活性”限定在了题型扩展领域，前期设计时即可以测重考虑这部分。

以上九把刀，刀刀催人老。