详情
本书以高效开展研发组织管理工作为目标，首先引入研发管理的常见问题，然后介绍研发管理的概念、目的、建设思路，以及如何从头创建一个项目（包括项目管理过程、项目开发过程、项目实施过程、产品管理和营销客服过程、研发支持过）。本书围绕研发管理体系的四个要素—思想方法、工作流程、配套工具和人力资源进行了详细讲解。阅读本书，读者可从中学习到如何建立自我成长、高效能的研发作战团队，从而在预定的时间和成本之内开发出让消费者满意的产品。
书名：研发管理快速上手
ISBN：978-7-115-60527-6
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 林 锐
责任编辑 李 瑾
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书以高效开展研发组织管理工作为目标，首先引入研发管理的常见问题，然后介绍研发管理的概念、目的、建设思路，以及如何从头创建一个项目（包括项目管理过程、项目开发过程、项目实施过程、产品管理和营销客服过程、研发支持过程）。本书围绕研发管理体系的四个要素—思想方法、工作流程、配套工具和人力资源进行了详细讲解。阅读本书，读者可从中学习到如何建立自我成长、高效能的研发作战团队，从而在预定的时间和成本之内开发出让消费者满意的产品。
本书适合企业中高层管理者、产品研发人员、企业运营流程设计者和管理者、高校老师及研究机构专业人员阅读。
如今，中国的电商和物流非常发达，“卖货和送货”的门槛低、赚钱快、失败风险低，所以大量创业者和就业者加入“卖货和送货”大军，可谓夜以继日。相比之下，研发的门槛高、难度大、失败风险高，所以从事研发的人员和企业越来越少。这会让表面上的市场繁荣暂时掩盖住长久的隐患。
极容易得到的东西往往是平庸之物，也极易被人抛弃。任何行业的竞争最终比拼的都是好产品（包含好服务），因为消费者关注的是好产品。这里的“好”是功能、质量、价格和吸引力的综合表达。
那么，好产品从何而来？
好产品绝对不会遍地都是、唾手可得！
除了自然资源（如农林渔牧矿）之外，绝大多数好产品都是企业研发出来的。越好的产品，研发投入就越大。研发能力是企业持久的核心竞争力。
当今时代，研发弥足珍贵，值得所有企业重视。
研发管理的目的是在预定的时间和成本之内开发出让消费者满意的产品，这是一件很不容易的事情。
需求、设计、质量和效率、项目管理、产品管理、跨部门协作、商业模式等研发管理的常见问题相互交织，每个问题都无法单独解决。例如，你无法用一种方法单独提升质量或效率，只要需求、设计、产品管理、项目管理做不好，就一定会降低质量或效率。
所以研发管理不能“头痛医头、脚痛医脚”，不能依靠应急措施、经常救火，必须寻求系统性的解决方案，即建设研发管理体系。
研发管理体系有四个要素：思想方法、工作流程、配套工具和人力资源。
企业的研发管理体系一旦建立好，就好比是铁打的营盘，是企业持续发展的根基。企业不再害怕人员流动，新人进来之后，经过相应的培训，可以很快地融入体系之中，能够为企业创造价值。
效能是效率、能力、成效的综合表述，可以简单直观地表达为“效率和能力的乘积”，即：效能=效率×能力。高效能意味着工作既快又好，用较短的时间、较低的成本获得满意的成效。
请注意，能力和效率之间不一定是正比例关系。如果个体能力很强，但他们很懒散，或者不服从管理，整体效率也会很低，相应的效能也低。反之，如果他们效率很高，但是能力很低，只能够很快地做出很平庸甚至很差的产品，也是没有前途的。
效能这个术语，既关注结果（即成效），又关注过程（即效率×能力），非常适合于研发管理体系。提升效率主要依靠合适的流程和工具，提升能力主要依靠培训、实践和探索，两者结合才能获得高效能。
在融合CMMI、敏捷和迭代的基础上，本书建立了“研发管理体系模型”（见图1），将效能划分为2-3-4-5等级，对应及格-良好-优秀-卓越水平等级。希望读者在理解之后，再根据企业自身特征修改模型，研制适合本企业的研发管理体系。
图1 研发管理体系模型
自工业革命以后，人类在科技领域的进展可谓突飞猛进、日新月异，相比之下，管理的演进却并非如此。如果你的产品使用的是十年前的技术，你会被别人嘲笑。然而，如果你的管理方法来自千年前的古人思想，却可能不仅不显得落后，反而会被别人仰视。
可见，管理方法并不刻意追求先进或创新。好的管理有共同的特征：人性化、容易理解和易于使用，能够获得期望的成效。
对于管理，人们总希望“大道至简”。但是，我们不能为了迎合人们的期望，而把原本复杂的事物硬生生地弄得很简单，以至于简单而无效。我们只有深刻理解复杂事物的原理和逻辑之后，才可能对它进行精炼（优化），使其容易理解和易于使用。
研发管理是复杂的，不可能极简单。研发管理体系是一个复杂系统，不是三言两语就能说明白的，也不是随随便便就能掌握的，这是客观事实。
我从2000年开始从事研发管理方法论的研究和相应软件系统的研发，至今已有20多年的实践，其间出版了十多本著作。我的使命是：不断地实践和思考，把复杂深奥的研发管理方法论转化为容易理解和易于使用的管理体系，帮助中小型企业，用较低的代价快速、平稳地提升研发效能。
本书是我20多年来研发管理经验的浓缩，书中建立的研发管理体系模型（见图1）已被修改上千次，模型中的每个字、每条线都有其含义。这幅图清晰直观地展示了研发管理的逻辑，是我锤炼了20年的心血之作，已经被大量IT企业引用，发挥了重要作用。
要想获取更多与研发管理相关的资料，请发邮件给我（linrui@mansuo.com）。此外，我根据效能3级研发管理体系模型开发了“项目管理平台”，该平台集成了需求管理、任务进度管理、缺陷（问题）跟踪、质量检查、客服管理、知识库管理等常用功能，欢迎读者发邮件联系我，以了解更多信息。
本书的读者对象主要是研发企业的管理人员，高校的老师也可阅读本书。高校拥有数量众多的研发项目，以及人数最多、最松散的研发群体，但是缺乏有效的管理，本书的方法和工具将有助于高校科研项目管理。
研发管理是一门严谨、枯燥的实践性学问，远不如快速赚钱、成功学那么吸引人，其读者群也很小，因此，对于本书的出版，我特别感谢人民邮电出版社的鼎力支持。
同时感谢读者和客户多年的支持。感谢西安电子科技大学校友金志江、宋朝盛、戴玉宏和浙江大学校友董军 、刘灵辉、石磊的大力支持。
林锐
上海漫索计算机科技有限公司
本书由异步社区出品，社区（https://www.epubit.com）为您提供相关资源和后续服务。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，单击“发表勘误”，输入勘误信息，单击“提交勘误”按钮即可，如下图所示。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线投稿（直接访问www.epubit.com/contribute即可）。
如果您是学校、培训机构或企业用户，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、人工智能、软件测试、前端、网络技术等。
异步社区
微信服务号
本章从需求、设计、质量和效率、项目管理、产品管理、跨部门协作、商业模式七个方面，论述研发管理的常见问题和对策。
上述问题相互交织，几乎无法单独解决。例如，无法用一种方法单独地提升质量或效率，只要需求、设计、产品管理、项目管理做不好，就一定会降低质量或效率。
所以研发管理不能“头痛医头、脚痛医脚”，必须寻求系统性的解决方案，这也是企业建设研发管理体系的缘由。
[1] 为了表述简洁，本节用“客户”来代表需求提出者，包含消费者、企业领导、营销人员等人。
客户提出的需求没有条理性，甚至相互矛盾。
比如装修时，客户最初提出要简洁大方的设计，越简洁越好，提倡“少即是多”的设计理念。但是在设计和施工的过程中，客户为了追求完美，需求从简洁演变为复杂。
上述案例的一种可能是客户内心知道自己需要什么，但是表达能力不强，缺乏条理性，让开发者不能充分理解其真正需求。
下面做个小测试，询问几个人，请他们用两分钟时间总结今天做了什么事情。估计会有半数的人支支吾吾、不知所云，可见“人们说不清楚自己内心知道的事情”是一种普遍现象。
还有一种可能，客户是个缺乏主见、立场不坚定、思维跳跃的人。无论他的表达能力是否很强，他都不可能表述清楚需求，因为他内心并不知道自己究竟需要什么。
一日，老张请老王吃饭。老张问老王：“你要喝点什么？”
老王说：“随便。”
老张问：“那我们就喝点葡萄酒？”
老王说：“不喝，像血，酸不拉几的。”
老张问：“那我们喝点米酒？”
老王说：“不喝，一股子馊味。”
老张问：“那我们喝点果酒？”
老王说：“不喝，那玩意儿甜丝丝的，一点酒劲儿都没有。”
老张无可奈何地说：“这里只有三种酒，委屈您选一种吧！”
老王说：“我都说了随便啊。”
老张叹了一口气，沉思片刻，就把葡萄酒、米酒、果酒随便地混在一起。
老王尝了一口，嗯，味道不错。这就是老王要的“随便”。
当客户不断地否定需求，或者滔滔不绝地阐述需求时，他其实需要专家帮他选择最重要的需求。不要企图满足他说的所有需求，因为很多需求是相互矛盾的，无法同时兼得。
客户感觉：“要是有那种东西该多好啊！”但有些感觉是错觉，于是产生了“伪需求”。
叶公的亲朋好友、街坊邻居都知道他喜欢龙，可是当龙兴冲冲地飞到叶公家里做客的时候，叶公吓得魂飞魄散。所以“叶公好龙”是伪需求，叶公本人、龙和观众们都误会了。
消费是要付出代价的，如金钱、时间、耐心等，不只是说说而已。每天都有无数人提出了无数的需求，而凡是经不起“消费验证”的需求，都是伪需求。
客户很喜欢表达伪需求，越是得不到的东西，他就越热切。这种表达使开发者以为抓住了市场需求。但是当伪需求真的被实现时，客户却不愿意付出代价来消费，使开发者的一切努力付诸东流。
毫无疑问，围绕伪需求做出来的产品一定是失败的，因为没有真实的消费。但若要从众多需求中鉴别出伪需求，也是比较困难的事情。
对于人说的话、写的文字，其含义并不是唯一的，比如一词多义、望文生义，很容易让人产生误解。
电梯里贴着告示“请带好孩子”。妈妈严肃地对孩子说：“你看到了吧，只能带‘好孩子’进电梯，坏孩子不能进电梯。”孩子听了暗暗下定决心，一定要做一个好孩子，否则这辈子乘不了电梯，上不了高楼。
开发者和客户都有可能误解对方，当开发者把产品交付给客户的时候，双方才发现对需求或解决方案产生了误解，则纠错的代价会非常高。
客户前期表述需求后，最近又有了新想法，于是提出了新需求。这里也许是他发现前期需求不太成熟、不太正确，才纠正了需求。
频繁的需求变更将使开发者不断地修改原本正确的工作成果，导致进度延误，质量低下，因为修改成果极易产生新的错误。如果客户不能给予补偿，那么增加的开发成本无疑是一种损耗。
在市场经济时代，无论是产品项目，还是合同项目，都不可能等到人们完全明确需求之后，才进行立项开发。
客户的需求是有时效性的，他们不可能等待太长时间。现实中，绝大多数项目都是在大致明确主要需求后，就进入开发过程。开发者会一边细化需求，一边开发，快速地交付试用，然后再改进。
在项目开发初期，需求比较少，容易明确，即使项目经理口头传达，项目成员也能落实。
之后需求会不断涌现，可能来自领导、产品经理、营销人员、客户代表、客服人员，等等。如果没有合适的流程和工具，就无法管理繁杂的、源源不断的需求。
当需求在开发过程中突然狂增时开发者和领导就会疑惑，也不知道已有的功能为什么发生了变更，于是项目失控，无法实现预期的进度、质量和成本。
为了加深对需求问题的理解，建议大家观看网络幽默剧《这个杀手不改需求》。
一位女画师接了客户的一个小单子，画一幅仕女图。双方对仕女的长相产生了分歧，三个月内客户变更了1 600多次需求，原本一头秀发的妙龄女画师被整得秃头了。女画师向官府报案，官府却说这个纠纷不在管理范围之内，不予受理。
女画师迫不得已求助一位杀手。这个杀手最恨言而无信之人，尤其是不断变更需求的人。在报仇的过程中，他们发现画仕女图的需求是转包过来的，原来的客户不是真客户。为了厘清需求的来龙去脉，拍了整整28集电视剧，观众们纷纷点赞。也许这个编剧也遭受过“需求苦难”，所以此剧编得真切。
需求是一切开发工作的源头，如果需求做不好，企业纠错的代价就会很高，失败的风险也会很高，所以要高度重视需求问题。
企业的所有工作归根结底都是围绕消费者的需求开展的，需求会从四面八方涌现，如图1-1所示。
图1-1 需求的相关流程
对于自主研发的产品，产品经理负责产品需求的调研、分析和定义。对于合同项目，营销人员要尽可能厘清客户需求。
立项之后，在项目开发过程中，项目经理负责需求管理。项目需求会不断地细化，也可能不断地产生新的需求。
如果企业没有清晰的需求相关工作流程，各环节的人员就不知道如何配合，导致需求传达混乱。
企业制定需求相关的流程之后，还要有配套的需求管理工具，实现条目化管理。否则时间一长，需求的执行情况就容易被遗忘。
所谓条目化管理，就是把需求文档里面的需求拆成若干条，每一条需求都落实到责任人。责任人要跟踪这条需求的实际执行情况，如果需求发生了变更，相关人员要知道变更原因和影响。
开发者都盼望：需求提出者一次性表达清楚需求且不再变更，并且各方都达成共识，但这是不切实际的。
好比医生（开发者）不能指望病人（客户）把病情讲得清清楚楚，自己听得明明白白。医生的职责和价值是诊断和解决病人的问题，即使病人自己也不清楚病情所在。
即使客户说不清需求，作为开发方的需求分析人员，也一定要准确、清楚地描述“必要并且完整”的需求，因为这是职业要求。
需求工程有6项活动：需求获取、需求分析、需求定义、需求确认、需求跟踪、需求变更控制。
开发者在读大学期间可能练习过设计和开发，但是几乎没有完整的需求工程训练。他们毕业后到企业工作，大多数人是凭感觉开展需求活动。即使他们看了需求流程，也暂时没有能力做好需求。所以企业必须弥补员工在“需求工程”方面的能力欠缺。
需求来自人的欲望。人的需求永无休止，没有高低贵贱之分。消费者的需求是可以引导的，只有当需求和供给相匹配后，才会产生商业价值。
即使开发者费了九牛二虎之力把客户说的全部需求都完成了，客户也不一定很满意。因为客户说的需求不一定是他内心真正想要的，有些是他不曾了解也根本想象不到的。
开发者（包括设计师）要比客户有远见，不拘于眼前需求，才能做好产品（或合同项目）。
如果每个项目都从零开始做需求分析，开发者被动地等待客户提出需求和变更需求，那么企业就会被客户牵着鼻子走，这种模式是没有前途的。
企业应当在战略高度上重视领域需求研究，系统性地深度研究领域需求。企业要比绝大多数客户更了解需求，让客户信服，从而引导客户消费。
苹果公司研发手机，腾讯公司研发微信，从未向客户询问过需求，因为开发商比用户更加了解需求，能正确引导用户消费。
上述三点需求对策，说起来比较容易，但是执行难度比较大，所以企业人员要有毅力坚持改进，才可能做好需求工作。如果想更好地了解需求的相关知识，欢迎读者阅读我的另一本著作《天性：长久需求和无限商机之源》。
我们把设计分成两大类：一类是用户看得见的设计，另一类是用户看不见的设计。
例如一栋大楼，看得见的是这个大楼的外观和每个房间的设计。而看不见的设计包括大楼的地基、框架结构和隐蔽工程等的设计。
从上例可以知道：看得见的设计是给用户直接使用的，用户能够快速地感知设计的价值；而看不见的设计则支撑了产品的可靠性，用户要用较长时间之后才能够感知到其价值。
（1）企业虽然重视看得见的设计，如产品外观和人机交互设计等，但比较遗憾的是，设计缺乏吸引力，不能打动消费者，导致产品销量不高。
（2）很多企业不重视那些看不见的设计（后台设计），因为消费者看不见后台，有问题再改。
以IT产品为例，技术框架、安全性、性能、可扩展性等属于看不见的设计。若在设计初期缺乏远见和投入，认为能用就行，则当用户规模发生比较大的变化时，这个系统就会不断地出现故障。当需求发生变更的时候，后台也无法适应变化。若这样的事情频繁发生，用户会觉得这个产品质量不好，就会放弃使用。
如果看得见的设计做不好，消费者不感兴趣，产品就没有销量。如果看不见的设计做不好，消费者虽然买了，但是产品经常出问题，消费者也会放弃产品。
产品经理、营销人员和设计师要经常聚在一起，深入地探讨产品的设计方案。首先要明确究竟是什么因素打动了用户，这些因素又叫“吸引力要素”，比如说美观、独特、有趣、安全、健康、舒适环保、易用等。
注意，卖方经常宣传的“产品功能多”不一定能打动用户，因为其并不在乎可有可无的“多功能”。
并不是每个产品都要比拼美观，有时候有趣可能比美观更加重要。比如有的短视频社交软件，其操作界面不是很美观，但是用户量极大。
企业不要去做“面面俱到”的平庸设计，而要先研究用户的特征，提炼出这款产品的吸引力要素，然后集中精力把“吸引力要素”做好。
公司的技术骨干要提前进行技术框架选型，如果没有现成可用的，那么可以自己重新研发。好的技术框架可以让公司使用若干年，且能适应各种变化。
公司技术骨干要参与项目的立项评审和设计评审，要让全部项目构建在公司指定的技术框架之上。不能让项目团队自由开发，否则，不久之后公司的技术产品将五花八门，互不兼容，开发效率和质量也会很低。
想要了解更多的设计话题，欢迎读者阅读我的另一本著作《吸引：产品制胜的设计思维》——专门探讨如何打造产品吸引力。
开发者都希望研发工作做得又好（高质量）又快（高效率），但鱼和熊掌往往不能兼得。即使个体的研发能力比较强，也不意味着整个团队的效率高、产品质量高。只有好的研发管理，才能有效发挥全部个体的能力。
企业领导经常追求管理的理念和方法，虽然很有道理，员工们也都清楚，但是并没有落实到流程中和工具上。
研发管理的专业性很强，也算是比较深奥的学问，员工无法凭借领导讲话和自己领悟就能把研发工作做好。
如果员工并没有真正执行流程，没有使用合适的工具，那么研发过程必定混乱，从而导致效率和质量不高。
一群缺乏有效管理的武林高手是没有战斗力的，在没有和敌人战斗之前，他们就开始内讧了。这个思想也适用于企业。
十多年前，我曾经给上海一家软件公司做研发管理咨询。这家公司约50人，做政府信息化项目。
研发总监自豪地对我讲：“政府信息化需求旺盛，只要做得好做得快，项目源源不断。我们招聘的开发人员技术都很好，工资也比较高。目前所有的编程语言，如C/C++、Java、Delphi、JSP、VB、PHP，我们公司都会做。国内最先进的软件技术，我们都用上了。以我们的能力和发展趋势，估计几年后就能成为全国一流的软件公司。”
公司总裁却愁眉苦脸地对我说：“公司人员的技术不错，项目不缺钱，一开始做得很快，但是交付试用的时候毛病非常多，客户用着用着就死机了，哪个项目都无法正常结项。每个项目都埋了很多地雷，不知道什么时候爆炸。我经常被客户叫到现场教训，各级领导看着我，要我几小时内把系统恢复正常，否则要承担若干后果。客户要求我每天24小时开机，我一听到电话响就哆嗦。家丑不可外扬，我真的很苦啊。我感觉自己都要精神崩溃了。”
我诊断的结论是：这是一家由没有研发管理的一群高手组成的企业，个体崇尚自由，不愿意被管理，喜欢在客户项目中使用各种新技术，个人的喜好高于客户需求，他们很不适合开发政府信息化项目。
几乎每个项目都重复开发其他项目做过的功能，又重复产生相似的缺陷，然后去修正缺陷，消耗了很多精力。这种做法会导致效率和质量都不高。
很多开发人员没有自我测试和自我优化的习惯，他们认为提高质量是公司质量部门的事情，或者是公司领导的事情。
有些开发人员在任务一完成后就抛给测试人员去测试。等测试人员发现问题后再通知他们修改，如果没有发现问题，就说明产品很好。结果导致测试人员花费大量精力去测试浑身缺陷的产品，做了很多无用功。
如果质量管理不够仔细，有缺陷的产品匆忙上市，后续退货、修正的代价会很高。
（1）企业必须制定研发管理流程，选择配套的工具，对相关人员进行培训，确保所有员工都明确流程，且会使用相应的工具。
凡是流程和工具能解决的事情，建议领导就不要去干预，尤其不要发生多人重复管理的现象。
（2）企业要不惜在建设公共技术平台上多投入资本。
公共技术平台的技术功能都是可复用的。每个应用项目不要全部从零开始做起，而应直接从平台中调用已经做好的功能。
如果一个应用项目的大量功能都直接从公共技术平台调用，会节省大量人力和物力。这时只需要集中精力开发新功能即可，开发效率和质量必定会更高。
（3）企业要多花时间去建设知识库。
就是把前人的经验教训、心得体会制作成规范化的知识，便于学习交流。例如把知识做成网页，其中包含有文字、图片、视频和其他附件，员工用手机就能浏览这些知识。
这些知识可以帮助员工少犯相似的错误，少走弯路。
（4）企业一定要对全员灌输质量理念：任何人都必须对自己的工作成果负最大的责任（责任到人），而不是由质量部门或公司领导来负责。
项目管理的好坏，与管理方法和项目经理个人有很大关系。
（1）过度管理，是指项目经理事无巨细地监督每一个项目成员的工作过程。一方面让项目成员很烦恼，另一方面项目经理自己也没有精力去做重要的开发工作。
（2）过少管理，是指项目经理只顾自己埋头干活，根本不考虑别人做什么、怎么做、成果怎么样。他虽然有项目经理的头衔，但是没有行使项目经理的职责。
比如，项目成员没有使用代码版本管理工具，大家经常修改别人的代码，导致项目的代码版本较多且混乱。再如，项目成员不使用缺陷跟踪工具，不知道有哪些缺陷，也不知道缺陷处理情况，导致质量较低。
项目经理不能及时解决开发过程中遇到的一些技术障碍（自己无法解决，也没有寻求外援），导致项目开发堵塞在某个地方无法前进。
项目经理不能透彻理解需求和控制需求变更，导致团队经常返工。
项目团队不清楚这个项目的来龙去脉和项目的目标，也不清楚怎么样才算是做完了。
老项目停不下来，新的项目又不断地产生，工作没有完结，导致员工对自己曾经做过的功能的价值产生怀疑。
在项目启动的时候，要让全员明确项目的来龙去脉和目标，以及工作流程和指定的工具，确保每个人都理解“做什么、怎么做”。
在结项的时候，要让项目成员知道哪些工作做得好，哪些工作需要改进以及如何改进。
项目经理不仅自己要研发，也要监督项目成员的工作。如果项目成员的进度没有延误，成果质量也高，那就尽量不要干扰他。
如果进度延误或者质量不合格，项目经理要及时了解原因，帮助项目成员解决问题，这样才能够让项目顺利地开展。
需求研究能力甚至比技术能力更加重要，如果对需求的理解出现偏差，可能导致项目团队迷失方向，需要不断返工，开发效率和质量很低，代价很高，士气低迷。
第一个问题：很多企业搞不清产品管理和项目管理之间的区别，也搞不清产品经理和项目经理之间的区别，经常套用合同项目的开发模式去做产品，这样是做不好产品的。
解决这个问题的对策：企业一定要制定产品管理流程，厘清产品经理的职责。（详见7.1节）
产品经理决定“做什么”，项目经理负责实现。
产品经理要站在消费者角度去思考问题，努力使这个产品符合消费者的需求，并且吸引消费者。
项目经理是这个产品的开发负责人，他要努力使开发团队实现期望的进度、质量和成本。
第二个问题：企业很难招聘到优质的产品经理，优质的产品经理留不住，他们可能去更好的企业，或者干脆自己创业，怎么办？
解决这个问题的基本对策：企业要用较高的薪资招聘产品经理。如果招聘不到合适的人员，就自己培养。
企业要挑选那些对消费者行为有洞察力的人，这样的人适合培养成为产品经理。可能他一开始不会做产品，但只要遵循产品管理流程，多思考和实践，很快就能学会。
很多小企业老板最初并不懂产品管理，他们出于生存的本能成为产品经理，当产品在市场上取得成功后，企业存活了下来。但之后就不能再依靠本能和感觉去做产品了，因为风险太大。
企业要花精力去培养产品经理和项目经理，因为他们是研发团队的核心力量。
（1）各个部门之间的接口人员互不熟悉对方的流程，沟通起来比较困难。
比如营销部门、研发部门、生产部门、施工部门、服务部门，各工种差异比较大，如果一件事情要遍历上述部门，想要顺畅执行的确比较困难。
（2）上游传达给下游的需求或任务不清晰，而且经常变更，这会导致下游不知所措或不断地返工。
（3）上游不了解下游的工作进展情况，不知道他们的工作负荷。可能下游人员已经疲惫不堪了，但上游人员还在不断地下达任务。下游忙不过来而造成工作堵塞，导致任何新的任务都无法执行。
（4）跨部门利益冲突。不同部门的业绩考核是不一样的，比如营销部门的人员总是希望签下更多的合同，他们会答应客户各种各样的需求，还可能会承接一些利润很低的项目。这些都会增加开发人员的压力，导致哪个项目都做不好，研发力量无法聚焦，做不出精品。
（1）企业要制定覆盖全部工种的流程。每个部门都有相应的工作流程，本部门和接口人员要进行流程培训。
能力成熟度模型CMMI的第三级叫“已定义级”，就是指全公司的流程已经定义好、已经标准化，相关的人员都能够按照既定的流程来执行。
（2）企业要赋予下游制约上游的机制。否则，压力一定会堆积到下游。
比如，如果测试人员可以拒绝测试质量不达标的产品，就会逼迫开发人员认真对待自己的工作成果。开发人员开发完成某项工作，及时自我测试，很快就会发现问题，及时把问题解决，这样会大幅度提高开发和测试的效率。
（3）企业要重视文化建设。所有跨部门合作中的矛盾，归根结底都是企业文化的问题，因为员工缺少为集体利益而奋斗的意识。
企业文化建设就是建立全员认同的价值观，从而减少内耗，提高全员战斗力。企业文化建设属于企业顶层设计。
（1）合同项目的商业风险比较低，但是利润也低，没有发展前途。有些企业的主业是开发合同项目，在签订合同的时候，能够估算出大致的毛利，觉得可以承接。但是客户的需求经常变化，项目不断延误，无法正常验收。开发者的成本不断增加，利润越来越少，导致开发人员的付出和收获比例失衡。
（2）有些企业开发自主产权的产品，商业模式貌似比合同项目略好。但是自主产品也有很大的风险，如果设计不够好，产品没有吸引力，无法打动消费者，就很难销售，造成库存积压，成本损失严重。
有些复杂的产品可能要到客户现场去实施（如安装、调试和维修），企业一般都会寻找当地的合作伙伴。如果合作伙伴能够赚到期望的利润，他会一直合作下去。反之，如果实施的代价比较高，合作伙伴赚不到期望的利润，他可能很快就会放弃这个业务。
（3）商业模式不好导致开发人员忙碌不停却收入较低。开发人员感觉自己的技术水平没有长进，也看不到前途，结果导致能力强的员工离职，企业损失严重。
企业领导最重要的使命是找到具有竞争优势的业务，设计具有合理利润的商业模式。
如果商业模式较差，那是无法靠勤劳工作来挽救的，必须“断舍离”。因为勤劳虽然可以脱贫，但是很难致富，致富主要靠商业模式。
在企业发展过程中，其商业模式可能会调整。商业模式是很复杂的，一般要从7个方面来研究，包括价值、消费者、产品和服务、盈利模式、供应链、营销、竞争力，如图1-2所示。
图1-2 商业模式的研究图
若要了解更多的商业模式，欢迎读者阅读我的另一本著作《做对：创业决策和执行的历练》。
