當軟體專案計劃趕不上變化時

軟體專案在「收尾巴」之前，很多專案的利害關係人都會很樂觀地認為，軟體的問題可以在收尾巴的過程中得到修正。然而，當大家發現專案後期因為需求變更與軟體本身所存在的缺陷產生複雜的交互作用，使得軟體問題不斷地發散，才會發現，收尾巴？！這應該還沒開始吧！

對此，志威兄提到，從程式設計者、網站委外服務之業主、專案管理者之間，存在了觀點的差異。而他指出，讓專案順利及圓滿完成的解決方案就是找到一個稱職、有能力的專案經理。志威兄認為良好的專案經理除了具備相當的領域知識與時程控管能力外，最重要的就是溝通協調能力，他提到了：

他必須將老闆時長過於遠大的夢想，找到執行與實做的方法，更要能溝通協調把像在各星球各自為政、不同部門的理性嚴謹工程師與行銷、美工等創意人員，通通揉合在一起朝相同目標前進。也能夠事前就規劃好整個專案的時程，並且設定適當的check point，隨時掌控進度與各部門狀況。

事先做好規劃，按照時程追踪進度無疑是確保專案成功的基本動作，相信大家都能了解這個道理。但事實上，在軟體專案的開發過程中，要完全做到卻又發現窒礙難行，因為軟體開發本身存在著抽象性與變動性，要事前就規劃好整個專案的時程，恐怕只是個無法實現的理想。

然而，雖然「計劃趕不上變化，變化比不上老闆一句話」，但趕不上或比不上並不代表要放棄計劃，否則專案的成功也只是聽天由命的偶然罷了。同人認為，軟體專案要成功，關鍵不在於如何照計劃進行，而是要「計劃」當計劃趕不上變化時該怎麼辦。換句話說，當軟體專案管理者把計劃當成死的名詞時，他將不會成為稱職的專案管理者；稱職的專案管理者會把計劃當動詞，用以採取適當行動，才會讓專案走向成功。

實際上，根據同人在軟體專案開發的實務經驗，期待專案問題藉由收尾巴的過程而得到解決的想法，往往是要付出很慘痛的代價的，但許多人總是無法從這些慘痛教訓中得到啟示。在專案後期所發現的問題、或產生變動，其所花費的成本與消耗的開發人員的青春，與產出軟體的功能與品質相比往往是划不來的。於是，歷史不斷地重演，軟體開發的痛苦經驗也一再地被經歷。

問題並不在於軟體功能無法說加就加、說改就改，而是在收尾巴的過程中自廢武功。不根據需求的變動或軟體的現存問題規劃出合適的架構與概念設計，現存設計怎麼會有足夠的空間來容納新功能？就好像想在堆滿東西的房間中，還要硬塞一些東西進去，這樣的結果當然很容易會讓我們在這房間中跌倒。

為什麼不採用較為務實的做法呢？在放新東西進去前先好好地整理一下房間，把不必要的東西收起來，才能有足夠的空間放得下新東西呀。增加軟體功能也是同樣的道理，根據需求思考現有架構及設計概念如何適當地做調整。

只有設計概念的完整性才能幫助我們形成簡單可行的計劃，然後才能讓軟體開發者採取更有效的行動，否則在變化無常的情況下很容易讓專案成果失去控制呀。這或許就是 XDite 所說的「完全不想去理解技術方面的事」的人最容易犯的毛病，簡化軟體開發的技術問題，認為一切只是 INATT（It’s not about the technology）。

理論上，專案管理中的專案收尾過程（project closeout）本來就不是用來讓開發者增加功能、修改缺陷的，而是吸取專案的經驗及教訓（Lessons Learned），以利後續專案當作規劃參考。因此，期待在專案收尾巴才來修改軟體的想法，事實上，正代表著專案在規劃、執行及控制的過程中有所遺漏。然而，一廂情願地認為收尾巴可以彌補這些在專案過程中的遺漏，這種想法實在是太過樂觀了呀。

Powered by ScribeFire.

Please follow and like us: