千人技術團隊背後的CTO：CTO的修煉遠不止於技術修煉（轉）

原文地址：http://mp.weixin.qq.com/s/Lb-y-H1g8DLZqnXs6zqfuQ

當絕大部分的技術人還在思考創業團隊 CTO 須要有什麼勝任力的時候，有人已經把技術團隊從 7 年前的不足 10 人帶到了千人規模的技術團隊。

 

聊起這 7 年的經歷和故事，遠比在紙上討論「CTO 是否要寫代碼」要精彩得多。現實中的 CTO 面臨的挑戰也不止於技術挑戰，還有業務挑戰、團隊挑戰、視野挑戰等等。

 

9 月 9 日，51CTO 旗下 CTO 訓練營第五季的開營課上，國美互聯網 CTO 于斌平爲現場的 40 位技術管理者分享了他在國美 7 年的 CTO 經歷以及對 CTO 七大基礎能力的理解，從這些經歷裏面咱們也能夠窺見一些領悟。

CTO 七大基礎能力

能力一：核心目標管理

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

01

與公司目標一致

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

02

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

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

 

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

03

支撐業務，引領業務發展

你們常說，互聯網行業技術要引領業務，但支持業務正常開展是基石。在業務正常開展的基礎上，才能站在將來看如今，才能進一步創新，經過技術驅動/引領業務發展。

 

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

 

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

 

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

 

主要列舉如下幾點：

• 總體技術戰略目標。

• 眼下要完成的事&近期要完成的事&中長期要完成的事。

• 技術路線&實現方法。

• 技術架構。

• 創建和帶領團隊。

• 規範、制度、流程。

• 考覈方法。

 

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

能力二：項目管理

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

不管有多少個部門、是瀑布/敏捷開發、仍是大小的各類目標，全部均可以拆分紅件件小事，每件事均可當一個項目來看待。

 

以下圖，左側是九大項目管理，右側是四個關鍵環節。

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

 

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

• 提煉需求。面對老闆及業務提出的衆多需求，從中提煉出核心的目標是「基本功」。固然是在充分理解業務下的狀況下，才能作出清晰正確的梳理和判斷。

• 分解需求。提煉出核心需求後，要根據輕重緩急合理的拆分需求，分解成多個項目階段是「基本規範」。這裏等同於敏捷開發過程當中的合理迭代，但切記要先上線簡單可用版本，以後再縱向切，逐步推動。

• 溝通。溝通是項目管理的核心，管理過程當中，溝通對最終結果起到決定性做用。

• 如期上線。項目的最終目標是「如期上線」，不然以前作的全部事都是白用功。「如期上線」不是簡單的上線完成任務就行，質量和成本一個都不能少，尤爲是質量不能忽略。

  更不能爲了上線而上線，表面上上線完成了項目，但實際跟原來的目標相差很遠，甚至用戶都無法使用。

 

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

01

溝通

前面說到，溝通是項目管理的核心，但不少技術管理者並非很擅長溝通。

 

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

• 與職級高的人。提倡跨級溝通，但需採用一些技巧，如發送郵件同時抄送直屬領導；如和直屬領導打招呼，再去彙報；如非正式，「恰巧偶遇」，不經意說起；如從團隊中找到善於溝通的人去作溝通。

• 與職級相同人。和同級別人溝通，就須要把技術語言翻譯成非技術語言，以便業務、財務等不懂技術的管理者更好的理解。

• 與團隊和下屬。初創/互聯網公司與下屬的溝通相對開放，職級的觀念相對較小。但對於大型傳統的公司來說，下級會對上級不天然產生戒備/恭敬的心態。技術管理者須要作的是先緩解心態，以後像朋友同樣坦誠的去溝通。

• 與合做商。與合做商溝通，要時刻謹記本身表明的是公司，而後是合做雙贏，找到利益平衡點，把可能的狀況先談清楚了，避免後續一些沒必要要的麻煩。

02

資源整合

一個項目完成與否，資源會從中起到很大做用。資源在未整合以前大可能是零散的，要發揮其最大的效用，轉化爲競爭優點，爲企業創造價值，還須要運用科學的方法將不一樣來源、不一樣效用的資源進行配置與優化，使有價值的資源融合起來，發揮「1+1>2」的放大效應。

 

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

03

成本控制

不少人感受作技術管理和成本沒有關係，成本是採購纔會考慮的問題。

 

實則否則，例如：

• 時間和人力。如一個項目管理不善，因工做效率或其餘緣由，致使不只超時完成，還用人過多，這是看不見的最大成本浪費。如一個項目研發三個月，最終沒有上線放棄，這也是一種成本浪費且還可能喪失機遇。

• 招聘牛人。要招聘當前須要的人，一些技術牛人可能未必適合當前階段。初創小公司不須要很牛的人，只須要成熟技術，能支撐業務，保障業務的正常運行就好。當業務達到必定量，才須要招聘牛人，反之就是成本浪費。

• 超前技術。不少時候，時間和人力的浪費，就是由於招聘牛人，研究超前技術所致。因此在每一個階段，需考慮技術是否合適。

• 技術方案。不要迷信最好的技術方案，根據實際狀況，採用最快方式實現目標。

 

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

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

能力三：架構建設

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

 

 

說起架構，不少人認爲是代碼的架構，涉及方向也是採用哪一種框架，是開源仍是自研等。這裏分享的架構是做爲一個 CTO 應該精通的大架構，以下圖：

• 業務架構。業務架構是 CTO 應該首要知曉的，就是所處公司的業務組成及發展規劃，清楚具體業務，以及它們之間的關係，是相關，仍是獨立等。

