文章详情

关键链在软件项目管理中的应用 4 - 问诊III

孙卫东 1个月以前

1、出路

什么时候可以打破这些恶性循环?

要不就是我们承受不了压力,辞职走人;

要不就是公司承受不了压力,重新调整项目管理方式、绩效考核办法等;

要不就是客户在进度上或报价上承受不了压力,换其他公司做。

这就是我们的现状,解决问题的关键在哪里?

回头看看我们上篇文章最后两个导致项目不断拖延的恶性循环图,里面隐藏着什么假设错误导致我们项目的延后呢?

办法1,保佑项目不要出现异常情况?这个墨菲不同意。

 墨菲:我一直在你身边。

办法2,我们评估任务需要的时间更精准?哦,得了吧。用一个简单的方法测试预估是有多么不靠谱。

你先预估下你正常速度写1-26这26个数字的时间,然后拿出手表马上写写看实际时间是多少。

我相信以项目经理的智商应该明白我在表达什么意思了。

办法3,我们在项目任务预估时拿掉保护时间(缓冲),让项目组的人提升做事情的节奏?接近答案,不过面临着三个障碍。

  • 如果每个任务的评估时间没有缓冲,每个任务不能按时完成怎么办?

  • 如果整个项目按照没有缓冲的任务时间排计划,项目整体完不成怎么办?

  • 如何评估应该去掉多少缓冲?

第一个障碍

每个任务在评估时间的时候没有缓冲时间会导致任务开发不能按时完成,从而影响项目按时完成。

这个想法是我们项目管理中最需要调整的错误假设(没有之一)。仔细想想,做为项目经理我们要保证的是项目能够按时完成,项目中每个任务是否能够按时完成非常重要吗?

NO,我们在上一遍文章中已经明确的指出,正是因为我们不断强调每个任务必须在评估的时间内完成,才导致了我们在评估的时候不断的塞入了缓冲时间,最终引发了项目延误的三大杀手出现。

如果我们追求每项任务都按时完成,必然导致整体项目不能按时完成。

第二个障碍

如果项目中没有缓冲时间,会很大可能导致项目不能按时完成。

这是一个问题,因此缓冲时间还是需要的,但是缓冲时间不是给每个任务,而是给整个项目增加缓冲时间。

第三个障碍

如何在评估的时候去掉真正缓冲时间(究竟应该去掉多少)?

看到很多项目管理理论中评估任务需要天数时,工作量评估可以精确到小数点后2位。我就觉得像我告诉你地球诞生到现在有46亿5892万1327.83年一样有趣。

我们需要的大致正确,不需要精确的错误。

我们假想一下一个射击冠军在打靶练习,那么他射击的位置与靶心的距离是什么样的分布?

我们都知道应该是正态分布,而实际是图中的曲线1还是曲线2就取决于这位射击冠军他命中率的稳定性了。

同样的,我们完成一项任务的时间也是以平均时间为中心的正态分布,不过这个正态分布需要缩短时间比较难,而任务延长时间的可能性比较大,因此我们可以基本预测一个任务需要的时间大致是一个近似的正态分布图。右侧延伸长短的幅度,取决于我们对任务的了解与把控能力。这里,我们就大致预估一个任务的时间里面有一半左右是缓冲时间。

从以上的思考逻辑,我们最终的做法是:

将每个的任务时间的一半做为缓冲时间从任务中减去,再将减去的缓冲总和时间的一半放到项目的最后,做为项目的缓冲。

最终我们的项目计划会从上图变成下图。

image.png

我们通过观察项目的缓冲消耗情况来确认项目的执行情况。

如果在我们的项目里面不止一条路径,那么除了在最长的关键链上增加项目缓冲外,还需要在接入关键链的分支上增加接驳缓冲,确保分支任务的延误不会影响关键链上的缓冲。


image.png


调整前的项目甘特图


image.png

调整后的项目甘特图

我们知道关键链是项目中依存关系最长的那条链路。

关键链上的任何延误都会影响项目整体的延误。

所以我们要尽量避免关键链上的延误。对于关键链上的任务,我们务必要保证当上一任务完成时,下一任务可以马上开始,正如前面讲的接驳缓冲。同时,我们需要确保任务开始时,任务需要的资源也已经到位,这就需要有一个资源缓冲的工作。即下一任务即将开始时,需要提前确认资源。即我们在需求即将完成时,告诉研发团队还有14天将进行开发、一周后再告诉研发7天后将进行开发、再4天后告诉研发3天后进行开发。

