1.與公司目標一致

作為 CTO，要時刻明確公司目標，實現公司目標是首要任務。其次才是與之配套的技術目標。

2.充分理解業務，比業務更熟悉業務

如何讓業務增長，是每個做技術管理的人都要考慮的問題，也是最根本的價值體現。

每個小團隊的業務/技術人員只需瞭解所負責的業務即可，但作為 CTO 要比這些人更瞭解業務，瞭解每個業務的同時還要把所有業務串起來，明白整個公司的業務和規劃是什麼樣。

3.支撐業務，引領業務發展

大家常說，網際網路行業技術要引領業務，但支援業務正常開展是基石。在業務正常開展的基礎上，才能站在未來看現在，才能進一步創新，通過技術驅動/引領業務發展。

在核心目標之下本質的內容，是企業願景及戰略目標、業務目標、技術戰略、產品規劃、行業分析等戰略層次部分和系統架構、系統建設等戰術層次部分。

如出現 CTO 和公司/CEO 的目標不一致情況，只有兩條路，要麼調整到一致；要麼離開。

技術管理者充分理解公司目標之後，就是要確立非常明確的技術目標。

主要列舉以下幾點：

• 整體技術戰略目標。
• 眼下要完成的事&近期要完成的事&中長期要完成的事。
• 技術路線&實現方法。
• 技術架構。
• 建立和帶領團隊。
• 規範、制度、流程。
• 考核方法。

當然，這些內容不是一成不變，而是不斷修正的過程。

能力二：專案管理

提煉是“基本功”，合理分解是“基本規範”，溝通是核心

無論有多少個部門、是瀑布/敏捷開發、還是大小的各種目標，所有都可以拆分成件件小事，每件事都可當一個專案來看待。

如下圖，左側是九大專案管理，右側是四個關鍵環節。

左側圖中所示的這些技術管理者必備的常見基本技能，大家都已經很瞭解，在此不一一展開。

右側是提煉需求、分解需求、溝通、如期上線等四大關鍵環節：

• 提煉需求。面對老闆及業務提出的眾多需求，從中提煉出核心的目標是“基本功”。當然是在充分理解業務下的情況下，才能做出清晰正確的梳理和判斷。
• 分解需求。提煉出核心需求後，要根據輕重緩急合理的拆分需求，分解成多個專案階段是“基本規範”。這裡等同於敏捷開發過程中的合理迭代，但切記要先上線簡單可用版本，之後再縱向切，逐步推進。
• 溝通。溝通是專案管理的核心，管理過程中，溝通對最終結果起到決定性作用。
• 如期上線。專案的最終目標是“如期上線”，否則之前做的所有事都是白用功。“如期上線”不是簡單的上線完成任務就行，質量和成本一個都不能少，尤其是質量不能忽略。更不能為了上線而上線，表面上上線完成了專案，但實際跟原來的目標相差很遠，甚至使用者都沒法使用。

其中，溝通、資源整合和成本控制這三方面無論專案大與小，都貫穿整個管理過程，且對於大多技術管理者來說，多少會遇到一些難題，下面分享一些方式方法。

1.溝通

前面說到，溝通是專案管理的核心，但很多技術管理者並不是很擅長溝通。

面對不同的人，要如何進行溝通呢？方法如下：

• 與職級高的人。提倡跨級溝通，但需採用一些技巧，如傳送郵件同時抄送直屬領導；如和直屬領導打招呼，再去彙報；如非正式，“恰巧偶遇”，不經意提及；如從團隊中找到善於溝通的人去做溝通。
• 與職級相同人。和同級別人溝通，就需要把技術語言翻譯成非技術語言，以便業務、財務等不懂技術的管理者更好的理解。
• 與團隊和下屬。初創/網際網路公司與下屬的溝通相對開放，職級的觀念相對較小。但對於大型傳統的公司來講，下級會對上級不自然產生戒備/恭敬的心態。技術管理者需要做的是先緩解心態，之後像朋友一樣坦誠的去溝通。
• 與合作商。與合作商溝通，要時刻謹記自己代表的是公司，然後是合作共贏，找到利益平衡點，把可能的情況先談清楚了，避免後續一些不必要的麻煩。

2.資源整合

一個專案完成與否，資源會從中起到很大作用。資源在未整合之前大多是零散的，要發揮其最大的效用，轉化為競爭優勢，為企業創造價值，還需要運用科學的方法將不同來源、不同效用的資源進行配置與優化，使有價值的資源融合起來，發揮“1+1>2”的放大效應。