• 應用架構。對應業務，決定採用什麼樣系統配套支持，是要採購，仍是必須自研，是縱向獨立劃分，仍是橫向邏輯劃分。

• 數據架構。必定要了解數據流的現狀，不少技術牛人會忽視數據架構，對於數據如何存儲、如何流轉、安全機制都不是很瞭解，每每信息安全問題，就是因數據流出現情況所致。

• 技術架構。這裏就是有些系統架構，如代碼框架、中間件、服務治理等。

• 運維架構。進行運維建設、安全建設等，作好風險控制，針對系統、帳戶、財務作好安全保障。

 

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

 

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

如圖中所示，用戶層/流量入口、業務單元、應用系統、業務服務、中間件、平臺層，這一層層逐級下來是一個很清晰的電商行業比較通用的架構。做爲 CTO 要清楚每一層的數據流、運行機制，由哪些人在主導，關鍵負責人是誰。

 

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

作開發的人對於這個圖都很熟悉，可用性、可擴展性和成本這三大原則你們應該都很瞭解，這裏不一一展開。

 

做爲 CTO 要走在前面，在擴展、成品和可用三者制約的狀況下，架構要如何建設?

 

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

能力四：產品能力

交互和業務邏輯是基本功，懂技術實現和項目管理是昇華

做爲 CTO 首先要很清楚研發的系統/產品，最終用戶是誰？根本訴求是什麼？以後纔是用戶體驗、業務和產品的設計及產品創新。必定切記，從用戶、業務、運營的三個角度出發去設計產品。

01

用戶體驗

產品總體要簡約而不簡單，提供給用戶應該是視聽上的體驗，還要強調溫馨性。操做方面，要儘可能知足易用/可用性。目標信息儘量的醒目而親近，讓用戶能認同、抒發本身的內在情感。

02

業務設計

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

03

產品設計

依據業務藍圖和功能設計軟件產品，重要的是如何讓用戶用的「爽」。最後的輸出結果纔是 PRD（是結果不是目標）。

04

產品創新

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

 

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

 

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

 

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

能力五：研發能力

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

談起研發能力，不少人會想我就是一個技術牛人，能夠一人頂幾人。可是當項目不少的時候，又能頂幾個呢？

 

因此，從技術牛人晉級 CTO，還須要在關鍵技術、交付效率、代碼規範和開發模式等方面作不少調整和標準：

• 關鍵技術。做爲開發領導最好能親自制定代碼框架，肯定使用哪一種技術框架或者方案。要始終保持學習最新的技術及資訊，至少在理念上與行業同步。還要不間斷的研究技術。

• 代碼管理。制定合適的代碼管理規則，制定合適的分支模式，並創建代碼管理規範。

• 規範標準。須要在項目早期創建一系列的編碼規範、接口規範、中間件使用規範、加密規範、密碼規範、字符集規範等等。

• 開發模式。用敏捷仍是瀑布要依照實際狀況而定，對於輕量級的需求，或研發人員較少的狀況下，可採用敏捷開發模式。當業務很重，就選擇瀑布模式，把項目規劃清楚，作好細節拆分，可規避需求不匹配的狀況。

• 開發質量。要實現代碼 Review 機制、單元測試機制、持續集成、自動構建和自動發佈。

能力六：基礎管理能力

從傳統響應服務向自動化、可持續集成提高

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

 

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

 

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

 

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

 

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

 

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

• 服務監控。硬件、軟件、流量、數據、故障的自動化監控。作好問題和故障反饋機制及故障響應機制、處理機制。此外，還需設計故障預案，實現預案的自動化執行。

• 配置管理。包括集羣、部署、變動等管理。

• 硬件管理。網絡及服務器架構，VM、資源分配機制。

• 運維機制。自動化部署、自動化運維是基本目標。還需建設日誌平臺，報警機制及相應處理機制。

 

以下圖，是咱們的基礎架構（GCP）：

 

能力七：團隊能力

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

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

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

 

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

 

領導藝術主要體如今三方面分別是：

• 多個部門的協做。合理選擇，知人善任；揚長避短、寬容待人；合理使用，積極培養；用人要正激勵人才。

• 工做效率的提高。統籌兼顧、把握關鍵、指令明確；決斷及時；想象力、洞察力、應變力、善於調動他人的積極性。

• 快樂的工做。平等待人，尊重別人，注意方法；簡化語言，積極傾聽，控制情緒；把握主動；創造互信環境。

啥樣的人能晉升 CTO

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

懂技術

CTO/技術管理者自始至終都要懂技術，不斷地研究學習新技術，纔可以帶領技術人員往前衝，對團隊給出有高度的建議和合理的技術架構、技術方向的判斷。

懂管理

技術再牛，不懂管理，不知道核心目標，不能理解業務，不知道怎麼管理人，也不是優秀的 CTO/技術管理者。

修煉

技術和管理是基石，修煉是一個長期的過程，我的的視野和能力修養經過不斷歷練才能昇華。

 

站在山下跟站在山腰看到的風景不同，站在山頂看到的風景和感受又不同，從山腳到山頂的路途確定不平坦，付出的不只是汗水和努力，不經歷風雨，如何見彩虹。

 

這全部的過程，都是歷練，也是修煉。「橫當作嶺側成峯，遠近高低各不一樣」，「五嶽歸來不看山，黃山歸來不看嶽」，這形象的反映出了一我的的境界。

總之，不會打仗的士兵，作不了將軍；只會打仗的士兵，也作不了將軍；CTO/技術管理者晉級之路就是不斷學習，歷練、昇華的過程。祝各位成功！

 

做者：王雪燕

編輯：陶家龍、孫淑娟

本文選自CTO訓練營