项目进度的监控 ——浅谈TOC.doc
项目进度的监控 —— 浅谈 TOC 做 PM 一年,一直应用 TOC 的有关概念在 tracking project progress,不过一直不大清楚大家都是如何来监控项目进度的,这里小弟根据自己的理解,简单写下这些东东,和大家一起探讨一下监控项目进度的一些方法,共同进步。 1. What is TOC (Theory of Constraints)Principle concepts -- What is a “ constraint?” That aspect of a system or organization that prevents it from achieving its goal.If a system =a chain, its constraint = its “ weakest link” .Unless the constraint is improved, there is little chance for significant improvement in the system as a whole.由这里的描述可见,TOC 的中心思想是找到一个系统中的脆弱的链,进而加以改善,然后再重新分析脆弱的链,再加以改进,以此类推从而达到强化系统的目的。这个原理如何应用到 IT 软件项目的管理中呢? See following. 2. Critical Chain 对于软件项目来说,关键是能否在规定的时间之内,预定的资金内,有质量的交付客户要求的产品。我们这里关注的是如何 准时的完成项目,预算和质量都有其特定的系统去监控。能否按时完成项目就取决于我们的网络图中最长的那条 chain,所以我们说一个项目网络图中最长的那条 chain 我们就称之为 Critical Chain, 简称为 cc。在一个项目的 pert char 未定之前,我们要做的就是反复分析最终得到 cc,具体就是先找出最长的 chain,然后分析每个task 的 duration 是否都是不可再缩减的,若可以就进行优化,再看这条 chain还是不是最长的 chain,如果不是则找出新的最长的 chain,依次类推,最终得到最优的网络图,得 到 cc。当然在项目的执行过程中,可能最初的 cc 慢慢的不再是最长的 chain 了,但是由于 buffer 机制管理的问题, cc 一旦确立,在项目的执行过程将不再改变。有关 buffer 的问题在后面解释。 cc 确立后,就是整个项目的 constraint,对于 cc就要更多的关注与控制,也就一个项目的主要矛盾。非 cc 的 task 就是次要矛盾,但是不意味着就不重要,只是相对而言要更关注cc 而已。 3. Buffer 人在做事情的时候,当需要预估这件事情完成所需的周期时,会有两种方式在脑中思考: 50% confidence and 90%confidence, 50% confidence 是指在最好的情况下,我尽最大的努力完成这个任务所需要的时间; 90% confidence 是指我有相当大的把握完成这个任务所需要的时间。出于人的惰性以及害怕一旦无法如期完成所带来的后果,大多数的人在预估完成任务所需要的时间的时候,倾向于使用 90% confidence。而实际是 90% confidence 的时间偏长,往往造成项目周期的加长; 50% confidence 则由于过于不给自己留有余地,往往在意外情况发生的时候造成任务超时。所以我们引入 buffer 的概念 来平衡,既有一定的把握完成,同时又避免 50%所带来的高风险,又不像 90%那样延长了工期。 Buffer 是指在某条链上所有的 tasks 最后加上一个 task,给予一定的duration 用于保护项目,避免突发事件造成的项目延期。例如一条链上有 4 个tasks,每个 task 10days,则在最后一个 task 后再加上一个 task,给上一定的时间,比如 10days。如果有一个 task 在预计的 10 天内没有完成,而是用了 12天,那么这个 task 就吃掉了 2 天的 buffer,这时候 buffer 的 consumption 就是 2/10=20%. 在这里每个 task 的时间都是采用的 50% confidence 标准定的,而 buffer 就起到了降低了 50%所带来的高风险。同时由于只有一个 buffer,所以 buffer 是团队共享的 buffer,这个时候个人消耗 buffer 就是消耗整个团队的 buffer,即使 PM 不看着, team 的其他成员也会注意的,而吃 buffer 的这个人所得到的压力就不只是来自 PM 了。:) 4. Buffer managementBuffer 的另外一个重要的作用就是显示整个项目的状态。buffer 如果没有被吃,那么整个项目的 risk 相对就低,如果 buffer 面临被吃完的局面,则说明 buffer 的保护作用已经慢慢消失, risk 慢慢的在上涨。如果我们依照 buffer consumption 的比率设定一些值,如 30%以下为绿色, 30%~70%为黄色, 70%~ 80%为红色。那么我们就可以依照这些颜色来简单的确定项目的状态,从而制定相应的对策。 5. As late as possible 大家有没有这种感觉,毕业前要交一个论文,你提前一个月写往往是在期限的前一天刚刚搞定;而如果你提前 2 周写,往往又是也很可能刚刚在期限的前一天搞定。这也是人 的惰性的因素所致。所以有一种叫 as late as possible 的方法,不管这个项目什么时候开始,我们只是考虑在最好情况下,当所有的 tasks 的 duration 定下来了, buffer 的大小定下来了,我们依据项目结束的日期从后往前推,从而得到项目开始的日期,如果这个日期晚于今天,那么可以考虑将 resource 放到别的项目中去。这种方法最早主要用于物流方面,因为仓库的占用是要花费相当的成本的,如果能很好的利用 ALAP,则可以更有效率的利用仓库,降低成本。如今用于软件领域也可以使用。 小弟文采有限,很多表达可 能不大清楚,请各位海涵。总之在小弟在使用 TOC的过程感觉不少方面还是很科学的。只是不知道国内 TOC 应用的程度如何,也望有使用 TOC 的朋友交流一下感想和 经验。同时也希望能了解大家都是采取什么机制来监控项目的进度的呢?