做PM一年，一直應用TOC的有關(guān)概念在tracking project progress，不過(guò)一直不大清楚大家都是如何來(lái)監控項目進(jìn)度的，這里小弟根據自己的理解，簡(jiǎn)單寫(xiě)下這些東東，和大家一起探討一下監控項目進(jìn)度的一些方法，共同進(jìn)步。

　　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.

　　由這里的描述可見(jiàn)，TOC的中心思想是找到一個(gè)系統中的脆弱的鏈，進(jìn)而加以改善，然后再重新分析脆弱的鏈，再加以改進(jìn)，以此類(lèi)推從而達到強化系統的目的。這個(gè)原理如何應用到IT軟件項目的管理中呢？See following.

　　2. Critical Chain

　　對于軟件項目來(lái)說(shuō)，關(guān)鍵是能否在規定的時(shí)間之內，預定的資金內，有質(zhì)量的交付客戶(hù)要求的產(chǎn)品。我們這里關(guān)注的是如何準時(shí)的完成項目，預算和質(zhì)量都有其特定的系統去監控。能否按時(shí)完成項目就取決于我們的網(wǎng)絡(luò )圖中最長(cháng)的那條chain，所以我們說(shuō)一個(gè)項目網(wǎng)絡(luò )圖中最長(cháng)的那條chain我們就稱(chēng)之為Critical Chain，簡(jiǎn)稱(chēng)為cc。

　　在一個(gè)項目的pert char未定之前，我們要做的就是反復分析最終得到cc，具體就是先找出最長(cháng)的chain，然后分析每個(gè)task的duration是否都是不可再縮減的，若可以就進(jìn)行優(yōu)化，再看這條chain還是不是最長(cháng)的chain，如果不是則找出新的最長(cháng)的chain，依次類(lèi)推，最終得到最優(yōu)的網(wǎng)絡(luò )圖，得到cc.當然在項目的執行過(guò)程中，可能最初的cc慢慢的不再是最長(cháng)的chain了，但是由于buffer機制管理的問(wèn)題，cc一旦確立，在項目的執行過(guò)程將不再改變。有關(guān)buffer的問(wèn)題在后面解釋。

　　cc確立后，就是整個(gè)項目的constraint，對于cc就要更多的關(guān)注與控制，也就一個(gè)項目的主要矛盾。非cc的task就是次要矛盾，但是不意味著(zhù)就不重要，只是相對而言要更關(guān)注cc而已。

　　3. Buffer

　　人在做事情的時(shí)候，當需要預估這件事情完成所需的周期時(shí)，會(huì )有兩種方式在腦中思考：50％confidence and 90%confidence，50% confidence是指在最好的情況下，我盡最大的努力完成這個(gè)任務(wù)所需要的時(shí)間；90％confidence是指我有相當大的把握完成這個(gè)任務(wù)所需要的時(shí)間。出于人的惰性以及害怕一旦無(wú)法如期完成所帶來(lái)的后果，大多數的人在預估完成任務(wù)所需要的時(shí)間的時(shí)候，傾向于使用90％confidence。而實(shí)際是90％confidence的時(shí)間偏長(cháng)，往往造成項目周期的加長(cháng)；50％confidence則由于過(guò)于不給自己留有余地，往往在意外情況發(fā)生的時(shí)候造成任務(wù)超時(shí)。所以我們引入buffer的概念來(lái)平衡，既有一定的把握完成，同時(shí)又避免50％所帶來(lái)的高風(fēng)險，又不像90％那樣延長(cháng)了工期。

　　Buffer是指在某條鏈上所有的tasks最后加上一個(gè)task，給予一定的duration用于保護項目，避免突發(fā)事件造成的項目延期。例如一條鏈上有4個(gè)tasks，每個(gè)task 10days，則在最后一個(gè)task后再加上一個(gè)task，給上一定的時(shí)間，比如10days.如果有一個(gè)task在預計的10天內沒(méi)有完成，而是用了12天，那么這個(gè)task就吃掉了2天的buffer，這時(shí)候buffer的 consumption就是2/10=20%. 在這里每個(gè)task的時(shí)間都是采用的50％confidence標準定的，而buffer就起到了降低了50％所帶來(lái)的高風(fēng)險。同時(shí)由于只有一個(gè)buffer，所以buffer是團隊共享的buffer，這個(gè)時(shí)候個(gè)人消耗buffer就是消耗整個(gè)團隊的buffer，即使PM不看著(zhù)，team的其他成員也會(huì )注意的，而吃buffer的這個(gè)人所得到的壓力就不只是來(lái)自PM了。

　　4. Buffer management

　　Buffer的另外一個(gè)重要的作用就是顯示整個(gè)項目的狀態(tài)。buffer如果沒(méi)有被吃，那么整個(gè)項目的risk相對就低，如果buffer面臨被吃完的局面，則說(shuō)明buffer的保護作用已經(jīng)慢慢消失，risk慢慢的在上漲。如果我們依照buffer consumption的比率設定一些值，如30％以下為綠色，30％～70％為黃色，70％～80％為紅色。那么我們就可以依照這些顏色來(lái)簡(jiǎn)單的確定項目的狀態(tài)，從而制定相應的對策。

　　5. As late as possible

　　大家有沒(méi)有這種感覺(jué)，畢業(yè)前要交一個(gè)論文，你提前一個(gè)月寫(xiě)往往是在期限的前一天剛剛搞定；而如late as possible

　　大家有沒(méi)有這種感覺(jué)，畢業(yè)前要交一個(gè)論文，你提前一個(gè)月寫(xiě)往往是在期限的前一天剛剛搞定；而如果你提前2周寫(xiě)，往往又是也很可能剛剛在期限的前一天搞定。這也是人的惰性的因素所致。所以有一種叫as late as possible的方法，不管這個(gè)項目什么時(shí)候開(kāi)始，我們只是考慮在最好情況下，當所有的tasks的duration定下來(lái)了，buffer的大小定下來(lái)了，我們依據項目結束的日期從后往前推，從而得到項目開(kāi)始的日期，如果這個(gè)日期晚于今天，那么可以考慮將resource放到別的項目中去。這種方法最早主要用于物流方面，因為倉庫的占用是要花費相當的成本的，如果能很好的利用ALAP，則可以更有效率的利用倉庫，降低成本。如今用于軟件領(lǐng)域也可以使用。