公司各個階段 CTO 須要作什麼？

CTO 是企業內技術最高負責人，對企業的發展起到相當重要的做用。但隨着公司的不斷髮展，CTO 的工做重心也會不斷變化。只有在正確的階段作正確的事，才能更好地爲公司作出貢獻。我是空中金融 CTO ，TGO 鯤鵬會上海分會會員。加入空中金融以前，我曾在餓了麼、空中網、5173 等互聯網公司擔任中層技術管理者，有過三次從 0（ 或 0.5 ）開始的創業公司工做經歷。本篇文章，我將爲你們分享，公司初創階段 CTO 須要作的事。

假設一個公司發展有如下幾個階段：

• 0 ：創始階段；
• 0.5 ：有產品但無管理階段；
• 1 ：通過 1年的發展初步穩定的階段；
• 1+ ：穩步發展階段。

這一篇，我將和你們聊聊公司初創階段 CTO 須要作什麼。剩下的階段將會在另一篇文章分享。

初創公司 CTO 或者技術負責人，最重要的目標是在最短期內用有限的預算打造合適的團隊把項目作起來。說說我遇到的兩種初創公司的狀況。

從 0 開始的狀況

從 0 開始指的是：你是公司第一個技術人員，你須要從 0 開始搭團隊。最初，你須要作以下幾項工做：

預算和組織

評估項目初版在規定時間內上線須要多少人的技術團隊，是否須要分產品線，規劃出不一樣崗位的人數。好比，項目經理 1 人、前端 2 人、後端 5 人、客戶端 2 人、UI 設計 2 人、產品經理 2 人、測試 3 人、運維 2 人等等。而後根據技術團隊的規模預估人員成本，以及作服務器、軟硬件的預算，把這些預算和整個公司的預算放到一塊兒評估，看是否可行。若是可行，當即全面開啓人員招聘。若是初期人數不超過 20 人，不須要特別複雜的組織架構，全部人直接向你一人彙報也能夠。在項目執行過程當中，項目經理甚至是產品經理能夠幫你負責一部分管理工做。在初期，雖然完全扁平化的架構會很累，但有助於提升效率和執行力。

人員和招聘

對於通常作產品的初創公司而言，業務量不大，不須要高端人才，須要的是踏實肯幹、願意拼搏、願意與公司一塊兒成長的具備相同價值觀的人才。公司初創階段各崗位須要大量招人，選擇合適的面試方式和麪試難度很是重要。我會經過筆試初篩，以節省時間，避免和不合適的面試者禮節性聊天。

個人筆試有兩個特色：

一、能夠開卷

我不反對現場拿手機查資料，可是由於筆試時間固定，現場查資料每每意義不大。第一，個人筆試題不是網上搜的，沒有現成的答案；第二，大部份內容考察的都是技術細節或對技術的總體理解。若是面試者以前不理解或是沒有經驗，臨時抱佛腳用處不大。

二、筆試考察的知識面是比較全面的

好比，後端的面試題涉及到語言基礎、算法、SQL 、虛擬機、Linux 、架構設計、設計模式、框架等分類，難度比較高。30% 的面試者在看到筆試題後會選擇放棄，其實只要是認真回答問題的，哪怕只答出 40% ，我也會安排面聊。我只是但願經過難度較高的面試題刷去一些內心不那麼強大的面試者。

在招聘淡季，我會要求人事廣撒網進行筆試，由於確實遇到過一些工做經歷不那麼出色，但技術基礎特別紮實的面試者，若是簡歷初篩淘汰了這樣的面試者是比較惋惜的。筆試以後的面聊會針對筆試的問題展開討論，而且要求面試者介紹以前的項目經驗、學習方式以及對技術的追求。

面試是搭團隊最重要的一個環節，搭團隊是技術管理者最重要的事情之一，怎麼強調面試的重要性都不過度。最好在最初能招到幾個優秀的人做爲核心成員，這樣可讓他們來分擔一些面試工做，讓本身有時間作其餘的事情。初創團隊的人員必須個個是精英，好比，一個只有 3 我的的前端團隊，其中 1 我的很平庸，那麼你的前端團隊就有 33% 的人是很平庸的。若是所以前端成了短板，那麼 1 人的問題就極大限制了整個技術團隊的效率和產品質量。

