需求变更-要效率还是要规矩?

需求变更在项目管理中是经常遇到的问题,特别是当项目进展到尾声时,一个需求变更对成本产生的影相往往比项目初期成几何级放大。虽然我们在需求阶段细致入微,在开发阶段滴水不漏,在流程管理上规规矩矩,但无奈的是,我们的客户总是希望拿到更完美的产品。于是乎,变更就成了结项后的潮水,一波一波,无休无止。不是你的产品坏,是这个世道变化快……

如何对需求变更做科学的规划和控制?在做好需求变更管理的前提下,分级管理客户需求不失为一种很好的方法。但是如果客户的需求变确实需要在将要结项得产品中尽快体现时,应该如何处理呢?特别是一些在需求中非常重要,但从技术上很好实现的需求变更时,是否还要走正规的需求变更流程?要效率还是要规矩,就成了许多产品经理心头的疑问。

首先,需要确定:是否真的需要走需求变更流程?灵活点说,需求是变了,但走不走这个流程是另一码事。如果项目几乎结项了,这时的需求变更就像百米赛跑后,裁判说这个跑道不标准,少跑了一米要重新跑一样;一鼓作气后,项目团队都疲惫不堪时,再次击鼓的效果可想而知。其实针对这时需求的变化,特别是技术上很好处理的问题,直接在结项后作为升级内容即可;毕竟版本得改动可小可大,小的版本变更从流程上讲要比需求变更简单的多;

其次,还有一个偏方,是我最近经历的项目变更得解决方案,即将这个需求分解放在其他相关项目中完成。在项目日程已经排满,并且项目间有一定相关性时,这不失为一种好办法。如果项目是迭代设计的,那么采用这种办法再合适不过了;

最后,当非变更不可时,如果没有针对不同变更得不同流程得话,唯一要做得就是做好前后沟通了。在有正规流程时,走正规流程是必须的,也只有这样,项目才能真正可以控制。如果对流程不满,除非能够很快吧流程修改或完善了,否则一步一步做吧。所谓得追求效率而抛弃规矩,是对项目不负责任的原则性问题。

需求变更就像误差,可以控制,但又无可避免;但是因为前期工作没有到位而引起了需求变更,就太不应该了,错误是不应该出现的。出现需求变更时,先不忙着救火,而是冷静下来先考虑问题产生得原因,比做救火员要有意义的多。后面会详细讨论这个问题。

分享到: