這裡要和大家分享的是：CTO的領導力和管理能力。

這也是我回到中國之後發現的，不僅僅互聯網而是很多企業都存在的共性問題：大家不區分領導力和管理能力。

事實上，領導能力是指如何帶動一個企業不斷地向前走，靠的是領導者個人的魅力，領導者對理念目標和使命的引導，去激勵大家。而管理能力是指把一個大的目標分解成小的目標，小的目標進一步分解，讓員工高效率地實現。

領導能力和管理能力的主要區別在於力量的方向。領導力是像火車頭一樣牽引團隊的動力。管理力是在團隊後面推動的力量，讓團隊向前走。

兩者所需要的技能是不一樣的。領導力需要以身作則，有自知之明，或很謙虛，使命為先。更多的是一種天賦，領導精神和犧牲精神。

而管理的能力呢，更多的是關注細節分解任務，要善於溝通，善解人意，能夠有很強的執行力。這是兩者的不同點。

另外還要注意企業及企業文化。用一個花園來比喻企業，花園裡的土壤就像企業的文化。我們談起企業文化，總認為只有中國才講究的話，其實到了美國更加講究企業文化。良好的企業文化，就像花園土壤的土質很好，可以長出很多好的花花草草。那這些花草就是企業的員工。當然有很漂亮的花也會有奇葩。奇葩或者不合適的草，即不合適的員工。而管理者就是企業這座花園裡的園丁。園丁的責任：施肥除草，淘汰不合適的花草，進行選材。

我從矽谷剛回來的時候，很多人問我：能不能幫忙介紹一個矽谷的大牛，我們公司上市就差這麼一位大牛了，或者是有了這位大牛，公司才能如何如何……

我們認為人員是組織過程中的首要元素，但人員沒有最佳，只有最合適。

我經常用 Steve Jobs 的例子來說明這個問題：Steve Jobs 在三十歲的時候呢，是一個很自負，孩子氣的一個人，不負責任，缺乏團隊精神，很多項目朝令夕改。結果，員工和企業不歡迎他，被迫離開了蘋果。而當他四十一歲重返蘋果的時候，他變得很負責，很自律，不僅保持了自己的創新精神，還加強了產品的經驗。

那麼同樣一個 Steve Jobs，為什麼在十年前被企業掃地出門，十年後成為天才，帶領蘋果騰飛，使蘋果有了今天的成就？

原因就在於十年前他不是一個合適的人，並不是說他不是一個牛人，不能打造最佳的產品。但是十年後，經過歷練，他變得更適合團隊，也更適合環境，所以才會有他和蘋果當年的成功。

關於CTO的人才觀，要和大家分享的是，如何像園丁一樣對花園裡的花花草草進行區別考評，優勝劣汰——B 指 behavior，指員工是否符合企業文化，P 指 Performance，指員工是否具有能力創造業績。

那麼公司管理者最喜歡的是既符合企業文化又有能力的人，即處於第一象限，要保留的精英。相反，如果是對企業文化不認同，技術的能力又差的員工，就是需要淘汰的人。

而第二象限代表的員工，是管理者需要培養的員工。這類員工有專業的能力，是不同領域內的專才，但是企業文化方面比較差，這樣的員工可以通過培養讓他成為精英。

關於人員，還有一件事要和大家分享：如何使我們的人員能夠在一個企業裏留得住，發展好。我從美國回到易寶支付之後有一點感觸非常深刻，就是這麼多人，卻連一個架構師都沒有。

一個總監領著大家做，可能會有一些初級研發啊、中級研發、高級研發，但是沒有架構師，大家做的事都是一樣的。

最後我們做了一些改變，實行技術職級管理。我們有研發架構、測試架構、網路架構、安全架構、配置架構、系統架構和數據架構。

那這些架構師是怎麼培養呢？首先，工作經驗很關鍵，因為架構師需要一定的經驗積累。我們認為七年以上的工作經驗足以勝任一個架構師，從而給員工成長的空間。

組織

我觀察到的，矽谷的企業和國內的企業之間的一個差別：即在業務和技術之間溝通上的問題。特別是主管一級人員溝通的問題。