項目和產品

在招聘的同時應該抽時間來制定項目計劃，若是技術管理者不熟悉業務，須要先作功課熟悉產品的業務形態，這樣才能夠評估產品的技術難度和工做量，以便作出合適的計劃。有了明確的研發計劃，公司的運營、業務部門才能根據這個計劃作相應的推廣運營計劃。

除了計劃，須要先用腦圖把核心業務的領域、模塊、功能梳理出來，和管理層一塊兒把產品形態討論清楚，而後在產品研發內部宣講，讓你們對產品的目標達成共識。在初期，產品能夠根據這個方向來細化造成產品文檔，技術能夠根據這個方向來調研須要的技術。

技術和架構

技術架構方面有幾點很是重要：

語言

開發語言是招聘以前就應該肯定的。通常而言，技術管理者會選擇本身熟悉的語言做爲項目最初的核心語言。對於業務型項目，採用 Java 或 Python 這種普適性語言；對於純高併發的服務端項目考慮 Go ；對於 Windows 項目或企業級項目考慮 .Net ，按照這個方向來作不會出大錯。我不太建議在初期融入太多語言，或許不一樣語言的結合能夠發揮出性能和開發效率的優點。但在初期就混用會增長管理成本，提升基礎框架的開發難度，並且每一種語言的開發都須要學習和成長路線，得不償失。

框架

肯定了語言以後，圍繞語言咱們要肯定開發框架。通常而言就是前端的 JS 、CSS 框架、後端的 MVC 、SOA 、ORM 框架的選型。若是沒有必定積累，不建議選擇自研，能夠先選用成熟穩定的開源技術做爲開始。項目發展到必定階段，若是開源技術不能知足須要，在選擇自研合適的框架或中間件來進行逐一替換。

架構

包含幾個方面的不一樣類型的架構，這些事情雖然不可能在很短的時間內都想清楚，但這是領導者必須考慮的。不少公司不少項目在運行了幾年以後，核心系統整體上仍是維持了初版的架構，雖然遇到各類問題想要推翻重來，但都由於代價實在太大而擱置或放棄：

• 產品架構：戰略是怎麼樣的，是否須要進行產品化抽象，擴展性是怎麼樣的；
• 系統架構：網絡怎麼接入，哪些環節作高可用，涉及到哪些中間件，存儲是什麼，容量評估；
• 業務架構：多少領域，多少子系統，對內仍是對外，怎麼相互支持；
• 應用架構：層怎麼分，邏輯層仍是物理層，模塊或服務怎麼分，模塊和模塊之間怎麼通信，同步仍是異步；
• 工程化：咱們是須要考慮可持續、可迭代的，一個良好的工程結構和工程方式也是初期須要肯定的。好比，肯定項目結構、源碼管理方式、分支管理方式等等。

核心業務

在幾個創業公司工做時，我都會本身來實現最底層的技術框架或核心業務代碼。一方面本身能夠徹底把控最難的核心繫統，另外一方面能夠順便把技術架構搭建起來。接下去，團隊成員就能夠在這個骨架上填肉，這樣即使一開始沒有很好的標準和指導原則，也能夠把控住整個項目的代碼。

技術難點

除了核心業務，我會在最初就分析項目的技術難點，這些技術難點咱們會選擇三方技術來實現。可是一開始咱們就要去考慮之後要脫離三方技術本身實現核心技術的可能性和代價，把這些問題擺在桌面上，讓全部管理層都認識到。

除了這些，技術管理者須要作到的很是重要的一點就是以身做則，給你們作榜樣。團隊的規則和規矩一視同仁，這樣，團隊成員在執行你定的這規則的時候纔沒有任何理由拒絕和作不到。

從 0 開始確實須要作大量的工做，研究討論產品方向，作產品計劃，大量面試和新人培訓，本身參與部分代碼編寫，還要凝聚初始的團隊和團隊磨合。這些事情每每會讓你以爲分身乏術，但這段時間熬過去後，你就會體會到，這些工做都很是有意義。相反，若是一開始缺失這些工做，讓技術野蠻生長，以後的工做就會很混亂。

從 0.5 開始的狀況

