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