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

　　在一個科技公司里，軟件技術(shù)經(jīng)理用在編程上的時間應(yīng)該不低于總工作時間的30%。無論是管理一個團(tuán)隊，還是一個分部，還是整個公司，當(dāng)技術(shù)經(jīng)理用在編程上的時間低于30%時，他執(zhí)行職責(zé)的能力就會發(fā)生嚴(yán)重退化。

　　我的這個斷言可能跟那些我看到的想成為團(tuán)隊首領(lǐng)的軟件程序員們期望的情況完全相反。每次晉升，程序員們都期待花在編碼上的時間會大幅度減少，當(dāng)從“leader”爬到“經(jīng)理”職位時，就應(yīng)該徹底脫離編碼活動。而且，他們期望以一種“動口動眼不動手”的方式來保持對代碼庫的熟悉。再上級的領(lǐng)導(dǎo)就跟編碼完全沒關(guān)系了(如果有的話)。

　　大概一年前，當(dāng)時我的時間被越來越多的其它事情占用，例如招聘，管理，開會等。我就發(fā)現(xiàn)，作為一個技術(shù)首領(lǐng)，當(dāng)花在編程上的時間低于某個比例后，管理效果和工作效率就會出現(xiàn)問題。之前我寫過一篇短博客闡述過這種體驗和觀點，但沒有展開具體的描述。這里，我將會對這個觀點展開更詳細(xì)的論述。

　　為什么要堅持編程活動

　　很多人認(rèn)為，作為管理者，應(yīng)該退出戰(zhàn)斗第一線，專注于大戰(zhàn)略和管理工作。當(dāng)然，管理者把大部分的時間用在這種事情上是應(yīng)該的。但是，在我們這樣一個行業(yè)里，因為我們允許或要求管理者幾乎不再去編程，現(xiàn)實讓我們付出了沉重的代價。一旦一個人停止編碼，他和程序員們關(guān)心的事物之間的重要聯(lián)系就會退化。當(dāng)這種情況發(fā)生時，決策、計劃和干群關(guān)系就會出問題，從而瓦解了將技術(shù)人員提升到管理職位的良好愿望基礎(chǔ)。

　　項目開發(fā)評估能力

　　程序員的百寶箱中最重要的一個絕活就是估計工期。如果沒有準(zhǔn)確預(yù)估的能力，整體計劃是不可能正確的出臺的。大家也知道，做為一個族群，程序員們對工期的估計是臭名昭著的——糟糕的不能再糟，事實上，當(dāng)從程序員口中得到一個預(yù)估的數(shù)字后，公認(rèn)的方法是將它乘以二。通常，程序員都會對開發(fā)工作抱有非常樂觀的態(tài)度，但如果我們使用“estimate traction”理論，就會發(fā)現(xiàn)，編程活動表現(xiàn)出特別易變的特征。因為我可以用很多方法實現(xiàn)一個功能，當(dāng)我們在還沒有深入細(xì)節(jié)之前，我們的估計就是不可靠的。

　　技術(shù)債務(wù)

　　另外一個事情是，對于技術(shù)債務(wù)給項目造成的影響，技術(shù)經(jīng)理必須掌握第一手的資料。如今，技術(shù)債務(wù)這個術(shù)語非常流行，常被用來當(dāng)作爭論的彈藥——優(yōu)先開發(fā)新功能還是先重構(gòu)老代碼。對“技術(shù)債務(wù)”這個詞的內(nèi)涵熟悉的人通常最容易發(fā)起論戰(zhàn)。作為技術(shù)經(jīng)理，你不僅僅要熟悉這個概念，而且它們會在你判斷何時償還技術(shù)債務(wù)的決策中起直接作用。經(jīng)常寫代碼的經(jīng)理擁有更多更有價值的信息來判斷何時/如何做出這樣的決策。

　　知情的連續(xù)性

