地球人都知道IT人喜欢自黑。
经过作者的非常不完全统计，99.9%的IT圈段子，都来源于同一个素材——改需求。
比如下面这个：
这么多关于“改需求”自黑，说明了大家普遍对这件事情感到很无奈。
在如何面对挨骂链底端的产品经理一文中，我说过一个事实：
但这就意味着我们对变更永远无能为力吗？
不是。
这篇文章将一次性解决所有需求变更的问题：
1. 什么是需求变更，这篇文章讨论的需求变更是哪一类？
2. 需求变更这件事，到底是好事，还是坏事？
3. 我们用什么态度来面对需求变更?
4. 为什么需要管理需求变更？
5. 如何高效管理需求变更？
6. 送给大家一个可以拿来就用的需求变更管理流程图。
7. 行动起来，和变更问题做了结！
这篇文章中讨论的需求变更指的是，在计划已经定稿，团队开始工作之后，所有不在当前团队的工作计划中的任务（包括需求）。
包括：
新加入的任务
现有任务的改动
如果是要改动下一个工作周期/阶段的计划，不在这篇文章的讨论范围之内。
如果是在这个工作周期/阶段的计划定稿、团队开工之前做的计划的改动，也不在这篇文章的讨论范围之内。
本篇讨论的需求变更，仅限于已经排好了计划，团队已经开始工作之后，要做本个工作周期中的变动。
需求变更可以分为两类，一类是需求的优化，比如功能优化，性能增强等；一类是需求的往复变更，就是今天要方案A，明天说要改成B，后天又说觉得改成C比较好。
看到这里，有人会说：
我知道我知道！第一类变更是好变更，第二类变更是坏变更！
我还知道，第一类好变更，是优化嘛，改是理所应当的，你怎么说我怎么改！
第二类变更，是坏变更，不改不改，还要把产品经理打20大板，不，50大板！
以上整个思路表面上是正确的，但是本质却是错误的。
今天早上，我的一个同事问了我一个问题：
我思考了一下，回答说：
价值就是用户的真正的需要。 如果我们满足了用户的需要，我们就创造了价值；反过来，如果我们做了很多事情，但是没有满足用户的需要，我们就没有创造价值。
这两类的需求变更，无论是需求的优化，还是需求的往复变更，都是为了更好的贴近用户的真正的需要，所以，这两类的变更，都是好事情。
所以，
找到正确的问题，问题就解决了一大半，到现在为止，我们找到了正确的问题了：
这个问题其实在第2个问题里已经侧面回答过了。需求变更的目的是为了更好的满足用户需要，关乎我们创造的价值大小，所以我们要积极面对。
积极面对包含两部分的含义：一，不抵触或者反对，二，不迎合和欢迎。而是积极的去管理。
如果不管理，就会出现下面的场景：
1各个渠道提出来的变更统一提到产品经理。研发团队只和产品经理对接。
反例1：变更直接提给开发团队，开发团队直接被外部多方打搅，不知道哪些做哪些不做，哪些先做哪些后做，就只能打乱仗。
反例2：开发在工作中自己觉得设计不合理，就自行把原来的定义给改了，连产品经理都不知道。最后验收的时候才发现。
反例3：开发团队直接接收了一个高管的新加入需求，就凭直觉接受了这个需求去做了，结果造成现阶段的交付目标不能按时达成，而这个交付目标是在之前和高层承诺过的。
2产品经理对变更请求进行初步评估，评估第一个标准是：这个变更是否和本阶段的工作目标对齐。
反例1：团队收到一个和本阶段产品发布目标完全没有关系的突发奇想。
反例2：团队收到一个损害本阶段产品目标/与产品目标背道而驰的改动建议。
3产品经理对变更请求进行进一步评估。评估第二标准是：这个变更是否已经定义清晰，清晰的标准是团队清楚理解需求和解决方案
反例：团队收到一个还在概念阶段（缺乏详细定义）的新增需求，边开发边澄清需求和返工，造成本阶段工作目标受到严重影响。
印象派作品《日出》
4产品经理进行初步评估后，变更请求需要团队各方代表进行评估
是否接受变更，至少需要团队的各方代表，包括开发代表，测试代表，运维代表进行统一的评估。如果是属于产品目标的变更，同时还需要投资人，用户代表，和业务方代表参与评估。
反例1：一个项目干系人提出了一个重要的需求，这个需求需要完全地改变本阶段的工作目标，团队在没有向投资人请示的情况下接受了这个变更，导致最后无法满足投资人对本阶段团队工作的期待。
反例2：变更请求未通过团队各方代表评估，直接提给开发去开发，最后交付运营才发现性能无法满足要求。如果在评估的时候就请包括运营代表在内的各方代表评估，就可以在开始开发之前有更周全的考虑。
5产品经理可以提建议，但是由研发团队代表（开发代表和测试代表）负责最终决定是否接受该变更（进入本次迭代）
理论支持：《Scrum指南》，团队是迭代待办列表的Owner。
反例：产品经理说要改，团队就要无条件接受，产品经理说要加需求，团队就要无条件加班完成。导致范围蔓延，交付延期。
6如果研发团队接受变更请求，研发团队可以选择同时请产品经理从当前迭代待办列表中移除同样工作量大小的待办项，产品经理需要按照研发团队的要求进行移除，移除哪些待办项由产品经理决定。
理论支持：《Scrum指南》，团队是迭代待办列表的Owner。
反例：研发团队接受了很多变更，没有提出移除的请求，造成团队常态性加班，带来产品质量风险和团队士气低落。
需求变更管理流程图
关注“轻松做软件”公众号，回复“变更”就可以领取啦。
团队成败，匹夫有责。如果你认同本文的变更管理理念和方法，也希望优化你的团队现有的变更管理流程，你可以做下面的行动：
行动指南
1. 下载第6步的变更管理流程图；
2. 将本文发到你的团队群里，请大家阅读;
3. 组织一个正式的会议，邀请大家对这个主题进行讨论，可以展示下载的变更管理流程图请大家参考；
4. 形成你们团队自己的变更管理方案。
祝你成功！
END
精选文章
需求定义不清？看这一篇就够了（赠需求分析工具箱和需求文档模板）
“轻松做软件”是IT人的效率公众号，不加班必备
科学工作，少走弯路，快来关注吧！
