作者 | Alfredo Pinto
譯者 | 彼得
出品 | CSDN（ID：CSDNNews）
開發人員所做的工作與工人類似，但管理人員很容易犯的一個錯誤是：試圖像管理在工廠裡每天8小時組裝電視的工人那樣管理開發人員！在工廠裡，不讓工人停止工作是有道理的——停止工作意味著每天的產出減少，從而會提高成本，降低利潤。
但這種方法並不適用於管理軟件開發人員。軟件開發人員通常把90%的時間花在思考如何解決問題上，而只有10%的時間花在編寫代碼上。通常沒有代碼開發經驗的經理會認為開發人員在90%的時間裡什麼都沒做。
我曾經負責管理客戶現場的開發人員。客戶抱怨很多，用他自己的話說，“開發人員一天中大部分時間都無所事事。”在客戶現場管理開發人員時，我總是每天審查開發人員的進度。事實上，這些開發人員已經做得很好了。但是客戶總是希望看到他們每天8小時都在編寫代碼。
在軟件開發中，我們的主要工具是頭腦。有時我們思維遲滯，很難做任何工作；有時反應敏捷，我們一天就可以完成一週的工作；有時候因為擔心家庭問題而分心，有的時後可以集中精力完成任務。實際上，一個軟件開發人員在全心工作6小時之後就很難保持高效率了。他們通常需要喝大量的咖啡和利用空閒時間來做些其它的事情，才能更有效率。有時候，我們的思維太侷限於任務本身，其實，通過偶爾的放鬆聊天，或許能更好地解決問題。
所以，對於一個軟件開發人員，他們的情形是相當複雜的，他們的開發能力也是比較獨特的。有的開發人員更精通某些編程語言，有的人精通某種數據庫系統，有的人精通前端，有的人精通後端，有的人精通開發工具。所以試圖統一量化他們工作的是很困難的。
每一個軟件的需求都不一樣，開發人員需要解決的問題千變萬化。經過多年的積累，我們也只有在很少的的場景，才能有兩次解決同樣問題的機會。開發軟件沒有捷徑。我們可以藉助軟件庫和軟件框架來從技術角度提高效率，但是在軟件開發過程中，商務邏輯是最難以實現的。企業軟件是最難以實現的軟件。
但是，這也不意味著我們什麼都不能做。你需要理解程序員，設身處地地為他們著想，你才能為他們創建好的方法和策略。
通常我在給軟件開發人員安排任務時，一般不會給他們超過半天（4個小時）或兩天（16個小時）的任務。如果一個任務看起來會超過兩天，我會把它們細分成兩個、三個或更多的子任務。這樣可以避免大任務帶來的時間浪費。
例如，假設一個開發人員需要完成CRUD操作，通常一個簡單的CRUD操作需要一天時間（8小時）。在這種情況下，我會給開發人員分派一個8小時的任務。在其他情況下，比如，假設創建操作（Create）有很複雜的商業邏輯同時更新操作（Update）有另一套不同的商業邏輯，而整個任務需要5天才能完成。在這種情況下，我就不會給開發人員一個大的CRUD操作的任務。相反，我會將這個任務分成幾個小任務。比如，一個定義數據模型的任務（8小時），一個插入操作的任務（16小時）和一個更新操作的任務（16小時）。這樣，我每次給開發人員分派一個小任務，並且在他完成第一個任務之前，不會讓他去做其它的兩個任務。這樣，如果他在任何一天沒有完成至少一項任務，你馬上就能夠知道這個開發人員要麼在浪費時間，要麼被某些事情阻礙住並且沒有尋求幫助。希望你能明白：作為一個經理，你需要在每一天結束的時候，檢查你的團隊已經完成了哪些任務。
在軟件開發的過程中，聲稱百分之多少已經完成通常是不準確的。很有可能有人會告訴你“為了這個任務，我已經花了4天，並且完成了90%工作量。我還需要花另外的4天來完成剩下的10%”。這種用百分比來說明項目進展的方法很武斷，而且容易對人產生誤導。唯一正確的衡量進度的方法應該是該任務完成還是沒有完成。
一個任務是否完成，並不是由開發者來決定，它應當由測試人員或客戶（通過客戶認可測試UAT）來決定。當開發人員聲稱任務完成的時候，我們只不過暫時停止該項目的用時統計。如果測試人員或者客戶認為該任務的功能不正確，我們還需要繼續統計時間。如果在我們暫停項目用時統計的時候，該軟件已經實現了預期的功能，我們就可以認為該任務已經完成。
像《GettingThingsDone》和《Pomodoro》等方法論的文章都非常有幫助，《Work gamification》也很有益處。
原文鏈接：https://dzone.com/articles/how-to-deal-with-developers-that-tend-to-be-relaxe作者簡介：Gunther Verheyen，獨立的Scrum管理員，他是一個作家、演講者和人道主義者。他為Scrum相關的所有問題提供幫助、服務和建議，幫助人們學習Scrum。他不斷地思考和學習，並且創造機會、貢獻價值。本文為 CSDN 翻譯，如需轉載，請註明來源出處。閱讀更多 CSDN 的文章
