本文在騰訊內部論壇被瀏覽達7347次，收藏615次，評論幾百條，曾經是討論最熱烈的項目管理文章之一。

作為作者本身，感覺這個話題可以討論的范圍非常大，希望能有更多朋友一起切磋探索技術團隊的管理之道。

資深程序員是團隊中最強大的生產力，但往往被不合理的工作安排浪費掉。

因此作為一個團隊的技術的“頭”，必須要有明確清晰的認識，把主要的事務性工作剝離出來。并且放棄大量的管理“權力”，以提高團隊開發質量和效率為最主要的目標去安排自己的工作。

一般來說技術總監其實會被要求做事實上是2個職位的工作：主程、項目經理（技術化）。

因此必須明確此兩個職位的工作任務分割。然后把項目經理的工作，安排給另外一個人做，當然其職稱可能同樣也得叫“技術總監”或“主程”，總之聽起來越牛X越好。

而真正的主程（技術總監）則應該投身于盡量多的技術工作中。而最重要的工作則是開發——生產代碼和文檔。

主程的工作：

一、開發

從來沒有一個資深的外科醫生會放下手術刀，而轉到手術室外面指手畫腳。一個資深的程序員也不應該離開代碼和文檔的編寫，而只是做做架構圖。

作為對一個復雜系統的負責人，必須親手領導和參與建造，才能有足夠的能力去負擔起這個責任。

因此需要至少使用60%的時間來參與開發的工作，并且建議從一開始上班就開始，雖然早上的效率很低，但是跟任何艱巨工作都一樣：萬事開頭難。

在你好不容易等待電腦慢吞吞的打開了所有的IDE、需求文檔、參考資料、工作計劃這堆要命的東西之后，你就邁出了最重要的一步，你會發現你不在需要在網上看微博和聊QQ來提振開始工作的激情，而會被某一個優化代碼的靈感而激勵，或者被一個復雜而有趣的問題所吸引，從而更快的能投入到開發中。

堅持打開電腦做的第一件事是打開IDE軟件，是這一切最重要的一步。

開發的工作內容包括有：

1、提出非功能性需求

一般來說功能需求總是讓開發人員焦頭爛額的主要原因。但是實際上很多項目死在發布之后，卻是因為性能、產品質量、擴展性、二次開發效率等非功能性需求沒認真去解決而導致的。

主程作為經驗最豐富的成員，必須要利用自己曾經的經驗和教訓（在這里教訓往往比經驗重要），提出那些自己折騰自己的“非功能性需求”，來保障整個項目在發布后不會轟然倒塌。

這是個吃力不討好的工作，因為老板和客戶往往只會抱怨技術人員在玩弄把戲，騙取更多的資源或者杞人憂天。如何說服這些家伙也許不是主程的工作，但是主程必須要以高度的責任心把問題放到臺面上來。溝通的工作也許讓項目經理去做會更好，他們有一整套如何威逼利誘老板和客戶的戲法。

2、設計和修正軟件架構

軟件架構設計至關重要，而且工作繁重。不畫圖紙就敢開工的技術人員要么是天才要么是笨蛋。

對于團隊來說，架構在分工合作、避免風險、提高質量等多個方面有無可替代的作用。架構要避免成為空洞的文檔，最重要的一步是有人來掌控和實施。而主程主持設計和修正的架構，并且親手實施，讓團隊中的腹誹之徒完全無法避開，否則代碼將無法運行！

所謂設計和修正架構，并不意味所有的文檔應該一個人寫，而是指這個架構的每個環節，都是經過主程決策同意的。當然最好這些文檔能盡量由他撰寫，對于“菜鳥”團隊來說，輸出這種文檔本身就意味著“權勢”，有助于主程建立個人威信——這種看起來有點骯臟的“政治”東西，在避免團隊內無止境的扯皮，以及穩定那些隨時準備跳槽的成員來說，都是相當實用的。