從 0.5 開始的狀況是，公司已經有一支團隊，產品也已經上線。因爲前期缺少管理，技術方面處於一個爛攤子的狀態。開發效率低、問題多，沒法知足公司高速發展的須要。這個時候進入公司和從 0 開始的狀況略有不一樣（但這其實又不一樣於成熟公司空降管理層），對內，我會在最短的時間作下面的工做：

熟悉產品

熟悉這個行業或領域，熟悉公司既有的產品，評估產品的技術難度，內心對指望的團隊形態有一個底。同時能夠花一點時間過一遍現有項目的技術架構和代碼，對於現有的技術債也有一個預期。

熟悉團隊

對現有團隊成員進行 1 對 1 溝通（或者直接點說就是面試），瞭解每個人的技術水平，當前的心態和狀態以及對公司的指望。

開展救火

根據對產品的理解和已經與各需求方溝通的結果，按照輕重緩急整理出目前技術上須要調整的部分，挑選最重要的任務進行突擊救火。能夠進行小黑屋形式的集中開發，給予團隊必定的壓力，把工做分配到具體的人。一方面考察每一個人的能力，一方面也考察成員的抗壓能力和拼搏精神，追求安逸的人不適合在創業公司工做。若是業務在高速發展，不太建議一開始就停滯業務的迭代，把老項目推翻重來。最好的方式，是先進行必要的重構，等之後每一塊業務進行大調整的時候進行逐一推翻。

調整團隊

根據 1 - 3 的結果，快速進行團隊調整，勸退不合適的人，招聘須要的人才。這些調整是基於一段時間對於產品和團隊熟悉後的結論來的。並不建議所謂的新官上任三把火，在不瞭解團隊的狀況下直接調整。有的時候可能會心軟，認爲不合適的人能夠去幹一些沒有那麼大技術含量的工做，我也這麼作過，但最後都付出了代價。

完全融入

我我的的習慣是挑選比較重要的某個痛點本身上陣，對代碼或架構開刀，只有這樣才能真正瞭解你們目前遇到的問題，而且能儘快熟悉業務，你們融入到一塊兒。若是時間有限，就把工做放到晚上或者週末進行。只有本身走到了最前線，才能在作出更有利於團隊實際狀況的決策。

創建信任

做爲管理者進入新團隊，團隊的成員會擔憂新上級作出的團隊調整會對本身有影響，會形成軍心不穩。因此，在進行團隊調整時，必定要對核心成員進行確定和鼓勵，另外，信任的創建不能僅靠權勢，更重要的是，在平常工做中和你們一塊兒拼搏，給予你們幫助，和你們創建平等的信任關係。

對部門外，須要同時和其餘部門的負責人進行逐一溝通，瞭解你們對產品和技術的指望。另外，須要和 CEO 進行密切溝通，使本身的決策獲得上級的支持。通常而言，我還會接手對公司外部的溝通工做，讓團隊成員能夠更專一於項目。

0.5到1的階段

公司通過了初創階段，產品也已經上線運行。接下來產品須要高速、高質量迭代，做爲技術管理者須要把各方面都規範起來。

管理須要標準化

創建項目管理流程：

• 是否要使用一些項目任務管理工具，好比 Jira 或 Tower 等；
• 是否要使用一些文檔知識管理工具，好比 Confluence 等；
• 選擇什麼樣的開發模式，是敏捷開發仍是傳統瀑布開發；
• 制定各類會議制度，好比固定的晨會、週會、總結會等；
• 規劃分支使用的流程，代碼審覈的流程；
• 測試如何進行，選用什麼樣的 Bug 管理平臺，Bug 的分級等；
• 和公司其餘部門按期同步並討論項目整體計劃流程。

創建溝通匯報流程：

• 規劃平常對內、對外 IM 溝通工具和郵件使用的規則；
• 肯定平常工做流程（評審、提測、發佈、上線）；
• 制定每個團隊成員的日報或週報的模板。

績效管理：

績效管理如何來作，選擇 OKR 仍是 KPI ？你們有太多討論和不一樣意見。在 TGO 鯤鵬會的小組活動中，咱們組員也常常會針對這個話題討論，每個公司都有不一樣的作法，這和公司層面的文化、背景、項目屬性、甚至是管理層的性格都有關係，沒法徹底照搬別人的作法。

