(http://www.lifeparty.idv.tw/blog/archives/321)以下內容經過縮減，全文請參考原作
軟體專案開發常常會面臨時間不足的問題，尤其在台灣，Price on Cost更是不容易達到的理想，迫於現實，開發者只能硬著頭皮上陣去執行不可能的任務。但最後的結果卻常常是賠了夫人又折兵。即使透過不斷地加班，任務依舊還是無法完成，而且還會造成團隊士氣低彌，使得開發者缺乏工作的成就感與滿意度，甚至使專案開發人力大量流失。
其實大多的軟體開發者都期望專案能爭取到足夠的開發時間，不希望他們的青春浪費在無意義且永無休止的加班上。然而，軟體開發的現實就是如此殘酷，受到開發組織的營運面影響，通常專案總是很難爭取到足夠而充裕的開發時間。
工程與技術的妥協
因為軟體價格實在太低了，開發者只好捨棄一些可以增進或維持軟體品質的作業。結果軟體品質就會變成時間允許才能夠達到的一個理想，而現實通常是「時間總是不夠」。
當軟體專案把軟體價格當做專案成本估算的基礎時，這樣軟體開發就會沒辦法重視專業，只能讓外行（市場因素）領導內行（研發設計專業），軟體開發者的痛苦夢魘於是從此開始。
現實就是這樣，專案就是難以爭取到足夠的充裕時間。但這樣要如何才能達到專案不可能的任務呢？從筆者在工作上的觀察中發現，不少的管理者會將這個問題焦點放在團隊生產力上，以提昇軟體的開發效率來縮短開發時間。不過，實際上卻不見軟體開發成果獲得到顯著地提昇。
生產力的迷思
管理者會希望軟體開發者加班或是增派開發人力，軟體開發每日的總工時增加了，照理說應該是可以增加軟體開發的效率，但卻也因此引發出新的問題，也就是軟體開發出錯的機率也會隨每日工作時數或開發人力增加而增加，反而降低了軟體開發的效能。
為什麼會這樣呢？綜歸一句話，增加了生產力卻讓軟體開發變得更複雜，使得團隊無法有效整合、發揮綜效。而這種現象又可從兩個方面來看，一方面是加班讓開發者身心耗弱、無法集中心力來完成任務，因此常因為工作上的疏忽而產生錯誤，反而讓問題變得更複雜，需要花更大的心力才能解決。
理論上，壓縮專案時程可以運用趕工（crash）或作業重疊（fast tracking）的方式來減少開發時間。趕工必須讓工作者加班而增加開發成本，作業重疊則會增加工作產出重工（rework）的風險。因此，似乎只要多付一些成本來支應加班的需求或加強風險管理，應該就可以達到時程壓縮的目標。然而，由前面的分析我們卻可以發現到，軟體開發的複雜度其實是經常超乎我們想像的，由此可知，軟體專案的時程上的妥協其實是很難用成本來彌補的。
筆者最近才聽到朋友告訴我一個軟體專案失敗的案例，該專案是以另一個將近結案的專案為基礎。原來他評估勉強半年可以完成，本來公司把專案交由他負責，但最後專案經理卻因為客戶的意見而交由負責該客戶的業務來掛名，實際上專案則由我的朋友來負責開發該專案。
然而，當我的朋友才開始需求訪談時，專案經理卻告訴我的朋友他程式開發時間要在三個月內完成。而在我的朋友在研讀前一個專案的程式碼，以求了解程式架構以後才能根據客戶需求加以修改，那位專案經理卻要我的朋友立刻著手動手修改程式，問題留待後面再來處理。
雖然我的朋友還是在時限內完成了程式，不過，這時候問題才真正開始。客戶驗收後提出了上百個程式錯誤。這時候我的朋友才發現，這專案所依據的快結案的專案本身就有很多問題，並不是像那位專案經理所說的「沒有問題」，因為有 3/4 的 bug 都是那個專案本來就存在的問題。
此外，客戶還提出了一些原先沒談到的需求，而那位專案經理則要求我的朋友要在不增加時間的情況下予以照單全收。因此在需求不斷膨脹的情況下，這個專案最後還是失敗了。當然，最後那位專案經理把失敗的所有責任都推到我的朋友身上。
相信任何有經驗的軟體開發者看到這故事都會了解，那個專案經理實在是太外行了，他以為軟體開發只是依據客戶的需要來產出程式，認為只要壓縮開發者的時間來產出更多的程式就可以解決問題。卻殊不知軟體開發在缺乏產能的情況下，再多的產出也只是徒增軟體的複雜度與風險，這樣要成功地達到專案目標只能靠聽天由命了。
開發產出與產能之平衡
由此可知，在專案開發時間不足的情況下，用生產力的迷思所生產的程式產出，其實多半是無法具有實質效用的。因為開發者在龐大時間壓力是很難會有思考的空間，將使他的產能逐漸耗竭殆盡。即使在剛開始，可以一時滿足了客戶的需要，然而長久下來，卻在無形之中增加了專案的複雜度，最終只會在耗盡了開發者的青春與熱情之後，得到專案失敗的苦果。
因此，在專案時間不夠的情況下，要達成不可能的任務必須要提昇軟開發的產能，必須讓開發的產出與產能可以相互配合。但至於要如何增進良好設計架構的產能呢？依筆者在軟體專案開發的實務經驗來看，關鍵在於必須同時兼顧客戶價值與開發風險。而要做到這一點則必須要讓開發者與客戶充分溝通，讓專案產出確實可以為客戶創造最大的價值，同時也能有效地降低專案的風險。
筆者常觀察到許多開發者習慣把客戶提出來的功能直接當做軟體需求規格，卻沒有深入分析客戶真正遇到的問題。他們以為問題領域、業務流程或現場作業等知識是客戶的專業，開發者無從介入，因此往往在不知客戶要求之所以然的情況下，直接把客戶的話轉換成軟體規格。
然而，客戶所知道的並不是軟體需求（requirements），他們對系統的觀點只能顯露出他們對系統的需要（needs）。需要是抽象而片斷的，本身是非結構化的，而可用的軟體需求卻必須是具體而完整一致的，具備結構化的特性。
因此，如果開發者沒有針對客戶需要分析他們的問題，設計解決方案，只是直接把客戶的想法直接轉成軟體規格的話，客戶心中想的那朵雲，隨時都會變幻出各種不同的形狀，需求不斷變動當然是必然的，如果開發者沒做適切的分析及設計，只靠技術是很難滿足客戶多變的渴望與需要的。
事實上，軟體開發是知識與腦力密集的工作。自許為知識工作者，重要的不在於產出的數量，而在產出的品質。要讓產出具有足夠的水準，必須要有足夠的時間在問題領域的分析上，才可能為客戶設計出可以解決他們問題的軟體，為客戶創造價值；也才能讓軟體具備足夠的彈性來適應客戶千變萬化的需求，有效地降低開發風險。
要如何充分溝通？
於是，當我們用以上的思路來看軟體開發時，縱使專案沒有足夠的開發時間，我們依然要會從客戶的立基點中去思考問題，並從中找出最可行的技術來創造客戶的最大價值。同時，在這樣的情況下，開發者展現了足夠的專業，客戶也會很自然地信任開發者誠意與專業，形成了良性的雙向溝通。
在這種客戶與開發者良性溝通的情況下，客戶可以決定了時程、成本、品質等限制條件，而專案範疇的限制條件則應該由開發者與客戶溝通後依業務需求及技術架構的取捨來決定。這也就是說，客戶提出他的問題、以及希望解決的時限及願意付出的成本。開發者則應該針對問題分析出需求規格、發展出技術架構，並據此實作出軟體後再交由客戶驗收。然後客戶再依軟體實際使用狀況予以回饋，開發者再依照客戶的意見反覆地演化系統，以使軟體更趨於完善。
客戶應該優先提出最關鍵及最核心的業務問題，而開發者則必須針對這些問題分析，發展出軟體需求、找出解決問題應採用的技術與方法、優先將最高風險及最核心的架構與程式實作出來。如此客戶最重要的問題可以優先被解決，而開發者也可以針對客戶問題而設計，而不會浪費時間與成本在過度設計上，降低了軟體開發的風險與複雜性，使得產出與產能可以相互配合。
開發產出與產能相互平衡，才不會偏廢於需求面或技術面，使技術可以面對現實地解決客戶的問題。就算開發時間真的不夠，至少也可以用空間換取時間呀。因為無論如何，客戶至少都會擁有一個可用的系統，而不是一堆無法正常運行的程式碼與文件。
在水深火熱的時間看到這文章，也為時未晚。我對這文章也有同感，我們正面對的正是不斷加班，而且不了解老師想要的和技術的可行性，結果做不完便把失敗的所有責任推到我們身上。我們得要思考箇中原因，我們花了太多時間去寫程式，往往因需求不斷改變而未能完成。
老師的需求不是軟體需求，這個是重點，你們一定要牢記。我們設計軟體是要解決問題，應付千變萬化的需求是要解決的問題之一，不然我們為什麼要讀OOT和AOOT。給自己一點時間，想想老師真正想要解決的問題，檢視自己寫過的程式，修改甚至重新設計以便之後能應輕易面對不同需要，只要我們的程式能輕易應付不斷變化的需求，和不要接受不可行的要求(時間不許可也是原因之一)，就是治本的方法。
