M項目自實施以來已經(jīng)過去了1個半月，目前該項目還在;試用-修改-再試用-再修改”的泥沼中苦苦掙扎，4名開發(fā)人員已經(jīng)人困馬乏，疲于應(yīng)付，但系統(tǒng)的問題清單仍然越來越長，似乎沒有盡頭。這個項目是為生產(chǎn)部門開發(fā)的生產(chǎn)線的管理系統(tǒng)。去年，由于生產(chǎn)工藝和流程變化，已經(jīng)使用了幾年的管理系統(tǒng)無法繼續(xù)使用了，因此生產(chǎn)部門購買了一套外國公司的生產(chǎn)管理軟件，花費不菲，試運行的時候卻發(fā)現(xiàn)系統(tǒng)響應(yīng)速度非常慢，幾乎造成5條生產(chǎn)線全部停工，無奈之下只好提前結(jié)束合同，當然，首付款也打了水漂。
目前，生產(chǎn)線完全依靠人工管理，生產(chǎn)效率低下，生產(chǎn)部門迫切希望于信息部門能夠盡快開發(fā)出新系統(tǒng)，以緩解生產(chǎn)制造的混亂局面。系統(tǒng)的上線時間，生產(chǎn)部門的要求近乎苛刻，信息部在接到任務(wù)后，只好將項目計劃緊縮、再緊縮。開發(fā)部的工程師非常努力，只用了3個月就完成了需求調(diào)研和代碼開發(fā)，并于1個半月前開始試運行。但是問題很快出現(xiàn)了，本來預(yù)計只要2周的系統(tǒng)實施階段一拖再拖，問題不斷，眼看三個2周都過去了，距正式上線仍遙遙無期，對此各方面都非常著急，卻搞不清楚為何如此。
TOC(Theory Of Constraints)是高德拉特(Eliyahu M.Tolerate)創(chuàng)立的“制約法”，是一套獨特的管理方法論，將之應(yīng)用到軟件項目管理中也一樣適用。TOC致力于找出管理鏈條中的薄弱環(huán)節(jié)，然后通過各種手段加強它，當它不再是最弱的一環(huán)時，再去尋找新的薄弱環(huán)節(jié)，如此往復(fù)，整個管理鏈條都得以加強了。
一、原因何在?
實施受阻，原因何在?信息部為了按時交付系統(tǒng)，不得不一再的壓縮開發(fā)和測試的時間，軟件質(zhì)量因此大打折扣。在開發(fā)過程中，系統(tǒng)集成測試基本屬于奢望，開發(fā)人員甚至沒有時間對自己的代碼做充分的單元測試，就匆忙發(fā)布了，這種做法大大降低了軟件的質(zhì)量，也正是不斷降低的質(zhì)量標準導(dǎo)致了試運行時鋪天蓋地的錯誤和缺陷。更麻煩的是，由于不斷的對軟件功能進行修改，只好不斷的對修改的代碼進行測試，不斷的對修改過的功能進行用戶培訓(xùn)，造成實施時間一延再延。
“實施階段”指的是指軟件拿到用戶的實際工作場所進行部屬和使用的階段。一般來說，系統(tǒng)實施要經(jīng)過“軟件交付——〉發(fā)布——〉用戶培訓(xùn)——〉用戶試用——〉發(fā)現(xiàn)問題——〉軟件修改——〉軟件測試——〉重新發(fā)布”這樣一個螺旋式前進的過程，這個過程將不斷的重復(fù)，直到系統(tǒng)沒有問題或者存在的問題用戶可以接受為止。不要懷疑這個過程的復(fù)雜和繁瑣，因為這才是事實，像那種理想化的、一帆風順的實施過程通常只會在教科書上出現(xiàn)，我們必須充分認識到系統(tǒng)實施階段存在的風險。
在這樣一個循序漸進的過程中，每個環(huán)節(jié)都可能引發(fā)混亂，造成延誤，并在各步驟間傳遞和放大這些延誤，導(dǎo)致實施階段的延期。比如：開發(fā)過程的延誤，造成交付的推遲;用戶培訓(xùn)的拖后，造成試用的推遲;問題發(fā)現(xiàn)的緩慢，造成軟件修改的推遲;軟件修改的頻繁，造成測試的推遲;軟件測試的延誤，造成再次發(fā)布的推遲。
二、沖出泥沼
讓我們用TOC的觀點和方法來分析這混亂的狀況，并找出解決方法。
1、沖突
[TOC觀點]：發(fā)現(xiàn)沖突是解決問題的第一步。TOC認為，如果一個問題未能以兩個必備條件之間的沖突來表達，那么這個問題就沒有清晰的定義。
從成本世界出發(fā)，各步驟所用的時間越短越好，所進行的循環(huán)次數(shù)越少越好;
從有效產(chǎn)出世界出發(fā)，各步驟所做的準備工作越充分越好，所進行的循環(huán)次數(shù)越多，則有效產(chǎn)出的質(zhì)量和效果越好。
2、制約因素