我認爲一個相對成熟的公司，適合公司的績效管理方式必不可少，須要不斷探索。通常而言，考覈是用來激勵那些不太優秀的人，特別優秀的人才不管如何考覈，他們永遠都是是衝在最前面的一批人。可是，任何公司都不可能作到 100% 的員工都有合夥人的心態和衝勁，也不可能 100% 的員工都是世界一流人才。因此，幫助全部員工創建清晰的目標而且進行回顧和考覈很是重要，要讓全部人的目標都是清晰、具體且正確的。

技術須要標準化

各個環境標準化：

• 定義明確 Dev 、QA 、Staging 、Live 環境的做用、每一個人的權限，以及每個環境的使用方式；
• 創建一套統一的發佈系統來處理平常發佈。好比，能夠封裝 Shell 腳本或 Jenkins ，而且明確在線上發佈事中過後，包括：運維、開發、測試、產品等每個應該負責的點。

創建技術標準規範：

• PRD 產品需求文檔和 UI 標註的標準；
• 開發標準，好比，能夠在阿里的 Java 開發規範基礎上和你們一塊兒討論，總結出符合本身公司需求的開發標準，而且經過代碼規範插件來約束；
• 概要設計文檔的標準，文檔必須包含哪些點，何時提交評審；
• 概要設計時錶結構和服務定義的標準，各類中間件使用方式的標準和最佳實踐；
• 自測標準，單元測試的要求，自測不完善測試打回的懲罰等；
• CMDB 的創建、服務器配置，操做系統基礎配置，程序安裝方式的運維標準化。隨着時間的推移能夠總結出適合本身團隊標準或最佳實踐，全部的標準應該是全部團隊成員共同承認和遵循的，能夠按期就這些標準進行回顧和討論。

創建監控管理制度：

• 搭建日誌、監控報警基礎設施。好比，可使用 ELK 、Grafana 、InfluxDb 等來搭建；
• 統一公司的日誌、打點框架，規範明確項目的日誌和打點標準；
• 爲各個業務創建監控面板和報警規則，明確報警處理標準；
• 定義事故分級流程，覆盤方法以及追責方式；
• 定義運維平常監控容量巡檢方式以及應急響應預案。

1+ 的高速發展階段

隨着業務規模的擴大，極可能有了多條產品線；隨着團隊規模的擴大，完全扁平化的組織架構可能沒法知足須要；隨着訪問量的增大，對技術和架構的要求也愈來愈多。這種狀況，無論是對技術的要求仍是對管理的要求都更上一層樓，這個時候須要在標準的基礎上再作一些管理和組織結構的演進，站在更高的角度管理去思考。（這個時候作一些細枝末節的工做對於總體的意義就不大了）。

技術方面的昇華

隨着公司的發展，產品要麼形態豐富，各類產品和業務衍生出來，要麼產品形態不變，訪問量急劇增大。對於前者，管理方面很容易犯的一個錯誤就是簡單的進行業務線的拆分和招人、招人、招人，造成 N*20 個這樣的團隊，每個團隊之間相對獨立，技術沒有沉澱。對於後者，很容易犯的錯誤是經過堆服務器和堆運維來抵擋壓力的上升，致使技術架構老舊問題增多。這種粗曠風格的團隊擴張是不太健康的，更好的方法仍是多折騰：

1. 個人建議是經過進行技術和組織架構的調整，造成專才，造成縱向技術線，把通用技術提煉出來，讓整個公司均可以積累統一的、可以向前發展的技術平臺；
2. 強制經過自動化手段把人解放出來，人應該去作創造性的工做；
3. 消除團隊安逸的狀態，讓團隊或業務線之間造成競爭，保持衝勁。

組織架構調整

隨着業務規模的擴大，團隊規模也在擴大，僅僅對業務線的技術團隊進行橫向拆分（ X 維度拆分 ）還不夠，還須要有專門的垂直團隊服務於橫向的業務團隊。經過創建架構、中間件、運維等垂直團隊服務於全部業務團隊，確保技術和架構的統一（ Y 維度拆分 ）。

