這些哭笑不得的情景，每個程式設計師都可能面對

每個程式設計師都經歷過專案的洗禮，你是專案成員還是專案經理？許多年過去了，那些讓你哭笑不得的場景是否依然沒有改變？幾位大牛將大量場景抽象為模式，以其幽默、深刻的洞察力講述了專案失敗的原因，這些原因跟每一位程式設計師息息相關。

1、工作忙亂是生產率高的表現

優先順序總是變化不休，所有事項都是“昨天”就要，總是沒有足夠的時間交付專案，每個專案都是加急專案，而且加急專案還在不斷出現。每個人都忙得焦頭爛額……永遠如此。

2、所有失敗的會議…

你經常開會嗎？你們會議得出的大多數決定都是正確的，且可以很乾淨利落地決策和行動嗎？還是會議組織雜亂，新想法層出不窮，主題不斷變化，新問題源源不斷，但卻沒有一個有答案。最終，大家在會議結束時安排了額外的會議。——所有失敗的會議最終都走上這一步，概莫能外。

3、死魚就在那兒

從開工起，專案就完全不可能完成目標，專案團隊中的大多數人都很清楚這一點，卻緘口不言。

很多組織過於看重成功，所以任何表達疑慮的人都不會因為說真話得到任何獎賞。事實上，如果誰在專案的前期階段就聲稱死魚的存在，管理層的第一反應多半如下：

“證明給我們看。給我們證明成功的可能性是零。不要拿以前專案的死魚經驗來唬人。現在的專案不一樣。請用嚴密的數學證明來告訴我們失敗無法避免。”

一旦你提出任何缺乏精確證據的東西，就會被指責為軟蛋或者是試圖逃避辛苦紮實的工作。

4、專案經理是保姆

快偷偷笑吧，這個好難得！

你所在的組織或許已經有一些“保姆型”經理，如果你留意，會發現：不必預約就能見到你的頭兒，或者不必在瑣碎和令人生厭的管理工作上花費太多時間。周圍是開放的氛圍，人們暢所欲言，互相學習。這種經理認為培訓或進修非常必要，而不是視之為燒錢。他們還會專門安排時間（比如早晨咖啡閒談或者週五下午閱讀探討），讓大家在一起討論新想法。

5、把靈魂賣給開發語言

合格的專業人士能夠根據待解決問題的實際情況來裁剪解決方案，而不是把個人或者團隊久經檢驗的技能強加在問題上。這不是說團隊成員不懂應用已知的工具或方法。他們沒有把靈魂賣給任何技術，換而言之，一旦出現了好的新思路，他們能夠比較優劣，明智地決策。

不把靈魂賣給開發語言的好處是，當技術潮流退去時，你不會在沙灘上裸泳。你可能知道，有些人自詡為開發人員，卻很久都沒有嘗試學習新的程式語言。這些人眼巴巴地搜尋提到自己所用語言——當年也曾風行一時，但現在基本不再使用的程式語言——的工作職位。悲哀就在於，他們把靈魂賣給了那種開發語言。

6、你們為什麼不是米開朗基羅

“我給了你鑿子，可你為什麼不是米開朗基羅？”這樣的疑問充斥在迫不及待希望立即提升生產率的組織，以及招聘時重視應聘者的薪水要求而非所掌握技能的組織。熱切人人都是米開朗基羅的組織內，架子上總是堆滿了各種工具。

沒錯，工具是有用的，在合適的人手中它們能大幅提升生產率，還可以完成那些本來無法完成的任務。但是，工具的構造者會告訴你，最關鍵的是，擁有對應的技能來使用工具。所謂鑿子，在米開朗基羅拿起它之前，只是擁有鋒利邊緣的鐵器而已。

7、影評人

影評人是團隊成員或者公司內部的旁觀者，他們認為自己對專案的貢獻在於，指出問題所在或者將會出現問題的地方，至於解決問題，那不是自己的職責。

並不是所有評論專案的人都是“影評人”，重要的區別在於選擇的時機不同。如果對專案的成敗負有責任感，人們一旦發現事情做得不對，或者可以做得更好，就會毫無顧忌地講出來。他們會走到他們認為可以發揮作用的人面前，講出自己的想法。他們儘可能及時地行動，因為他們知道時間總是有限的，糾正措施應該越早採取越好。這些人不是“影評人”，他們是跟你攜手並肩的“電影製片人”。他們知道自己和專案是一損俱損的，因此他們每天都會把問題攬在自己身上，以增加成功把握。

而“影評人”往往到“電影”結束，或者快要結束的時候才參與進來，此時已經沒有足夠的時間來採取糾正措施。

8、沉默即同意

利益相關方無法區分真正的贊同和屈從的沉默。承諾被誤解的情形通常是：一方表達了需求，然後另一方點頭示意明白。前者把這種情形理解為承諾：“我告訴他必須在12 月31 號以前完成，這非常重要。”後者則視為痴人說夢：“當然，他希望我在年底完成，但那不可能。”通常，提要求的人更有權力，而且他會依據法律上的格言“沉默即同意”來設定自己的期望。如果沒有對這樣的人物說“不”，就相當於在說“是”。

9、稻草人

