（終於可以講這個了.......嗎？）

如果能夠不用「是否有成功通過驗收並結案」來判段專案是否成功，那這個標題其實很好懂。

像：是否有留下成功的工程經驗方便下一次專案進行得更順利？
像：是否有留下成功的設計模式方便下一次專案進行得更順利？
像：是否有建立成功的商業模式方便下一次專案進行得更順利？

即便是「無法驗收的專案」也有可能在這些問題上得到「是」的答案。

但偏偏很多專案團隊在業務上總是抱著一種「客戶喜歡垃圾就給他垃圾」的心態，請問花了大把工作天去完成的專案，最後團隊成員學到的盡是「如何產生垃圾去給那些沒品味、短視、仗著自家有集團規模優勢裙帶關係可以揮霍的客戶在專案驗收會議上得意的簽字買單」，那團隊大概一輩子都只能跟「產生垃圾」的勾當為伍。

對很多專案團隊管理人來說，這是很划算的，因為他的個人職涯看重的是團隊的「營業額」，只要這次的團隊結案了、錢進來了，他在跳槽下一份工作時用的履歷上就會有一筆更漂亮的數字。

但對其他人來說可能就不是那麼回事了。

工程師是否有機會驗證自己的專案架構？設計師是否有機會實現自己的美學認知？（忽然忘了這到底是什麼東西？）產品企劃是否有機會建立自己的商業概念？......不！大家得到的只是「另一件垃圾」而已。

這跟標題有什麼關係？

我的主張是「專案會死掉，除了專案團隊本身的管理溝通技巧與工程設計能力以外，其實很多都是政治（權力）考量長期介入扭曲了一個團隊運作的最終結果。」

像（之前有提過）「為什麼要大量導入第三方OpenSource的元件」？——因為「決策者以為這個世界上真的有那麼輕鬆容易就降低成本又快速滿足客戶需求的方法」。（最後專案可能就會因為在技術上使用了缺乏驗證的元件，管理者又拒絕花費更多時間成本去進行修正，最後導致驗收失敗......這是其中一種可能。）

像最近很火紅的「敏捷式開發法」，——用我的說法，其實敏捷式開發法要真能充分運作，每階段任務在規劃時就要考慮到「需求還沒有提到的地方」。
像本來用在A環境下的X功能，忽然會被遷移到B環境，如果兩個環境無法提供相同的初始化條件，那X功能就會無法搬移，當收到搬移的需求時，要重新大規模修正元件？要重新大規模測試元件？還是要重新大規模修正環境？要重新大規模測試環境？......通常專案團隊會怎麼選擇，答案有點明顯，問題是「避免這種事情發生」也是「敏捷式開發」的目標與功能之一，真發生這種事情時怎麼選則就不是那麼有營養的一件事。
但先不論「敏捷式開發」的「敏捷不等於快」，為了讓開發過程富有彈性、能夠應付修求更動，需要建立的團隊規模與運作模式，這些也都需要成本（金錢/時間），但這種成本通常.....所以敏捷式開發的命運經常......

故，那些註定要沒什麼用的專案開發法。