神刀安全网

软件需求总变更,我要如何控制?

需求变更对每一位产品人来说都会经常遇到,产生变更的原因很多,有外在的、有内在的,但不论是因为什么产生的变更,遇到了就要正确的、合理的分析、评估,给项目以正确的指导。如果项目前期进行了大量的调研、跟踪、分析、评审,并请客户尽早参与,许多变更是可以避免的。

软件需求总变更,我要如何控制?

软件需求总变更,我要如何控制?

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

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

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

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

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

1、需求表达不到位

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

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

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

3、需求理解不正确

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

4、没及时让客户参与

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

5、不愿听取意见

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

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

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

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

需求变更流程

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

软件需求总变更,我要如何控制?

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

1、从业务方面分析

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

2、从技术方面分析

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

3、从项目方面分析

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

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

总结

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

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

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

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

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

本文由 @产品人老吴(微信公众号:ChanPinLaoWu) 原创发布于人人都是产品经理。未经许可,禁止转载。

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 软件需求总变更,我要如何控制?

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址