“客戶只有看到了系統，才知道自己真正想要什麼……肯定不是那個系統。”

稻草人模型是一種需求釣餌。你給客戶一個激發想法的東西，試探出他們的好惡。這些模型都是快速完成的，而且因為它們不保證正確，所以不必花太多精力。由客戶來評審解決方案——比如說，“選定區域銷售主頁”介面——的實物模型、原型或者故事畫板。用這些東西模擬未來要交付的軟體，作為回報，客戶帶你走向真正的需求。

最好的分析師不會問：“你們想要什麼？”他們意識到這種問題通常會令人不快。人們討厭對著一張白紙設想答案，但樂意批評已經寫在紙上的答案。

10、貪多求全

組織想要貪多求全，就會影響速度，最終導致淨收益降低。但是那種誘惑可能是無法抵抗的……

承擔超出最大能力範圍的工作是降低速度的罪魁禍首。你大概從未見過有人如此坦率地指出數量和速度之間的關係，因為說出來絕對是令人不快的。正因為大家無視這個問題，所以如此多的組織會為了完成大量的工作而讓自己慢到幾乎動不了。如果他們暫停下來，從麥麩中挑出麥粒，就能明白停滯的原因是沒價值的麥麩太多了。

11、壞訊息

在組織裡，壞訊息不能準確向上傳達。

12、把壞訊息埋在心底

許多企業文化都會傳達一種訊號：誰發現了雜亂不堪的現象，誰就得負責清理。另外，指出問題，卻沒有立刻提出改進措施——這會被認為是在抱怨。而在很多組織裡面，抱怨者的職業前景相當有限。

13、記者

記者是指這樣的專案經理，他們認為，準確報告專案的情況與保證專案成功是兩個目標。

想一想記者報導飛機失事的情景。記者覺得自己有責任準確地報導哪架飛機失事了，發生的時間地點，飛機上有多少人，是否有人生還，但他不會因為沒有阻止飛機的失事而覺得內疚。那不是他的責任。

記者型專案經理也同樣如此。他們的報告清晰、準確、細緻，可以列為範本。他們清楚地知道“訂單管理”子系統延遲多長時間，偏離關鍵路徑多少天，這項延遲對依賴它的後繼任務有什麼影響。但是他們忽略了非常重要的事情：這個職位存在的意義，是要保證專案有個圓滿結局。

14、資料質量

資料質量往往異常低劣。很遺憾，常見解法竟然是尋找更好的軟體來處理它。

資料庫軟體的質量高出它所處理的資料的質量，這並不罕見，儘管對終端使用者來說，系統的質量受制於兩者之中更差的那個。各家公司的資料庫裡面都堆滿了不準確的，以及過期或不完整的資訊。問題就像鼻子長在臉上一樣明顯，但人很難看到自己的鼻子。即便每個人都能看出其他人的資料有問題，公司也很難去直面自己的資料質量問題。相反，公司看到的總是軟體與資料混在一起的問題。因為軟體總是比資料（資料量大得可怕）容易修復，所以公司樂意修復或者更新軟體。

這兩種做法都沒有意義，因為我們要討論的關鍵問題不是“為什麼我們不應該從軟體動手”，而是“為什麼明知不是軟體的問題，我們仍然從軟體動手”。

15、好想法不會很快被接受

更新、更好並不足以保證想法能立刻被接受，接受新想法需要時間。組織會抗拒變化，或者延長決策期，以推遲變化。但是發明和支援更好想法的人可能備受打擊，因為看到自己的建議被人忽略，或者被翻來覆去地考量。在軍事上，反反覆覆的思考被稱為“慢搖”。在做專案的這些年裡，我們看到幾乎每一個新出現的好想法都經歷過“慢搖”（至少在短時間內是這樣的）。舉個例子，即使在像軟體這種應該是高速發展的行業裡面，一些今天已經被廣為接受的最佳實踐也花了差不多20 年時間才被接受。

經典推薦

作者：Tom Demarco等
譯者：餘晟 金明
書號：978-7-115-39130-8
定價：49
頁數：207

第19屆Jolt大獎獲獎作品
《人件》作者又一力作
入木三分刻畫軟體專案眾生圖

“只要經歷過一兩個軟體專案的磨練，就能從書中找出許多熟悉的模式，也會從大多數模式中獲益。”
——Joel Spolsky，《軟體隨想錄》作者

“作者兼具十足的幽默感和深刻的洞察力。本書清楚地講述了專案因何而失敗，有何補救措施，並以極為友善且易於接受的方式提出了切實可行的建議。”
——Warren McFarland，哈佛商學院教授

“對於任何一位曾經在組織裡面從事過專案工作的人來說，86個專案模式熟悉得令人心驚。幸運的是，其中有一些模式是良性的，應該給予鼓勵。然而悲哀的是，剩下的絕大多數模式不僅僅令人心灰意冷，而且它們對生產率、質量和專案團隊士氣的破壞程度令人瞠目結舌。”
——Ed Yourdon，《死亡之旅》作者

“這本《專案百態》就是關於專案管理的實話集……讀這樣一本書，你會笑，更多的時候你會搖頭苦笑，甚至如芒在背。”
——熊節，ThoughtWorks中國公司首席諮詢師