【騰訊Bugly乾貨分享】總結一個技術總監的教訓和經驗
導語
2017年來了，新年開篇，就不跟大家聊技術啦，給大家分享一篇鵝廠技術總監在多年工作中總結出的教訓和經驗。
這篇文章自從在騰訊內部論壇發表後，精神哥每年都會拿出來重新研讀一番，每次都有新的感悟和收穫，所以強烈推薦給大家。
正文
資深程式設計師是團隊中最強大的生產力，但往往被不合理的工作安排浪費掉。因此作為一個團隊的技術的“頭”，必須要有明確清晰的認識，把主要的事務性工作剝離出來，並且放棄大量的管理“權力”，以提高團隊開發質量和效率為最主要的目標去安排自己的工作。
一般來說技術總監其實會被要求做事實上是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許可權，測試環境，福利，週末的活動……
- 面試：人員是最重要的資源，不是嗎？
- 資源談判：往往是和老闆談判，讓別人明白現在的真實情況。又一個吃力不討好的差事，但是總需要人做。
三、溝通
- 需求評審：和需求方討價還價，專案經理真是命苦啊……
- 組織會議或者用其他方式通知資訊給所有人：小喇叭、大喇叭、全服廣播、世界頻道……
總結
對於一個小型公司，職權，頭銜，收益，往往會更加敏感。但是這些都不是讓專案失敗的理由。一顆叫程式設計師的種子說：長大了我就是叫管理者的樹。這個錯誤的觀念只會讓這個種子永遠無法發芽。軟體開發是類似外科醫生的行業，而不是血汗工廠，所以不需要手持皮鞭的經理，而需要仁心仁術的神醫。
更多精彩內容歡迎關注騰訊 Bugly的微信公眾賬號：
騰訊 Bugly是一款專為移動開發者打造的質量監控工具，幫助開發者快速，便捷的定位線上應用崩潰的情況以及解決方案。智慧合併功能幫助開發同學把每天上報的數千條 Crash 根據根因合併分類，每日日報會列出影響使用者數最多的崩潰，精準定位功能幫助開發同學定位到出問題的程式碼行，實時上報可以在釋出後快速的瞭解應用的質量情況，適配最新的 iOS, Android 官方作業系統，鵝廠的工程師都在使用，快來加入我們吧！