案例：需求你先做吧，我去和客户确认！

场景：

同事cdw大半年在业主方现场工作，负责开发的工作，在此之前和他有两次在现场一起进行性能优化的合作，难得在公司见到了他，和他聊了最近的工作情况。cdw和我介绍了他最近的工作情况，其中也提到本周内他已经开始带3个同事进行开发工作，和以前相比，除了自己开发工作外，已经需要进行一些管理的工作，并形象地比喻，说他自己目前需要从单核CPU改进成多核的。

在聊的过程中，他询问了本周管理工作中发生的一个现实问题：“需求变更如何控制，我带领的3个同事目前的设计和开发都是针对需求1.0版本，但是项目组中负责需求的同事需求已经更新到2.0版本！”，并告诉我：“这周我们因为这个问题，导致了包括我在内的4个人1天开发推倒重来。”，询问：“应该怎么办？”

分析：

从他的谈论中，我们可以发现问题的源头有几个。

第一，整个项目小组Split在不同的地点进行办公；好比我们编写进程间通讯，是需要事先进行约定，是Shared Memory File，还是选择用Named Pipe，还是TCP/IP通讯。所以问题不在于另一项目组有没有把信息Push给负责开发的cdw，也不在于cdw有没有及时将设计开发的进展Push给需求的同事，在于小组在工作初始化的时候，没有定义沟通约定。如果项目组的补位、相互监督检查的意识不足，都会让项目组的虚耗增大！

第二，我询问了他为何在需求可能不稳定的情况下进行设计和开发？cdw说当时他没有发现可能存在不明确的地方，而且需求的同事说：“需求你先做吧，我去和客户确认。”，所以他更加以为没有问题。我的回答是，既然你们当时都认为没有问题，现在问题真真实实摆在面前，原先认定没有不会出现的问题现在出现，按照CMMi的精神，你们应该重新坐到一起，分析当时大家都忽略了什么，变更的Impact在那些原先没有考虑的地方，这种情况以后如何在工作中辨识出这种风险，有了规律就能避免在下面的阶段重蹈覆辙，否则，你们还会再次吃亏！

我给同事cdw的建议是：

1. Work Together!无数成功的项目经验告诉我们，这样规模的团队应该工作在一块！减少项目沟通的成本应该做为一个组队原则被尊重；
2. 需求是需要进行Risk分析的，我有理由相信小组之前的Requirement Analysis 还不够细致，在需求分析过程中，如R1可被分解成R11、R12、R13，假设R11、R12的风险级别才2级，R13的级别是5级，那么整个R1的风险将可以被评为5级；同样，如果R1依赖于R3，如果R3的风险级别是5级，那么R1的风险就不能只是原先的5级；
3. 迭代是允许的，但是如果没进行Risk Analysis就盲目认为需求不会进行变动，是一个很不理智的行为；
4. cdw刚从事一周的管理工作，要特别注意开发的3个同事，他们各自的能力强弱在那里？安排工作不是分猪肉，没有安排好也会加大项目组的虚耗；