　　我并不是隨意選擇30%的比率的。我是基于自己的經(jīng)驗，將足夠的時間參與到開發(fā)活動中，你很容易就能時刻掌握代碼庫的任何變化。如果時間太少，你對開發(fā)動態(tài)的掌握就是斷斷續(xù)續(xù)，無法連成線。一旦斷了線，我就需要重新理順脈絡(luò)，由此得到的懲罰就是浪費了額外的時間。

　　分擔(dān)責(zé)任

　　作為負(fù)責(zé)人，你不可能讓所有決策都由你制定或由你批準(zhǔn)。但你需要了解所有決策的前因后果和背景知識，來輔助這些決策。最終，你要為這些決策的后果負(fù)責(zé)，你對項目情況的掌控能力要能匹配你的這份責(zé)任。

　　積極參與編程贏得團(tuán)隊尊敬

　　大家需要明白：要想成為一個成功的經(jīng)理，你需要為團(tuán)隊成員提供服務(wù)，促進(jìn)開發(fā)，確保他們完成任務(wù)。我曾在一篇博客里寫過如何診斷和修復(fù)經(jīng)理們有問題的干群關(guān)系。但是對于的管理程序員來說，你需要熱愛編程。因為你的團(tuán)隊在編程，如果你在編程上做榜樣，他們都會對你肅然起敬。

　　達(dá)到30%的障礙

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

　　工作繁多：在一個創(chuàng)業(yè)公司里，你總有忙不完的工作需要去做，即使在公司有規(guī)模、壯大后，如何對眾多都很重要的事情排優(yōu)先級也是一種考驗。技術(shù)經(jīng)理有很多職責(zé)，完全會占滿他的70%的時間。下面就是一些：

• 領(lǐng)導(dǎo)和照顧團(tuán)隊：這是一個技術(shù)經(jīng)理的第一要務(wù)。你已經(jīng)不能只為自己的工作負(fù)責(zé)，你要為你的團(tuán)隊能保持最好的工作狀態(tài)負(fù)責(zé)。指導(dǎo)團(tuán)隊任務(wù)，解決紛爭，思考如何優(yōu)化工作條件來提高工作效率和舒適度，這都需要時間。
• 做決策：隨著職權(quán)的增加，技術(shù)經(jīng)理需要花更多的時間放在各種各樣戰(zhàn)略上的統(tǒng)籌和計劃等事務(wù)上。起初，也許只是一些技術(shù)方面的決策，但之后，產(chǎn)品開發(fā)和競爭策略方面的事務(wù)將會占去很大一部分。
• 招聘：經(jīng)理，總監(jiān)，副總們，CTO都需要組建自己的團(tuán)隊，有時需要迅速組建。一個好的招聘高手能帶來很大幫助，技術(shù)經(jīng)理在這樣的事情上的作用是無可替代的。好的技術(shù)經(jīng)理會活躍的跟上級保持溝通，不斷的將自己團(tuán)隊中的優(yōu)秀人士推薦出去。
• 客戶：隨著技術(shù)經(jīng)理職權(quán)的增加，他們經(jīng)常會對外拋頭露面。他們會被帶去參加“推銷會”，期望他能帶去一些有深度的話語。或當(dāng)重要客戶不高興時被叫去滅火。
• 公關(guān)：資深技術(shù)經(jīng)理會把一部分時間奉獻(xiàn)給公開演講，寫博客，或者報刊上發(fā)表文章。不論你在這些活動中出了多少力，這些寫作、編輯、排練、差旅、出席活動等都是花費時間的。

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

• 勇于說不：高成就意味著要努力工作。然而，做事要穩(wěn)妥，一個技術(shù)經(jīng)理最重要的職責(zé)就是，當(dāng)你的團(tuán)隊負(fù)擔(dān)過重或接近這種狀態(tài)時要勇于說不。如果你這個時候不說不，其他人就會開始對你的計劃和工期承諾指手劃腳。
• 開會：為如何高效的開會出謀劃策已經(jīng)成為了一幫人的職業(yè)，這是有其自身原因的。我的職業(yè)生涯中浪費在會議中的時間算是最多的了。尤其是不斷的面試或出席必須由團(tuán)隊首領(lǐng)出席的會議。

