坊间流传一句话——“杀一个程序员不用枪，改三次需求就可以了”。问君能有几多愁，恰似调完代码改需求。需求变化是程序员眼中最大的痛，没有之一。
对程序员来讲，最理想的情况是，需求定下来后，直到软件交付都不发生一次变化。然而，需求的变化却是客观存在，无论你接受与否，稍微复杂点儿的项目，需求变化都是难以避免的事。所以，我们既要了解需求为什么说变就变，又要修炼面对需求的心态，，还要知道怎样控制需求变化。
老板为什么老调整需求
有位朋友在微信的一个群里问我：
安老师，如何保证项目进度呢？目前我们采用Scrum敏捷开发，分配的任务卡，还没等写完……需求就调整……告诉老板一个冲刺内尽量不要调整需求，可老板还是停不下来……
你是不是也有这样的老板？说好的需求不动了不动了，结果隔上半天就跑过来说“我们必须得调整一下，这个功能做成这样，那个砍掉，再加一个这个”……
为什么老板总在变？
我想你也知道原因的：
老板才是真正一心想要做好产品的那个人，才是日思夜想不断琢磨怎样把产品做好的那个人。他的思考一刻也不会停下来，他总是自发的去探寻、求索、完善自己的想法。他是那个没人催促也要自我燃烧的人。
所以，他比我们捉急，比我们更担心错失某个好点子、做错某个需求、做了无用的功能，所以，他总是想要不断调整来逼近他心中的最佳。
而我们呢，其实没老板那么把产品当回事儿，其实是不自觉地想着自己方便，越方便越好，最好需求定下来一年都不要变。
正因此有这样心态上的差距，所以冲突就起来了：我们总觉得老板反复无常，老板总觉得我们不尽心尽力拒绝把事情做好。
破除私心，拥抱变化
现在我们知道老板为什么不断调整需求了，那我们再来看看我们为什么不愿意接受需求变化。
前面说我们没老板那么全心全意、不惜一切代价想把产品做好，所以我们的心态和老板的心态有较大差距，所以不能理解老板为什么频繁对需求进行调整。那其实呢，我们并不是因为不想把产品做好才拒绝需求变化的。
我们拒绝需求变化，一方面是出于执行层面的考虑：
- 担心需求变来变去，不能按最初约定的时间点交付
- 认为自己已经投入时间完成了某些需求，变化会导致自己投入的精力浪费
- 因为调整需求，会导致设计、实现等多方面的变化，给自己带来更多工作量
另一方面也有心理上的原因：
- 当因为需求变化而扔掉已完成的代码时，认为自己的付出没有价值，也认为自己的劳动没有得到认可和尊重，心理上是拒绝的
- 喜欢计划和秩序，不喜欢自己的节奏被中断
- 认为老板本人脑子进水，做事没规划没常性，不考虑他人感受，本能的就对老板变更的要求抱有拒绝态度
- 拒绝变化（无常），总担心可能这个会有错那个会不好或者这样变会失去什么，心有焦虑
不管是哪方面原因，其实深思一下，你就会发现：你是因为过于关心自己的感受、不想勉强自己难受才希望需求不要变化。
也就是说，我们面对需求变化，心理和行为模式是这样发展的：
- 需求变化
- 我得要调整、舍弃、重做，我不爽
- 我要拒绝
- 拒绝不了，心生埋怨，消极对抗或四处埋怨
我有时就是这样的，你呢？
假如我们能穿上老板的鞋子走一走，可能就会得出不一样的结论，可能就会认为需求变化是可以接受的。
假如我们把自己的感受放下，将如何把产品做好放在第一位，可能就会理解需求变化，拥抱需求变化。
一件事情发生或，你的感受和压力，往往源自于你在思维层面对事件的解释。假如你改变了思维，改变了自己解释事件的逻辑，那原本让你感到不爽的、难受的、拒绝的，可能就会让你欣喜、赞同。
我们这么讲，是不是就是说，我们要毫不犹豫地接受一切需求变化呢？
非也！
控制需求变化
我们破除思维上、思想上、心理上对需求变化的抗拒，并不是为了让变化随意发生，而是为了使产品更好，所以，我们还要从实际上控制需求变化。
稻盛和夫在《干法》中有八个字，说了我们做一件事时应该持的态度：“动机至善、私心了无”。非常赞啊，不能比赞更赞了。
前面我们讲“一个人拒绝需求变化往往是因为私心，要拥抱变化，就要放下自我”，也是一样的道理。
当你放下了私心，没有自我，只有大道时，你就可以客观地看待一个需求，客观的分析它是不是为产品好，是不是对公司有益。当你以这样的基点来和老板讨论需求时，你拒绝某个需求，就不是因为它让带给实现层面的麻烦，就没有私心，没有情绪，就更容易与老板达成一致。
有了态度上、思维上的转变，就有可能优雅地拒绝不合理的需求。
那么当我们与老板商榷需求是否要被纳入当前的开发计划中时，有几种方法可以参考：
- 目标整理
- 后果揭示
- 优先级重排
一个一个简要介绍一下。
- 目标整理
老板提出新的需求或变更已有需求时，往往伴随着目标变化。此时我们需要重新整理项目或产品的目标。
你可以先问自己，老板这么做的目的是什么，我们产品的目标是什么，两者什么关系。当你想不明白，或者觉得新需求（需求变更）对产品目标害处多于好处时，你可以接着与老板沟通。（如果相反，接受就很自然）
你可以询问老板，这么做的目的是什么，我们这个产品的目标是什么，老板自然就会思考，这个新的需求会不会影响原来的目标，有没有必要做。如果他想一想，哦，这个需求没卵用，那他自然会取消。
如果老板觉得还是有必要加入这个需求，那你可以接下来和老板谈你的理解。有一个方法，你可以在白板上来对比，左边列出老板的想法，右边列出你的想法，请老板帮你看看是否你的理解存在问题。这样一对比，就容易找到差距，就容易统一认识。
这样的目标整理方法，有的是事实、分析、数据，没有私人情绪宣泄，通常都可以帮助我们和老板形成一致的目标。
- 后果揭示
假如很难和老板达成一致，而你又觉得老板的做法不妥，那你也可以把你的担忧理一理，把添加某个需求可能产生的后果推演出来给老板看。这种做法就是后果揭示。
有时老板不想改变他的想法，仅仅是因为我们没有触动他，没让他产生改变的动力。当老板能看到他的做法对产品的不良后果时，他会比谁都愿意放弃这个新增的需求——因为他比任何人都更愿意把自己的产品做好。
- 优先级重排
假如大家都觉得新增的需求很合理，那还有另一个问题：交付时间。原本评估一个月交付，加了需求后，可能需求两个月，而老板不能接受这个时间点。怎么办？
此时你就可以把手上的事情列出来，A、B、C，各有多大工作量，你有几个人，张三、李四、王二、马六，每个人做什么。新增需求需要多大工作量，什么时间才能开始做。然后就是事实：如果要加这几个需求，别的功能就会后延。再然后就可以请老板帮你来排A、B、C、D这些事项的优先级，老板排一排优先级，可能就会主动把新增的需求D放弃或延后。
福利，送书
这次送的书是《人人都是产品经理》，关注我的订阅号“程序视界”（微信id：programmer_sight），点击公众号底部的我可以菜单，选择查看历史消息，找到本文（最新一篇），即可参与活动。
