2.4 如何进行立项评审？

研发项目不仅仅和研发相关，而且跟采购、工艺、制造、销售、市场都相关。如果相关人员未在立项环节参与，项目中存在的非技术类风险就无法提前识别、预防，等项目开展过程中再暴露问题，可能为时晚矣。这样的话，人力、时间、资金的投入可能会完全浪费，或者造成计划之外的极大投入。

前面章节我们讨论了一个立项材料包括市场趋势判断、客户需求分析、产品规格定义、开发执行策略四个步骤，每个步骤中研发工程师都要和市场、销售、采购、制造、财务等各个环节进行沟通，让信息及时传递，听取他们意见，充分讨论后优化立项内容。

2.4.1 立项沟通不充分会带来的问题

在项目中大家可能都经历过以下几个场景。

场景一：产品都要开发出来了，销售还对产品定义和量产时间不清楚销售季度会邀请产品经理们来介绍产品，项目经理们慷慨激昂一番后，销售们炸开锅了：“怎么这个产品我都没听过？什么时候定的要开发的？怎么没有××功能？××产品别家公司早就推出了，我们的产品怎么这么晚？还卖得这么贵，让我们怎么去卖啊？”

场景二：项目开发了很久了，采购才告知研发工程师关键芯片很难采购研发工程师跟项目经理抱怨：“采购一个物料都快一个月了，还回不来？天天要求设计降成本，同样的物料，怎么别的公司的采购人员买回来就便宜，我们家买回来就贵？”采购也跟项目经理抱怨：“研发选的物料太偏门了，独家供应，还是国外的厂家，采购周期预计得这么短，怎么催也买不回来。”

场景三：产品马上要卖了，技术验证的效果不符合预期箱体的密封由密封圈换成了点胶，一体成型，结果密封测试总是通不过，测废了好几台机器，硬件项目经理直接找工艺主管：“点胶密封效果不好，项目的样机都没法进入下一阶段的测试，这些样机都是很贵的，研发费用要包不住了。点胶设备买回来一年多了，技术验证不是说已经好了吗，怎么到产品交付时就不能用了？”

类似的场景，大家在做硬件工程师和硬件项目经理时可能都遇到过。在项目中，硬件工程师和销售、采购、生产甚至硬件内部其他部门会产生误解和矛盾，而大多数误解和矛盾都是因为沟通不充分导致的，各个职能部门从自己的专业角度去思考问题，对项目目标没能达成一致意见。因此，立项评审这个动作不可缺少，在这个环节大家针对任务书内容做集体评审，对项目目标达成一致。任务书就是承诺书，一旦项目立起来了，后续的任务、计划都得跟着承诺书来，大家对目标理解一致，才可能走得快、走得顺，力往一处使。

2.4.2 让大家都参与到立项评审中发表意见

立项评审有序高效，依赖立项流程设计和组织设置。

首先，研发项目不仅仅和研发相关，销售、采购、制造、工艺都应该有代表参与，充分发表意见，如果相关部门未在立项环节参与，项目中存在的非硬件技术类的风险就无法提前识别、预防，等项目开展过程中再暴露问题，可能为时晚矣，人力、时间、资金的投入都可能会加倍。

其次，参与立项评审的工程师和最后的决策者需要有技术背景或具备专业知识，如果决策者不懂产品，也不懂技术，即使开再多的会，也评审不出来问题。虽然我们可以用流程优化管理，但是如果流程的应用者缺乏专业性，将无法胜任流程角色要求。

那么，到底应该由谁来决策是否立项呢？对于重大项目，如新产品和新平台，资源投入大，研发周期长，可以采用集体评审+核心团队决策的运作方式，这种运作需要有组织支撑，下面介绍一种组织运作方式。

（1）成立虚拟组织——“产品管理委员会”，即由相关部门的管理者组成团队，承担立项管理的职责。
（2）产品委员会的成员构成可参考图2.5。（规模不大的企业可以简化模型，减少参与的人数，但是思考维度需要包含以下角色，需要在公司内部针对这些维度进行讨论。）

产品管理委员会主任是这个组织的最高决策者、最强利益相关者，如产品线总裁或企业总经理等，对产品立项进行最终决策；产品管理委员会成员由各领域代表组成，在立项评审的过程中代表各自领域充分发言，提供专业意见；秘书负责整个产品管理委员会的运作，包括议题的收集、材料的预审、会议的组织、遗留问题的跟踪等。

特别注意，千万不能小看“秘书”这个角色，秘书是决定产品管理委员会运作好坏的关键人物，这里的秘书不是公司的行政秘书，而是这个委员会的“书记员”，必须由一个懂产品，执行力和推动力都相当强的人来担任。

产品管理委员会可根据企业的规模、产品的特点进行不同的设置。规模大、产品线多的企业，可以在产品线内部设置产品管理委员会，对本产品线的立项进行管理；如果涉及跨产品线的解决方案的立项，可以设置解决方案管理委员会，对解决方案的立项进行管理；如果企业规模小，产品单一，则整个公司设置一个产品管理委员会足以。

总体原则：参与会议的各领域代表都能代表本领域对这一产品实现商业成功做出承诺，换句话说，如果立项过程中，代表们未能代表本领域提出有效意见，而又在项目开展的过程中出现了问题，代表们是要承担责任的。

为什么需要这么多角色参与呢？主要原因是需要从各个维度对项目是否能够取得商业成功进行思考。小公司如果没有这么多角色，则可以角色合并，但是思考维度不能裁剪。硬件项目跟软件项目不同，硬件项目更依赖供应链，所以芯片、工艺、结构等维度的可行性需要充分分析，在立项阶段，对于硬件项目，硬件框图和数据流等系统设计需要在主项阶段基本明确。所以对于硬件项目来说，除了前面我们明确的“市场”维度的思考之外，还需要考虑采购、制造的维度，避免定义的产品无法批量生产出来。