若是團隊人數超過 20 不足 50 ，咱們須要增長經理層來管理一線員工，變爲三層架構，若是人數超過 50 不足 100 ，咱們須要增長高級經理來管理經理，變爲四層架構（ Z 維度拆分 ）。固然，可能還會造成一些虛擬的或實際的技術或項目管理委員會，對技術人員的發展、技術的標準化、公司層面的技術大任務進行定義和協調。

補充如下幾點：

1. 隨着層級的增多，管理者對於一線員工的觸達會愈來愈難，可能致使執行效率下降。這個時候，對下屬主管的任用和管理很是重要。與管理一線員工相同的是，主管也須要績效考覈和標準，不一樣的是，主管們承擔了管理職務，一線員工是由他們直接管理和影響的，此時對於主管的培養很是重要。不只僅要讓他們使用 CTO 原先定的標準和套路來管理，更多的是讓主管明確意識到本身的管理職責，激發出他們本身的管理風格；
2. 在確保主管被充分受權，而且有團隊管理自治性的同時，最好提供一個通道，讓一線員工有機會表現和表達本身的想法，讓高層管理者能夠了解到任何一名員工的想法，保持公正透明；
3. 在公司這個階段，能夠和人事一塊兒把人員的職級要求和薪資標準進行統必定義，要和績效考覈結合起來，造成固定週期的職級調整方案，造成明確的上升通道。讓每一位成員意識到只要經過本身的努力，在公司內部一樣能夠走的很遠；
4. 業務團隊和平臺架構團隊的目標使命不一樣，會存在一些矛盾存在。做爲 CTO 要作好引導，讓業務團隊認識到架構統一的重要性，讓架構團隊認識到業務團隊的壓力。也能夠鼓勵團隊之間的人員換崗以及作一些技術團隊的培訓，讓架構團隊理解業務，讓業務團隊深挖技術。

創建文化

人畢竟是社會動物，是有感情的，若是公司全部的管理手段都是硬手段，員工很難從心裏承認。咱們能夠和 HRBP 配合，打造有團隊特點的技術文化。好比，分享文化、開源文化、學習文化、鼓勵自動化的文化等。

咱們能夠創建技術團隊的微信公衆號，讓全部人一塊兒來發文和運營。能夠把自研的項目開源出去貢獻給社區，讓社區一塊兒來完善，能夠組織按期的公司內部或公司與公司之間的技術培訓或交流，組織一年一度的技術之星、產品之星評選等等。初期能夠經過使用必定的獎勵激勵手段來傳播固定技術文化，造成文化後，每一位團隊成員會以爲工做不只僅是完成我的的任務，而是在一個集體中成長，在團隊中生活，有歸屬感價值感。

創建價值觀

通常而言公司層面會提煉出 3 - 5 項重要的價值觀，技術團隊也能夠在此基礎上細化、提煉技術方面的價值觀，並歸入考覈。

我的認爲價值觀一方面能夠給咱們定一個大方向，好比，咱們須要怎麼樣的人；另外一方面又相似於心理暗示，潛移默化的影響每一位員工。慢慢地，員工會演變爲符合公司價值觀的人（變得和公司有「夫妻相」），或者意識到沒法適應價值觀而主動離職。好比，若是能夠定義一專多能、主動承擔、敢於創新、言出必行做爲技術團隊的價值觀，而且展開列出一些子項歸入考覈。即便員工的業務能力沒問題，但平常的表現不符合價值觀，那麼他只能是一個過客，沒法和公司一塊兒發展，這也是爲何不少大公司如此強調價值觀的緣由。

團隊規模小的時候，咱們只要本身衝在前線就能夠很好的管理團隊，在規模中等的時候咱們能夠利用一些標準和制度進行管理，在規模更大了之後，咱們須要更高維度的文化價值觀等手段來感染到每個員工，讓員工認同公司，這比約束命令式管理更有效。

處於這個階段的公司，CTO 不只要作好對內的管理工做，還要抽出時間作一些對外的工做，來幫助公司作品牌宣傳，而且用技術爭取更好的資源，好比，按期和同行以及投資人交流，組織參與一些技術討論，跟進行業趨勢等。

最後，想聊聊技術如何服務於公司戰略？

