摧毀程式設計師生產力的 12 件事
編者按：12件影響程式員效率的事情，看看你身邊存在嗎？本文作者 ofollow,noindex" target="_blank">John Lafleur ，原文標題 Top 12 Things That Destroy Developer Productivity 。
身為技術主管和工程經理，我們經常遇到的問題是如何提高團隊的效率。但是在你集中精力提高他們的工作效率之前，你可能首先要考慮是什麼在破壞他們的工作效率，並建立起良好的基礎。
程式設計師想要完成什麼工作，根本離不開電腦，但確實還有很多公司希望程式設計師不使用電腦就能完成工作（你敢信）。
因此，我們列出了12件阻礙程式設計師提高效率的事情。下面給出的順序是按最重要到不重要的排序的（從我的視角），請大家斧正。
其實吧，給程式設計師們加薪也是個好辦法，哪怕加薪10%，也能起到相當不錯的激勵作用。
1) 干擾&會議
在我看來，隨意打斷是程式設計師的工作最影響他們效率的事情。開發人員無法輕鬆回到被打斷之前的狀態。他們需要再次找到感覺，然後繼續上手原來的工作。干擾越多，挫折越大，質量越低，bug就越多——而且還在繼續。
我越被幹擾，效率就越低。每次被打斷了工作流程，我就得重新開始找感覺，所以如果我一天被多次打斷，這一天想要又什麼成果基本就不可能了。
——一位程式設計師如是說道
那開會呢？開會和干擾的唯一區別是，會議是有計劃的干擾，會讓事情變得更糟。如果程式設計師知道自己會在工作時可能會出現干擾，那麼他們就無法在工作中取得進展。因此，如果他們在一兩個小時內得去開會的話，幾乎無法在工作上取得進展，因為大多數工程任務需要足夠多的時間。
正如Paul Graham所說的，“一次會議可能會毀掉整個下午，因為它導致了大塊的時間碎片化，無法集中精力完成任何艱難的事情。”
如何才能避免這種情況？其實也不難，例如，在一天開始的時候或者午飯前開個短會，以避免給程式設計師們不必要的打擾。
2) 微觀管理
在不同型別的管理人員中，那些微觀管理人員可能最招程式設計師嫌棄。因為微觀管理人員往往手伸得太長，喜歡組織更多的會議，或者有計劃外的干擾——而且不僅僅如此，他們還對程式設計師缺乏信任，這樣一來，程式設計師會覺得他們在不斷地削弱自己的技能和完成工作的能力。這時候，程式設計師所有的工作盡頭就都沒了，這就不單單是效率的問題了。微觀管理人員可能是程式設計師離職的最主要原因，或者至少是更換團隊的原因。
3) 語焉不詳
語焉不詳也是導致程式設計師效率低下的原因。如果一份Bug報告裡面寫著“它壞了，把它修好”，這份報告裡沒有為程式設計師提供足夠的資訊。順便說一下，在這種情況下，如果你專門設定了報告模板能解決很多問題。
如果有什麼東西的含義非常模糊，然後程式設計師又錯誤地理解了意思，最終他們的努力就都打了水漂，一切就又得推倒了重來。
工作的優先程度也要弄清楚，你需要為程式設計師省下思考該幹什麼的時間。這樣一來他們可以全方位地投入到工作中，給你交一份滿意的答卷。
4) 運動式管理
你聽說過“運動式管理”嗎？最怕的就是領導們一般什麼都不管，然後突然哪天心血來潮，唰地“俯衝”下來橫插一槓，把所有的事情就都搞砸了。他們會口裡嚷嚷著“這樣不對，這是錯的，不行這樣不好”之類的話，然後拍屁股走人。更不幸的是，這種事情發生的頻率比我們以為的要高得多。這種行為讓程式設計師深感沮喪，然後在接下來的幾個小時裡，他們的工作被迫停止，有時甚至會耽擱好幾天的時間。
5) 把別人的功勞攬到自己頭上
還有一些經理或其他程式設計師把你過去幾周所做的工作全部歸功於自己。程式設計師最看重的是能力。把別人的功勞攬在自己身上，就是把別人的能力從他或她身上強行奪走。這種行為實在太過惡劣，因為我覺得這種行為在團隊之中製造了太多的緊張，在相當長的一段時間內它只會破壞整個程式設計師群體的效率，有百害而無一利
6) 周遭的環境——噪音啦、工作場所設計啦……
這對非程式設計師來說可能有些奇怪，但是程式設計師身處的工作環境對他們的工作效率有重要的影響。例如，有一些白噪音——交流電聲，車聲駛過——可以幫助他們更好地集中注意力。這就是為什麼我們很多人都戴著耳機的原因了。而且我剛剛發現雨聲也很棒。
同樣地，如果工作場所的設計乏善可陳，而且人來人往噪音很大，那簡直就要了程式設計師們的命了！或者從經理的辦公室可以直接看到程式設計師的電腦，這個會帶來額外的壓力，也會有更大的機率使得程式設計師的工作被打斷。
7) 不可控的變化
在某個專案範圍內出現不受控制的變化也是讓程式設計師痛苦的地方之一。當某個專案的範圍沒有正確定義時，這種情況很容易出現。
這種情況會導致相對簡單的請求變成非常複雜和耗時的行為。大多數情況下，它發生在開發過程中，這對程式設計師來說不啻為巨大的噩夢。
8) 產品定義過程
這個乍一看可能有點奇怪，但其實很容易理解。如果某個產品團隊在沒有驗證（通過客戶反饋或任何其他方法）相應特性的情況下定義了其團隊的優先順序，然後程式設計師又發現大多數特性最終都沒有被採用時，他們會覺得自己的努力是無用的，更糟糕的情況下會失去動力。我們或多或少都想有點影響力，這對程式設計師來說可能更重要。
9) 缺乏對技術引進的瞭解
技術引進是個比較複雜的問題，需要深思熟慮，從更長的週期來考量。如果說當前任務緊迫，或者一定要迅速將產品投入市場，那麼適當地引進一些技術是不可避免同樣也是合情合理的，並且可以在短期內提高軟體開發的速度。但是，從長遠來看，一味地引進技術可能會增加系統的複雜性，從而減慢開發速度。非程式設計師常常低估了效率的損失，並且總是傾向於突飛猛進，這就導致了重重問題。
但是，如果從來都沒有把自行開發列入考慮事項，那麼它不僅會影響效率，還會影響將來的產品質量。
10) 硬體以及工具不足
程式設計師們每天都會使用各種各樣的工具來程式設計。自動化程度越高越好。不用說，如果哪個程式設計師使用了比較“古老”的工具，那可能會影響自己的工作效率。同樣，大螢幕與筆記本電腦的對比也會產生影響。考慮到硬體成本和程式設計師的薪水，如果效率能提高5%，那就值得投資！身為經理，完全應該為開發團隊提供他們喜歡的工具和硬體（硬體單獨提供，工具就沒必要了）。
11) 無用的廢話
在學習如何編寫程式碼時，老師們教育我們要儘早和經常地討論。老師的出發點在於，多討論起碼可以增加思想的碰撞，比自己一個閉門造車要好得多。但不幸的是，許多程式員將其錯誤地理解為自己必須註釋每一行程式碼，這就是為什麼我們經常看到這樣的程式碼了：
r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}
你知道這段程式碼是做什麼的嗎？我反正不知道。問題是，雖然有很多註釋描述了程式碼是做什麼的，但是沒有一個註釋說明為什麼要這樣做。如果程式中有一個bug，而你在瀏覽時無意中發現了這個bug，你甚至不知道從哪裡改起。
12) 過分緊張的最後期限
最後一個與管理人員要求程式設計師進行評估的傾向有關，管理人員會要求程式設計師儘可能降低這些評估，然後神奇地將它們視為最後期限！管理人員甚至會認為，正如程式設計師自己根據估算“決定”的那樣，他們承諾在最後期限內完成工作，因此最後期限完全可以視為是足夠有效。
作為 程式設計師肯定覺得這些最後期限不合理，然後他們就會因為緊張無法集中注意力。
這12件事，它們對大多數其他專案工作來說都很普遍。對於程式設計師來說，每一種情況可能更甚，因為他們需要集中精力來完成任務。
如果你在日常工作中發現有上述影響存在，可以與程式設計師們談談，看看這些問題如何解決，最重要的是要相信他們的反饋和見解。儘管今天的科技與30年前大不相同，但教訓仍然是一樣的。當你考慮團隊效率時，不能忽視人為因素。與你的團隊一起改善工作流程、環境和習慣，以提升整個團隊的工作效率。
編譯組出品，編輯：郝鵬程