比如說業務主管會強調要完成什麼業績；而技術主管在討論的時候經常強調有什麼問題，什麼技術細節，什麼 Bug，什麼無法解決的問題，這兩者很難溝通到一起。

而這部分，需要CTO承擔起來彌補兩者鴻溝的職責。

原因是很清楚的：因為業務主管和技術主管在教育背景、經驗背景和性格特質上差別很大。一個內向，一個外向；一個是學理工的，一個是學經濟和管理的。特別是他們成長的路徑，業務主管往往是業績做得好，技術主管往往是項目做得好研發做得好。

組織內的衝突，是我們探討人員的時候必須要強調的。

組織內的衝突：一種是認知型衝突，一種是感情型衝突。當我們在做一個項目的時候經常有疑問：誰來幹這件事？這就是一種感情型衝突。

人作為一種高級動物，我們都會有保護自己的本能，而這樣的情況往往在我們做項目的過程中是存在一定破壞性的。

作為一個CTO，應該及時發現這種衝突，制止這種衝突。我們在項目進行的過程中需要衝突，但不是感情型衝突，而是認知型衝突。

那什麼是認知型衝突？認知型衝突是指在決定要做某個項目，對執行方案有不同意見時，我們要從中選出一種最佳方案。

所以當一個團隊在討論什麼是最優方案的時候，最好的組織方式是討論時，參與人員有年齡差異，也有崗位和職能差異，能從各個不同的角度對方案提供不同的意見。

我們再從中選取一個最佳的方案，這是保證項目或研發走向成功的基礎。只有當選擇的方案和策略是對的時，結果纔有可能是正確的。

還有一件讓我印象深刻的事：在我們的互聯網企業，特別是國有企業或者是大型的傳統型企業中，常常分成兩種思維模式：

• IT 思維模式。
• 產品思維模式。

所謂 IT 模式，指的是 IT 部門往往服務的是企業內部客戶。比如說公司的 IT 部門，其提供的服務可能是 CRM 系統或某種業務系統。

那麼在工作過程中，這個部門主要考慮的是成本，因為 IT 部門的成本是直接計入公司成本，需要盡量節省成本。

還有一個要考慮的因素，是公司內部的客戶的滿意度。在這種情況下，產品做出來後，如果內部客戶反饋不好，常常是採取企業內培訓的方式，培訓到用戶會用為止，可能產品很差，但是培訓跟得上，這就是 IT 思維。

而產品思維，特別是互聯網產品思維呢，他不知道他的用戶是誰，在哪裡，或僅知道用戶某種類型，但不具體。

那麼這個時候就會採取試錯的辦法，做出一個產品後投放到市場上，根據市場反饋，作相應的修改。而關於成本，產品人員更多考慮的是產品能賺回多少錢，而不是花掉多少。

我們再來探討組織，人員都是要靠組織組成起來的，那什麼樣的組織最合理？

我們簡單計算一下：八寸的這種披薩大概兩張能餵飽八個人左右。所以團隊的規模不能太大，過大的團隊會造成噪音的存在。規模最好是七到八個人，其中有主管、架構、項目管理、研發和測試。

說完了組織規模，還要考慮組織的結構。大家都知道我們現代社會的工業或企業的組織結構是按照軍隊的線性結構設計的：騎兵在一起，步兵在一起，通訊兵在一起，炮兵在一起。各兵種之間有縱向的領導和橫向的合作關係。

隨著工業發展，當我們提供軟體服務，這就需要研發人員、測試人員、運維人員、項目管理人員和產品人員，大家天天在一起去討論問題、解決問題。當項目結束，軟體研發成功後，團隊解散。這就是矩陣型結構，非常適合軟體行開發企業。

第三種情況，是指將所有項目人員放在一個團隊裏，即敏捷型組織。這種敏捷型組織呢，所有的人在一個團隊，溝通更順暢，更容易形成合力解決問題。

這種方式最適合 SAS 服務，即對外提供的是軟體為基礎的服務。我們可以根據自己企業所處的不同階段，所提供的不同產品和服務，選擇合適的組織機構。

