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

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

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

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

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

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

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

结项是产品的另一个起点

通常,一个产品项目完整的周期包括前期调研、立项、需求文档、开发、测试、部署等。其中,用户、销售、市场可能需要参与前期的调研和需求;开发到部署主要由技术部门负责;而产品经理负责整个产品项目的周期。虽然结项是这个周期的结束,但实际上项目的结项也是产品另一个周期的起点。

1、试用期-完善产品
试用期对绝大多数新产品来说都是必须的。产品本身是为需求而设计开发,最终还要回归到用户中去检验这种需求是否被满足。特别是对于技术主导的网络、软件等IT产品而言,试用期可以很好的检验这种新技术的价值;而没有试用期的产品是危险的产品,就像新研发的药物没用经过活体实验及持续不断的跟踪观察一样。
通常,试用期阶段的产品能反馈给产品经理绝大多数的 BUG 或需要再次完善的地方,如果持续关注和改进,产品本身也会不断完善,直到被用户认可。一般这个周期是三个月。

2、应用期-改进产品
在应用期前,产品应该已经能够满足用户的基本需求。其中,除了对产品正常的维护外,最需要关注的就是用户体验。在产品开发周期中,如果在用户体验方面已经足够关注,这里应该能节省绝大多数的时间,但这并不意味着你不需要对用户体验在做关注了,因为产品团队并非用户本身,真理也需要实践的检验,何况是你的产品?当然,如果这个产品在开发周期中从未关注过用户体验,那么相信这个产品已经被抱怨淹没了。你的产品是以用户为中心的吗?能用-有用-易用-好用……改进有很长的路要走。

3、升级-让用户知道你在进步
你的产品不是真金白银这种硬通货,在竞争如此激烈的今天,一成不变的产品再完美,也会转眼成为昨日黄花,时刻保持危机感,定时或不定时升级你的产品,哪怕仅仅像新款牙膏只是将牙膏口开得大了点这样的升级,也会使你的用户感到,你非常重视他们,这很可能意味着忠诚度的提高。

以上是最近做的两个项目下来的切身感受,一点浅见,适用于互联网产品以及软件产品多些,有不完善的地方,还望大家指教。