破壞程序員生產力的 12 件事

原文轉載自 John Lafleur ： goo.gl/fqfN8h

不少文章都提到如何當好一個技術組組長或者技術部經理。常見的話題通常都是如何提升團隊的效率。但當你試圖提升程序員的效率時，首先要搞清楚效率是怎麼變慢的，清楚緣由後再來提團隊效率。雖然 Peopleware 在 30 年前就發表了，但不少團隊依舊會出現精力浪費和效率低下的問題。

沒人會期待程序員不用電腦就能編好程序，但卻有不少公司在不瞭解程序員的思惟方式下就期待他們能把程序編好，這確定是不現實的。

我總結了拖慢程序員創造力和效率的 12 件事，從影響最大到影響最小進行排序。若是有疑問歡迎給我留言！

若是你在想是否應該繼續看下去的話，想一想付給程序員的高工資，因此哪怕提升 10% 的效率也是值得的！

1.打斷&會議

我認爲「打斷」能夠排在破壞程序員創造力的第一位。程序員在被打斷後通常不能作到馬上從新開始編程。被打斷以後繼續編程的話，一般程序員須要從新看一遍代碼，再次逐漸進入到編程的思惟環境中，才能想起來被打斷以前的思惟邏輯，再從被打斷的點從新開始。這個過程大概要花 30 分鐘以上。「打斷」越多，煩心越多，工做質量也會下降，Bug 也會隨之增長—成爲惡性循環。

「若是你在我準備開始編程的時候打斷我，次數越多- 我從新進入狀態耗費的時間就越長。若是你在早晨就安排了一堆會打斷我工做的會議，就別怪我這一天什麼程序也沒編出來」出自 Reddit 上的一個程序員。

那麼「會議」呢？「會議」和「打斷」的惟一區別在於會議是計劃好的打斷，這比非計劃的打斷還鬧心。程序員沒法在被打斷的時候還能專心作其餘任務。好比你跟程序員開 1-2 小時的會議，基本上不會有什麼進展，由於通常技術性的任務 1-2 小時之內是沒法完成的。

保爾·格雷厄姆(Paul Graham)說過，「一個下午若是被分紅兩個小會議是最糟糕的狀況，由於這兩個會議都過短了，什麼都作不了。」

那麼，如何避免這兩種狀況呢？

如下請記筆記：工做會議能夠安排在一天開始的時候或者午餐前，並儘可能簡短，避免沒必要要的「打斷」。

2.微管理

在全部管理者類型裏面，微管理經理對程序員的效率影響最大。這很容易理解，由於微管理經理的會議和臨時打斷會更多一些，而這些會議和打斷會顯示出來他們對程序員不信任，程序員也會以爲他們的能力被低估。致使程序員編程的動力在每次被打斷的時候就跟澆了冷水同樣。這樣的影響不止效率，還會使程序員離職或者更換團隊。

3.編程要求模糊

編程要求很模糊有不少種表現方式。好比，故障報告（Bug report）中像「這個不運行，重作！」並不能有效告訴開發人員如何解決問題。用統一的故障報告模版就能解決不少問題。

若是某項功能要求很模糊，在這個狀況下，開發人員只能靠本身的感受來編程。最好是可以把某項功能的要求細節化，再遞交給開發人員。

再有，不清楚的優先級也算需求模糊。這些沒必要要的時間原本是能夠避免的，程序員卻要花時間搞清楚本身是否在完成正確的任務。想象一下若是經理來問程序員爲何在作這個任務（在任務優先級沒有細節化以前）。你能想象以後的各類解釋和誤解…

4.海鷗管理

你據說過「海鷗管理」麼？「海鷗管理」是指管理者徹底無論工做，像海鷗同樣在高空飛，但….他們時不時的會跳出來搗亂。「這個作的不對，這個，這個還有這個作的不行」等，而後再繼續飛走。我必須得說，這個場景雖然聽起來很好笑，但卻很常見。這種狀況對開發人員來講很是的煩心，他們可能在以後的幾個小時，甚至幾天都沒法專心。

5.被「佔便宜」

你有過上層或者其餘的程序員把你工做成果拿去當成本身成果的狀況嗎？在程序員心中，能力被承認是擺在第一位的。別人把本身的成果拿去當成是他們的成果，等於剝奪了其餘人對本身承認的機會。這一點很是很是重要，若是這種狀況發生了，程序員在很長一段時間以內都不會有動力工做。

6.環境-噪音，走動，工做環境等等

這些對非程序員來講可能比較奇怪，但對程序員工做的效率影響卻很是大。好比一些白噪音，像空調噪音，汽車卡車行駛的這些聲音，反而能夠幫助他們更好的集中注意力。這就是爲何咱們老是戴着耳機的緣由。順便推薦最近剛發現的 RainyMood 。

