最能摧毀程式設計師工作效率的 12 件事
小編推薦： ofollow,noindex">掘金是一個面向程式員的高質量技術社群，從 一線大廠經驗分享到前端開發最佳實踐，無論是入門還是進階，來掘金你不會錯過前端開發的任何一個技術乾貨。
很多文章都涉及技術主管和專案經理的角色。 我們經常遇到的一個共同主題是如何提高團隊的工作效率。 但是在你集中精力來提高團隊生產力之前，你可能首先要考慮是什麼在摧毀程式設計師的生產力，以便建立一個可靠的基礎。
沒有程式設計師能在沒有計算機的情況下完成工作，但是有很多公司希望程式設計師能夠在不使用電腦的情況下完成工作。 這同樣不切實際。
因此，讓我們深入探討 12件摧毀程式設計師提高效率的事情。下面給出的順序是按最重要到不重要的排序的（從我的視角）， 隨意評論！
如果你想知道這些投入是否值得，只要考慮給程式設計師們加薪水就可以了。即使加薪 10% 也能很大程度上提供程式設計師的工作效率。
1）打斷 和 會議
在我看來，最影響程式設計師工作效率的事情是隨意打斷他們的工作。開發人員無法輕鬆回到被打斷之前的狀態。他們需要進入原先的思維模式，然後慢慢追溯到他們離開時的思路。這可能需要超過 30 分鐘。打斷越多，挫折越多，工作質量越差，錯誤也就越多 – 而且還在持續。
“你越是在我嘗試一些新想法的時候，你來打斷我，我每次嘗試的時間間隔越來越長。如果你讓我的早晨老是被打擾，當一天什麼事都沒幹的時候，請不要感到驚訝。“ Reddit上的開發人員
會議怎麼中槍了？會議和打斷的唯一區別是，會議是有計劃的打斷，這會讓事情變得更糟。如果開發人員知道他們在工作時會被打斷干擾，他們就無法在任務上取得大的進展。因此，如果他們在一兩個小時內召開會議，他們將無法取得任何進展，因為大多數工程任務需要更多時間。
正如保羅·格雷厄姆（Paul Graham）所寫的那樣，“一次會議可以將整個下午分成兩部分，碎片化時間太多導致無法做任何事情。”
如何避免這種情況？這裡有成功的先例；你沒有理由不借用。例如，在一天的開始或午餐前舉行簡短的狀態會議，以避免不必要的打斷。
2) 微觀管理
在不同型別的管理人員中，微觀管理人員在開發人員的效率方面可能做的是最糟糕的。 當然，微觀管理人員往往會有更多的會議和意外打斷。 但不僅如此。 他們表現出對程式設計師缺乏信任，這樣一來，程式設計師會覺得他們在不斷地摧毀自己的技能和完成工作的能力。 這時候，開發人員的工作勁就消失了。 影響的不僅僅是效率。 微觀管理人員可能是程式設計師離職的最主要原因，或者至少是更換團隊的原因。
3) 模糊
有許多方法可以說明模糊性也是導致程式設計師效率低下的原因。。 錯誤的報告，如“它破了，修復它！” 沒有足夠的資訊供開發人員使用。 順便說一下，擁有錯誤報告模板可以幫助解決這個問題。
或者對某個功能的規範不明確，在這種情況下，一旦管理員更好地詳細說明了預期的行為，開發人員就會開始實施對他們感覺合適的事情。
不明確的優先順序次序也屬於這一類。 避免讓開發人員去思考接下來該幹什麼，省下時間。如果管理人員問他們為什麼要先做這個任務的時候(雖然優先順序沒有明確標明)，他們會感到很沮喪……
4) 海鷗管理
愚人碼頭注：海鷗經理們飛進來，製造了好多噪音，把每個人給說一遍，然後又飛走了。海鷗管理指管理者等出了現問題才跟員工去溝通的管理模式，管理者對於自己不太瞭解的事務匆忙做出決策，然後把爛攤子留給其他人來處理。
你聽說過嗎？ 當管理者完全沒有參與工作時，就會發生這種情況，但是……突然哪天心血來潮，橫插一槓，說 “這是錯的，這個看起來很糟糕，”等等，然後又飛走了。你可能也經常碰到這種管理人員，不幸的是，這種情況比我們想要的更頻繁。 這種行為讓開發人員感到非常沮喪; 他們將在接下來的幾個小時內無法回到原本的工作狀態，有時甚至連續幾天。
5）把功勞攬到自己頭上
您是否有過這樣的經理或同事，他們把你過去幾周所做的工作全部歸功於他們自己？ 開發人員最看重的是能力。把別人的功勞據為己有，就是把別人的能力從他或她身上強行奪走。這種行為實在太過惡劣，因為我覺得這種行為在團隊之中製造了太多的緊張氣氛，以至於在相當長的一段時間內它只會破壞整個開發人員團隊的生產力。
6) 環境 – 噪音，運動，工作區設計等等…
這對於非程式設計師來說可能看起來很奇怪，但開發人員工作的環境對他們的工作效率有重要影響。 例如，有一些白噪聲 – 大聲的交流，聽見汽車和卡車駛過 – 幫助他們更好地集中注意力。 這就是我們這麼多人戴耳機的原因！ 我其實剛剛發現了 RainyMood – 非常棒！
同樣，如果工作區設計的人來人往，噪音很大，那將無法幫助開發人員集中注意力！ 或者計算機螢幕高度設計可以輕鬆讓管理者看見…這會產生一些額外的壓力，甚至開發人員工作被打斷的機率也大大提升。
7）範圍蔓延
專案管理中的範圍蔓延（也稱為焦點蔓延，需求蔓延，特徵蔓延，有時是廚房水槽綜合症）是指專案範圍出現不受控制的變化。 當專案範圍未正確定義，記錄或控制時，可能會發生這種情況。
範圍蔓延將相對簡單的請求轉變為可怕的複雜的且耗時的怪物！ 大部分時間它都發生在開發過程中！ 例如，對於一個簡單的功能：
- 版本1（實施前）：功能是 “顯示位置的地圖”
- 版本2（版本1幾乎完成時）：功能更改為 “顯示位置的3D地圖”
- 版本3（當版本2幾乎完成時）：功能再次更改為 “顯示使用者可以飛越位置的3D地圖”
愚人碼頭注：範圍蔓延是多數專案中的風險。大多數大型專案因為範圍蔓延而失敗。自由策略的影響難以抵消，即使是對最有經驗的專案經理，面對範圍蔓延仍然是艱鉅的挑戰。
8) 產品定義過程
這個乍一看可能有點奇怪，但其實很容易理解。如果某個產品團隊在沒有驗證（通過客戶反饋或任何其他方法）相應特性的情況下定義了其團隊的優先順序，並且開發人員又發現大多數特性最終都沒有被採用時，他們會覺得他們所做的事情是無用的而失去動力。我們都希望感受到自己有影響力，這對開發人員來說可能更為重要！
9) 缺乏對技術債務的考慮
技術債務是故意決定實施非最佳解決方案或編寫非最佳程式碼來更快速地釋出軟體。 承擔一些技術債務是不可避免的，並且可以在短期內提高軟體開發的速度。 但是，從長遠來看，它會導致系統複雜性，從而降低開發人員的速度。 非程式設計師經常低估這種情況多效率的損失，並且總是傾向於突飛猛進，這就導致了重重問題。
但是，如果重構永遠沒有被列入優先事項的話，它不僅會影響效率，還會影響產品質量。
10) 工具多樣性和硬體
開發人員每天使用許多工具來程式設計，推送和合並他們的程式碼。 自動化越多越好。 不言而喻，如果您使用“古老”工具，這將影響您的工作效率。 同樣，擁有一臺筆記本電腦，再加上一個大屏顯示器，也會提升開發人員的工作效率。 考慮到硬體成本和開發人員的工資，如果效率能提高5%，那就值得投資！只需提供開發人員團隊喜歡的工具和硬體（單獨使用的硬體，和相關的工具）。
11) 無用的註釋文件
在學習如何編碼時，我們被告知要儘早和經常註釋。 這個想法是，多註釋總比不註釋要好。 不幸的是，許多程式員錯誤地將其解釋為他們必須對每一行程式碼進行註釋，這就是我們經常看到這樣的程式碼的原因（來自Jeff Atwood的帖子“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)
}
你知道這段程式碼的作用嗎？ 我反正不知道。 問題是雖然有很多註釋描述了程式碼正在做什麼，但沒有一個描述它為什麼這樣做。 如果程式中存在錯誤並且您偶然發現了這段程式碼，那麼您將不知道從哪裡開始。
12) 緊迫的專案截止日期
最後一個與管理人員的傾向的有關！管理人員要求開發人員預估專案開發時間，然後推動他們儘可能減少開發時間，然後神奇地認為它們是最後期限。 管理人員甚至會認為，由於開發人員自己“決定”了估算，他們承諾在截止日期前完成，因此截止日期應該被視為足夠有效，以便反饋給高層管理人員。
毫不奇怪，開發人員認為這些截止日期是不合理的，這會造成緊張和無法集中注意力。
所有這些東西對開發人員來說都是獨特的？
如果你看了所有這12件事，它們實際上對於大多數其他專案來說都很常見。對於開發人員來說這些影響可能更為重要，因為他們需要深入關注他們的任務進展。
如果您意識到公司內部也存在提到的這些問題，那麼與開發人員討論這些問題可能會很有趣。與他們談談，看看這些是否是一個問題，以及如何解決。無論他們說什麼，最重要的是相信他們的反饋和見解。雖然今天的技術與30年前截然不同，但教訓仍然是相同的。在考慮團隊工作效率的同時，不能忽視人為因素。與您的團隊一起改善工作流程，環境和工作習慣，讓開發人員指導您如何提升工作效率和影響力。
翻譯自：https://hackernoon.com/top-12-things-that-destroy-developer-productivity-2ddf0abc190