--- title: 为什么开发团队和业务团队之间需要产品经理？ canonical: "https://xiaofeng.dev/writing/product-manager-between-dev-and-business/" pubDate: 2016-06-18 author: 唐小锋 Xiaofeng TANG description: 人月神话第七章“为什么巴别塔会失败”（见本消息的另一篇文章），里面提到了三种组织关系： tags: [Product Management, Software Teams] --- 人月神话第七章“为什么巴别塔会失败”（见本消息的另一篇文章），里面提到了三种组织关系： - 产品负责人和技术主管是同一个人。 - 产品负责人作为总指挥，技术主管充当其左右手。 - 技术主管作为总指挥，产品负责人充当其左右手。 在今天的常见的互联网企业组织，“产品负责人”演化成了多个角色：业务负责人（通常是老板，具备管理责任）、项目经理、产品经理。谁是总指挥、谁是左右手并不重要，毕竟这是他们不同的人，他们的立场和做事原则，决策原则，喜欢做的事情都不一样，没必要分清个主次出来。 知乎上关于**“为什么产品经理会存在”******里面关于产品经理的职责也有很好的讨论。（见阅读原文） 看完以上两个材料，结合自己的体会，于是有了这个结论：**在开发团队和业务团队之间需要产品经理，开发团队不应该承担过多的需求规划和设计职责。** 在大部分标准的互联网公司，这种情况不太需要特别提出来，这里只是谈一下笔者在B2B的行业的一些体会。**在没有产品经理的情况下**，有一些比较低效的情况发生：让开发人员或者技术主管去谈供应商合作、谈客户、做产品规划、做需求设计。 **为什么开发**人员不能兼任产品经理？ **首先是能力问题：** 很少有人同时基具备技术决策和产品决策的技能。**理解和参与业务需求**对开发人员进行技术决策非常有帮助的。但是开发人员同时**设计业务需求**是非常分裂的行为，虽然可以避免互相撕逼（因为一个人不会左右互搏），做到快速决策，但是在某些特定情况下决策质量会大幅下降——因为他在妥协。**一个未经争论的妥协，要么牺牲需求服从系统，要么牺牲系统的未来服从当下需求。** 技术和产品本来就是有一定冲突的角色（这种工作中的冲突和争论的经历，也是两者专业能力的重要来源），他们做事的原则就有本质不同： - 技术的基本原则：系统的标准化、扩展性、技术性能和未来的用户承载能力 - 产品的基本原则：客户的普遍真实需求，用户使用体验 以B2B行业普遍的客户的系统定制需求为例，它是如此普遍，以至于没有办法回避，放弃定制可能就是丢单，业务方一定要据理力争。然而我相信每一个开发人员都是非常厌恶用大量的定制来服务不同客户，因为它不能扩展，100个客户会有100个方式，难以快速增长。这种两难处境一定是需要特殊的妥协和小心谨慎的决策。双方各退一步的决策结果就是： - 轻量级定制：满足90%的共性定制需求，限制定制的增长（用5个定制去服务1000个客户） - 把定制变成特性（Convert customizations to features）：先定制几个客户，再逐步提炼成具有共性的功能 开发人员对定制的厌恶恰恰是这两个决定能够执行的强大保证。业务人员也可以从这种过程中也可以学会如何去管理、去引导客户的预期和需求。 在业务早期，兼任现象或许没有什么问题，随着那些团队健全、拥有大量专业人才的竞争对手的加入，兼任角色能力的天然约束会对业务增长的影响会越来越明显。 **其次是个人发展：** 现在T型人才比较流行，对公司来说，碰到这样的人当然非常幸运，但从做事的角度，它不是公司的普遍需求。开发人员在专业上出类拔萃依然非常必要，优秀开发人员可以带来十倍技术生产力的提升，为什么要去做他既浪费专业才能也浪费钱的事情呢？专业能力的提升明明是让他个人增值的更好途径。 **其他动机：** 在我的观察里，业务方之所以让开发团队去和客户谈需求，还有些其他原因： - 这些事情涉及系统设计和需求设计，超出了业务人员本身的一些能力范围，他不得不这么做。 - 避免在承诺出无法在系统上实现的需求 **可以做点什么？** **因人设岗：** 如果业务处于早期，而且恰好有可以兼任的人，果断要使用，不必在乎什么岗位限制。如果没有合适的人或者业务已经到了成长期，就应该考虑剥离角色，重新招聘一个人。如果市场无法招聘到非常合适这个业务领域的人来独立承担产品经理的事情，可选的办法有两种： - 从业务团队剥离一个人承担这个角色，去更进一步了解系统设计； - 从开发团队剥离一个人承担这个角色，去更进一步了解业务。 无论什么手段，都是基于参与人员来组织这个角色，这个人也需要站在边缘地带，既认可技术权威，又同时能以聪明合适的方式挑战开发团队，支持和约束业务团队。 **即认可又挑战（也是对于产品经理的建议）：** 认可开发团队在技术方面的权威是很自然的沟通原则，因为开发人员才是系统的“直接创造者”，在实现需求的技术方面有自由决策的权力。凡事过犹不及，事事寻求技术的意见也是一种失败。**任何时候都要谨慎地区分技术决策和产品决策。** 经常碰到业务方咨询可行性问题，似乎这是个技术问题：要么行，要么不可行。然而对开发人员来说，这更多是个产品问题。日常碰到的大部分需求都是可行的，关键取决于你愿意付出多少的成本和努力，是一周之后就要，还是可以等待花10个人、1整年才出第一版本。**正确的询问方式应该是：这个需求有没有低成本的解决方案？——这种提问姿势是善意的挑战，也是一种激励，更能够激起开发团队的思考和创造力。** 以上都是个人体会，我相信这些内容只在一定特殊情况下适用，纯粹是记下来，希望对其他人有帮助，如有不同意见，请务必留言指教！