資深程序員是團隊中最強大的生產力，但往往被不合理的工作安排浪費掉。因此作為一個團隊的技術的“頭”，必須要有明確清晰的認識，把主要的事務性工作剝離出來，并且放棄大量的管理“權力”，以提高團隊開發質量和效率為最主要的目標去安排自己的工作。
一般來說技術總監其實會被要求做事實上是2個職位的工作：主程、項目經理（技術化）
因此必須明確此兩個職位的工作任務分割，然后把項目經理的工作，安排給另外一個人做。當然其職稱可能同樣也得叫“技術總監”或“主程”，總之聽起來越牛X越好。而真正的主程（技術總監）則應該投身于盡量多的技術工作中，其中最重要的工作則是開發———生產代碼和文檔。
主程的工作
一、開發
從來沒有一個資深的外科醫生會放下手術刀，而轉到手術室外面指手畫腳。一個資深的程序員也不應該離開代碼和文檔的編寫，而只是做做架構圖。作為對一個復雜系統的負責人，必須親手領導和參與建造，才能有足夠的能力去負擔起這個責任。因此需要至少使用60%的時間來參與開發的工作，并且建議從一開始上班就開始，雖然早上的效率很低，但是跟任何艱巨工作都一樣：萬事開頭難。
在你好不容易等待電腦慢吞吞的打開了所有的IDE、需求文檔、參考資料、工作計劃這堆要命的東西之后，你就邁出了最重要的一步，你會發現你不再需要在網上看微博和聊QQ來提振開始工作的激情，而會被某一個優化代碼的靈感而激勵，或者被一個復雜而有趣的問題所吸引，從而更快的能投入到開發中。堅持打開電腦做的第一件事是打開IDE軟件，是這一切最重要的一步。
開發的工作內容包括：
1. 提出非功能性需求
一般來說功能需求總是讓開發人員焦頭爛額的主要原因。但實際上，很多項目死在發布之后，卻是因為性能、產品質量、擴展性、二次開發效率等非功能性需求沒認真去解決而導致的。
主程作為經驗最豐富的成員，必須要利用自己曾經的經驗和教訓（在這里教訓往往比經驗重要），提出那些自己折騰自己的“非功能性需求”，來保障整個項目在發布后不會轟然倒塌。
這是個吃力不討好的工作，因為老板和客戶往往只會抱怨技術人員在玩弄把戲，騙取更多的資源或者杞人憂天。如何說服這些家伙也許不是主程的工作，但是主程必須要以高度的責任心把問題放到臺面上來。溝通的工作也許讓項目經理去做會更好，他們有一整套如何威逼利誘老板和客戶的戲法。
非功能性需求中，其中有三類：
- 性能需求
- 運維需求
- 開發效率
性能需求
最好的性能需求實際上所有沒有需求，因為性能優化往往錯的。特別是有一定經驗的開發人員，更容易產生“執念”。經驗不是特別豐富，而又熱愛學習的開發者，往往對很多網上的所謂文章、經驗沒有太多的識別能力，又缺乏動手實際測試的機會，所以道聽途說先入為主的觀念也是非常多的。這些觀念里面最多的就是關于性能的，先不論所謂優化性能的各種說法，就是推薦各種高性能框架、庫的文章也很多。這個時候，撥開紛繁的信息迷霧的人，就只能靠主程了。
運維需求
運維需求的目標是盡量自動化，這里除了最基本的批量啟動、停止、重載靜態數據（配置）外，還應該包括自動讀取本地IP地址，以及自動下載配置文件來啟動；等待所有用戶退出后才停止的“安全退出”；自動檢查進程停止后重啟等等功能。
但是運維的工具也要避免過度設計。很多人往往一想到搞運維工具，就想搞一個功能非常大而全，具備漂亮的WEB界面的大平臺。實際上真正救命的往往是一些自動化的小型工具，只有這些小工具和小功能都齊備了，耐心額漂亮界面的平臺系統真正有意義。所以這主要依賴于經驗，但也需要有想象力。
開發效率
開發效率的需求一般都在代碼結構上，而這是最容易產生爭吵的地方。實際上所謂的代碼結構，是對業務領域抽象的一種表現形式，所以對業務領域的理解能力和經驗是第一位的。如何抽象好業務領域的模型，不能照搬別人的經驗，但也不能完全靠自己想象。需要自己對業務領域做深入思考，同時也多學習了解其他項目的模型。
一般來說，比較底層的技術模型，作為開發人員，都是非常熟悉的。比如UNIX系統把所有東西都抽象成文件。而大量的開源項目，作為通用的技術產品，對于比較技術層面的抽象，也都非常優秀。但是，作為業務邏輯開發人員，是絕對不應該被這些模型所困住的，因為我們要解決的問題，并不是去寫一個操作系統，或者某個開源框架，而是具體的某一個領域的問題。只有真正深入的去了解業務領域，才能很好的抽象業務領域的模型。
也就是說，如果你是開發游戲的，就要深入的理解游戲產品的概念；如果你是開發電商產品的，就要對商業貿易有深入理解，否則是不配做這些產品的開發領導人的。我們有一些技術人員，并不愿意去深入業務領域做理解，而是希望把所有的業務問題，都抽象成他自己最拿手的某一種技術模型，這樣反而是會嚴重影響開發效率的。
比如說有的人，喜歡把所有的業務邏輯，都看成是一種“輸入數據結構”和“輸出數據結構”的處理管道，不管寫什么程序，都是同樣一套類似的代碼結構，就是“讀輸入-解包-處理-寫輸出”。盡管這樣一定可以完成所有的需求，但是其代碼結構并不能應對真正的需求變化，開發效率也一定是低的。真正的主程，就是應該在這個時候，挺身而出提出自己的抽象模型，從而帶動整個團隊，提高開發效率，同時也做好應對需求變化的準備。
2. 設計和修正軟件架構
軟件架構設計至關重要，而且工作繁重。不畫圖紙就敢開工的技術人員要么是天才要么是笨蛋。對于團隊來說，架構在分工合作、避免風險、提高質量等多個方面有無可替代的作用。
架構要避免成為空洞的文檔，最重要的一步是有人來掌控和實施。而主程主持設計和修正的架構，并且親手實施，讓團隊中的腹誹之徒完全無法避開，否則代碼將無法運行！所謂設計和修正架構，并不意味所有的文檔應該一個人寫，而是指這個架構的每個環節，都是經過主程決策同意的。當然最好這些文檔能盡量由他撰寫，對于“菜鳥”團隊來說，輸出這種文檔本身就意味著“權勢”，有助于主程建立個人威信——這種看起來有點骯臟的“政治”東西，在避免團隊內無止境的扯皮，以及穩定那些隨時準備跳槽的成員來說，都是相當實用的。
很多軟件架構只有運行時架構，沒有代碼架構，這是非常可惜的。誠然，我們要關注系統的運行效率，運行時架構（進程結構圖）是必不可少的。然而，代碼架構是更加穩定的設計方案，因為在必定會發生的需求變更下，進程結構往往也會因此變化。代碼的結構是對需求的抽象和描述，這種描述是對業務需求的理解，業務需求小的變化非常多，而大的方向卻往往不會變化很頻繁，因此如果能基于這些大的方向來組織代碼，劃分模塊，那些繁復的小需求，僅僅是對系統局部的修改，而不會影響過多的其他部分；反之，如果我們沒有整體的視野去組織代碼和模塊，僅僅從一開始的細節需求去組織進程代碼，一定會因為需求變化而把整個系統改的亂七八糟。
所以，作為主程或技術總監，把控代碼結構，往往比把控進程結構更為重要。同樣的代碼可以組織到不同的進程內來啟動，如果進程結構不適應性能需求，還是可以優化的。但反過來就行不通了，一個混亂的代碼結構，不管你怎么去用進程結構調整，還是會問題百出。
3. 難點代碼（關鍵需求）的開發
主程必須寫代碼，寫那些大家都認為風險大的代碼。
有的系統對于性能要求很高，他就必須去完成容易出性能問題的部分。比如IO操作或者設計數據庫索引。有些系統的需求非常飄忽，他就要去想辦法完成框架代碼或者腳本引擎，以便眾多小弟可以跟著產品人員疲于奔命。這種工作內容會讓主程不必完全的讀過所有代碼，而能牢牢的“掌握”代碼，以免團隊成員甩耙子的時候能充當備胎。因為融入團隊的代碼開發，也是一個讓架構設計從日常工作中真正控制系統的工作。而且主程代碼通常會被別人接觸，能直接教育其他團隊成員，同時也能建立——威信。
在大公司中，由于團隊成員普遍素質比較高，所以都這部分的需求會比較少。但是還是有一些部分的代碼，應該親自操刀。如果不能對最核心的實現模塊下手，起碼也應該對客戶使用界面有一定的編碼經驗。
比如游戲開發中，某個比較復雜的業務邏輯腳本；在發行的產品或庫中，編寫針對用戶演示用的DEMO等等……。究其原因，是因為客戶是最重要的，而領導者起碼應該直接參與面對客戶的部分。店長不迎賓，廠長不進車間，事情是絕對做不好的。
而中小型公司里面，如果編碼工作還是放給別人做，到頭來還是給自己找麻煩。因為小型公司人力本來就緊張，而質量低下的代碼，造成的故障和BUG，會更加消耗不多的時間成本。自己做的越多，項目成功的幾率就會越大。
4. 救火和殺蟲
這個工作其實和代碼開發是一致的，如果沒有平日的開發，通常緊急問題的解決也是比較難處理的。但是這個也有一個調試技巧的要求，比如要求會使用各種診斷工具。這些工具一般的開發人員可能會比較少使用。找問題的過程本身也可以提高團隊其他人的技術水平。
二、培訓
培訓的工作應該占用30%左右的工作時間。培訓是穩定團隊人員最重要的手段。也是提高團隊開發效率最有效的手段。工具、過程、制度、獎懲，這些都代替不了程序員一行行的去寫代碼，最直接的方法是讓他們做的更快更好，這些需要經驗和知識的積累。
1. 代碼審查
關于代碼審查，有太多的論述。但是代碼審查還是一種“強迫”推行某種風格或者技巧的手段，這是最真實的“控制”系統的手段。也是推廣知識和經驗最直接的手段。一個人寫的代碼通常應對的問題不會特別“廣泛”，因此只要審查其中一部分代碼，就能給大部分別的代碼帶來好處。
代碼審查的實施，應該有一定的基礎。需要代碼作者進行問題描述、代碼結構的講解。而且也需要作者自己來挑選重點代碼段。主程序員應該指出自己關心的重點代碼應該符合什么特征。
2. 技術方案評審
什么事情應該寫一個技術方案，然后進行評審，這是一個關鍵的問題。一般認為開發時間在2周以上的單項工作應該先做個方案。往往技術方案是系統架構的完善和補充，或者是挑戰。所以主程的參與是非常必要的。但是要注意不需要去做的太瑣碎，而是要提煉出“關鍵”的需求和“關鍵”的解決方案進行評審，而這些“關鍵”往往不是功能，而是質量上的需求，如這個系統的擴展性，是否能方便后續開發等等。也有可能在這些會議上會發生爭吵，但是決策人是主程的地位是不容動搖的。君子和而不同，每個程序員都可以擁有自己的看法，但是代碼必須能按方案運行起來，主程必須經常申明這點。
技術方案在差距較大的團隊中評審，一般來說可以視為一種培訓；而在水平相當的團隊中評審，可能會變成各自想法的爭執。不同的項目經歷，絕對會造成意見的大分歧。其實這就是所謂“非功能需求”沒有被明確出來造成的。這個時候主程就應該履行自己的義務，去提煉爭論中的“非功能需求”，然后做出決斷。
3. 學習與講座
如果團隊碰到問題，沒有新的方法和技術去解決，是不會提高開發效率的。就好像你用牛來耕地，不管用什么管理方法，都不會趕上機械化的速度。而主程承擔著不斷突破自己的技術上限，介紹和推動團隊使用更新的技術來解決問題的責任。抱殘守缺，思想僵化，最后會被團隊成員所拋棄，而且也會讓團隊的效能落后于業界，最后直接影響產品的生死。每年學一門新語言，這個說法可能有點激進，但是這也是作為程序員應該有的激情。
三、管理
管理等于權勢？管理等于溝通？管理等于文山會海？多年專業訓練出來的技術人員如何去做管理？
管理的目標是提高績效，如果和這個目標無關，而只是和“管理者”這個頭銜有關的事情，最好丟給別人去做，包括那個頭銜。管理主要手段是創新：想出新的方法去解決問題，而不是繁雜的事務性工作！——一個專業秘書能比主程做的好一百倍。技術工作的創新，最主要還是在技術工作里面，而不是跳出來說：做這個，做那個。
管理的事情如果超過10%的工作時間，等于說你更像一個項目經理而非主程。
1. 績效評定
以專業的意見來衡量別人的工作，這個負擔是無人能夠承擔的。這個工作往往是利益分配的一種手段。類似獎懲手段。這種管理方法已經不是新事物了。但是實際上技術人員對于績效往往持一定保留和曖昧的態度，因為這種事情難以很清晰的界定出來。需要判斷而非量度，才是績效的真正手段。如果一定要打分，一共兩項足夠了：進度、質量，5分制即可。更重要的事情是，告訴每個人主程的看法，告訴別人，怎樣做才是更好。或者告訴團隊，怎樣做才更有利于我們成功（發財、上市、贏得老板和客戶……）——把目標清晰告訴團隊，發揮他們的主動性，是績效評定最重要的目標。
KPI是一個爭論非常多的話題，技術人員的KPI的爭議更多。
關于KPI，有幾個觀點是必須明確的：
- 難以量化的東西，就不要強行量化；
- KPI應該以任務是否有去做完為標志，而不是做到的效果為標志；
- 分解和設計KPI是一個非常需要承擔風險的工作，基本上等于提出實際的工作方案。
以上三點，是互為結合的。技術工作的質量很難量化，或者指導性不強，還不如以工作的數量為標準，指導性反而更強。
那么要怎么設置這些工作任務的數量呢？
應該去設計一些能“保證質量”的工作任務，作為必須要完成的工作數量。那么，問題就更進一步了，要設置些什么樣的工作，才能作為指標？這就需要技術總監根據自己的經驗和智慧，提出切實可行的方案去要求下屬完成，而不是把需求簡單的分切后丟給下屬去自行了斷。
舉個例子，有一個部門的業務邏輯開發任務很重，由于需求多變化快，代碼質量難以監督，所以各種性能和邏輯故障都層出不窮。如果你只是設置了BUG的數量和需求完成數量作為指標，靠這種KPI是難以推動真正的改進的。反過來，如果你對需求實現模塊，設置了必須要完成的單元測試任務指標，設置了運行質量監控系統的開發指標。如果部門完成了這些事情，項目的質量和進度自然就會有提高。——但是這些措施是否真的能奏效，這就是作為技術總監必須自己承擔的決策風險。
2. 需求評定
最讓技術人員頭疼的可能就是和客戶談判。這個事情實際上不應該讓技術人員來傷心，有項目經理就可以了。而需求評定更多的是可行性的討論。主程如果參加每個需求評定，他要三頭六臂也搞不定，正確的做法應該是具體開發的團隊人員參加，而主程在開會前給與自己的意見，或者會后聽取參與者的總結。——這是了解別人做什么事的一個重要手段，但無需陷入太深，因為還有代碼評審和項目經理的幫忙。
3. 跨部門溝通
實在沒必要參加，能躲就躲，這是扯皮的天堂。讓項目經理去吧，他們的專業技巧能讓這些事情更加有效。只要回來后讓項目經理告訴你發生了什么事情就可以了。
4. 進度審核和任務分派
又是一個很有“權勢”的工作，實際上團隊成員的情況大家都知道，決定誰應該做什么事情并非需要很多時間去想的事情。所以大可以把方向性的意見告訴項目經理，讓他去做。很多優秀的開發者玩ExcelPROJECT之類的水平還不如只有一年工作經驗的秘書，別折騰自己了。
5. 面試
如果真想幫忙，準備一份有區分度的筆試題目吧。不靠譜的人太多，老板可不是花錢請你和他們聊天的。讓項目經理去聊，不用擔心他們技術不強，再不夠，也會比大多數面試者要牛X。他們搞不定的人，就是應該雇傭的家伙。畢業生招聘怎么辦？只要看看他們課外活動是不是有搞些專業的事情就可以了，上進心比別的東西都重要，HR會比主程看的更準，相信我。
6. 各種會議
飯無好飯，會無好會，超過6個人的會議應該堅決抵制。如果你有一個程序等著你去寫，你一定無比痛恨這些會議，順應你的內心吧！上帝保佑你。
最后說說項目經理的工作
項目經理就像下水道的清潔工，所有那些主程不愿意去做的事情，他們都彎下腰去認真的把玩，實在是太偉大了。既然如此，為何不讓他們擁有更好一點的頭銜呢？如果沒有他們去處理這些工作，任何一個主程都會被逼瘋掉，或者他們自己變成了項目經理，讓團隊損失了最強力的一臺代碼發動機。
在一些公司，有專門的項目經理的崗位，這無疑是幸福的，但也是不幸的。因為項目經理本身是一種既需要專業性，也需要通用技能的崗位。項目經理由于專業定義不清晰，導致了大量的誤解，這就是不幸的原因。有的團隊會說我們不需要項目經理，又有的團隊會認為項目經理無比重要，這兩種觀點的爭論一直沒有平息過。因此比較實際的做法是，不要輕易的去評價“是否需要項目經理”，而是努力把工作細分，專業化，然后再看應該安排誰去做。不同的項目和不同的團隊，也許項目經理的工作都是不同的。
根據經驗，項目經理大概的工作內容方向包含以下這些：
一、進度
- 指定工作計劃
- 進度檢查和進度延遲的預警
- 工作總結和統計
二、資源
- 整合提供各種資源，如找DBA，IT，運維人員，硬件，SVN權限，測試環境，福利，周末的活動……
- 面試：人員是最重要的資源，不是嗎？
- 資源談判：往往是和老板談判，讓別人明白現在的真實情況。又一個吃力不討好的差事，但是總需要人做。
三、溝通
- 需求評審：和需求方討價還價，項目經理真是命苦啊……
- 組織會議或者用其他方式通知信息給所有人：小喇叭、大喇叭、全服廣播、世界頻道……
總結
對于一個小型公司，職權，頭銜，收益，往往會更加敏感。但是這些都不是讓項目失敗的理由。一顆叫程序員的種子說：長大了我就是叫管理者的樹。這個錯誤的觀念只會讓這個種子永遠無法發芽。軟件開發是類似外科醫生的行業，而不是血汗工廠，所以不需要手持皮鞭的經理，而需要仁心仁術的神醫。