3、難點代碼（關鍵需求）的開發

主程必須寫代碼，寫那些大家都認為風險大的代碼。

有的系統對于性能要求很高，他就必須去完成容易出性能問題的部分，比如IO操作或者設計數據庫索引。有些系統的需求非常飄忽，他就要去想辦法完成框架代碼或者腳本引擎，以便眾多小弟可以跟著產品人員疲于奔命。這種工作內容會讓主程不必完全的讀過所有代碼，而能牢牢的“掌握”代碼，以免團隊成員甩耙子的時候能充當備胎。因為融入團隊的代碼開發，也是一個讓架構設計從日常工作中真正控制系統的工作。而且主程代碼通常會被別人接觸，能直接教育其他團隊成員，同時也能建立——威信。

4、救火和殺蟲

這個工作其實和代碼開發是一致的，如果沒有平日的開發，通常緊急問題的解決也是比較難處理的。但是這個也有一個調試技巧的要求，比如要求會使用各種診斷工具。這些工具一般的開發人員可能會比較少使用。找問題的過程本身也可以提高團隊其他人的技術水平。

二、培訓

培訓的工作應該占用30%左右的工作時間。培訓是穩定團隊人員最重要的手段。也是提高團隊開發效率最有效的手段。工具、過程、制度、獎懲，這些都代替不了程序員一行行的去寫代碼，最直接的方法是讓他們做的更快更好，這些需要經驗和知識的積累。

1、代碼審查

關于代碼審查，有太多的論述。但是代碼審查還是一種“強迫”推行某種風格或者技巧的手段，這是最真實的“控制”系統的手段。也是推廣知識和經驗最直接的手段。

一個人寫的代碼通常應對的問題不會特別“廣泛”，因此只要審查其中一部分代碼，就能給大部分別的代碼帶來好處。

2、技術方案評審

什么事情應該寫一個技術方案，然后進行評審，這是一個關鍵的問題。

一般認為開發時間在2周以上的單項工作應該先做個方案。往往技術方案是系統架構的完善和補充，或者是挑戰。所以主程的參與是非常必要的。

但是要注意不需要去做的太瑣碎，而是要提煉出“關鍵”的需求和“關鍵”的解決方案進行評審，而這些“關鍵”往往不是功能，而是質量上的需求，如這個系統的擴展性，是否能方便后續開發等等。

也有可能在這些會議上會發生爭吵，但是決策人是主程的地位是不容動搖的。君子和而不同，每個程序員都可以擁有自己的看法，但是代碼必須能按方案運行起來，主程必須經常申明這點。

3、學習與講座

如果團隊碰到問題，沒有新的方法和技術去解決，是不會提高開發效率的。就好像你用牛來耕地，不管用什么管理方法，都不會趕上機械化的速度。

而主程承擔著不斷突破自己的技術上限，介紹和推動團隊使用更新的技術來解決問題的責任。抱殘守缺，思想僵化，最后會被團隊成員所拋棄，而且也會讓團隊的效能落后于業界，最后直接影響產品的生死。

每年學一門新語言，這個說法可能有點激進，但是這也是作為程序員應該有的激情。

三、管理

管理等于權勢？管理等于溝通？管理等于文山會海？多年專業訓練出來的技術人員如何去做管理？

管理的目標是提高績效，如果和這個目標無關，而只是和“管理者”這個頭銜有關的事情，最好丟給別人去做，包括那個頭銜。

管理主要手段是創新：想出新的方法去解決問題，而不是繁雜的事務性工作！——一個專業秘書能比主程做的好一百倍。

技術工作的創新，最主要還是在技術工作里面，而不是跳出來說：做這個，做那個。

管理的事情如果超過10%的工作時間，等于說你更像一個項目經理而非主程。

1、績效評定

以專業的意見來衡量別人的工作，這個負擔是無人能夠承擔的。這個工作往往是利益分配的一種手段。類似獎懲手段。這種管理方法已經不是新事物了。

