需求,是项目经理的紧箍咒。 开发说到需求,项目经理磨破嘴; 甲方说到需求,项目经理跑断腿。 其实需求本身不可怕, 大家怕的是它后面跟着的“变更”。 那么问题来了, 为什么需求会变更? 我堂堂项目经理,还控制不了它吗? 为了签合同不择手段 对客户要求大包大揽 客户:这世间所有的功能,我全都要。 售前:好!可以!没问题! 开发:不行,没戏,实现不了。 客户:我不管,你答应我的,给我改。 三方沟通不顺畅 甲方和开发之间隔着一个宇宙 客户:马冬梅 需求文档:horse winter flower 开发:玛丽莲 客户:??? 启动阶段需求分析不足 给客户留下了钻空子的空间 开发评估:APP识别不了手机壳的颜色!什么XX需求! 项目经理:客户爸爸,APP识别不了手机壳的颜色呀 客户:你怎么不早说?别家都说这个识别不了,就你们没说,我才选择跟你们合作的,退钱! 答应的太痛快 让客户以为变更成本很低 客户:项目经理,有个小需求要改一下 项目经理:您看这个变更流程... 客户:不用不用,小事一桩,一句话就说完了 项目经理:那您说 客户:这版不行,全部重做。 我们是项目经理, 我们不怕变化, 我们怕的是跟不上变化的步伐。 怎样不被变更牵着鼻子走? 这里有6个办法可以参考 把风险提前解决 在签订合同的时候,先约定哪种情况的变更可以接受,哪种部分接受、哪种不能接受。 虽然我们也知道,在签订合同时,我们做不到精确定义每项要求,但合同只要签了,就能具备一定的约束力。在你被客户和开发两面夹击生不如死的时候,或许一份合同条款,就能救你于水火之中。 规范变更流程 流程麻烦吗?麻烦。流程必要吗?必要! 流程就像减速带,为的就是让客户把速度降下来,把脑子跟上去。有些需求变更只适合过过嘴瘾,一旦要写下来,客户自己都觉得浪费墨水。 在审批不合理需求的过程中,客户失去了张口就来的快感,又能意识到需求的不合理性,自然可以减少无效变更。 分级管理变更 当客户的需求变更突破了前面的两层防御,直奔项目经理而来的时候,说明这个需求是非改不可了。 这种情况下我们可以给客户提出建议,把新需求按重要和紧迫程度分档,作为需求变更评估的一项依据,在需求变更会议上专门讨论。 变更会议后,给客户提交一份需求变更计划,告知各项变更可能引起的时间、资金成本,要求客户配合需求变更计划,保证大局稳定。 一般来说,只要客户的需求不是拍脑袋而来,此时就会考虑接受变更的代价;如果变更可有可无,客户就很可能会取消变更。 建立完善的变更管理还有一个好处:即使没有达到最理想的结果,也可以避免项目经理同时遭到客户和开发团队的里外埋怨。 专人负责变更管理 如果有条件,我们也可以专门派一个工作人员管理需求变更,专门负责客户和开发成员的沟通和跟进。 当然这种操作对大部分人手不足的项目组来说,都是比较奢侈的,这里仅作建议,大家量力而行就好啦! 让客户参与需求评审 如果条件允许,我们也可以请客户参与需求评审,作为需求的提出者,他们理所当然是最具权威的发言人之一。实际上,在需求评审过程中,客户往往能提出许多有价值的意见。 同时,这也是由用户对需求进行最后确认的机会,可以有效减少需求变更的发生。 前面说的终归是补救措施,而亡羊补牢,永远比不上未雨绸缪。 要减少需求变更导致的加班,项目经理可以把时间更多地用在前期,尽可能挖掘客户的潜在需求,发现可能会产生变更的地方,让客户在前期确定,是否需要进行相应变更,而系统开始运行后,就不再接受类似的变更需求。 这种做法在合同的约束下,可以发挥出更好的效果。虽然前期会花费较多时间,但能够有效减少后期扯皮,简直是功在当代,利在千秋。 我们都能理解,并不是所有变更都不好,很多时候客户提出的需求,确实能让产品更完善。只是需求万千种,并不是每一种都适合做出来。 摒弃零碎、非必要的需求,规划好必要的、逻辑清晰的需求变更,是我们项目经理的天职,也是责任。 你是谁? 我是需求变更 你从何处来? 从售前、甲方、老板、用户处来 你往何处去? 往项目经理锅里去! |
|