就我我的而言，我以爲兩點很重要，一是堅持，二是應變，三是要思考。圍繞這幾點，我列了一些技術服務公司戰略的要點。

產品技術部門最基礎的職責

做爲產品技術團隊，最本職的工做仍是持續高效輸出高質量、高可靠的產品，知足公司的業務須要。而且在不斷提升可用性的同時，經過自動化、標準化提升效率，節省人力成本。在組織規模變大了之後，還能經過管理手段來保持團隊的高效。隨着業務和團隊規模擴大，作到這幾點並不容易，但這只是技術服務於公司戰略的基本要求。

以技術創新把不可能變爲可能

舉個例子，有一次，業務給我提了一個需求，由於受到底層外部接口的限制，這個需求沒法實現。可是業務表示，爲何別的公司能夠實現，咱們就不行。這時候，我才花時間去認真思考是否有一些突破的辦法，嘗試找到別人的實現方式，最後想到了能夠繞開限制的方式，把這個項目實現了。我沒想到的是，項目上線後業務告知當時問錯了，其實別人也沒法實現這個東西，由於只有咱們實現了這個技術，因此不少人都願意來找咱們合做。

不少時候，我會認爲本身有十幾年的技術研發經驗，我對公司既有技術足夠理解，我覺得我能夠對一件事情是否能夠實現很快下結論。其實這是不對的，在收到外部需求的時候，應該反過來思考，先假設這個需求是必須實現的，或者競品已經實現了的，在拒絕別人以前，給本身幾天時間，給團隊幾天時間來想一下怎麼去實現，若是你作到了別人作不到的，那麼你的技術就是核心競爭力。

創建一支能夠打快戰的鐵軍技術團隊

隨着公司技術的標準化和成熟，團隊應該 具備打快戰的能力，可是穩定的業務每每會讓老兵們進入溫水煮青蛙的狀態。做爲技術管理者，應該用各類手段來激勵你們的鬥志（好比搞階段性的重構、黑客馬拉松比賽），保持團隊的活力。這樣，若是有新開闢的項目，能夠在公司內部輕鬆找到並造成一支敢死隊來參與戰鬥，超高的執行力使得新業務能夠儘快進行低成本試錯或搶佔市場，這也是技術產品團隊成熟於否的體現。

根據戰略及時調整團隊架構和技術架構

無論是團隊架構仍是技術架構應該有必定時間的先行，通常而言對於線性發展的項目，公司目前若是處於 A 量級的 PV ，就應該開始儲備十倍 A 量級 PV 的架構。根據業務的發展估算技術架構的挑戰，提早半年或者一年進行新一代架構方案的確立，確保技術不拖業務後腿。團隊架構也是一樣須要先定義骨架，再在每個可能的職位上進行填坑招聘。技術管理者須要對公司的戰略敏感，根據公司的發展和戰略，提早作好這兩個架構調整的準備，並在須要的時候及時應用調整。

提煉核心技術，產品化產品，探索進行產品輸出的可能

若是作的是 2C 的產品，在一個領域作了多年或許就有能力把核心技術或產品提煉出一套 2B 或 SaaS 的產品來賣，若是成功，這就不只僅是一個 2C 的產品，極可能又多出一套 2B 的產品甚至是一套 2C 的平臺。若是作的是 2B 的產品，或許就要思考一下，如今的產品是複製粘貼的定製化產品仍是徹底配置的產品化產品，若是不是，怎麼讓他更通用地進行產品化，減小人力成本。產品化平臺化的過程是一個痛苦的抽象過程，對技術的要求更高，不過一旦實現就可讓公司的用戶和規模獲得爆發式發展，真正的技術改變戰略。

關注前沿技術，思考前沿技術和公司業務的結合

目前正處在技術變革的一個關鍵階段，在將來 5 年內，垂直細分的 AI 將會變得成熟，區塊鏈也可能會出現大量的實際應用，技術管理者應該時刻關注這些技術，不斷思考可能的結合場景。這個世上不缺愛思考的人，但不少懂業務的人不懂技術，懂技術的人又不能理解業務痛點，只要積極關注前沿技術並和業務專家保持討論溝通，說不定哪天就會碰撞出具備革命性的產品。

- End -