比变态需求更变态的事情

廉正之勤

问：什么比变态的需求更变态？
答：需求变更。
开发说需求，项目经理磨破嘴；甲方说需求，项目经理跑断腿。需求变更应该是最令让项目经理头疼的事情了。
老板改想法、预算有变化，在付出了大量时间、精力后，临时的需求变更，导致不得不重新修改设计、重写代码、修改测试用例、调整项目计划等，导致进度延迟，大家都会感到烦躁。
为了尽量避免这种情况的发生，缩减因为变更而产出的高额成本，就要了解需求变更的原因，针对各阶段的变更给出相应的解决办法。
需求变更的原因

01 需求定义不明确
当客户提出需求时，要学会判断客户给出的信息，有时候客户觉得他讲明白了，但其实他没说明白，你没听明白。就开始根据客户模糊的概念总结进行需求分析细化，这样就会造成细化后的需求并不是最初的客户需求，造成偏差。
前期的需求分析做得越好，基准文件定义的范围越详细清晰，后期的“麻烦”也就会越少。
02 需求理解有偏差
开发者也有可能对客户需求理解错误或者开发团队内部沟通时、人员更替时造成的信息偏差。有沟通的地方，就有“误会”。在整个沟通过程中，尽量避免信息差，也会减少后期的变更。
03 缺少指定需求基线
需求基线是指是否容许需求变更的分界线。对于需求变更，一味选择无条件接受，指定是不行的，要明确不可更改的需求范围，例如在软件整体结构已经设计出来后，是不容许改变需求范围的，避免影响整个项目的进度和成本。随着项目的进展，容许的变更的范围将越少。
此后每次变更并经过评审后，都要重新确定新的需求基线，做到小需求可以变更，但大方向要力保不频繁变更。例如，对于项目中的需求，可以实行分级管理，以达到对需求变更的控制和管理。
在与客户签订合同时，可以增加一些相关条款，规定何种情况的变更可以接受、部分接受或拒绝，还可以规定发生需求变更时必须执行变更管理的流程。明确需求变更会带来的后果，看客户是否可以承担后果。
需求变更控制流程

1 明确问题
当客户提出需求变更时，了解客户的目的。
2 书面申请
申请书上要清晰描述需求变更的内容，并包括客户的签字确认。
3 判断变更需求类别
需求产生的原因，分为功能变更、设计调整、范围扩大、工期变动、产品原因和其他。
4 评估影响
评估变更所造成的影响，范围、进度、成本、质量等方面。
5 判断变更的紧急级别
从以下内容中选择：很紧急、紧急、一般，以该问题或需求对项目的影响程度和需求完成的时限来划分。
6 沟通确认
就变更影响，与客户进行沟通，达成共识。
7 明确解决方案
针对变更内容，提出相应的解决方案。
8 审批管理
向CCB（变更控制管理委员会）提交正式申请，召开变更控制会议，做决策，是接受变更，还是拒绝变更。
9 执行变更
把审批的结果告知相关人员，并执行与跟踪变更的执行情况。
10 版本控制
记录变更的全过程，这是项目过程可控的重要保证。

微山湖

56个项目管理资料：http://hzqinghui.mikecrm.com/uFDHpT8