S22 專案的痛苦在投入時間的不足

常聽人說專案給的時間都很緊迫所以沒法把設計作好，有次我就反問同事說如果現在有個專案給的時間非常充足，那會怎麼做來作好設計呢？他想了一下暫時沒有答案，不過我倒開始思考壓迫時程之後會造成設計上的什麼問題。

兩點之間最短的距離是一直線，完成功能最快的方式就是只直接寫出達成所需的全部動作，其他狀況就依經驗想得到的就做，所以此時完成的程式根本只夠做出達到目標的動作，沒空細想可能的變化。這樣先天不足的設計，若加上寫的人想偷懶只先寫一部分其他等測到再寫的後天不良，在動作層次不分、判斷條件不足的情況下如果測得出來問題就算幸運，沒測出來等客戶測到或是上線才爆發，那可只有一個慘字能形容。

客戶需求變更的管理是讓系統穩定的因素，但是時程過趕的狀況下，SA與SD沒有完全收集到Use Case應做的全部動作，未來發現缺少動作時就得再補上。一般無關緊要的動作直接補就沒事還沒話說，就怕缺少有關鍵性影響的動作與根據之前資訊所作的設計有所衝突，此時每加上一個就像一次重大的需求變更（或是需要抽取與分派的狀況卻無法重構而硬塞許多重覆的程式碼）。在這種狀況下作出來的設計怎麼可能有穩定的品質呢？

有次與總經理談話的時候他說：管理階層解決問題才是眼前重要的事。但是眼前的問題卻是之前專案模式所殘留下來的後遺症，再加上人設計程式時被測試抓到一項才承認一項的惰性，因而形成令人詬病的品質問題，到頭來需要投入更多額外的人力去找出問題。麻煩的是找到問題後即使知道怎麼改也會擔心影響其他大部分已經正常的功能而無法從根本改起，進而造就疊床架屋式的結構。