摘要：《人月神話》可謂是IT軟件開發管理人員的必讀之書。距離書中的理論提出已經快50年了，仍然像哥德巴赫猜想一樣吸引和困擾著人們。本篇來看其中的一個理論，“焦油坑”是否還存在？
（人月神話中插圖焦油坑）
焦油坑字面意思，描述的是在史前，巨大的野獸，比如恐龍、猛獁象、劍齒虎等掉進了其中。它們在焦油中痛苦地掙扎，掙扎的越是猛烈，焦油糾纏得越緊。沒有任何猛獸足夠強壯或具有足夠的技巧，能夠掙脫束縛，它們最終都沉到了坑底。
大型信息系統開發，就像這樣一個焦油坑。在成本、時間進度和目標的多重因素下，很多大的或小的團隊，一個接一個地淹沒在焦油坑中。表面看起來沒有任何一個單獨的問題會導致悲劇的發生，每一個都能被解決，但當它們相互糾纏和累積在一起的時候，就變成了一個可怕的焦油坑。
（圖片來自人月神話）
如上圖所示，當一個程序誕生的時候，可能這是一個很愉快的過程；程序員憑藉自己的思維和靈感，把它創作出來了，然後執行運行命令，“完美，跑起來了！”。遺憾的是，如果這個程序想變得更有價值，它需要變成產品，變成可以被任何人運行、測試、修復和擴展的程序。最好還要具備平臺兼容性。這樣的話，需要至少增加三個工作：1、補充易用性方面的編碼；2、編寫支撐文檔；3、測試。按照作者的說法，工作量增加了3倍。
進一步的，如果這個程序想變成系統的一個構件，它必須具備規範的格式，與其他系統一致的API接口，還是要進行集成測試。成本又增加了3倍。
如果這個程序想變成編程系統產品，它的成本又幾乎性的增長，變成了9倍。
以上就是大型信息系統開發中的焦油坑理論。我們姑且不去較真一個軟件所變成的商業價值形態（即是以程序、編程產品、系統產品中的哪種）和成本到底增加了幾倍，毋庸置疑的是，當項目陷入糾纏時，成本確實在成倍的增加。
那麼，在這個理論從提出到現在這麼長的時間裡，這個問題得到解決或緩解了嗎？事實上，這個問題如同其他矛盾一樣，無法徹底解決，但卻可以緩解至每一時期管理水平發展的最大限度。
大型項目管理科學化程度已經大大提高
首先，大型信息系統項目建設，已經發展為了項目、項目集、項目組合。每個層級不僅有項目經理，而且有相應的管理委員會，及管理理論、過程和工具。科學的大型信息系統項目管理知識，從項目的組織架構、生命週期管理、過程治理等方面提供了健全穩妥的解決方案。這是其一。
工種細分已經十分完善
其次，現在項目或軟硬件產品開發，不再是程序員單一工種在戰鬥。而是往往至少拆分出了需求和研發兩部分；需求通常由產品經理或類似職責的角色來完成採集和分析，而且需求到研發手中的時候，可以是以原型的形式，做到了可視化。並且，有運營人員和售前人員協助反饋需求，改進功能。從這些方面來講，也大大降低了焦油坑的糾纏程度。
成熟的開發模式不斷湧現
我們對經典項目管理模式已經運用得輕車熟路了，在立項、設計、部署、運維等階段都建立了完善的開發模式。對項目管理的5大過程、9大領域、44個管理點位都創建了橫成體系、豎成套路的一體化理論和實踐。
另外有各類開發過程模型，瀑布、螺旋、原型等，雖然每種模型都有缺點，但靈活的在不同情況不同階段使用不同的模型，可以最大限度地規避焦油坑。
成熟的測試模型和測試工具
不僅發展出了V模型、W模型、H模型等；還配合著開發模型，產生了單元測試、集成測試、系統測試、白盒測試、黑盒測試、功能測試、性能測試等。並編寫出了各類高效測試的工具和缺陷標準。
再就是各類質量保障的建立和健全，ISO、CMM、CMMI等。
所以，信息系統開發項目中的焦油坑，已不再像從前那樣不可解。但這對一些公司或團隊來講，並不是一件好事，因為，如果你對這方面不專業，那麼你和別的企業並不在一個起跑線上。
閱讀更多 靜靜水流 的文章
