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