OK！上一篇最後講了個我親身體驗過會讓人掉san值的專案開發經驗，但.......那個專案最後還是完成並驗收了。

不要懷疑！它確實有辦法完成並通過驗收。
但就算拿那些根本沒辦法驗收的專案來相比較，它依然是個失敗的、「用自己的速度走向死亡」的專案！

因為...
雖然最終有成品產出（好讓公司跟客戶收取費用），但開發過程中需求頻繁修改，導致根本沒有個前後一致不矛盾的模組框架，會讓這個專案後續肯定很難擴充維護。
如果沒有後續的擴充或維護，就表示這個專案能帶給公司的商業效益就只有這場「冗長且讓眾多開發者疲憊且痛苦的開發任務」而已。（至於為什麼會讓專案難擴充維護？這要另外說明了。）

而且團隊成員之間的信任度幾乎是破產，就算未來要重啟全新的專案，可能「運作」起來也會缺乏效率......
這點在我來看是最要命、偏偏是很多專案公司的管理者不太當一回事的地方。
因為在他們的認知中，「人再找就有了！能力不適任、不願配合專案需求，就把人辭退換掉就好了！」

明確的讓專案團隊感受到這種「你是可以被我輕鬆替換淘汰」的恐懼，幾乎就是今天業界專案管理技巧的全貌了！

並不是說「懂專案管理的人都死光了」，而且這種「讓人感受到恐懼後不得不驅使自己產生動力去完成任務」的做法根本也不是專案管理認可的技巧。
但看看人類現存的社會與過往的歷史，這「運用恐懼去操縱別人」的思維和行跡倒是四處可見。

我不是要在這邊開始打不切實際的高空。
應該不會有人認為每個管理者或專案團隊都可以像漫畫航海王中的魯夫那樣，一路順利的招集到一幫願意為了讓自己成為「海賊王」而拼死戰鬥的團隊。——這點常識我還是有的。
如果魯夫來到真實世界，可能連載還沒破一百回以前，就要先被索隆們背刺個一兩次、忍受娜美得罪客戶三五回、收到騙人布任性的辭呈七八封、發現香吉士整天就想著把辦公室的年輕美眉約出去開房間（真正的偉大航路其實是「整座城市的賓館」）。

眾多管理者要面對的現實是：聆聽完別人的理念藍圖而願意為此在戰場上迎向死亡的勇士少之又少，平常貪圖享樂又畏懼刑罰、只能膽怯地站在軍隊陣列中幫忙壯聲勢、希望可以碰到好運嚇退敵人的懦夫卻多如過江之鯽。
不管是「先有（管理者）差勁的管理，才有（員工）頹廢的工作心態」，或是「先有（員工）不思進取的性格，才有（管理者）只能求自保的粗暴管理」，或是兩者同時發生...成功如果很容易，那成功一點都不稀奇，更不值得大家肯定讚賞並把「研究成功案例」當成顯學。