技術總監應該做哪些事情？一個人精力有限，開發、帶人、教育訓練、管理如何權衡？怎麼才能做到最好？本文作者韓偉，他将會和我們分享他的個人經驗，韓偉就職于騰訊互動娛樂研發部。
開發
從來沒有一個資深的外科醫生會放下手術刀，而轉到手術室外面指手畫腳。一個資深的程式員也不應該離開代碼和文檔的編寫，而隻是做做架構圖。作為對一個複雜系統的負責人，必須親手上司和參與建造，才能有足夠的能力去負擔起這個責任。是以需要至少使用60%的時間來參與開發的工作，并且建議從一上班就開始，雖然早上的效率很低，但是跟任何艱巨工作都一樣：萬事開頭難。在你好不容易等待電腦慢吞吞的打開了所有的IDE、需求文檔、參考資料、工作計劃這堆要命的東西之後，你就邁出了最重要的一步，你會發現你不在需要在網上看微網誌和聊QQ來提振開始工作的激情，而會被某一個優化代碼的靈感而激勵，或者被一個複雜而有趣的問題所吸引，進而更快的能投入到開發中。堅持打開電腦做的第一件事是打開IDE軟體，是這一切最重要的一步。
下面我來談談開發的主要工作内容。
1. 提出非功能性需求
一般來說功能需求總是讓開發人員焦頭爛額的主要原因。但是實際上很多項目死在釋出之後，卻是因為性能、産品品質、擴充性、二次開發效率等非功能性需求沒認真去解決而導緻的。主程作為經驗最豐富的成員，必須要利用自己曾經的經驗和教訓（在這裡教訓往往比經驗重要），提出那些自己折騰自己的“非功能性需求”，來保障整個項目在釋出後不會轟然倒塌。這是個吃力不讨好的工作，因為老闆和客戶往往隻會抱怨技術人員在玩弄把戲，騙取更多的資源或者杞人憂天。如何說服這些家夥也許不是主程的工作，但是主程必須要以高度的責任心把問題放到台面上來。溝通的工作也許讓項目經理去做會更好，他們有一整套如何威逼利誘老闆和客戶的戲法。
2. 設計和修正軟體架構
軟體架構設計至關重要，而且工作繁重。不畫圖紙就敢開工的技術人員要麼是天才要麼是笨蛋。對于團隊來說，架構在分工合作、避免風險、提高品質等多個方面有無可替代的作用。架構要避免成為空洞的文檔，最重要的一步是有人來掌控和實施。而主程主持設計和修正的架構，并且親手實施，讓團隊中的腹诽之徒完全無法避開，否則代碼将無法運作！所謂設計和修正架構，并不意味所有的文檔應該一個人寫，而是指這個架構的每個環節，都是經過主程決策同意的。當然最好這些文檔能盡量由他撰寫，對于“菜鳥”團隊來說，輸出這種文檔本身就意味着“權勢”，有助于主程建立個人威信——這種看起來有點肮髒的“政治”東西，在避免團隊内無止境的扯皮，以及穩定那些随時準備跳槽的成員來說，都是相當實用的。
3. 難點代碼（關鍵需求）的開發
主程必須寫代碼，寫那些大家都認為風險大的代碼。有的系統對于性能要求很高，他就必須去完成容易出性能問題的部分，比如IO操作或者設計資料庫索引。有些系統的需求非常飄忽，他就要去想辦法完成架構代碼或者腳本引擎，以便衆多小弟可以跟着産品人員疲于奔命。這種工作内容會讓主程不必完全的讀過所有代碼，而能牢牢的“掌握”代碼，以免團隊成員甩耙子的時候能充當備胎。因為融入團隊的代碼開發，也是一個讓架構設計從日常工作中真正控制系統的工作。而且主程代碼通常會被别人接觸，能直接教育其他團隊成員，同時也能建立——威信。
4. 救火和殺蟲
這個工作其實和代碼開發是一緻的，如果沒有平日的開發，通常緊急問題的解決也是比較難處理的。但是這個也有一個調試技巧的要求，比如要求會使用各種診斷工具。這些工具一般的開發人員可能會比較少使用。找問題的過程本身也可以提高團隊其他人的技術水準。
教育訓練
教育訓練的工作應該占用30%左右的工作時間。教育訓練是穩定團隊人員最重要的手段，也是提高團隊開發效率最有效的手段。工具、過程、制度、獎懲，這些都代替不了程式員一行行的去寫代碼，最直接的方法是讓他們做的更快更好，這些需要經驗和知識的積累。
1. 代碼審查
關于代碼審查，有太多的論述。但是代碼審查還是一種“強迫”推行某種風格或者技巧的手段，這是最真實的“控制”系統的手段。也是推廣知識和經驗最直接的手段。一個人寫的代碼通常應對的問題不會特别“廣泛”，是以隻要審查其中一部分代碼，就能給大部分别的代碼帶來好處。
2. 技術方案評審
什麼事情應該寫一個技術方案，然後進行評審，這是一個關鍵的問題。一般認為開發時間在2周以上的單項工作應該先做個方案。往往技術方案是系統架構的完善和補充，或者是挑戰。是以主程的參與是非常必要的。但是要注意不需要去做的太瑣碎，而是要提煉出“關鍵”的需求和“關鍵”的解決方案進行評審，而這些“關鍵”往往不是功能，而是品質上的需求，如這個系統的擴充性，是否能友善後續開發等等。也有可能在這些會議上會發生争吵，但是決策人是主程的地位是不容動搖的。君子和而不同，每個程式員都可以擁有自己的看法，但是代碼必須能按方案運作起來，主程必須經常申明這點。
3. 學習與講座
如果團隊碰到問題，沒有新的方法和技術去解決，是不會提高開發效率的。就好像你用牛來耕地，不管用什麼管理方法，都不會趕上機械化的速度。而主程承擔着不斷突破自己的技術上限，介紹和推動團隊使用更新的技術來解決問題的責任。抱殘守缺，思想僵化，最後會被團隊成員所抛棄，而且也會讓團隊的效能落後于業界，最後直接影響産品的生死。每年學一門新語言，這個說法可能有點激進，但是這也是作為程式員應該有的激情。
管理
管理等于權勢？管理等于溝通？管理等于文山會海？多年專業訓練出來的技術人員如何去做管理？
管理的目标是提高績效，如果和這個目标無關，而隻是和“管理者”這個頭銜有關的事情，最好丢給别人去做，包括那個頭銜。管理主要手段是創新：想出新的方法去解決問題，而不是繁雜的事務性工作！——一個專業秘書能比主程做的好一百倍。技術工作的創新，最主要還是在技術工作裡面，而不是跳出來說：做這個，做那個。
管理的事情如果超過10%的工作時間，等于說你更像一個項目經理而非主程。
1. 績效評定
以專業的意見來衡量别人的工作，這個負擔是無人能夠承擔的。這個工作往往是利益配置設定的一種手段。類似獎懲手段。這種管理方法已經不是新事物了。但是實際上技術人員對于績效往往持一定保留和暧昧的态度，因為這種事情難以很清晰的界定出來。需要判斷而非量度，才是績效的真正手段。如果一定要打分，一共兩項足夠了：進度、品質，5分制即可。更重要的事情是，告訴每個人主程的看法，告訴别人，怎樣做才是更好。或者告訴團隊，怎樣做才更有利于我們成功（發财、上市、赢得老闆和客戶……）——把目标清晰告訴團隊，發揮他們的主動性，是績效評定最重要的目标。
4. 進度稽核和任務分派
又是一個很有“權勢”的工作，實際上團隊成員的情況大家都知道，決定誰應該做什麼事情并非需要很多時間去想的事情。是以大可以把方向性的意見告訴項目經理，讓他去做。很多優秀的開發者玩EXCELPROJECT之類的水準還不如隻有一年工作經驗的秘書，别折騰自己了。
5. 面試
如果真想幫忙，準備一份有區分度的筆試題目吧。不靠譜的人太多，老闆可不是花錢請你和他們聊天的。讓項目經理去聊，不用擔心他們技術不強，再不夠，也會比大多數面試者要牛X。他們搞不定的人，就是應該雇傭的家夥。畢業生招聘怎麼辦？隻要看看他們課外活動是不是有搞些專業的事情就可以了，上進心比别的東西都重要，HR會比主程看的更準，相信我。
1. 進度
- 指定工作計劃
- 進度檢查和告警
- 工作總結和統計
2. 資源
- 整合提供各種資源，如找DBA，IT，運維人員，硬體，SVN權限，測試環境，福利，周末的活動……
- 面試：人員是最重要的資源，不是嗎？
- 資源談判：往往是和老闆談判，讓别人明白現在的真實情況。又一個吃力不讨好的差事，但是總需要人做。
-END-
- 長按下方的二維碼可以快速關注我們
-