IT行业中失败项目的比例可以说明“项目管理”是很难做好的事情，项目失败的缘由千千万，我认为需求管理、需求变更管理是个很重要的要素。恰恰PM的任务缺不了项目管理，更缺不了对于需求的管理，偶然的缘由，和团队分享了我对于项目进行中“需求变更”的理解和管理方法。忽然发现之前写过很多产品思考和细节思考的东西，但从没有整理出方法论，后续应该多整理下方法论。

我认为对需求变更这件事是需求无限关怀的，它的目的在于两点：
1，管理需求变更的过程，实际上是不断明确项目目标的过程，是自我完善的过程。
2，需求变更对虚拟团队的打击是PM需求避免的，无论是对PM的信任度，还是对于本身的波折感，都很重要。

我整理的需求变更循环如下：

1，需求质量
需求包含调研过程、沟通过程、文档产出等内容，PM前期需求尽可能的想清楚、表达清楚，包括大局、节拍和细节。需求质量的高低能够对后续的变更起到决定性的作用，芜杂无章、漏洞百出的需求必然会导致无尽的需求变更。但需求质量也并不是绝对的，要看项目，看开放方案，对于敏捷开发来说，质量要求也许70分就够了，快速迭代才是硬道理。对于严重项目，也许要80分才能过各级的评审。但无论如何60分是必须的，需求达到一定质量才能立项进入开发阶段，这也是普通情况下采取的项目评审方式。

2，团队理解分歧
PM团队、项目虚拟团队的沟通效果最重要，要明确每团体的理解分歧。PM把本人的调研、设想、预期描述清楚是第一步，这也是PM的必须课。但更重要的是要明确每团体的理解是分歧的。要知道很多时候不同的人对于同一句话，同一个描述段落，理解很有可能是不分歧的，这必然会导致后续的发展不分歧。因此团队成员每一团体的理解是分歧的这件事很重要，不光是为了给大家洗脑，更重要的是让大家做同一件事。

3，越早发现问题越好
问题发现的越早，产生的破坏力越小，对项目进度的影响也越小。可行的方法有很多，随时关注开发进度、进行每日例行站会都是好方法。PM的责任当然不是启动开发后把所有的事情交由项目经理（或者开发担任人，或者什么人）去管理，正确的方式应该是要不本人就是项目经理，要不本人也参与项目的管理任务，最低本人也得随时关注项目的进度。

4，积极面对
发现问题后不能等待，要么变更要么放弃，必须做出选择。理想上经常会遇到一些情况，让我们很难去积极面对，比如资源紧张，比如时间紧张，比如麻烦太大，比如无法向老板交代，比如无法向同学们解释，比如会让同学们鄙视等等。但不作为永远都是下下策，积极面对是处理问题的独一出路，也是必需要使用的方式。

5，及时更新文档
文档虽然不是最重要的，但记录变更非常重要。无论是对团队成员来说，还是对本人来说，记录变更内容都是非常重要的。每团体的记忆力都是无限的，每次评审都是没有记录的，每次邮件都是芜杂无章的，每次会议纪要都是不正式的。独一正式、可靠的就是需求文档，将变更内容及时更新不但是良好的任务习惯，也是对项目团队担任人的表现，任何人这样做都会获得别人的尊重。

6，冻结时间点
需求太多、诱惑太多、我们每团体都是个完满主义者。无论是从用户角度出发，还是从本人的完满癖好出发，还是从领导交差出发，好像都需求把事情做到极致。但极致是需求一步一步来的，为了避免项目延期、成员灰心丧气，我们需求有个冻结需求的时间点。同事为了保护团队和项目进度，要自我严厉执行，任何时候都反过来想一想，我本人是不是曾经成为了项目失败的缘由，想一想我的所作所为是不是曾经是问题本身而不是处理问题的方法了。

7，必要的妥协
事无完满，快速迭代得永生。无论是技术代价还是人力代价，都是有阀值的，虽说技术没有实现不了的想法，人力代价往往也不是问题，但时间代价是实实在在的。而且，世界上没有一口吃成胖子的事情，也没有万事如意的情况。妥协是必要的甚至是每天都要面对的，妥协并不是放弃，而需求细心的思考和规划。也许之前考虑的就不成熟，也许后续可以更好的安排。

8，事后总结，才能进步，避免重蹈覆辙。

http://daxu.net/archives/1333.html