2、遗珠

当我们开始用关键链来管理我们的项目时,意味着什么?

  • 我们的项目不再有阶段性的里程碑;

  • 我们不会在项目开始的时候很松懈;

  • 我们不会再说:大家加把劲,我们完成这个任务,本阶段的工作就完成了。

  • 除非重大变更,我们不需要三天两头变更我们的项目计划;

  • 。。。

这些现象表面上看并没有什么特别的好处,没有里程碑还让我们对项目缺少了能对它可控的感觉。而实际上其实是:想通过控制项目局部的时间最终只会拉长项目整体时间。

当我们用关键链来管理项目的时候,每项任务预估完成时间都减半了,这样每项任务都没有明确的开始时间与结束时间。

也就是说,在阶段上,需求调研没有明确的完成时间、研发每个模块没有明确的完成时间、测试没有明确的完成时间,只有项目的最迟完成时间是明确的。

这避免了当我们设置里程碑时间过长则会出现学生症候群与帕金森定律。同时,也避免了每个里程碑结束后人员就会松懈的问题。同样的,我们会在项目一开始就非常抓紧,不会在项目一开始的时候松懈,因为每浪费一点时间就相当于缓冲被消耗了。这不就是我们所有项目一开始就希望这样做的吗?

因为任务的提前、按时、延后完成都被认为是正常的,所以随着任务的进展,正常情况下只有项目的缓冲会有变化。而不像我们常规的项目管理,当一项或几项任务延后了,项目整个时间表就需要调整了。


3、案例


三得利


一家14,340亿日元的集团公司,是日本酒精与非酒精饮料的生产与配销企业。公司信息系统部门(CIS)为 170家集团的旗下公司提供信息系统的支持。170家公司会不断提出为解决日常经营中所面临问题的系统需求。CIS部门面临系统复杂程度迅速增加的压力,严重制约了公司的发展。

CIS部门内有一些人读过《目标》和《关键链》,他们在寻找方法把这些知识应用于眼下的现实环境。他们听取了AGI(高德拉特研究所)所做的一个初步的TOC介绍,并在AGI帮助下开始一个内部“市场需求——拉式”的业务系统改造项目。

CIS 部门在不超预算的前提下完成了信息系统的升级,整个项目占用了极少的资源,公司内部客户和CIS部之间的关系获得了极大的改善。

 

希捷科技

一家64亿美元的电脑硬件公司,全球雇员超过六万。

在实施TOC之前,希捷科技的状况是:

  • 十多个磁盘产品同时在开发。

  • 没有确定用何种工具管理项目。

  • 供应商没有跟公司作所需的协调。

  • 交货期有两个,一个对内,一个对外,目标不明确。

  • 没有确定用何种方法管理资源。

1997年,希捷科技的营业额是85亿美元,并期望1998年会提升至100亿。但事与愿违,营业额下降至65亿。明显地,希捷科技在科技及产品开发速度方面,已失去在市场上的领导地位。

他们唯有改革求变,成立各产品项目小组,其中之一负责代号「豹X-15」的每分钟转速15000的硬盘,小组决心比对手更快推出市场。

开发小组和行销部坐下来,谈谈项目的优先顺序,发觉项目成本的监控、产品的转速、声浪都不难解决,但对产品开发过程的管理,却说不出可以用一些什么工具来进行。后来,有人向他们推荐《关键链》这本书,看完后,他们马上找「高德拉特学会」,经讨论后,小组初步认为有信心可以将项目得所需时间减少一个月,这其实等于为公司赚取了一百万美元的额外利润,希捷科技高层最后批准了实施TOC关键链,并以「豹X-15」项目作为头一炮。

在「高德拉特学会」的指导下,「豹X-15」项目小组比预估完工期早了五个星期就完成了。在他们的行业,五个星期是极为珍贵的,(1997年的一项报告指希捷科技比对手只落后短短一季,已经令营业额损失5亿美元,毛利损失2亿美元)。

「豹X-15」是第一个抢先登上市场的每分钟转速15000的硬盘,其后对手纷纷被逼退出,因为太晚了。

现在,希捷科技三个设计中心都实行TOC关键链项目管理,每年十多个新产品项目,海外的产品开发中心亦陆续上马,形成了一股热潮。

(以上案例来自于互联网)

只要不断的监察所有缓冲,他们的注意力就会高度集中。

——高德拉特

阅读 161
0
4
收藏成功