但是實際上技術人員對于績效往往持一定保留和曖昧的態度，因為這種事情難以很清晰的界定出來。需要判斷而非量度，才是績效的真正手段。

如果一定要打分，一共兩項足夠了：進度、質量，5分制即可。

更重要的事情是，告訴每個人主程的看法，告訴別人，怎樣做才是更好。或者告訴團隊，怎樣做才更有利于我們成功（發財、上市、贏得老板和客戶……）——把目標清晰告訴團隊，發揮他們的主動性，是績效評定最重要的目標。

2、需求評定

最讓技術人員頭疼的可能就是和客戶談判。這個事情實際上不應該讓技術人員來傷心，有項目經理就可以了。

而需求評定更多的是可行性的討論。主程如果參加每個需求評定，他要三頭六臂也搞不定，正確的做法應該是具體開發的團隊人員參加，而主程在開會前給與自己的意見，或者會后聽取參與者的總結。——這是了解別人做什么事的一個重要手段，但無需陷入太深，因為還有代碼評審和項目經理的幫忙。

3、跨部門溝通

實在沒必要參加，能躲就躲，這是扯皮的天堂。讓項目經理去吧，他們的專業技巧能讓這些事情更加有效。只要回來后讓項目經理告訴你發生了什么事情就可以了。

4、進度審核和任務分派

又是一個很有“權勢”的工作，實際上團隊成員的情況大家都知道，決定誰應該做什么事情并非需要很多時間去想的事情。所以大可以把方向性的意見告訴項目經理，讓他去做。很多優秀的開發者玩EXCELPROJECT之類的水平還不如只有一年工作經驗的秘書，別折騰自己了。

5、面試

如果真想幫忙，準備一份有區分度的筆試題目吧。不靠譜的人太多，老板可不是花錢請你和他們聊天的。讓項目經理去聊，不用擔心他們技術不強，再不夠，也會比大多數面試者要牛X。他們搞不定的人，就是應該雇傭的家伙。畢業生招聘怎么辦？只要看看他們課外活動是不是有搞些專業的事情就可以了，上進心比別的東西都重要，HR會比主程看的更準，相信我。

6、各種會議

飯無好飯，會無好會，超過6個人的會議應該堅決抵制。如果你有一個程序等著你去寫，你一定無比痛恨這些會議，順應你的內心吧！上帝保佑你。

最后說說項目經理的工作：

項目經理就像下水道的清潔工，所有那些主程不愿意去做的事情，他們都彎下腰去認真的把玩，實在是太偉大了。

既然如此，為何不讓他們擁有更好一點的頭銜呢？如果沒有他們去處理這些工作，任何一個主程都會被逼瘋掉，或者他們自己變成了項目經理，讓團隊損失了最強力的一臺代碼發動機。

一、進度

1、指定工作計劃

2、進度檢查和告警

3、工作總結和統計

二、資源

1、整合提供各種資源，如找DBA，IT，運維人員，硬件，SVN權限，測試環境，福利，周末的活動……

2、面試：人員是最重要的資源，不是嗎？

3、資源談判：往往是和老板談判，讓別人明白現在的真實情況。又一個吃力不討好的差事，但是總需要人做。

三、溝通

1、需求評審：和需求方討價還價，項目經理真是命苦啊……

2、組織會議或者用其他方式通知信息給所有人：小喇叭、大喇叭、全服廣播、世界頻道……

對于一個小型公司，職權，頭銜，收益，往往會更加敏感。但是這些都不是讓項目失敗的理由。

一顆叫程序員的種子說：長大了我就是叫管理者的樹。這個錯誤的觀念只會讓這個種子永遠無法發芽。

軟件開發是類似外科醫生的行業，而不是血汗工廠，所以不需要手持皮鞭的經理，而需要仁心仁術的神醫。