干货｜如何控制软件需求变更

本文作者：老吴 原文地址：猛戳这里

从主教花园望见的索尔兹伯里大教堂

上图是一副非常有名的画作，名为『从主教花园望见的索尔兹伯里大教堂』，作者康斯太勃尔，英国的著名油画家。某年某月的某一天，康斯太勃尔去他的金主大教堂的主教Fisher先生（后面简称大鱼）家里玩。大鱼主教跟画家先生说：“亲爱的画家，你帮我画一幅画吧。把我和我美丽的妻子以及我这大教堂一起画到画里。我要把画留在教堂，成为镇堂之宝。当然，我是给钱的，于是康斯太勃尔先生很高兴的接下这个项目。

画家开始了辛苦的工作，经过一段时间终于把这幅画完成了。画家画这幅画时可能心情不好，所以在教堂塔尖上方的天空有一片乌云。大鱼主教看到这幅画后，很不满意。虽然画家把主教大人、主教夫人和教堂都画进去了，但是两口子只在左下角露了个背影，这也就忍了。“下面那几头牛是怎么回事，为什么比我们占的镜头还多？”主教问。画家说：“你没看懂？我是在恭维您呢，是说您和您夫人好牛！”，大鱼先生没什么话说了，然后又找到了新的吐槽点：“为什么天空的云都是乌云？”。他邀请画家再去他家做客，重新观察，以便于修改画作。画家很不高兴了，就单独把画展出了。展出之后得到很多好评，于是回信给大鱼主教：“你看，大家都说很好看，不用改了。”，大鱼主教收到信后也怒了，回信就说了一句话：“给我改！！！”。

从回复文字的三个叹号上可以看出——主教很生气、后果很严重。这就是关于需求的故事，请您再看上图，看看教主和教主夫人被画到了哪里？您能找到吗？

从上面案例中您看到了哪些与需求相关的问题？为什么导致客户不满意并被要求重画？

1、需求表达不到位。大鱼教主想要一幅画，画里有他们夫妻二人和教堂，需求表达完后，并没有再对需求进行更具体的说明。除了以上要求外，画作里是否还可以加些其它元素？人物要求画正面还是背面？画作的背景是什么？需要表达什么样的情感？

2、没有与客户认真沟通需求。当主教让画家画一幅画时，最初只是一个想法，并没有太具体的要求。细节需要画家一点点的引导，从而勾勒出画作的轮廓，这个轮廓就相当于产品的原型。与客户沟通好需求并得到客户认可后再开始画作，需求变更的可能性就会大大的降低。

3、需求理解不正确。画家在画作里多画了一些牛，并认为这样会更好，寓意深刻，可以表达出大鱼主教和夫人“很牛”的意思，还根据自己情绪需要将天空画得“乌云密布”。这说明画家没有正确理解客户意图，把需求想当然化了。我们应该合理控制需求，合理规划需求，不能随意的增加或删减需求，这都是不正确的。需求的管理也不应该是一人堂，要有需求评审等需求审核流程，让相关人一同参与、共同把握需求。

4、没及时让客户参与。在画家进行创作的这段时间里，画家并没有邀请大鱼教主来看画作，这也就错过了最后弥补的机会。当整个作品完成后，客户才有机会看到作品，得不到客户认可的产品再努力也是徒劳。

5、不愿听取意见。当客户明确提出自己的意见后，画家还是一意孤行，将作品拿出来展览，这对客户来说是种伤害。即表现出对客户的不尊重，又表现出了自己的自大。这就相当于还没得到客户、相关领导认可时，私自发布产品，它所产生的后果可能是无法想像的。所以，难怪主教生气。

从上面故事可以看出，项目的成败与需求关联非常密切。如果想要做好一款产品，从需求调研、需求分析、文档梳理、需求评审每一步都要走的坚实，不可以走过场。一点的疏忽都可能导致产品的失败，需求变更，也就再所难免。有的需求变更是无法避免的，如客户、领导在产品开发阶段要求增减需求；有的需求变更是可以避免的，如需求调研的不够充分、分析的不到位、评审的不够严格。只要我们更虚心一点、更认真一点，需求管理流程更规范一点，许多变更都是可以避免的。

针对需求变更要早发现、早预防

