程式碼全部寫完，但工作還沒結束

需求無法收歛、整合工作不如預期簡單、不如預期快速，都是影響到專案難以收尾的關鍵原因。而且，我們會對專案有「難以收尾」的印象，往往是因為我們太低估這件事情的難度及複雜度。

攤開許多專案的專案時程表，時常可以看到整合階段及測試階段所需的時間，還有資源，事實上都遠遠被低估。例如，時程表上可能為整合階段安排了兩個月，事實上，最後可能卻花掉了四個月；而測試階段或許安排了一個月，最後卻也花掉了四個月。

這種預期和現實之間的落差，又怎麼能不叫專案經理、團隊成員、甚至是客戶，打從心裡覺得這專案「怎麼如此難以收尾」呀。

低估收尾所需工作及時間的習慣和心態，正是專案難以收尾的重要原因之一，有時我們可以說，不是難以收尾，而是根本就估錯了收尾所需的工作及時間，自然會覺得收尾很難。

有些人總是認為，個別的模組程式都開發好了，距離專案完成，也就只差一小步了吧？只要把它們整合在一塊、然後花時間測一測，不就可以大功告成了？如此期待當然十分美麗，然而現實總是格外殘酷，劇情也不會單純地依照想像上演。畢竟，軟體專案不同於總是讓王子與公主從此過著幸福快樂日子的童話故事，專案的成員必須用如臨大敵的角度來看待收尾的工作，千萬不要以為程式碼都寫得差不多了，專案就幾乎到了完成狀態，事實上，還有很多的工作等待處理。

局部需求的異動，往往又影響到更多環節
在專案規畫上，必須接受需求難免會有改變、增加情況，進而做出適當的安排。到了專案尾聲，一旦牽扯到需求的改變，影響層面便可能很廣。因為一旦需求有所擴充或調整時，往往不僅只是需要改寫程式碼，甚至有可能會衝擊到設計。倘若改變波及到主架構、或核心模組的設計，那麼由於主架構和核心模組都是系統中被高度相依的，所造成的影響便格外的深遠。

主要設計若被需求變更所擊中，那麼相對應的各種設計，也可能需要進行配套的調整，接著再重新改寫必要的程式碼、然後重新進行單元測試，接著再行整合，最後再重新進行整合測試。

由於軟體程式碼天生的複雜特性，有時往往是牽一髮而動全身。每次的修改都有可能引發完全無法預料的副作用，接著就必須花費極多的時間，才有辦法找到問題然後加以修正。

既然需求的變動是難以避免的，那麼，在設計上考慮需求有可能變動，提前做出因應，甚至採取能適應變動的設計，那麼便有能力在需求發生變動時，降低因為改變而造成的影響、同時縮小影響的範圍。

有些人在從事設計時並不會考慮到可能會有的變動，雖然他們的設計能夠滿足當下的需求，但是，當需求有所改變時，想要擴充、調整他們原先的設計，代價就會十分高昂。所以，好的設計技巧其實有助於縮短專案的收尾階段。當設計者能在一些好的設計原則之下，運用好的設計技巧，使得所做出來的設計能夠達到更佳的擴充性、彈性，而且在面對需求改變，也能將改變限制在較小的局部範圍內、同時降低所做修改引起副作用的可能性時，那麼，在收尾階段遭遇到可能的需求變更時，便可以花費更少的時間及力氣。

面臨程式碼結構不夠理想的困境
專案收尾階段，能讓團隊設計能力的優劣高下立判。相同的，團隊的程式碼結構是好是壞，到了專案收尾階段，通常也能顯現得一清二楚。

軟體專案的進行，本來就是一個不斷評估現況、不斷針對現況和目標的差距進行修正的過程。在過程中，團隊可能會發現各種和計畫不同的項目，例如所認知的需求和客戶不同、所做的設計其實無法滿足需求、或者像程式碼的實作錯誤等等。到了專案後期，其實整個專案可以說是累積了一路上各種修正的產物。有時候，在有期限壓力下，人們難免被迫要做一些抉擇，在時間上求快及完備的解決方案之間，選擇了快、但不那麼「乾淨」的作法。這些作法隨著專案進行一路累積，往往就讓程式碼結構逐漸走向了敗壞的道路，不是變成了疊床架屋的奇怪建築，就是成了面貌可憎的大怪獸。

同樣的，到了收尾的階段，這個疊床架屋的奇怪建築，可能會遭受到各種考驗。例如，需求只要一改，最後自然會演變成程式碼的更動，或者，在經過各種測試之後，發現了程式碼的問題，進而必須進行修正時。而在面對充滿各種疊床架屋作法的程式碼，想要做一些改動時，我想大多數的程式設計者的心情，都是十分無奈、不知從何改起的。

結構敗壞的程式碼或許可以運作，但是，一旦你要去更動它時，就會顯得險阻重重。例如，它的問題可能出在相依性極高，想要修改一個小地方，可能得要修改到為數不少的其他部份，而且，更可怕的是，你可能不知道自己是否修改到所有需要修改的地方，因為需要修改的東西散落在程式碼四處。好比利用「複製、貼上」手法將某一段程式碼「重覆運用」在各地的方式，就很容易造成這種情況。一旦發現最先被拿來複製的那段原始程式碼，必須要修改（不論是因為需求改變或內有臭蟲），所有基於這段程式碼的「分身」，都必須跟著「本尊」一起同步改變。倘若有八萬六千個分身，那麼就得徹底找出它們，然後把它們變得和新本尊一樣才行。一旦有所疏漏，那麼修改就不完全，問題也不能真正根除。

有一些軟體專案之所以在收尾的時候，問題層出不窮，便是因為程式碼結構日積月累各種快速「dirty」解決方案，使得專案到了後期，面臨需求變更或測試修改的考驗時，付出了極為沉重的代價。

如同電影《無間道》有云：「出來跑的，遲早要還」。而在專案前，中期抄捷徑，通常就是在專案後期償還更多，而且還要加上利息。

程式碼結構愈糟，在這一個階段要經歷的折磨就愈痛苦，想要看到專案收尾完成的難度就愈高。

開發過程中沒有妥善解決的問題，都有可能在收尾時爆發
所以說，到了專案後期的各種不可預料的事情，實在太多，有客戶拼命增加、修改需求，好不容易個別的模組看起來都寫好了，整合起來卻是問題百出。最糟的是，竟然發現需要變更主要的核心設計，而這個設計一變，一大堆設計都被波及，而大量的修改，導致程式碼品質低落，測試好像沒有終止的一天。這都是很多專案在收尾時可以觀察到的現象。

收尾絕對不是一件簡單的事，會這麼的困難，其實是因為那時所要處理的是，整個專案執行過程中，一路下來所累積的所有錯誤。偏偏，許多人都沒有意識到，自己在這個階段即將面對的，其實是如此艱困的環境，然後低估了收尾的困難度。

我們這次談到了幾個可能造成難以收尾的原因，這些都有可能透過專案管理、軟體工程、設計技巧來加以改善，降低專案收尾的難度。只要能重視這些問題，其實是可以透過各種方式來處理，但如果只是抱持著輕視的態度，那麼難以收尾的情境，可能就會一而再、再而三地重演了。