“项目一旦启动，需求变更随之而来”，特别对于软件开发类项目、ODM/OEM类项目尤其如此。笔者接触的研发项目经理中，疲于项目变更甚至因项目变更而“欲仙欲死”的非常之多。为什么这么高比例的项目经理困于变更？主要是因为项目的变更不可避免，而且变更给项目带来的冲击有时候甚至是翻天覆地的，下面以ODM项目为例来说明：

 

 

 

       L公司是一家ODM公司，沐鸣2登录正在进行的是为某大客户提供关键组件的研发与生产项目，项目处于设计开发阶段。项目碰到的主要问题是大客户基于研发功能手板提出了6大项功能改变，同时客户表示由于产品交付需要，项目不允许延期。L公司项目经理经过与开发团队讨论后，发现客户有的变更和最开始提出的需求相互矛盾，有的变更简直无理取闹。如果按照客户要求进行变更，则项目成本大幅上升，同时无法在保障质量的前提下按期交付。大客户对L公司老板多次施压，L公司老板把项目经理叫到办公室，咆哮：“XX大客户对于公司至关重要，必须按照客户要求做，不然……！”

 

 

 

 

 

       看到这个案例，相信做过ODM项目经理的大多都觉得“似曾相识”。一般情况下，这样的项目变更最后的结局不外乎以下两种：

 

 

 

1. 项目团队累死累活，终于达到了预期的交付计划，但是项目的质量惨不忍睹，客户严重不满意；

 

2. 项目团队累死累活，保质量按计划交付客户，最后发现项目成本大幅上升，成了“亏本”项目；

 

 

 

 

 

       而更痛苦的是，发现最后客户并不care之前气势汹汹的变更要求，而这有可能助长客户下次继续随意变更……

 

       项目为什么会有这么多的变更？一般而言有这样两种原因：一种是项目的目标发生了变换，即项目需求变更；另一种是由于项目的内外部环境发生变换而导致的变更，例如新技术/工艺的出现、组织架构/流程的改变等。

 

       项目经理如何避免这种被动的局面？结合多年的项目管理工作经验以及研发咨询管理经验，笔者总结如下：

 

 

 

首先要建立项目需求基线

 

 

       什么是项目需求基线？简单点说就是产品策划团队与项目开发团队最开始共同定义的项目需要满足的客户需求，通常情况下以MRD （Market Requirement Document）文档形式书面记录。如果是ODM类项目，那么这个文档应该是项目团队与客户经过多次沟通后共同定义的项目需求文档。项目经理这个时候最需要花大力气做的一件事就是和产品策划团队逐条梳理、讨论项目需求，召开正式需求评审会议并“签字画押”。为什么要这样慎重？就是为了保障项目需求基线的严肃性，从源头严把关。

 

       如下图，虽然无法避免变更，但至少我们要在前期多挖掘客户深层次的需求，以减少后期的变更。

 

 

 

       可能有的项目经理会说“ODM项目，大客户不配合建立需求基线咱也没办法”。对于这样的情况，笔者建议：

 

 

 

1.在项目启动前和客户建立项目沟通接口人，这样做的好处是降低沟通成本，沐鸣2注册避免客户信息输入纷杂，同时客户项目接口人一般会是比较专业的人，不会胡搅蛮缠；

 

 

 

2.客户不愿意提供需求文档，很多时候是客户没有想清楚或者懒得想。那么项目经理要做的是主动提供一份需求文档样例，反复和客户方的关键人员进行需求沟通、讨论。“磨刀不误砍柴工”，项目经理切记这个时候一定要咬住客户，不能放松；

 

 

 

3.客户认可了需求文档后，一定要形成正式文档，要求客户签字确认。为什么一定要签字？有两点原因：一是签字可以追溯，免得后期有争议时缺少依据；另一个原因是一旦要求客户签字并且签字文档发送到客户方高层，那么客户提需求的时候就会谨慎，至少不会提无理取闹的需求。

 

 

 

其次是沟通需求变更目的

 

 

       简要说就是大家坐下来讨论为什么要变更？是不是真的有必要？变更后给项目带来的变化有哪些？变更是否值得？是否批准等。

 

       ODM类项目客户提出变更怎么办？项目团队还是要先评估变更带来的影响，然后和客户坐下来沟通。先要搞清楚客户为什么要变，变更的根本目的是什么？不变更或者用其他的方式能不能达到目的？如果客户确实需要进行需求变更，那么需要向客户明确需求变更后带来的改变（时间、成本等），必要时要求客户承担项目变更的成本。一旦涉及到项目成本增加，客户大部分情况下会慎重一些，因为他也有领导。

 

 

 

最后是规范项目需求变更规则

 

 

       没有规矩不成方圆，若没有严格的变更管理规范，会让人产生“我想变就变”的轻松感觉，有了严格的变更规范，在变更前就得好好思量一下。项目变更规范一般包括这样的内容：需求基线的建立、谁可以提出需求变更申请、谁来评估需求变更影响、谁来决策是否可以变更、谁来批准变更、谁追踪变更结果等。

 

       所以对于项目的需求变更需要严格控制，有了规范的流程就能够避免文中最开始提到的案例中的不愉快局面。

 

       对于花很少时间进行需求管理的项目经理来说，非常有必要先放下忙碌的项目，构建一套系统的需求变更管理规范。花更多的时间了解、沟通前期项目需求，从源头上进行控制，项目过程就会风险越小，“惊喜”越少。