“項目破壞者” 手冊
英文原文： The Project Saboteur’s Handbook
要想將一個開發項目搞砸，有很多種方法。開發者 Anders Abel 將他經歷過的項目中的破壞者的軼事整理成了一個手冊，如果你想搞砸你們公司正在做某些軟件項目，完全可以借鑒這個手冊中的方法。（項目管理者不必擔心，我 后續會寫一篇文章來講述如何應對這些招數。）
成功破壞一個項目的關鍵是要從對項目最重要的地方下手，將開發者的注意力從最重要的工作上轉移走，并耗盡開發者的精力。用你的想象力和創造力，不要放過任何機會，將項目一步一步拉向失敗的邊緣。
下面介紹一些主要戰略，一定要認真領會、學習。
1. 專注于邊緣問題，以證明你知識淵博
在一個項目中，都有幾個關鍵的、能夠促使項目成功的因素，它們擁有最高的優先級。其次是一些重要的問題和一些相關的問題。大多數項目都沒有足夠的時間來顧及所有的優先級。
作為一個“知識淵博”的破壞者，你應該關注別人往往不太關注的地方——最邊緣的問題，但同時不要忽視這些邊緣問題相關的一些問題，比如，你可以質問其他開發者：
- 你能保證不存在兼容性問題？微軟剛剛發布了一個操作系統補丁 KB12345。（了解系統補丁對軟件的影響需要大量的時間，拿出證據需要更多的時間）
- 如果用戶在姓氏字段中輸入數字，會發生什么情況？
- 在下一代 IE、Windows……發布時，我們需要做哪些改變？ </ul>
此類問題相當有效，可以很容易地將其他開發者的注意力轉移走。這需要破壞者有一定的水平，來問一些技術專家難以回答的問題，最好的方式是不要問技術深入的問題，而是問一些沒有合適答案的問題，這樣就不會被輕松駁回了。
2. 問一些你不理解答案的問題，并堅持弄懂
比如，一個問題已經有了答案，但是由于你缺乏必要的知識，而不能理解。比如，HTTPS 會話安全是如何實現的（這個算法大名鼎鼎）。關于數學方面的加密算法相當復雜，只要提及算法的數學原理，再問一些簡單的非數學方面的問題，這有可能會將你問的人逼瘋的。
3. 拒絕文檔或會議記錄
文檔是你的首要破壞目標，盡可能少地寫文檔。一份幾個月前的正式會議的記錄，有可能扼殺很多創意。盡可能地不要文檔，且歪曲事實，把責任推給別人。防止產生高質量會議記錄的最好的方法是，主要要求做會議記錄，然后忽略一些方面（如何忽略見下文）。
4. 避免明確的決定
一個明確的決議，可以對破壞者的行為產生很大的阻力。最好方式是，當某些人明確說出應該如何做時，你開始含糊討論。如果沒有明確的的決定，開發者的生產力將急劇下降。
5. 忽略分配給你的任務
最好的破壞者應該忽略所有分配到的任務，同時也忽略掉任何相關的問題。如果分配任務時沒有任何文檔記錄，那么這將是一個很大的機會，比如，你可以說你從來沒有聽說過這些任務。
6. 專注于其他人的缺點
如果你以上的行為被發現了，在項目中你將很難辦。此時，你需要進行防守，最好的方式就是把重點放在其他人的很小的一個缺點上。沒有缺點？不可 能，你總會找到一些的。一個人的缺點越少，他的完美主義情結就越大，如果你指出他的缺點，他將更痛苦。那么，問題的焦點會很快從你身上轉移走。
7. 沒有議程或結構的會議
富有成效的會議的關鍵是圍繞一個議程進行結構化的討論。你需要做的是，避免議程。如果一個討論接近尾聲，這通常意味著馬上要做決定了，這種情況 下，你應該快速轉移討論的問題，避免做出明確的決定。然后，在每次會議中故技重施，這對于時間寶貴的項目來說，是非常致命的。
8. 消耗能量
請記住，成功地破壞一個項目最關鍵因素是在項目最重要的點上轉移開發者的注意力，并消耗開發者的能量。你可以使用各種方式來做這些事情。這是一場艱難的戰斗！向你“致敬”！