有關技術主管和工程經理職責的文章很多。我們經常會看到的一個相同的主題是：如何提高團隊的工作效率。但是在集中精力來提高他們的生產力之前，你可能首先會考慮摧垮生產力的因素是什麽，並依據建立一個可靠的基礎。不幸的是，盡管30年前《人件》（Peopleware: Productive Projects and Teams）一書就已經出版了，但是至今我們仍然可以看見許多團隊由於一些出色（貶義）的做法而遭受巨大的生產力損失！

人人都知道程序員要想完成工作必須要用電腦，但是許多公司卻在期望程序員不用思想就能完成工作——這同樣不切實際。

因此，在本文中讓我們深入探討妨礙開發人員“進入工作狀態”並提高工作效率的12個註意事項。我會按照影響力從高到低逐個講解這些因素。歡迎大家在下面發表評論！

如果你猶豫下面這些投資是否值得，那麽只需想想開發人員的工資。即便只提高10%的生產力也是可觀的收獲！

1.

打斷與會議

在我看來，打斷開發人員是首要的生產力殺手。

開發人員不能輕易地回到他們被打斷前的狀態。他們需要進入開發的思維模式，然後慢慢回到離開之前的狀態。這個過程往往需要半個小時以上。打斷越多，他們受到的挫折就越多，工作質量就會越差，bug就會越多，等等。

“在我努力工作的時候，你打斷我的次數越多，那麽我重新回到努力工作狀態的時間就越長。如果一整個早上你不停的打斷我，那麽抱歉我這一天都沒有效率可言。”——Reddit上的開發人員。

那麽會議呢？會議和打斷唯一的不同是會議是有計劃的打斷，這會讓情況更糟。如果開發人員知道他們在做某個任務的中途會被打斷，那麽他們根本無法完成這個任務。因此，如果他們知道1-2個小時之內要去開會，那麽他們無法取得任何進展，因為大多數的工程任務需要的時間遠不止1-2個小時。

正如Paul Graham寫的那樣，“一次會議會將整個下午分割成了兩部分，每部分都太小，所以根本無法做任何事情。”

那麽怎樣才能避免這種情況呢？這個問題是有據可查的，所以你沒有任何借口推脫。你可以一大早或午餐前舉行簡短的會議，避免在中途進行不必要的打斷。

2.

微觀管理

在不同類型的經理中，采用微觀管理的經理在開發人員的生產力方面帶來的影響可能是最糟糕的。首先微觀管理人往往會帶來很多的會議和意外的打斷——但糟糕的遠遠不止是這些。

他們表現出的缺乏信任，會讓你覺得他們在不斷侵蝕你的技術力和完成工作的能力。任何很有動力的開發人員在被打斷的那一瞬間都會消失殆盡。而且這種影響超出了生產力。微觀管理可能是導致開發人員離職的首要原因，或者至少是改變團隊的原因。

3.

含糊其辭

含糊其辭的表現方式有很多種。例如，bug報告說：“無法正常工作，請修正！”卻沒有提供足夠的信息讓開發人員展開工作。順便說一下，bug報告模板可以幫忙解決這個問題。

或者對某個功能的規範不明確，在這種情況下，開發人員只能依靠自己的直覺開始實現，等到從經理那裏獲得更詳細的預期行為說明後，又不得不重頭開始。

優先次序不明確也屬於這個範疇。開發人員猶豫他們是否正在做正確的任務，他們花費的這些時間很容易避免。他們只需問問經理為什麽他們需要做這個特定的任務（如果優先次序沒有定義的話），但是往往他們在這方面遭遇了很多挫折……

4.

海鷗管理

你聽說過這個詞嗎？ 有的管理人員根本沒有參與工作，但是他們會突然闖進來然後一頓亂噴。“這個不對，還有這個，這個太差勁了，”然後就又飛走了。我不得不承認這個比喻很形象，但是不幸的是，這種現象發生的頻率比我們想象的還要高。

管理人員的這種行為會讓開發人員倍感沮喪，盡管他們幾個小時之內不會再來攪和，有時甚至幾天都不出現。

5.

將別人的功勞據為己有

你是否有過經理或其他開發人員將你辛苦努力了幾周的勞動成果據為己有的經歷？開發人員非常重視能力。將別人贏得的信譽據為己有實際上是搶占別人的能力或否認別人的能力。

這種現象對開發人員的生產力破壞極大，因為我覺得這會營造非常緊張的氛圍，會在很長一段時間內打擊開發人員的生產力。

6.

環境——噪音，動力，辦公室的設計等

