用穩定、可預測的管理，避免失控

在前文〈失控的專案就從失控的需求開始〉中，提到了專案之所以失控有許多種可能的原因，而在眾多的原因中，失控的需求是很常見到的一種，未妥善的對需求進行管理，或者是低估了需求變更造成的影響，都容易造成需求失控，進一步使得整個專案失控。

需求的失控也可以視為是開發範圍的失控，面對一個持續在變化、持續在擴大的目標，又要如何才能夠評估開發工作何時才能結束呢？這道理很簡單，還是有一些人會期待允許開發範圍變化及成長，卻又不影響到開發的時程及投入的成本。

專案計畫的內容，通常會包括許多面向上的規畫，其中有一個部份，便是主要的工作項目、施行的順序及時程、人員及資源的運用方式等等。

若是規畫本身就有問題，意謂著即使百分之百依照著計畫按表操課，也很有可能無法順利完工，到了專案進行到一半或近尾聲時，才發現計畫有根本的問題，此時，一方面若是回頭重來，又擔心前功盡棄，另一方面，若是在中途嘗試修正偏差的計畫，卻又有可能需要投注大量心血，甚至還不確定是否能重新導正計畫。在不斷嘗試導正的努力中，這才發現專案已經失控。

不適合的專案負責人，以及低估新技術風險
對於一個專案計畫來說，負責做計畫的人當然扮演一個靈魂人物的角色，一旦計畫出了嚴重的問題，即使是執行過程沒有誤差，也是很難將專案完成。有些時候，我們會看到沒有太多開發實務經驗的人被賦予專案計畫的工作，他們便有可能做出無法落實的計畫，進而造成專案的失控。

除此之外，開發團隊所選用的技術造成專案的失控，也是時有所聞。

怎麼說呢？有時候，開發團隊會選擇使用較新或是較受歡迎、主流的技術。很多開發者通常對於新的技術（例如新的應用程式框架，或是新的程式庫、甚至是新的開發方法）都有很多的期待，期待它能解決自己之前長久所受的痛苦，以及遭遇到的問題，而新的技術通常也是瞄準這樣的目標而發展。不過，新的技術通常不那麼成熟，也還有不少問題等著被發掘、被解決。太早開始使用新的技術，時常會低估新技術所帶來的這些潛在風險。

而且，開發團隊對新技術也不熟悉。新技術的熟悉有時在學習曲線過了之後，就可以克服，但若學習曲線過長超過了專案本身的時程，或是新技術本身各種難以預測的問題，不斷在開發過程中浮現，那麼，對於專案中要解決、和該技術相關的工作項目，就很難確切預測它究竟何時才能完成。

即使程式碼的編寫完成，到了測試階段所面對的品質問題，也有可能成為失控的隱憂。因為專案所開發的系統其品質和所採用的技術是息息相關，若所使用的核心技術本身有難解的品質問題，那麼所開發的系統自然也會承襲。這種情況下，除非所採用的新技術開發團隊能解決問題，否則，要倚靠自身處理，難度將會提高許多。

此外，若是邊學習新技術邊在開發中實際運用，還有另一個風險，也就是在專案初期的開發成果可能是較不成熟的產物，通常等到熟悉新技術之後，才察覺初期所開發的內容需要做調整，這時候再回頭修改，又會製造出諸多不穩定的因素，也有可能因此造成失控的局面。

影響專案管理的因素中，「人」很重要

軟體開發是人的產業，除了所制定的計畫有問題、所選用的技術有問題之外，若是所選用的人有問題，一樣有可能造成專案的失控。在前文中提到的專案計畫的問題，很多時候便是來自於選錯了制定專案計畫的人，才造成之後一連串的失控。除了制定專案計畫的人之外，開發團隊中的每個角色，都有可能影響到專案的成敗。

從人的觀點來看，第一個影響的因素是團隊的組成。舉例來說，一個團隊中若是缺乏經驗較為豐富的成員，而多是才剛上路的新手，那麼，在人的因素上就有比較多的變因。人的問題也有可能不是出在經驗的多寡與否，而是出在人的能力或態度。

當團隊中有了不正確的人，而且在專案的進行過程中始終沒有找出問題，或者即使知道了問題卻又未加以矯正時，讓人所產生的問題繼續累積、擴大，也會成為專案中不穩定的因素。只要專案中有不穩定的因素，你很難預計專案會有穩定進展。

例如，專案中有個負責開發重要項目的程式設計者，但他本身能力或是經驗就有問題，無法做出你希望他做出來的東西，或者是即使做出來，也只是徒具表面，事實上，其中還隱藏很多未爆的地雷。等到開始進入測試階段之後，才發現他的東西像是個黑洞，無法預測還有多少問題於其中。這種情況下，程式碼本身具備了嚴重的品質問題，最後有可能因為品質無法快速收斂，也造成了專案的失控。

專案在溝通上的不良，也有可能引發專案的失控，而溝通不良的問題，也有可能是來自於人的問題。例如，專案中有位負責重要項目的程式設計者，他所預估出來的工作時程總是很樂觀，而在專案中即使遇到了困難及障礙，他也不會主動提出，等到預計的期限到了之後，他才將遇到困難的事情道出，但已經錯過了期限。因為他所負責的是重要的項目，如果在專案過程中不斷的發生這樣的情況，就會很難衡量專案的進程，當然也就有可能引發專案的失控。

不論是能力有問題的人，或者溝通有障礙的人，在團隊成員中難免會出現，尤其是新加入的成員，大家對他可能還不甚熟悉。但最終會讓這樣的人引發專案的失控，其實又是管理面的問題。

在管理流程及制度上，沒法子察覺人的問題，進而利用矯正措施來解決人的問題，才會造成之後更嚴重的失控。

很多時候，團隊成員人多，不一定比人少好。因為即使是表面上看似較多的成員數目，但其中有些成員具備了不穩定的特性，就會使得整個專案也變得不穩定起來。不穩定就難以估計和預測，當不穩定到了一定的程度，就會變成失控。

相反的，人數較少的團隊，即使因為人力稍微不足，使得進度會較慢。但進度慢並不是最嚴重的是。進度慢但是可以被準確的估計，我們還是可以得到一個受控制的開發專案。但是進度時快時慢，無法被穩定的估計，會造成管理上的困難。可以預測和穩定，是我們想要妥善管理專案開發過程的兩個重要的元素。

還有一些因素，尤其到了專案後期，也會引發專案失控致使難以管理。像是因為專案前中期太多、太大的需求變更，即使需求變更已被管理，但因為程式架構不具備足夠的彈性來因應變化，導致程式碼不斷的疊床架屋，最後就會使得程式碼本身失去控制。到了後期，任何一點修改，無論是基於修正臭蟲或是滿足需求變動，都很容易引發一連串不可預期的效應，導致每次的修改都引發品質的問題，需要花費一段不易預測的時間才能修正。如果到了後期，修改的動作還不能收斂，那麼程式碼的失控就會造成專案的失控了。

談到目前為止，提到了一些會造成專案失控的原因。大多時候專案失控前會有一定的問題先行浮現，管理機制能預先處理，避免問題惡化造成失控的局面。專案最終會演變成為失控的情況，管理上無法妥善的監督及控制是最大的主因。此外，人是軟體開發最重要的因素，人對了，即使管理上有所問題，正確的人也能將即將錯誤的情況拉回正軌；相反的，人錯了，要花費更多管理的額外負擔，才能維持專案在正常的道路上前進。