業務、營銷和財務這些屬於企業內部資源，合作商、市場和投資方屬於外部資源，這些大家都很瞭解。這裡需要注意的是直屬領導/領導的領導是很好的內部資源，用好會事半功倍。

3.成本控制

很多人感覺做技術管理和成本沒有關係，成本是採購才會考慮的問題。

實則不然，例如：

• 時間和人力。如一個專案管理不善，因工作效率或其他原因，導致不僅超時完成，還用人過多，這是看不見的最大成本浪費。如一個專案研發三個月，最終沒有上線放棄，這也是一種成本浪費且還可能喪失機遇。
• 招聘牛人。要招聘當前需要的人，一些技術牛人可能未必適合當前階段。初創小公司不需要很牛的人，只需要成熟技術，能支撐業務，保障業務的正常執行就好。當業務達到一定量，才需要招聘牛人，反之就是成本浪費。
• 超前技術。很多時候，時間和人力的浪費，就是因為招聘牛人，研究超前技術所致。所以在每個階段，需考慮技術是否合適。
• 技術方案。不要迷信最好的技術方案，根據實際情況，採用最快方式實現目標。

綜上分享的核心目標和專案管理是做技術管理最基礎的勝任力，下面我們來分享作為CTO必備的看家本領，如下圖：

如圖中所示，一名合格的 CTO 必須具備的四大看家本領分別是架構建設、產品能力、研發能力和基礎建設。

能力三：架構建設

CTO 應該精通大架構，不是僅僅單一的技術架構

提及架構，很多人認為是程式碼的架構，涉及方向也是採用哪種框架，是開源還是自研等。這裡分享的架構是作為一個 CTO 應該精通的大架構，如下圖：

• 業務架構。業務架構是 CTO 應該首要知曉的，就是所處公司的業務組成及發展規劃，清楚具體業務，以及它們之間的關係，是相關，還是獨立等。
• 應用架構。對應業務，決定採用什麼樣系統配套支援，是要採購，還是必須自研，是縱向獨立劃分，還是橫向邏輯劃分。
• 資料架構。一定要了解資料流的現狀，很多技術牛人會忽視資料架構，對於資料如何儲存、如何流轉、安全機制都不是很瞭解，往往資訊保安問題，就是因資料流出現狀況所致。
• 技術架構。這裡就是有些系統架構，如程式碼框架、中介軟體、服務治理等。
• 運維架構。進行運維建設、安全建設等，做好風險控制，針對系統、賬戶、財務做好安全保障。

從業務、應用、資料、到技術、再到運維整個貫穿下來，就是做 CTO 應該有的視點，切記不是僅僅做單一的技術架構，那是架構師或研發主管應該做的事情。

如下圖，是電商行業基本的技術架構：

如圖中所示，使用者層/流量入口、業務單元、應用系統、業務服務、中介軟體、平臺層，這一層層逐級下來是一個很清晰的電商行業比較通用的架構。作為 CTO 要清楚每一層的資料流、執行機制，由哪些人在主導，關鍵負責人是誰。

如下圖，是架構設計原則：

做開發的人對於這個圖都很熟悉，可用性、可擴充套件性和成本這三大原則大家應該都很瞭解，這裡不一一展開。

作為 CTO 要走在前面，在擴充套件、成品和可用三者制約的情況下，架構要如何建設?

建議遵循 DID 原則，按照 20 倍體量去設計，因會遇到如雙十一等流量猛增的情況。之後，開發按照 3 倍的體量去實現，上線按照 1.5 倍的體量去部署。

能力四：產品能力

互動和業務邏輯是基本功，懂技術實現和專案管理是昇華

作為 CTO 首先要很清楚研發的系統/產品，終端使用者是誰？根本訴求是什麼？之後才是使用者體驗、業務和產品的設計及產品創新。一定切記，從使用者、業務、運營的三個角度出發去設計產品。

1.使用者體驗

產品整體要簡約而不簡單，提供給使用者應該是視聽上的體驗，還要強調舒適性。操作方面，要儘量滿足易用/可用性。目標資訊儘可能的醒目而親近，讓使用者能認同、抒發自己的內在情感。

2.業務設計

要充分理解產品背後的業務邏輯，基於市場目標和公司業務需求，梳理業務流程，勾畫業務藍圖，設計業務場景及功能，分析和優化流程。業務、財務、資料、使用者操作等設計要儘可能形成閉環。

3.產品設計

依據業務藍圖和功能設計軟體產品，重要的是如何讓使用者用的“爽”。最後的輸出結果才是 PRD（是結果不是目標）。

4.產品創新