類似的，若是工做空間的設計會有不少人走來走去，這也會讓程序員沒法專心。或者他們坐的位置很容易被管理者看到等等，這些因素都會讓程序員壓力增大而沒法專心。

7. 範疇蠕動

範疇蠕動（也稱爲焦點蠕動，需求蠕動，功能蠕動，有時候也稱爲廚房水槽現象）在項目管理中意思爲沒法控制的變數。這種狀況在項目範疇沒有被肯定以前會發生。

範疇蠕動會讓簡單的請求變成複雜，超級花費時間的怪獸。通常都在開發過程當中發生。好比，一個簡單的功能：

版本 1（發佈前）：功能是在地圖中顯示一個定位。

版本 2 （當版本 1 幾乎開發完畢時）：功能變爲「在 3D 地圖上展現一個座標」。

版本 3 （當版本 2 幾乎開發完畢時）：功能又變成「在 3D 地圖上展現一個用戶能在上空飛過的座標」。

8.產品定義過程

這一點可能第一眼看上去有點怪，可是其實很是好理解。若是一個產品團隊在沒有仔細考察功能是否有需求就定義了產品優先級（經過客戶反饋或者其餘渠道），程序員極可能會開發出不少用不到的功能。這會讓他們以爲本身作的東西沒有利用價值，開發的熱情也會大大下降。咱們都想創造更多的影響力，開發人員更是如此。

9.沒有考慮技術負債

技術負債是爲了更快上線產品而使用非最佳解決方案或編寫不是最好的代碼。這些決定有時候是不可避免的，由於能夠在短時間內提升軟件開發的速度。可是，長遠來看，這會讓系統複雜程度提升，而且會下降開發速度。非程序員老是想盡快推動項目而低估了生產力的浪費，這就成了一個問題。若是代碼重構永遠排不上優先級，這不只會影響效率，還會影響產品質量。

10. 工具多樣性和硬件

開發人員可能會用不少工具來編程，天天都要運行和合並代碼不少次。自動化越多越好。這就比如用很是老的沒有任何自動化工具來編程確定會拖慢編程效率同樣。大顯示屏和筆記本等硬件的區別也是如此。所以，在開發人員的軟件工具和硬件上投資是確定不會錯的！讓你的開發團隊選擇他們喜歡的工具和硬件（爲單人買硬件，爲整個團隊買軟件工具）。

11.如何註釋

當咱們學習編程的時候，知道要儘早開始爲代碼寫註釋，越多註釋越好。不幸的是，不少程序員把這概念理解錯了，致使他們在每一行代碼都有註釋，如如下這種常見的代碼（摘自傑夫安特烏茨（Jeff Atwood）的「不寫註釋的代碼」）：

r = n / 2; // 賦值 r 給 n 除以 2
// 迭代直到 r – (n/r) 大於 t
while ( abs( r – (n/r) ) > t ) {
  r = 0.5 * ( r + (n/r) ); // 賦值 r 給(r + (n/r))/2
}

你知道這段代碼想幹嗎麼？我也不知道。這就是註釋太多會帶來的問題，雖然有註釋，但這並無解釋爲何要這麼寫這段代碼。若是你在程序調試的時候看到這段代碼，對排除報錯（debug）並無幫助。

12.不可能實現的項目截止日期

管理者老是要求開發人員預估項目完成時間，而後再推進他們縮短預估時間，並以此爲截止日期。不少管理者甚至認爲，既然這是開發人員本身估計的時間，他們就應該在這個截止日期以前完成，因此這個截止日期是能夠正式向上級彙報的。然而，開發人員會認爲這個截止日是沒有辦法完成的，這就致使了開發人員與管理者之間緊張的關係。

以上這些事情爲何只針對程序員？

若是你看完這 12 件事，你會發現，這 12 件事其實在項目管理過程當中常常發生。只是這些事情對程序員的影響更多一些，他們在工做中更須要全神貫注。

若是你在公司裏看到了以上所提的 12 件事，不妨和你們探討一下。溝通後，搞清楚這些問題是否真實存在而且如何解決。無論他們怎麼說，關鍵是在於信任他們的反饋和意見。現今的科技和 30 年前比已經很不同了，但即便如此，人性並無變。你在考慮公司生產效率的同時必需要考慮人的因素。反覆推敲你團隊的工做流程，工做環境和工做習慣，讓你的團隊來指引你達到你想要的最高效率。

LeanCloud，領先的 BaaS 提供商，爲移動開發提供強有力的後端支持。 瞭解更多： www.leancloud.cn