　　失敗的策略

　　當(dāng)在探索如何奪回我的編碼時間時，有很多的方法并不奏效。

• 少睡：這種方式雖然對我有巨大的誘惑，但其實犧牲睡眠時間沒有一點效果。你的大腦需要休息，缺少睡眠會影響情緒并降低工作效率。
• 只看頭文件：我以為這種方法可行，但實踐中，只看提交的C++代碼的頭文件對你的管理工作的幫助甚少。
• 專一：作為團(tuán)隊首領(lǐng)，你只關(guān)注代碼庫里的一個項目也許是可以的，但對于總監(jiān)或更高級別的人來說，你應(yīng)該對負(fù)責(zé)的所有東西都要熟悉、了解。
• 委托：有時候為了多做工作，會將一些事情隨意的交給他人做，但實際上一些像寫報告這樣的事情你一定要認(rèn)真囑咐才行。

　　成功的策略

　　盡管走了很多死胡同，我還是發(fā)現(xiàn)了一些成功的方法：

• 時間分段：我的日程表上沒有被預(yù)先分配的時間是非常少的。想起來這也是很顯然的。于是我專門為編程特地分出一些時間段。實踐中，這些時間段經(jīng)常會被重新調(diào)整，雖然每周只擠出8小時，效果是完全不一樣的。
• 委派：委派要有技巧，尤其是在你對如何執(zhí)行抱有強烈想法并有能力去做時。有很多原因?qū)е乱粋€經(jīng)理反對將任務(wù)委托他人，但事實上每個原因都應(yīng)該被當(dāng)作一個現(xiàn)存的需要解決的問題，而不是一個不可逾越的障礙。沒有什么比放手讓一個你信賴的人替你主持一個會議能釋放你更多的編碼時間了。
• 工作時間：將時間分段，工作時間里盡量避免打擾。在這些時間段之間的時間里，我會干一些不重要或不需求注意力長期集中的事情。

　　最后幾招

　　下面是一些經(jīng)驗建議，送給那些發(fā)現(xiàn)自己試圖達(dá)到30%但無法接近的技術(shù)經(jīng)理們：

• 學(xué)習(xí)如何讀代碼。跟寫代碼比起來，這是一種完全不同的技巧。
• 指定會議流程，對會議進(jìn)程保持控制。不參加任何沒有計劃的會議。
• 用一臺好用的電腦。你喜歡MacBook Air？不，別用它。
• 清楚如何訪問一個開發(fā)環(huán)境，這樣當(dāng)有修改時可以快速測試。
• 記住你是把一小時分成5個時間段使用的人。如果有事情需要一小時，在日程表上標(biāo)明。
• 20–30%是我自己的發(fā)現(xiàn)。你的也許跟我不同。評估你自己的(你修復(fù)一個緊急bug需要多少時間？你知道代碼庫中麻煩最多的程序是哪一塊嗎？隨機找一段程序，看看你是否知道是做什么的。如果不能，說明你需要更多的時間)。
• 分類列出哪些事情什么時候做，哪些事情應(yīng)該完成。(知道Getting Things Done (GTD)的人會看出這是提高工作效率的基本技巧。)
• 最后，我最近越來越喜歡在紙上看一些東西。看上去好像是一種倒退，比如把需求規(guī)范、需要優(yōu)先實現(xiàn)的功能列表、甚至一段代碼打印出來看，但相對于長時間盯著屏幕，這是一種平衡。

　　我希望這些方法對你們有用。如果你有其它更好的技巧，請在評論里告訴我。謝謝。

it知識庫：項目經(jīng)理應(yīng)該把30%的時間用在編程上，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。