CMMI软件成熟度模型评估之四：需求开发与风险管理

1、需求是项目的命根子，也是麻烦的源头

  从事咨询这些年，我们总结了一个规律：项目出问题，十有八九根子在需求上。需求没搞清楚就动手开发，做到一半发现理解错了，返工、延期、扯皮、吵架……这一幕幕我太熟悉了。

  需求开发不是简单的“用户说要什么我就记什么”。它是一套从模糊到清晰、从粗放到精细的专业过程。而风险管理，本质上是提前把需求落地过程中可能遇到的各种“坑”识别出来，提前准备对策。

2、需求的三个层次，别只抓了一个

  很多团队搞需求，只做了一件事——收集用户的功能要求，然后就开始写需求规格说明书。其实需求有三个层次，只抓住一个是不够的。

  第一层是业务需求，回答“为什么要做这个系统”。这是最高层次的需求，通常来自高层或业务出资方。

  第二层是用户需求，回答“用户要用这个系统做什么”。这一层要通过调研访谈、工作观察等方式获取，是需求的中间层。

  第三层才是软件需求，回答“系统具体要具备哪些功能和性能”。这是开发团队直接使用的需求基线。

  三个层次层层递进，缺一不可。如果跳过了业务需求和用户需求，直接从“领导说要做一个系统”跳到写功能列表，那大概率做出来的东西和实际需要差十万八千里。

3、需求开发不是一次性工作

  新手项目经理最容易犯的错误，是认为需求开发是项目初期的一个阶段，做完就结束了。事实恰恰相反——需求开发是贯穿项目始终的活动。

需求会随着用户认知的深入而演进，会随着业务环境的变化而调整。敏捷开发之所以受欢迎，很大程度上就是因为它承认了“需求是动态的”这一现实。我建议企业建立需求的分层管理机制：高优先级需求精细分析，低优先级需求概要分析；近期开发的需求详细定义，远期开发的需求保留弹性。

4、风险管理，别只停留在“写个风险登记表”

风险评估时，我问项目经理“你们怎么管理风险的”，很多人的第一反应是掏出一张风险登记表，上面列了十几个风险，概率和影响都打了分，看起来挺专业。但再问“这些风险你们采取了什么应对措施”，就支支吾吾答不上来了。

风险管理的核心不是写登记表，而是把风险处置动作做出来。识别出一个技术风险，就要有技术预案；识别出一个人员风险，就要有人力备份计划；识别出一个进度风险，就要有赶工或范围调整的备选方案。每一条风险都要对应到一个具体的应对措施，并且要跟踪措施的执行情况。

5、需求变更，管好了是保险，管不好是灾难

需求变更本身不是问题——软件本来就是易变的。问题在于变更不受控制。我辅导企业建立的需求变更流程很简单：任何变更请求都要走评估-审批-执行-验证的闭环。评估阶段要分析对进度、成本、质量的影响，审批阶段要由变更控制委员会决策，执行阶段要更新所有相关文档和代码，验证阶段要确认变更确实解决了问题。

流程本身不复杂，难在执行。有些企业流程写得漂漂亮亮，但实际执行起来，“先改了再说、后补手续”的现象比比皆是。这是管理文化的问题，不是流程设计的问题。

厦门格略咨询，企业资质一站式服务平台。13年专业咨询公司，3000+服务案例累计；服务内容：各类ISO体系辅导，CMMI辅导，DCMM辅导，FSC辅导、IATF16949辅导，各类补贴项目申报。

地址:厦门火炬高新区软件园三期集美大道1997号608室

联系电话：0592-6270869

公司官网：www.fjgelue.com