【原創】公司各個階段 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 進行密切溝通,使本身的決策獲得上級的支持。通常而言,我還會接手對公司外部的溝通工做,讓團隊成員能夠更專一於項目。

 

本文首發於TGO微信公衆號,歡迎掃描頁面左上二維碼向我提問。

相關文章
相關標籤/搜索