推荐产品需求管理中的需求变更

1、产品需求管理中的需求变更IT 行业中失败项目的比例可以说明“项目管理”是很难做好的事情，项目 失败的原因千千万，我认为需求管理、需求变更管理是个很重要的因素。恰恰 PM 的工作缺不了项目管理，更缺不了对于需求的管理，偶然的原因，和团队分 享了我对于项目进行中 “需求变更” 的理解和管理方法。 忽然发现之前写过很多 产品思考和细节思考的东西， 但从没有整理出方法论， 后续应该多整理下方法论。我认为对需求变更这件事是需要无限关心的，它的目的在于两点： 1，管理需求变更的过程，实际上是不断明确项目目标的过程，是自我完善 的过程。2，需求变更对虚拟团队的打击是 PM 需要避免的，无论是对 PM 的信任

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

3、虚拟团队的沟通效果最重要， 要明确每个人的理解一致。 PM 把自己的调研、 设想、预期描述清楚是第一步，这也是 PM 的必须课。但更重要 的是要明确每个人的理解是一致的。 要知道很多时候不同的人对于同一句话， 同 一个描述段落， 理解很有可能是不一致的， 这必然会导致后续的发展不一致。 因 此团队成员每一个人的理解是一致的这件事很重要， 不光是为了给大家洗脑， 更 重要的是让大家做同一件事。3，越早发现问题越好问题发现的越早， 产生的破坏力越小， 对项目进度的影响也越小。 可行的方 法有很多，随时关注开发进度、进行每日例行站会都是好方法。 PM 的责任当然 不是启动开发后把所有的事情交由项目经

4、理 （或者开发负责人，或者什么人 ）去管 理，正确的方式应该是要不自己就是项目经理， 要不自己也参与项目的管理工作， 最低自己也得随时关注项目的进度。4，积极面对发现问题后不能等待， 要么变更要么放弃， 必须做出选择。 事实上经常会遇 到一些情况，让我们很难去积极面对，比如资源紧张，比如时间紧张，比如麻烦 太大，比如无法向老板交代， 比如无法向同学们解释， 比如会让同学们鄙视等等。 但不作为永远都是下下策， 积极面对是解决问题的唯一出路， 也是必须要使用的 方式。5，及时更新文档文档虽然不是最重要的， 但记录变更非常重要。 无论是对团队成员来说， 还 是对自己来说， 记录变更内容都是非常重要的

5、。 每个人的记忆力都是有限的， 每 次评审都是没有记录的，每次邮件都是杂乱无章的， 每次会议纪要都是不正式的。 唯一正式、可靠的就是需求文档，将变更内容及时更新不但是良好的工作习惯， 也是对项目团队负责人的表现，任何人这样做都会获得别人的尊重。6，冻结时间点需求太多、诱惑太多、 我们每个人都是个完美主义者。 无论是从用户角度出 发，还是从自己的完美癖好出发， 还是从领导交差出发， 好像都需要把事情做到 极致。但极致是需要一步一步来的，为了避免项目延期、成员灰心丧气，我们需 要有个冻结需求的时间点。 同事为了保护团队和项目进度， 要自我严格执行， 任 何时候都反过来想一想， 我自己是不是已经成为了项目失败的原因， 想一想我的 所作所为是不是已经是问题本身而不是解决问题的方法了。7，必要的妥协事无完美，快速迭代得永生。 无论是技术代价还是人力代价， 都是有阀值的， 虽说技术没有实现不了的想法， 人力代价往往也不是问题， 但时间代价是实实在 在的。而且，世界上没有一口吃成胖子的事情，也没有万事如意的情