有關(guān)技術(shù)主管和工程經(jīng)理職責(zé)的文章很多。我們經(jīng)常會看到的一個相同的主題是：如何提高團隊的工作效率。但是在集中精力來提高他們的生產(chǎn)力之前，你可能首先會考慮摧垮生產(chǎn)力的因素是什么，并依據(jù)建立一個可靠的基礎(chǔ)。不幸的是，盡管30年前《人件》（Peopleware: Productive Projects and Teams）一書就已經(jīng)出版了，但是至今我們?nèi)匀豢梢钥匆娫S多團隊由于一些出色（貶義）的做法而遭受巨大的生產(chǎn)力損失！

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

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

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

打斷與會議

在我看來，打斷開發(fā)人員是首要的生產(chǎn)力殺手。

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

“在我努力工作的時候，你打斷我的次數(shù)越多，那么我重新回到努力工作狀態(tài)的時間就越長。如果一整個早上你不停的打斷我，那么抱歉我這一天都沒有效率可言?！薄猂eddit上的開發(fā)人員。

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

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

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

微觀管理

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

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

含糊其辭

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

或者對某個功能的規(guī)范不明確，在這種情況下，開發(fā)人員只能依靠自己的直覺開始實現(xiàn)，等到從經(jīng)理那里獲得更詳細(xì)的預(yù)期行為說明后，又不得不重頭開始。

優(yōu)先次序不明確也屬于這個范疇。開發(fā)人員猶豫他們是否正在做正確的任務(wù)，他們花費的這些時間很容易避免。他們只需問問經(jīng)理為什么他們需要做這個特定的任務(wù)（如果優(yōu)先次序沒有定義的話），但是往往他們在這方面遭遇了很多挫折……

海鷗管理

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

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

將別人的功勞據(jù)為己有

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

這種現(xiàn)象對開發(fā)人員的生產(chǎn)力破壞極大，因為我覺得這會營造非常緊張的氛圍，會在很長一段時間內(nèi)打擊開發(fā)人員的生產(chǎn)力。

環(huán)境——噪音，動力，辦公室的設(shè)計等

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

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

范圍蔓延

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

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

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

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

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

產(chǎn)品定義的流程

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

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

缺乏對技術(shù)債務(wù)的考慮

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

但如果永遠(yuǎn)不優(yōu)先考慮重構(gòu)的話，那么不僅會影響生產(chǎn)力，還會影響產(chǎn)品質(zhì)量。

工具的多樣性和硬件

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

方法論的文檔

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

你知道這段代碼是干什么的嗎？我也不知道。問題是雖然代碼中加了很多注釋描述了代碼正在做什么，但沒有一個描述了這樣做的原因。如果程序中有bug，而你找到了這段代碼，那么你將不知道該從哪里入手。

過于緊迫的截止期限

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

開發(fā)人員認(rèn)為這些截止期限不合理，過于緊迫，這一點也不奇怪。結(jié)果就會造成緊張的氛圍，讓程序員無法集中注意力。

為什么這些注意事項是開發(fā)人員特有的？

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

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

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