對於非程序員來說這一點可能有點奇怪，但工作環境對開發人員的工作有重要的影響。例如，有一些白噪聲（響亮的交流電，或聽汽車和卡車的翻滾）可以幫助他們更好地集中註意力。這就是我們這麽多人戴耳機的原因！其實我剛剛發現傾聽雨聲也非常棒！

同樣，如果辦公室有太多的動靜，那麽會導致開發人員無法集中註意力！或者把臺式計算機的屏幕放在顯眼的地方，讓管理人員擡頭就能看見，那麽會產生額外的壓力，甚至還會導致打斷的發生頻率增高。

7.

範圍蔓延

項目管理中的範圍蔓延（也稱為重心蔓延，需求蔓延，特征蔓延，有時甚至被稱為廚房水槽綜合癥）是指不受項目範圍控制的變化。如果項目範圍的定義不正確，記錄不完整或控制不當時，就會發生這種情況。

範圍蔓延會導致相對簡單的需求變成極其復雜且耗時的怪物！大多數時候在開發過程中大家都會遇到這樣的情況。例如，對於一個很簡單的功能：

• 版本1（實施前）：功能是“顯示位置的地圖”；

• 版本2（版本1幾乎完成時）：功能更改為“顯示位置的3D地圖”；

• 版本3（當版本2幾乎完成時）：功能再次更改為“顯示可供用戶漫遊的位置3D地圖”。

8.

產品定義的流程

乍一看去這一點似乎很奇怪，但實際上很容易理解。

如果產品團隊在定義團隊的優先級時，沒有通過客戶反饋或其他方式驗證客戶對該功能的反應，而且開發人員發現大多數功能最終都沒有被使用，那麽他們會覺得他們所做的事情都是無用功，這就會導致他們會失去動力。我們都希望感受到自身的影響力，這對開發人員來說可能更為重要！

9.

缺乏對技術債務的考慮

技術債務是為了快速發布軟件，故意采用的非最佳解決方案或編寫的非最佳代碼。承擔一些技術債務是不可避免的，而且還可以在短期內提高軟件的開發速度。但是，從長遠來看，它會導致系統復雜，從而降低開發人員的速度。非程序員往往會低估生產力的損失，而且總是傾向於前進，這就成了一個問題。

但如果永遠不優先考慮重構的話，那麽不僅會影響生產力，還會影響產品質量。

10.

工具的多樣性和硬件

開發人員每天使用許多工具來編程，推送和合並他們的代碼。自動化越多越好。如果你使用“古老”的工具，就會影響你的生產力。同樣，擁有一個大屏幕還是一臺筆記本電腦也會產生影響。對比一下硬件成本和開發人員的工資，只需提高5％的生產率，就可以獲得所有投資！所以還猶豫什麽，抓緊提供開發人員團隊喜歡的工具和硬件（個人的硬件，還有團隊的工具）。

11.

方法論的文檔

在學寫代碼的時候，我們都知道應該盡可能多的寫註釋。也就是說註釋太多總好過太少。不幸的是，許多程序員錯誤地理解成了，必須對每一行代碼加註釋，這就是我們經常看到下面這樣的代碼的原因（來自Jeff Atwood的文章《Coding Without Comments》，地址：https://blog.codinghorror.com/coding-without-comments/）：

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，而你找到了這段代碼，那麽你將不知道該從哪裏入手。

12.

過於緊迫的截止期限

最後一個與管理者相關的問題是他們要求開發人員提供預估工時，但是他們會鼓動開發人員將這些預估盡可能降低，然後神奇地將這些降到最低的預估當成最後的截止期限！管理人員甚至還會認為，這是開發人員自己“決定”的預估，他們承諾在截止期限之前完成，因此這個截止期限理應有效，可以與高層管理人員共享。

開發人員認為這些截止期限不合理，過於緊迫，這一點也不奇怪。結果就會造成緊張的氛圍，讓程序員無法集中註意力。

13.

為什麽這些註意事項是開發人員特有的？

如果你仔細看看上述十二大註意事項，就會發現實際上對於大多數其他項目的工作來說這些問題也很常見。只是它們對開發人員的影響更為重要，因為開發人員需要精神高度集中，全神貫註到他們的任務中去。

如果你覺得你們公司內部也有上述某些問題，那麽與開發人員討論這些問題可能會很有趣。與他們交談，然後找出問題的解決方法。無論他們說什麽，最重要的是相信他們的反饋和見解。

雖然今天的技術與30年前截然不同，但教訓仍然是相同的。在考慮團隊生產力的時候，你不能忽視人為因素。與你的團隊一起考慮你們的流程，環境和工作習慣，讓他們幫助你獲取最大的生產力和影響力。

原文：https://mp.weixin.qq.com/s/P0arvQwCPgGcDSIav1kAMQ

譯者：John Lafleur CSDN

開發人員如何高效編程【轉載】