過程

除了人員和把人員合理地組織起來工作以外，還有一個重要的事情是過程。過程是指將所有人組織起來的活動中，大家按什麼邏輯和方向來走。

很多公司，包括易寶支付，我都發現這樣的問題：一個公司，特別是運維繫統發生一些問題，CTO會怎麼辦？大家往往會追究是誰的責任，然後處理責任人，如扣獎金、記過處分、甚至開除。往往把處理人作為主要的目標和主要的手段。

這裡有張伯克利一位教授的圖，借用他的圖，我們來說明上面這個問題：一個系統由軟體硬體測試、腳本、網路等很多要素構成，圖中每個紅點代表的是軟體中的 fault 或 Bug。

平常的它們相安無事，當外界用戶的輸入進入，如某種輸入情況、某種流量或某種 profile，可能會引發這些 fault 或 Bug 出現問題。

如果你的系統有合理的監控，能觀察到這些蛛絲馬跡，系統就可以避免出現大的問題。相反如果觀察不到，系統就會失去目標從而出現大的問題。

所以，當我們在考慮過程中所出現的問題時，我們應該聚焦在系統，也就是軟體硬體網路當中的 fault 上。一定要在每件事情發生之後聚焦為什麼會發生這種問題，其根源在哪裡，而不是聚焦在人上。

當我們把這些紅點，fault 都解決掉，那麼系統就不會在同一個地方栽兩次跟頭。這就是我們強調的，要聚焦優化過程和優化架構，而不是聚焦人。

架構設計理念

當我們在做架構設計時往往考慮的是：前端用 Java 語言、Tomcat，然後通過 MySQL 放在某某伺服器上、某某存儲上，然後由某某路由器來負責完成。

如果不知道的人看到這種設計一定會說架構師是收了人家錢在打廣告吧。實際上，真正的架構設計是不應該考慮任何產品的，而是為了滿足用戶的需求，選取最合適的手段和方式來完成。

架構設計要回歸事情的本源，這裡講一個故事：當年美國和蘇聯太空競賽，雙方遇到在太空無重力狀態下無法寫字的問題。美國的做法是花巨資研發一種新的太空筆，當這種筆研發出來後，他們發現競爭對手蘇聯卻一直在用鉛筆寫字。

這裡是想告訴大家，我們在設計系統時，必須要從事情本源出發，而不能只考慮用什麼系統、什麼技術，因此歸納出這個概念：非技術設計。所謂非技術設計是指在設計互聯網或信息系統架構的時候，要像建築師一樣去考慮問題：設計一座房子時，我們要考慮房子的結構，承重強度等。

在設計的時候從非技術角度考慮，不要一開始就給出技術解決方案，或許要解決的問題因為某個業務上的改動或者某個流程上的變化，就不需要幾個月的開發工作了。

這裡有兩個過度設計的例子：設計一個空調。如果設計一種空調在絕對零度到零上三百度都可以用，你也許能夠實現，但需要耗費大量資源，卻完成了一件沒有必要的事情，就如同美國太空筆一樣。絕大多數人不需要在這樣極端的環境中使用空調。

過度設計不僅指超出實際需求的設計，還包括過度複雜的設計。比如你要求你的助理把附近某便利店中的所有商品一種買一樣，卻只用其中一樣，然後把剩下的商品都送回去。

這樣的做法聽上去很愚昧，但實際上，我們在架構設計和系統實施過程中經常會發生類似問題：我們在調取一個數據的過程中，經常會把資料庫中的所有數據都搬出來，卻只找其中的一個記錄。

這兩個例子啟發我們：在架構設計的過程中，不要過早考慮技術因素，而是脫離技術，回歸到事情本源去解決問題。

---

CTO訓練營是專業性的中高端技術人才培養平臺 ，提供一個技術管理者的交友圈子和一系列技術管理者的知識分享。 致力於打造技術管理者的MBA！

CTO訓練營_技術管理者的MBA_51CTO技術成就夢想?

x.51cto.com

更多活動可以關注公眾號：CTO訓練營

推薦閱讀：