【光环学友研讨后感】论需求变更的痛点

首页发布时间:2017-07-12 点击: 142次

这是一个沉重的话题,不如从一个笑话开始:有一天一个程序员见到了上帝。上帝说:小伙子,我可以满足你一个愿望。程序员回答:我希望中国国家队能再次打进世界杯。上帝:这个啊!这个不好办啊,你还是说下一个吧!程序员想了想:那好!我的下一个愿望是做项目没有需求变更。上帝摸了摸鼻子:还是让中国国家打进世界杯吧…  

做项目没有变更,这是一个美好的愿望。需求变更是所有程序猿和PM(产品经理和项目经理)的痛点。但是这是不可能的,“项目一旦启动,变更也就随之而来”,既然变更是无法避免的,与其考虑如何避免,不如想想有什么有效的方法来管理项目变更,或者使之向好的方向转变。 

1499840589627059.png 

为什么会产生需求变更呢?为了能够获得项目,销售经理给客户描述的一艘航母的建造方案,方案到了PM手上,经过PM冥思苦想抓耳挠腮并掉了N多头发之后,交到程序猿手里之后,程序猿看到的是一艘五桅帆船。当程序猿准备开始建造五桅帆船,接到BOSS通知,为了抢占市场,需要加快进度完成,并且项目经费有限,苦逼程序猿们只好砍到一些暂时可以不做的需求,只做必要的功能,加班加点之后,终于做成了一艘小船。客户验收时,看到一艘破小船,还是靠人肉的,当然勃然大怒,自然无穷无尽的需求变更产生了,为了抚平客户的情绪,PM不得不接受客户的要求,甚至是无理的要求,于是无尽的加班降临了。 

blob.png

 

在上面的描述中,我们犯了那些错误呢?  

• 需求表达不到位,理解不正确  

需求描述的过于想当然,为了获得市场,失去了自己的底限,没有需求调研、需求分析、需求评审等的坚定支持,客户认可的需求与程序猿理解的需求完全不对路,造成了一艘航母和一艘小船的巨大落差。应该合理控制、规划需求,随意的增加或删减需求,都会产生不良的后果。需求的管理应该让相关人一同参与、共同把握需求。  

• 没有与客户认真沟通需求  

从想法到细节,没有与客户沟通,最后给了客户一个巨大的“惊”喜,如果与客户  

认真沟通过,至少需求变更的后果就会大大的减轻。  

• 没有邀请客户参与  

客户之所以大怒,是因为他认为他看到的应该是一艘航母,而不是一艘破船,这说明在过程中没有邀请客户参与,错过了最后的弥补机会,当产品完成,客户才看到产品,得不到客户认可的产品再辛苦也是枉然。  

blob.png

在最后验收时,我们再次犯了错误,为了不得罪客户,再次放弃了我们的底限,正常应该做的和客户拍脑门加塞的都做了,不仅把自己搞的筋疲力尽,也让公司手忙脚乱。此时,我们应该冷静的思考一下需求变更的合理性:  

• 业务方面  

需求变更通常是因业务变化而产生,所以当变更发生时,也要从业务角度思考,变更是否合理,是否必要,与产品定位是否相符,如果不做是否可以?  

• 技术方面  

变更对开发的影响,需求变更涉及的部分之前是否已经开发?到了什么程度?是否可以通过技术框架的扩容性解决变更?  

• 项目方面  

变更对项目的时间、资源、费用会产生多大影响?是否能够承受?  

分析清楚后,就理清了变更的脉络,变与不变、现在变还是以后变也变的有理有据。然后再设立完整的需求变更流程,自然就能做到防微杜渐、未雨绸缪。  

作为PM,我们天生就是替罪羊,PM夹在客户和程序猿之间,被客户抱怨,被程序猿憎恨。这是PM既定的角色,也是PM要挑战并破解的命运,PM们准备好你们的行程了么?

1499840784801423.png


最PMP常见问题