創新方面，要以潛在的需求為出發點，開發出具有差異性或全新的產品，將潛在的需求啟用為一個現實市場，實現產品價值，引領/驅動業務發展。要清楚產品上線僅是開始，還需以資料為檢驗標準，不斷運營和優化。

這裡需要提醒的是，有的產品經理側重於互動，但對業務邏輯不是很清楚。有的產品經理很明白業務邏輯，但互動方面較弱。

一名合格的產品經理，互動和業務邏輯是兩大基本功，在此之上，還要知道產品如何技術實現、也具備一些基本的專案管理能力。

走的相對較遠較順的產品經理，一定是對上要懂 CEO，對外要懂市場、懂使用者，對中間要懂業務，在實現方面還懂一些開發的邏輯。

能力五：研發能力

不是某位技術牛人，而是團隊整體多方面的調整與標準制定

談起研發能力，很多人會想我就是一個技術牛人，可以一人頂幾人。但是當專案很多的時候，又能頂幾個呢？

所以，從技術牛人晉級 CTO，還需要在關鍵技術、交付效率、程式碼規範和開發模式等方面做很多調整和標準：

• 關鍵技術。作為開發領導最好能親自制定程式碼框架，確定使用哪種技術框架或者方案。要始終保持學習最新的技術及資訊，至少在理念上與行業同步。還要不間斷的研究技術。
• 程式碼管理。制定合適的程式碼管理規則，制定合適的分支模式，並建立程式碼管理規範。
• 規範標準。需要在專案早期建立一系列的編碼規範、介面規範、中介軟體使用規範、加密規範、密碼規範、字符集規範等等。
• 開發模式。用敏捷還是瀑布要依照實際情況而定，對於輕量級的需求，或研發人員較少的情況下，可採用敏捷開發模式。當業務很重，就選擇瀑布模式，把專案規劃清楚，做好細節拆分，可規避需求不匹配的情況。
• 開發質量。要實現程式碼 Review 機制、單元測試機制、持續整合、自動構建和自動釋出。

能力六：基礎管理能力

從傳統響應服務向自動化、可持續整合提升

基礎管理能力，更多是體現在運維方面，伺服器宕機，網路不通，如何配置/部署/監控等都屬於運維範疇。

早期運維是 ITSM（IT 服務管理），側重流程，是一套幫助企業對 IT 系統的規劃、研發、實施和運營進行有效管理的方法。

佈設總服務檯來監控，出現故障後服務檯負責通知相關開發人員，響應機制和績效掛鉤。ITSM 整體過程很流暢很嚴格，但它的缺點是事後的管理。

現在提倡 ITOM（IT 開發運維、運營管理），側重 IT 運營管理，從開發設計開始就考慮上線後如何運維，如何設計程式碼架構、部署架構，如何發現問題，發現問題後如何自動故障轉移和修復，包括申請資源、建設配套的 CMDB-DCMS 等。

ITOM 更側重於一個 IT 運營或者運維的管理思想，目標是持續交付和自動化運維。

整個運維的流程大致由四步構成分別是：

• 服務監控。硬體、軟體、流量、資料、故障的自動化監控。做好問題和故障反饋機制及故障響應機制、處理機制。此外，還需設計故障預案，實現預案的自動化執行。
• 配置管理。包括叢集、部署、變更等管理。
• 硬體管理。網路及伺服器架構，VM、資源分配機制。
• 運維機制。自動化部署、自動化運維是基本目標。還需建設日誌平臺，報警機制及相應處理機制。

如下圖，是我們的基礎架構（GCP）：

能力七：團隊能力

擁有團隊能力的基礎上，還應瞭解學習一些領導藝術

團隊能力部分，主要總結六點，如下圖：

作為 CTO/技術管理者具備團隊能力的同時，還應該瞭解一些領導藝術。這個時代的比拼不僅是兵對兵，更是將對將的較量。

只有領導的能量不斷放大，團隊的競爭力才能整體提升。也可以說，領導之道是現代化競爭中的核心要求。

領導藝術主要體現在三方面分別是：

• 多個部門的協作。合理選擇，知人善任；揚長避短、寬容待人；合理使用，積極培養；用人要正激勵人才。
• 工作效率的提升。統籌兼顧、把握關鍵、指令明確；決斷及時；想象力、洞察力、應變力、善於調動他人的積極性。
• 快樂的工作。平等待人，尊重別人，注意方法；簡化語言，積極傾聽，控制情緒；把握主動；創造互信環境。

啥樣的人能晉升 CTO

最後，啥樣的人能晉升 CTO？個人認為，晉升 CTO 主要看三方面：懂技術、懂管理和修煉。

懂技術

明確公司目標，充分理解業務，技術目標與之配套