场景再现
=====================
BOSS:这么巧,你也在这儿喝咖啡。
小 王:是呀,您这是刚刚开完会?
BOSS:嗯,刚刚送走了客户,忙里偷闲,来这喝杯咖啡。
对了,你手头那个项目结束没?好像延期两次了,没问题吧?
小 王:没问题,就是发生了一些变更,导致了两次延期。
您放心,所有的式样变更都遵守着CCB(变更控制委员会)制定的流程办事,都是客户签字认可的,同时也会追加相应的成本。
BOSS:延期两次,客户没有什么意见吧?
小 王:没有,因为所有事都是通过流程、程序办的。推迟截止日期都是得到客户最终认可的,客户那边没有什么意见。
BOSS:那就好。
{说罢,BOSS转过身去,皱了一下眉头,渐渐的走去.......... }
=====================
场景中的亮点,并不是{小王}如何管理突如其来的式样变更,而是BOSS转过身去,隐隐约约感觉到一种潜在危机而皱了一下眉头。
IT界的朋友对“式样变更”一词并不陌生。
如果哪位朋友站出来说 “我经历一个没有式样变更的项目”。
我只能回复到 “这是一个不完美的项目”。
有很多管理者,每一天在纠缠着各种各样的式样变更中,这些突如其来的式样变更会使原有的计划变得“千疮百孔”。有规模的组织会成立CCB,来管理每一次变更请求。CCB负责评估那些被提交上来的变更请求,针对这些变更的目的、要求、项目要素(成本、范围、时间、质量等)和影响来决策是否实施这次变更请求。
正如场景那样,客户答应你所提出的各种要求(项目需要延期、项目需要追加成本),想必多数管理者会像{小王}一样,调整计划、实施计划、监控计划,最后保证项目保质保量的Release就OK了。(我也是多数中的一员)
有一次我接手一个项目,前期做调研时候,我发现客户在业务上对截止日期的要求不是很严格,很模糊,我只是大概知道一个时间范围。
调研结束后,后续的工作就陆续展开,项目起始周期也就定格在这个时间范围内,同时也得到了客户认可。
项目开发到中后期,客户陆陆续续看到了成果物,随之想法越来越多,迫于做出近似于完美的系统,新需求、式样变更便接踵而至。项目组也是严格按照变更管理流程做事。因变更导致的项目延期、成本追加,客户都同意了。我还能说什么 ,“有钱能使鬼推磨” 你懂的。
这种现象在管理学中有一个词 ----- 范围蔓延。
导致这一现象可能有两种情况:
→ 客户在业务上对截止日期的要求几乎没有,同时能给你足够的时间和钱,换回他想要的。
→ 客户已经不再关注这个项目。
当我第一次接触这个词的时候,我很费解。有活做,有钱赚,有何不可。
经历这次项目之后,我才发现 “我是错的。”
古代有一个典故 “一鼓作气,再而衰,三而竭” 想必大家都知道。
一个清晰的截止日期能给项目成员带来一定的紧迫感,帮助他们明白按时完成各自工作的重要性,只有这样整个项目就能够按时完成。
如果截止日期一而再、再而三地被式样变更所更改,看似无奈,其实团队内部已经渐渐无视项目截止日期了,无论是团队士气还是信任,都是非常糟糕的。后期的任何计划调整都形同虚设,因为他们根本就不相信计划。
无论项目多么复杂、难缠,无论客户多么无知、是否有无业务上的截止日期,我们都要帮组他们做出项目截止日期的估算。
如果错过了一次截止日期,就不要在错过第二次了,因为项目成员没有人会相信你的第三次。
其实我们有很多方法是可以防止 范围蔓延的,比方说,不一定所有的变更、新需求都要必须立刻对应,可以把项目分为一期、二期、三期。最起码,让团队内部知道变更项目截止日期是一个很严肃的问题,一旦失控,失去的不仅是团队士气和信任,还有项目本身。
读到此,场景中“BOSS转过身去,皱了一下眉头,渐渐的走去.......... ”也就不足为奇了。
![](http://images0.cnblogs.com/i/465356/201405/252013515128327.jpg)