技術經理應該把30%的時間用在編程上

英文原文：Engineering Managers Should Code 30% of Their Time

　　在一個科技公司裏，軟件技術經理用在編程上的時間應該不低於總工做時間的30%。不管是管理一個團隊，仍是一個分部，仍是整個公司，當技術經理用在編程上的時間低於30%時，他執行職責的能力就會發生嚴重退化。

　　個人這個斷言可能跟那些我看到的想成爲團隊首領的軟件程序員們指望的狀況徹底相反。每次晉升，程序員們都期待花在編碼上的時間會大幅度減小，當從「leader」爬到「經理」職位時，就應該完全脫離編碼活動。並且，他們指望以一種「動口動眼不動手」的方式來保持對代碼庫的熟悉。再上級的領導就跟編碼徹底不要緊了(若是有的話)。

　　大概一年前，當時個人時間被愈來愈多的其它事情佔用，例如招聘，管理，開會等。我就發現，做爲一個技術首領，當花在編程上的時間低於某個比例後，管理效果和工做效率就會出現問題。以前我寫過一篇短博客闡述過這種體驗和觀點，但沒有展開具體的描述。這裏，我將會對這個觀點展開更詳細的論述。

　　爲何要堅持編程活動

　　不少人認爲，做爲管理者，應該退出戰鬥第一線，專一於大戰略和管理工做。固然，管理者把大部分的時間用在這種事情上是應該的。可是，在咱們這樣一個行業裏，由於咱們容許或要求管理者幾乎再也不去編程，現實讓咱們付出了沉重的代價。一旦一我的中止編碼，他和程序員們關心的事物之間的重要聯繫就會退化。當這種狀況發生時，決策、計劃和幹羣關係就會出問題，從而瓦解了將技術人員提高到管理職位的良好願望基礎。

　　項目開發評估能力

　　程序員的百寶箱中最重要的一個絕活就是估計工期。若是沒有準確預估的能力，總體計劃是不可能正確的出臺的。你們也知道，作爲一個族羣，程序員們對工期的估計是臭名昭著的——糟糕的不能再糟，事實上，當從程序員口中獲得一個預估的數字後，公認的方法是將它乘以二。一般，程序員都會對開發工做抱有很是樂觀的態度，但若是咱們使用「estimate traction」理論，就會發現，編程活動表現出特別易變的特徵。由於我能夠用不少方法實現一個功能，當咱們在尚未深刻細節以前，咱們的估計就是不可靠的。

　　技術債務

　　另一個事情是，對於技術債務給項目形成的影響，技術經理必須掌握第一手的資料。現在，技術債務這個術語很是流行，常被用來看成爭論的彈藥——優先開發新功能仍是先重構老代碼。對「技術債務」這個詞的內涵熟悉的人一般最容易發起論戰。做爲技術經理，你不只僅要熟悉這個概念，並且它們會在你判斷什麼時候償還技術債務的決策中起直接做用。常常寫代碼的經理擁有更多更有價值的信息來判斷什麼時候/如何作出這樣的決策。

　　知情的連續性

　　我並非隨意選擇30%的比率的。我是基於本身的經驗，將足夠的時間參與到開發活動中，你很容易就能時刻掌握代碼庫的任何變化。若是時間太少，你對開發動態的掌握就是斷斷續續，沒法連成線。一旦斷了線，我就須要從新理順脈絡，由此獲得的懲罰就是浪費了額外的時間。

　　分擔責任

　　做爲負責人，你不可能讓全部決策都由你制定或由你批准。但你須要瞭解全部決策的來龍去脈和背景知識，來輔助這些決策。最終，你要爲這些決策的後果負責，你對項目狀況的掌控能力要能匹配你的這份責任。

　　積極參與編程贏得團隊尊敬

　　你們須要明白：要想成爲一個成功的經理，你須要爲團隊成員提供服務，促進開發，確保他們完成任務。我曾在一篇博客裏寫過如何診斷和修復經理們有問題的幹羣關係。可是對於的管理程序員來講，你須要熱愛編程。由於你的團隊在編程，若是你在編程上作榜樣，他們都會對你肅然起敬。

　　達到30%的障礙

　　儘管付出了最大努力，我仍然在保持30%的編碼時間上遇到了不少的阻礙。包括下面這些：

　　工做繁多：在一個創業公司裏，你總有忙不完的工做須要去作，即便在公司有規模、壯大後，如何對衆多都很重要的事情排優先級也是一種考驗。技術經理有不少職責，徹底會佔滿他的70%的時間。下面就是一些：

