项目进度的监控——浅谈TOC

申请免费试用、咨询电话：400-8352-114

做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 management
　　Buffer的另外一个重要的作用就是显示整个项目的状态。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的朋友交流一下感想和
　　经验。同时也希望能了解大家都是采取什么机制来监控项目的进度的呢？

　　更多信息请访问：考试大项目管理站 考试大论坛