《呐喊》

挪威画家爱德华 蒙克的名作《呐喊》。2012年5月3日，在纽约苏富比印象派及现代艺术专场拍卖上，以1.199亿美元拍出。

其实，这幅画另有一个不为人知的故事。

故事是这样开始的：蒙克先生是位当地小有名气的画家，是那种心怀诗和远方类型的。只是，生活确实需要面包和牛奶，经常需要给一些体面的客户画画肖像来苟且一下生活。

话说，那天来了一位客户康佛星先生（Mr. Confusing），貌似很好说话，要求也不高，希望在家乡海边的栈桥上画个有风景的肖像，寄给已经举家搬去新大陆的老舅和舅母。有人，有桥，有海景风光就好。

蒙画家早上吃的面包可能有些过期，一阵子内急。心想，小活儿，一个人月肯定能搞定，也就没有再和康先生细聊。送走客人，买了些颜料纸笔，就开干了。转眼一个月，画作完成，镶了框子，满心欢喜的把康先生请了来，盘算着验收尾款一起收了。完了活儿，能到隔壁亨利的酒馆喝上两口，顺便理一下自己遗世大作的创作思路。

站在画布前，康先生的脸色却不大好。人画的太小了，老舅能认出是我吗？旁边那两个人算什么？又不是我们family的！还有，这个天空，太TM暗了，怎么向远在天边的老舅传递正能量呢！高端，大气，上档次。就这么点要求嘛！三个小时过去，在一堆问号惊叹号后，画面百分之九十的面积被标上了槽点（bug），蒙克画家成了懵客画家。改吧。

又这样来了几次。吐槽，修改，再吐槽，再修改。一晃，就是大半年。画面越改越乱，蒙画家也都快忘了自己的诗和远方。在一个风雨交加的夜晚，蒙画家从亨利酒馆蹒跚着回到了自己的画室。刚才康先生取消合同拒付款项的决绝的话语，彻底激怒了画家内心压抑半年的愤懑，任颜料在纸面上涂抹着。

不久，贫病交加的蒙克先生去世了。这个画“残了”的稿子，被和杂物一起堆在了墙角，画面的一角露出了“呐喊”两个字。

（啊哈，上面的历史是小编杜撰的，不过，这样的场景在咱们每天软件开发的公司里一次又一次的发生着）失败案例和反思

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

1、需求表达不到位

康先生要一副带风景的肖像画，需求表达完后，并没有再对需求进行更具体的说明。除了以上要求外，画作里是否还可以加些其它元素？人物要求画正面还是背面？画作的背景是什么？需要表达什么样的情感？

2、没有与客户认真沟通需求

当康先生让画家画一幅画时，最初只是一个想法，并没有太具体的要求。细节需要画家一点点的引导，从而勾勒出画作的轮廓，这个轮廓就相当于产品的原型。与客户沟通好需求并得到客户认可后再开始画作，需求变更的可能性就会大大的降低。敲黑板：内急的时候不要安排和用户沟通需求。

3、需求理解不正确

画家在画作里增加了几位背景人物，并认为这样会更好，更自然，还根据自己情绪需要将天空画得“乌云密布”。这说明画家没有正确理解客户意图，把需求想当然化了。我们应该合理控制需求，合理规划需求，不能随意的增加或删减需求，这都是不正确的。需求的管理也不应该是一言堂，要有需求评审等需求审核流程，让相关人一同参与、共同把握需求。

4、没及时让客户参与

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

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

我们身处软件工业时代这个令人振奋的时代，却面临着遗留系统这个令人尴尬的难题。事情总是这样的：软件最开初开发的时候总是非常清晰，清晰的需求、清晰的设计、清晰的代码，清晰的程序结构让人赏心悦目，甚至有些自我陶醉。

随后，软件开始需求变更，每变更一次软件的质量就下降一次。这样，软件经过数次的变更以后，需求文档变得模糊不清，设计思路跟不上变更的脚步，程序代码则随着业务逻辑的复杂而臃肿不堪，程序员开始读不懂代码，软件开发工作变得不再是一种乐趣。随着时间的推移，经过数年、数十次的需求变更，情况变得越来越糟，软件质量像滚雪球一样直线下降。

针对需求变更要早发现、早应对。

需求变更避免不了，既然不能避免，那我们就要敢于直面惨淡的人生。

引入需求变更管理机制,以降低需求变更带来的风险。需求变更管理的核心是减少变更所产生的影响，而非消灭变更。

通过变更管理可以降低开发返工、重工的工作量，以减少项目风险。

需求变更属于需求管理范围，同时也属于风险控制范围，对于产品经理要随时关注产品，定期对需求进行跟踪，做到“早发现、早治疗”，以防病入膏肓后才下手。

对已变更的需求要做到文档标记更新，编写需求变更说明，保证需求与开发工作一致，不要出现“两层皮”的现象。从技术角度考虑，技术架构要做到可扩展，以弹性的架构来解决变更的需求，把变更造成的影响降到最低。需求变更流程

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

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

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

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

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

需求变更对每一位产品人来说都会经常遇到，产生变更的原因很多，有外在的、有内在的，但不论是因为什么产生的变更，遇到了就要正确的、合理的分析、评估，给项目以正确的指导。

如果项目前期进行了大量的调研、跟踪、分析、评审，并请客户尽早参与，许多变更是可以避免的。

如果，技术框架设计的可扩展，程序设计的可扩容的话，当发生变更时也可以把变更对项目产生的影响控制到最小。

防微杜渐、未雨绸缪，还是那句话：“早发现、早治疗”。

PS. 祝同学们六一儿童节快乐！（故事咱们就不当真了哦）

广告时间

智城外包网，连接需求与服务，很靠谱

六月送好礼，免费专家坐堂，需求诊断，预算省一半。