• 領導和照顧團隊：這是一個技術經理的第一要務。你已經不能只爲本身的工做負責，你要爲你的團隊能保持最好的工做狀態負責。指導團隊任務，解決紛爭，思考如何優化工做條件來提升工做效率和溫馨度，這都須要時間。
• 作決策：隨着職權的增長，技術經理須要花更多的時間放在各類各樣戰略上的統籌和計劃等事務上。起初，也許只是一些技術方面的決策，但以後，產品開發和競爭策略方面的事務將會佔去很大一部分。
• 招聘：經理，總監，副總們，CTO都須要組建本身的團隊，有時須要迅速組建。一個好的招聘高手能帶來很大幫助，技術經理在這樣的事情上的做用是無可替代的。好的技術經理會活躍的跟上級保持溝通，不斷的將本身團隊中的優秀人士推薦出去。
• 客戶：隨着技術經理職權的增長，他們常常會對外拋頭露面。他們會被帶去參加「推銷會」，指望他能帶去一些有深度的話語。或當重要客戶不高興時被叫去滅火。
• 公關：資深技術經理會把一部分時間奉獻給公開演講，寫博客，或者報刊上發表文章。不論你在這些活動中出了多少力，這些寫做、編輯、排練、差旅、出席活動等都是花費時間的。

　　奪回時間：上面我說的這些活動都是一個技術經理應該投入時間的事情。下面要說的是我從經驗中發現的一些陷阱，是它們在阻擋我努力保持20%最低限度的編碼時間，至今仍站在我面前，妨礙我重回30%的目標。

• 敢於說不：高成就意味着要努力工做。然而，作事要穩妥，一個技術經理最重要的職責就是，當你的團隊負擔太重或接近這種狀態時要敢於說不。若是你這個時候不說不，其餘人就會開始對你的計劃和工期承諾指手劃腳。
• 開會：爲如何高效的開會出謀劃策已經成爲了一幫人的職業，這是有其自身緣由的。個人職業生涯中浪費在會議中的時間算是最多的了。尤爲是不斷的面試或出席必須由團隊首領出席的會議。

　　失敗的策略

　　當在探索如何奪回個人編碼時間時，有不少的方法並不奏效。

• 少睡：這種方式雖然對我有巨大的誘惑，但其實犧牲睡眠時間沒有一點效果。你的大腦須要休息，缺乏睡眠會影響情緒並下降工做效率。
• 只看頭文件：我覺得這種方法可行，但實踐中，只看提交的C++代碼的頭文件對你的管理工做的幫助甚少。
• 專注：做爲團隊首領，你只關注代碼庫裏的一個項目也許是能夠的，但對於總監或更高級別的人來講，你應該對負責的全部東西都要熟悉、瞭解。
• 委託：有時候爲了多作工做，會將一些事情隨意的交給他人作，但實際上一些像寫報告這樣的事情你必定要認真囑咐才行。

　　成功的策略

　　儘管走了不少死衚衕，我仍是發現了一些成功的方法：

• 時間分段：個人日程表上沒有被預先分配的時間是很是少的。想起來這也是很顯然的。因而我專門爲編程特意分出一些時間段。實踐中，這些時間段常常會被從新調整，雖然每週只擠出8小時，效果是徹底不同的。
• 委派：委派要有技巧，尤爲是在你對如何執行抱有強烈想法並有能力去作時。有不少緣由致使一個經理反對將任務委託他人，但事實上每一個緣由都應該被看成一個現存的須要解決的問題，而不是一個不可逾越的障礙。沒有什麼比放手讓一個你信賴的人替你主持一個會議能釋放你更多的編碼時間了。
• 工做時間：將時間分段，工做時間裏儘可能避免打擾。在這些時間段之間的時間裏，我會幹一些不重要或不需求注意力長期集中的事情。

　　最後幾招

　　下面是一些經驗建議，送給那些發現本身試圖達到30%但沒法接近的技術經理們：

• 學習如何讀代碼。跟寫代碼比起來，這是一種徹底不一樣的技巧。
• 指定會議流程，對會議進程保持控制。不參加任何沒有計劃的會議。
• 用一臺好用的電腦。你喜歡MacBook Air？不，別用它。
• 清楚如何訪問一個開發環境，這樣當有修改時能夠快速測試。
• 記住你是把一小時分紅5個時間段使用的人。若是有事情須要一小時，在日程表上標明。
• 20–30%是我本身的發現。你的也許跟我不一樣。評估你本身的(你修復一個緊急bug須要多少時間？你知道代碼庫中麻煩最多的程序是哪一塊嗎？隨機找一段程序，看看你是否知道是作什麼的。若是不能，說明你須要更多的時間)。
• 分類列出哪些事情何時作，哪些事情應該完成。(知道Getting Things Done (GTD)的人會看出這是提升工做效率的基本技巧。)
• 最後，我最近愈來愈喜歡在紙上看一些東西。看上去好像是一種倒退，好比把需求規範、須要優先實現的功能列表、甚至一段代碼打印出來看，但相對於長時間盯着屏幕，這是一種平衡。

　　我但願這些方法對大家有用。若是你有其它更好的技巧，請在評論裏告訴我。謝謝。