需求变更避免不了，既然不能避免，那我们就要敢于直面惨淡的人生。引入需求变更管理机制,以降低需求变更带来的风险。需求变更管理的核心是减少变更所产生的影响，而非消灭变更。通过变更管理可以降低开发返工、重工的工作量，以减少项目风险。需求变更属于需求管理范围，同时也属于风险控制范围，对于产品经理要随时关注产品，定期对需求进行跟踪，做到“早发现、早治疗”，以防病入膏肓后才下手。那样，可能癌细胞已经扩散了。对已变更的需求要做到文档标记更新，编写需求变更说明，保证需求与开发工作一致，不要出现“两层皮”的现象。从技术角度考虑，技术架构要做到可扩展，以弹性的架构来解决变更的需求，把变更造成的影响降到最低。

需求变更流程

当发生变更时，正规的流程需要走变更申请，申请后组织人员对变更进行分析、评审，以判断变更是否必要，对项目的影响有多大。又必要又紧急的需求要排到开发计划中，尽快安排开发；对必要不紧急的需求要考虑是否可以放到下一版本安排开发；对紧急不必要的需求，要根据项目实际情况考虑，是否可以不要？对不紧急也不必要的需求应该直接砍掉，无须变更。评审完成后，对于需要安排开发的变更需求，先整理变更需求说明书，以帮助开发人员、测试人员了解变更内容，指导技术人员开发。

如何分析需求变更的合理性？从哪些方面着手？

1、从业务方面分析。需求变更基本都是因业务变化而产生的，当发生变更时，我们也要从业务角度多思考，变更的是否合理，是否必要，与产品定位是否相符，能给产品带来哪些好处？如果不做变更是否可以？

2、从技术方面分析。变更会对开发有多大影响，需求变更的部分是否已经开发？开发到什么程度？工作量多少？是否可以通过技术框架的扩容性很好的解决变更？

3、从项目方面分析。从项目角度考虑，变更会使项目的时间、资源、费用上产生多大影响？影响是否能够承受？本次变更的需求必须本版本开发完，还是可以放到下一版本迭代开发？

从以上三方面分析清楚后，变更的需求脉络也就理清了，变与不变、现在变还是以后变也能分析得透彻。

总结：

需求变更对每一位产品人来说都会经常遇到，产生变更的原因很多，有外在的、有内在的，但不论是因为什么产生的变更，遇到了就要正确的、合理的分析、评估，给项目以正确的指导。如果项目前期进行了大量的调研、跟踪、分析、评审，并请客户尽早参与，许多变更是可以避免的。如果，技术框架设计的可扩展，程序设计的可扩容的话，当发生变更时也可以把变更对项目产生的影响控制到最小。防微杜渐、未雨绸缪，还是那句话：“早发现、早治疗”。最后，以“扁鹊见蔡桓公”的故事结尾。

扁鹊进见蔡桓公，（在蔡桓公面前）站了一会儿，扁鹊说：“您在肌肤纹理间有些小病，不医治恐怕会加重。”蔡桓公说：“我没有病。”扁鹊离开后，蔡桓公说：“医生喜欢 / 习惯给没病的人治病来当作自己医术的功效。” 过了十天，扁鹊再次进见蔡桓公，说：“您的病在肌肉里，不及时医治将会更加严重。”蔡桓公不理睬。扁鹊离开后，蔡桓公又不高兴。

过了十天，扁鹊再一次进见蔡桓公，说：“您的病在肠胃里了，不及时治疗将要更加严重。”蔡桓公又没有理睬。扁鹊离开后，蔡桓公又不高兴。

过了十天，扁鹊（远远地）看见桓侯，掉头就跑。蔡桓公于是/特意派人问他。扁鹊说：“小病在皮肤纹理（之间），汤熨（的力量）所能达到的；病在肌肉和皮肤里面，用针灸可以治好；病在肠胃里，用火剂汤可以治好；病在骨髓里，那是司命神管辖的事情了，（医生）是没有办法（医治）的。现在（病）在骨髓（里面），我因此不再请求（为他治病）了。”

过了五天，蔡桓公身体疼痛，派人寻找扁鹊，（扁鹊）已经逃到秦国了。蔡桓公于是病死了。