從“天使輪”到“D 輪”，不同階段 CTO 的職責！
原創【51CTO.com原創稿件】雪球目前處于 C 輪融資，員工總共有 120 多人，其中工程師占一半以上;網站注冊用戶在千萬量級，日活躍用戶在百萬量級。我以公司團隊的發展為線索，針對已經經歷過的階段和未來即將經歷的階段，描述我所認為的不同階段技術團隊和CTO的主要職責。
從“天使輪”到“D 輪”，不同階段 CTO 的職責
天使輪
天使階段是驗證創業者想法的階段，這時沒有完備的技術團隊，事情比較多，沒有太多技術含量。
比如我們當時有個論壇是基于 discuz 建立的，有個官方網站是外包團隊做的，后來雪球的雛形也是外包的，總團隊不到 10 個人，這都是很正常的。
利用一切可以利用的外部資源，使用外包、開源產品等，只要能驗證想法就好了。
A 輪
這個階段要確保規劃的產品能夠按照預想發布，重復地驗證想法。此時要解決的是有沒有的問題，而不是好不好的問題。資源少的時候，需要聚焦在最核心的功能上,不要貪多貪大。
對技術團隊來說，肯定還是盡量拿開源的框架、開源的產品去搭建架構，確保不會花大量時間去開發復雜的底層基礎架構或者框架。
為了提高效率，可以多使用一些新技術，一般來說新技術都是為了避免上一代技術的某些缺點并提高效率而出現的。
我們在這個階段就開始使用 Node.JS 了，要知道 2011 年，很多人可能還不知道 Node.JS 是什么，雪球就把這個技術應用在生產環境了。
這個技術給我們帶來的好處是前后端分離，兩端的效率都大幅提升，前后端都獨立迭代，只要保證 API 兼容。這對我們當時的產品開發迅速驗證產品功能具有決定性的意義。
這種思路也一直延續，包括后來我們引入 Scala、SpringBoot、Docker 等技術都是基于類似的思考。
B 輪
在 B 輪這個階段，雪球已經分成了三個業務團隊。這個階段沒有專職的運維和測試團隊，所以運維的工作由開發來做，測試的工作由產品來做，另外，在這個階段我們重點關注項目管理。
因為產品功能和用戶的增長，這個階段人員的擴張不可避免。突然有一天，你發現開站會的每個同學說幾句話，這個會議時間就要開半小時。
于是我們開始拆分團隊，把按職能劃分的團隊重新按照功能來劃分，以前是前端團隊、移動端團隊、后端團隊、設計團隊、運營團隊。
現在是社區團隊、行情團隊、組合團隊，每個業務團隊都有完整的前后端、設計、運營的同學，所有的產品迭代都是由業務團隊來驅動的。
在這種情況下，我們的項目管理方式是這樣的：各個功能團隊都基本遵循 SCRUM 的迭代方式，每兩周做一次開發測試迭代，產品功能和設計提前一步迭代進行，每周進行產品演示確保產品符合所有人的預期。
功能團隊內部每天會有站會，每周會有對各自項目的周報，周報會說明項目進度，如果有延期用紅色突出標記提示風險和原因。
對于需要跨功能的管理，特別是 APP 需要發布版本，我們采用了版本列車的方法，也就是規定每個版本的提交日期，然后每個團隊根據自己的計劃選擇搭乘哪一個版本，各團隊負責人每周進行 1-2 次溝通。
通報各自團隊的項目進展，相互了解產品特性，確保相互依賴的部分按照預期實現。 這些方法簡單有效且一直沿用至今。
C 輪
在 C 輪階段，公司經過了兩三年不間斷的功能開發，終于迎來了業務量的大爆發，業務團隊也發展到了 5 個，并且為了更好地分工，我們引入了專業的 SRE 團隊、測試團隊、平臺團隊。
比如運維團隊負責基礎設施的建設維護，平臺團隊負責各種基礎框架、類庫、中間件的建設維護，業務團隊抽出專門的時間進行系統改造上線。
其實更多時候是業務團隊和幾個支持團隊一起在往前推進，這樣的組織結構可以充分發揮各個團隊的優勢，比較清晰地進行任務分配。
令我喜憂參半的是，我們的系統開始經常性地發生各種問題：程序負載高、數據庫查詢慢、緩存慢等等，一開始沒有線索，在逐步增加數據收集后，發現高峰時期的請求量是過去的 10 倍以上。
這個階段非常關鍵，尤其在數據、性能、架構方面投入了非常多的精力，做了很多穩定性的工作。
加強數據收集是盡可能地收集所有的數據，然后展現為圖表，再根據數據的突變做報警設置，以前是因為量小，所以不管你怎么去實現，在現在的服務器配置下可能都沒有太大問題。
即便程序本身沒有 Bug，數據量大了瓶頸就有可能出現在任何地方，所以要通過盡可能多地收集數據了解所有系統的細節，為系統重構和擴容做好準備。
性能方面，我大概介紹一下幾個主要的應對措施。另外一個要注意的是時刻要保持警惕，在收集數據的基礎上多觀察總結。
我們不怕出問題，也不可能避免出問題，主要怕出了問題還不知道，以及不知道為什么會出問題。監控報警能夠預知未來和實時提醒，可以把危險消除在用戶感知之前。
系統重構的主要著眼點就是把以前的一個單一的項目拆分成微服務，并且把對應的各種資源如緩存數據庫也進行拆分，因為以前都是混在一起的。
我們對架構***的一個改造就是把一個單一的項目拆分成了微服務，這涉及架構選擇、標準化推行、資源拆分、代碼重構、API 兼容測試、灰度上線、數據監控分析等一系列復雜的步驟。
這些都需要非凡的細心和耐心，我們差不多經歷了一年多的時間才把所有的服務都完全遷移到新的架構上。
D 輪
雖然我們現在還沒有進入 D 輪階段，但是我們已經開始做大部分相關的事情了。我們有更多的業務團隊，有更多的工程師，所以會更加關注流程、規范和運維、測試提供的服務化工具。
隨著參與項目成員的增加，之前描述的開發流程本身變化不大，但是隨著新人的加入，如何互相傳遞信息成為一個問題。
所以我們花了一些時間把以前做過的***實踐，分門別類做了整理，包括項目管理過程、角色定義、階段性產出、產品文檔規范、技術系統設計規范、代碼審查規范、灰度和上線規范等等，基本覆蓋了從需求到上線的大部分場景。
這部分的歸納可以讓所有參與項目開發的同學在對同一件事的認知上處于同一個水平，以便更容易理解和參與。
在運維和測試的基礎設施建設上，在現階段我們也逐漸把以前手工的、半自動腳本式的工具開始系統化、服務化，把***實踐固化在工具當中，只提供有限的靈活度。
這樣做的好處是運維和測試的同學能夠完全從零散的需求驅動轉化為服務提供方。幾乎大部分開發同學的運維、測試需求都可以通過自助的 Web 化工具來完成。
比如，我們自己開發的基于 Docker 的上線和編排系統，開發同學通過這個工具點幾個按鈕，就能把 Git 里的代碼發布到各種開發測試灰度線上環境中，日志自動收集到數據中心、監控系統和報警系統。
監控報警系統預先設置了很多選項，如果需要，開發同學可以完全自定義各種圖表、各種報警項。
測試同學提供的持續集成環境、靜態分析、API 自動化測試回歸工具、UI 自動化測試工具等很容易被開發同學使用，測試同學提供的更多是對工具的支持，以及對如何寫好自動化測試代碼的支持。
綜上所述，我們并不需要非常龐大的運維、測試團隊，就可以支持更多的開發團隊自主解決業務問題，畢竟業務團隊才是最了解自己業務的。
技術團隊建設之路
技術團隊建設之人才選拔
每個團隊都會有自己的風格和處事原則，一般會符合公司創始人的某種特質和風格，在團隊選拔人才上，我們采用了兩種不同的方式：
- 證明你不行的方式。聽起來很奇怪。這個方法是說通過了我們招聘環節的同學，我們都傾向認為是一個好同學，所以會***程度的去信任，入職***天就開通全部的權限、參加所有討論、***周就可以上線代碼，團隊的支持是無條件的。
除非結果很差，比如不積極、不主動、代碼質量差。這樣也沒問題，畢竟他們不熟悉!我們還會一起總結再給他工作調整的機會，甚至調換團隊，如果***所有的措施經過試驗都不行，那就證明了他不行，只好勸退了。
- 證明你行的方式。這個也挺有意思的，是說任何項目或者方案，如果有人可以提出來說我可以搞，那么只要你能給出當前方案存在的問題、解決的思路、方案設計、如何上線、如何測試，假如大家都覺得沒問題了，那這個項目就是你的了。
這樣的同學***手里會有很多重要的項目。他很快就能成為團隊的核心，靠的就是積極主動、先人一步、能承擔責任的品質，這是我們尤其鼓勵的。
對一些同學的能力或者行為有質疑的時候，如果不能很快地下決心解決，最終會給自己、給團隊帶來非常大的痛苦。這又分兩種情況：
有同學能力確實跟不上團隊發展了，但是一直任勞任怨，你不忍心開掉，拖得時間一長，嚴重影響團隊效率。
能力比較強的同學，但是過于個性化，自行其事無法很好的和團隊一起配合，恰逢相關的崗位又一直無法補充合適的人選就那樣湊合著，雖然一再溝通交流但是這種情況根本無法改變。回過頭來看，還是應該長痛不如短痛!
技術團隊建設之不可或缺的“一對一溝通”
日常的一對一溝通，是團隊建設里最不可缺少的一個環節。最開始的時候每過一段時間，我都會和所有工程師進行一對一的溝通。
除了了解想法、傳遞信息之外，我覺得這個過程非常重要的一點是：如果有什么問題，要直接的指出，讓對方很清晰地了解問題是什么，并且如何去改進。
如果不夠直接、不夠清晰很可能會讓對方陷入到誤解中。產生了誤解對于解決問題就沒有任何幫助，所以不要難為情，不要怕傷害對方，大家都是成年人，客觀清晰地表述是對對方***的尊重，也是上級對下級的責任。
如果公司的業務發展的好，特別是高速發展的時候，什么問題都不是特別大的問題，但是需要清醒的認識到隨時可能都有危機存在，對于重點要保護的人要保護到位，任何的溝通不到位或者是激勵不足，都可能會對業務造成比較大的影響。
技術團隊建設之招聘的兩個渠道
招聘渠道千萬條，其中兩個渠道是***的：用戶和內推。
如果一個用戶對現在這個產品感興趣甚至是資深用戶，那么溝通成本會小很多，入職以后通常會更加的積極主動。我們現在有不少工程師都是用戶轉化，他們進入之后無論投入程度、對業務的參與程度、對公司的認同感、服務的時間上都是非常突出的。
有些同學甚至可以降職降薪，當然現在他們的職位和薪資早已超過以前了。內推是另外一個重要渠道，內推的時候，現在的同事就已經幫忙主動過濾了一遍了，通常都是非常匹配的，并且內推獎勵一定遠比獵頭費劃算。
候選人是否合適，我們認為最重要的不是經驗，不是學校，不是資歷，而是價值觀。雪球希望工程師具有的價值觀有哪些呢?
積極主動、客觀、勇敢、對效率要有追求、對技術要有追求、對結果要有追求，至于其他方面，是男生還是女生、是什么學校畢業、發型是什么樣的，我們不是很在意。
***，我們在面試過程中一定要做到真誠，特別是在爭取候選人來的過程中，要站在對方的角度去溝通。現在比較好的同學手里有 3-5個 Offer 太正常了，怎么溝通呢?
我通常都會希望他把其他公司或者職位一起聊一下，我會幫助他分析利弊，根據他的情況幫他去想如何選擇。我并不會把其他 Offer 說的一文不值，我會很客觀的去評價。
這樣做的好處是，我們清楚了在招聘這個市場上其他競爭對手的優勢是什么，并且即便后來他沒有選擇我們，我們還可以成為好朋友，會在 QQ、微信上經常溝通，當他遇到不順的時候，會***時間想到我們。
當時非常真誠地邀請過，后來通過這種方式來的同學也不在少數。
另外，溝通的過程中，一定要知道，說出來的承諾***必須兌現，如果無法兌現的事情千萬不要說，否則是自己給自己挖個大坑，***一定是處理不掉的。
任何團隊的成長都是一路磕磕絆絆
我經常在想如果回到 5 年前，我會怎么規劃那些事情，應該更重點地去關注哪些事情。團隊建設和招聘應該沒有更好的方式了，這是一個長期持續的過程。
如果說哪些是最需要改進的地方?我會選擇在工程實踐上更早投入并且投入更多的精力，這包括兩個方面：
- 業務開發，絕大部分公司從一開始就要進行業務開發，如果開始對質量、架構、代碼不重視，到后來雖然可以重構，但是會非常痛苦，所以從一開始就要重視質量，從人的標準到代碼的標準再到測試的標準都要高，不能放松不能被破壞。
這樣也會對團隊形成一個非常良好的氛圍，就算是新人來了也會不自主地去習慣，不合適的人可以很快的被淘汰掉。以后需要重構時，因為前期的質量好，測試覆蓋好可能就沒有那么痛苦了。
- 基礎設施，在持續集成、持續部署、運維自動化、監控報警這些基礎設施都沒有的時候，我們工程師團隊的生產效率是不會高的，后期再接入這些會需要花費幾倍的時間精力。
另外要特別注重監控和數字，如果對監控和數字不敏感，當系統發生任何變化時，我們都不能感知到，那就危險了。這同時還可以帶來效率提高、避免一些人為操作失誤，對于整個技術團隊的技術積累也是非常有意義的。
王棟
雪球 CTO
互聯網從業 11 年，先后在國美在線、寶寶樹擔任資深架構師，現在雪球任職 CTO，負責雪球的產品技術團隊，關注團隊建設，高可用架構，高效率高質量的運維、測試、開發，運維和測試自動化服務化。
以上內容節選自 CTO 訓練營出版圖書《CTO說》，根據 30 多位CTO訓練營導師的課堂分享內容整理、改編，包括樂視網 CTO 楊永強、360 副總裁譚曉生、跟誰學 CTO 李鋼江、花蝦金融 CEO 段念、極客邦科技總裁池建強等，
更多內容查看：https://item.jd.com/12065279.html
CTO 訓練營為 51CTO 推出的面向中高端技術管理者的學習及社交平臺，16 年推出以來受到了行業里的中堅技術力量的歡迎，邀請了行業里資深的技術高管、技術類型的投資人以及技術創業者，打造技術管理者的 MBA，幫助中國***潛力的技術管理者成長為未來技術領域的***。CTO 訓練營第四季正在招募中，愿意加入我們嗎?
【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】
