本文在騰訊內部論壇被瀏覽達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.組織會議或者用其他方式通知信息給所有人：小喇叭、大喇叭、全服廣播、世界頻道……
對於一個小型公司，職權，頭銜，收益，往往會更加敏感。但是這些都不是讓項目失敗的理由。一顆叫程序員的種子說：長大了我就是叫管理者的樹。這個錯誤的觀念只會讓這個種子永遠無法發芽。軟件開發是類似外科醫生的行業，而不是血汗工廠，所以不需要手持皮鞭的經理，而需要仁心仁術的神醫。