如何破壞一個項目:項目破壞者伎倆大觀

　　Anders Abel是生活在瑞典斯德哥爾摩的一位軟件開發者，他在自己的網站上撰寫了一系列文章，箭頭直指“項目破壞者”。

　　該系列的第一篇是《項目破壞者手冊》，他在其中列出了自己在多個項目中遇到的破壞項目的方式。

　　首先，他指出了破壞一個項目的關鍵成功因素：

　　有些領域對于項目成功至關重要，要把人們的注意力從這些領域吸引開，而且要耗盡在這些方面投入的精力，任何能夠達到這些目的的行為都是允許的。使用你的想象力和創意，確保你永遠不會放過任何一個讓項目一步步接近失敗的機會。

　　接下來，他提供了一些讓項目失敗的策略。

　　關注邊界問題

　　項目中有很多處于最高優先級的關鍵因素，優先級低一個等級的是重要的問題，然后是大量的相關問題。很多項目沒有足夠時間去應對所有相關問題。

　　破壞者應該關注的是下一個層級：最細微的邊界問題，這些問題通常被忽略，但不能輕易作為相關問題排除掉。類似問題比如：

　　你能證明操作系統廠商剛剛發布的KB12345補丁沒有兼容性問題嗎?(要啃完操作系統補丁的發布說明得花大量時間，提供證明耗費的時間更多。)

　　如果用戶在“姓”字段里面輸入數字怎么辦?

　　對于下一個版本的IE/Windows/其它什么，必須要做出哪些變更?(挑任何一個目前只提供有限可用信息的RC版本的軟件吧)

　　這些問題特別有效，能達成兩個目的。首先：解決這些問題，項目中的技術專家需要付出時間和精力，因為這些問題沒有正確的答復很難忽略。其次：管理層會認為項目破壞者有很好的技術知識，能夠提出技術專家無法回答的問題。關鍵是：提出這些問題不需要精深的技術水平，只是看起來如此。

　　提出不理解答案的問題

　　提出確實需要答案的問題，但是你不具備理解這個答案的知識，這會讓所有人都感到不平衡。問問為什么HTTPS會話可以保證信息安全，雖然它的算法人所共知。從數學角度解釋加密算法很復雜。只要提到算法背后的數學問題，那就要他們給出一個非數學的解釋。如果項目中有人知道如何從數學角度解答問題，這就會讓他們瘋掉，因為要簡化這些答案，同時又不失重點，難上加難。

　　不寫文檔

　　文檔是對破壞的第一號威脅。盡量讓文檔越少越好。幾個月前的官方會議準確記錄會扼殺很多“創造力”【譯注：這里指破壞項目的創造力】。沒有文檔，就很容易歪曲真相，從而怪罪其他人。防止產出優秀文檔的最簡單方式，就是主動要求做會議記錄，然后無視任務部分(參見下面的無視任務)。如果你主動說要發送記錄，就沒人會再去做詳細記錄了，也就不會留下文字記錄。

　　避免清晰的決策

　　與文檔一樣，清晰的決策對破壞者也是威脅。討論要稀里糊涂，沒人知道有哪些決議，應該做些什么，這樣最好。技術人員的工作效率會迅速降低，同時也能為破壞項目的創造力提供更大空間。

　　無視分配給你的任務

　　破壞者所能做的最好的事情，就是無視所有任務。不僅如此，還要無視與任務相關的問題。堅決否認存在與任務相關的任何知識。如果沒有文檔說明分配給你的任務，很可能你就不用完成它了。要調動一切說服力，證明你從不知道這個任務。除非是最強硬的主管，所有人都會質疑：這些任務怎么會應該是你負責?

　　把焦點放在別人的少數缺點上

　　有時，會有人發現你幾乎沒做什么事情，而且試圖怪罪于你。要無視證明你自己沒有干活的明顯證據，最好的防守，就是把焦點放在那個人的缺點上，包括他工作中的任何一點小問題。問題越小，那個人的野心越大，那么指出他的問題，對他造成的傷害也就越大。當你的對手開始給自己辯護時，大家的關注點很快就不再是你的失敗。

　　沒有綱領或條理的會議

　　高效會議的關鍵是按照大綱開展有條理的討論。盡量避免大綱。如果一個討論行將結束，這就標志著要有決議了。這次，你應該迅速將討論從當前問題上轉移開，避免清晰結論。具備正確的技巧，能讓同一個問題在多次會議中反復討論，而不會得出任何決議或結論。對于有價值的項目時間來說，這是絕佳的黑洞。

　　在評論中，Pia Fåk Sunnanbo引用了CIA現在已解密的“敵方區域破壞簡單指南”：

　　下面這些東西破壞者用起來可能很方便：

　　(11) 組織或產品通用干擾指南

　　(a) 關于組織和會議

　　(1) 堅持一切事情都要通過“管道”完成。絕不允許為了加快決策采取任何捷徑。

　　(2) 發表“演講”，盡量多發言，長時間發言。使用冗長的軼事和個人經歷說明你的“觀點”，在做出一些“忠心愛國”的評論時，絕不猶豫。

　　(3) 盡可能讓所有的事情都提交委員會討論，以“進一步調查和研究”。要試著讓委員會人越多越好，絕不要少于5個人。

　　(4) 盡可能多說不重要的問題。

　　(5) 斤斤計較通信、記錄和決議中的精確用詞。

　　(6) 再次討論上次會議決定的事情，并盡量重新討論當時的決議是否恰當

　　(7) 倡導“小心”。要“理智”，督促你的與會者要“理智”，別急著動手，避免以后造成尷尬局面或是困難。

　　(8) 擔心任何決議的所有權，提出問題，指出計劃的行動是否屬于當前這群人的管轄范圍之內，或者它是否與高層的某些政策沖突。

　　他指出：任何參與過大型項目的人，肯定都見過其中大多數條目成為現實。

　　Johan Svard在評論中提到：

　　我想你忘記了軟件開發人員。我們也很善于這樣的游戲：

　　反復聲明：你已經完成了 直到有人推動。 這會讓人與人之間充滿不信任，而且，你將最終有機會假裝成為錯誤對待的受害者。“為什么你總要問我?這是騷擾!”此言可讓最好的會議陷入僵局……

　　選擇Sprint、項目或是其他工作中的核心任務，然后丟在那里一兩周。再交出來，還要說：“我不知道怎么做。”

　　讓團隊中資歷最淺的人做最復雜的工作，還要掩飾以好意：“這對他發展有好處。”對項目可不是這樣……

原文轉自：http://www.infoq.com/cn/news/2013/02/ways-of-project-saboteurs