如何勝任一個小型公司的技術總監？

時間 2019-11-05

原文原文鏈接

資深程序員是團隊中最強大的生產力，但每每被不合理的工做安排浪費掉。所以做爲一個團隊的技術的「頭」，必需要有明確清晰的認識，把主要的事務性工做剝離出來，同時放棄大量的管理「權力」，以提升團隊開發質量和效率，併爲最主要的目標去安排本身的工做。通常來講，技術總監這個職位主要包含兩個角色（職位）的工做：主程和項目經理（技術化）。程序員

所以咱們必須明確此兩個職位的工做任務分割，而後把項目經理的工做，安排給另一我的作，固然其職稱可能一樣也得叫「技術總監」或「主程」，總之聽起來越牛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. 進度