CTO要越過的幾道坎兒

本篇文章源自《CTO說》書中本來產品技術本部副總經理錢榮明分享的《技術架構的迭代與錘鍊》的解讀與感悟。最近工作中遇到的事情與這篇文章中的分享幾乎同出一轍，更加有了「感同身受」的共鳴。

書中給這篇文章所寫的標題與內容並不十分貼切，反倒是本篇文章通俗的標題更恰當的提煉了本篇文章的內容。

對於技術人員能夠上升到的最高高度莫過於CTO，當然像李彥巨集那樣的程式設計師就另當別論。技術的錘鍊、知識的提升、管理技能的磨鍊都是CTO躲不過去的必備素養。但大家往往忽略一項比較重要的使命——決策。跨過技術思維禁錮，站在公司發展的全域性層面進行決策（建議），成為公司業務與技術實現的樞紐型角色，也是CTO的重大使命。

重視雙向溝通才能共贏

首先，我們都認可的一件事情是：一個產品的成敗不完全取決於技術。想必經常聽說一個很爛的產品通過運營的手段在市場上廣為人知，同樣一個很牛的產品卻無人問津。CTO往往技術出身，手裏有技術這把用慣了的「錘子」，當一個需求過來，第一反應就是用「錘子」去鍛造它。其實，當從技術轉型到CTO的職位之後，第一個需要面對的決策就是暫時扔掉錘子，判斷產品方向是否對公司的發展有利，是否可以用非技術手段解決，然後纔去分析怎樣用專業的技術手段進行實現。

技術管理者往往會遭遇領導作出某項決策，卻沒有給技術人員留出足夠的準備時間，這是典型的缺乏溝通意識。

我們會經常遇到CEO一個電話就要求某專案一個月上線。或經常聽到這樣的話「這個功能有很難嗎？應該幾天就可以完成吧？為什麼這個這麼慢，兩天時間還搞不定嗎？」。作者（錢榮明，以下均稱作者）認為，不能要求每個老闆都懂技術，只能妥協，通過努力達到目標。其實，如果這樣做了，反而缺少了CTO的決策作用。

作為承上啟下的CTO，首先要搞明白不懂技術的老闆的真實意圖是什麼，按照老闆說的那樣去技術實現是否能夠達到老闆想要的目的。如果此決策對公司發展有重大利好，而且必須在規定時間完成，後面的事情纔是想盡辦法用技術去達成目標。

在這個情景中與CEO的溝通，不僅體現在具體需求的溝通，是否能夠達到預期，還體現在CEO與CTO需求溝通的提前量，防止技術實施的被動，造成專案的急迫感。

是否技術至上

企業技術體系的構建，絕對不要堅持「技術至上」原則。因為技術的構建離不開業務的發展，構建的目的也是爲了更好地實現業務的升值。

作者舉了一個爲了達到CEO的要求趕工期將一個專案拷貝成兩個專案導致的嚴重後果：獨立的伺服器、獨立的系統、獨立的資料監控，無論從財務層面、報告層面還是公司結構層面都暴露了極大的問題，最終還是需要花費大量的時間將兩個系統融合在一起。

個人看來，這個例子並不能很好的說明技術至上的原則性問題，但提出了技術至上這個問題的存在。技術至上的根源是任何問題都想通過技術來解決：當你手裏有一把錘子，任何事物看起來都很像釘子。技術離不開業務，業務不一定非要用技術來解決。

要重視資料庫

資料庫怎麼備份都不嫌多。然而，在創業初期往往因為人員配備、資金或資源、專案進度等原因被忽略掉。一旦出現重大問題，都需要用加倍的損失來彌補。

控制技術的求知慾

技術人員天然對新技術有強大的興趣，在每一個專案中都躍躍欲試的使用一些新的技術。對新技術的選型十分重要，不僅涉及到學習成本、運維成本，還涉及到新技術是否形成相應的生態，比如文件支援、論壇支援、技術更新週期、是否長期有人維護等，不然很可能到最後遇到問題還需要自己研究新技術的原始碼，自己去修改相應的bug，那就得不償失了。

在程式語言方面，有兩個方向的選擇，作者建議儘量統一程式語言，這樣在專案初期階段對資源、運營成本、溝通成本和專案把控度來說都是有利的。同時，針對大的企業，每種語言都有它的優勢和特定的業務場景解決方案，不同語言的思想也有不同的優劣之分，保持多種語言也就保持了人員與思路的多樣性。有很多選擇都是如此，適合的纔是最好的。

千萬不要選擇外包服務

本來生活最初的系統是外包供應商做的，可他們做了一件令我覺得不可思議的事情：爲了把核心程式碼加入系統中，他們把所有的邏輯都寫在了同一層裏面，不管邏輯是否通順，甚至也不管該不該寫在其中，全部一股腦的寫進去，然後把這個包加密了。當我原始碼購買來解密之後，那一瞬間我就想把系統推翻重做！

想必經歷過外包專案的人都有這樣的感受，再好的外包公司都要慎重選擇，一旦選擇外包就要準備好承擔它帶來的風險。前些天也寫了自己的經歷 《背鍋與填坑的一個月》 。在此延伸一下，對於剛入門程式設計行業的朋友來說，慎重選擇就職於外包公司；在招聘的時候對於長期在外包公司工作的應聘者也需要仔細的面試一番，習慣的力量是非常大的。

談談招人這件事

有人問我，創業初期，如何解決招人的難題？ 我的答案是，去北京各大學的論壇泡，看論壇中的學生，有沒有符合要求的人。還可以讓這些人推薦他們身邊的好友，不管是否畢業的、應屆的、沒有畢業的，只要是人才，通通招進來。

看到作者的做法首先是眼前一亮，不失是一個好辦法。但再一想創業初期哪有那麼多時間去各種泡論壇尋找人才。而且在初期階段，專案進度異常緊張，也沒有太多的時間和精力去培養新人。

個人反而覺得，在此階段需要招聘全能型人才，一個頂兩三個普通員工的人才。但這裏又形成一個悖論，創業公司無法用工資或品牌效應來吸引人才，前途和「錢途」都無法保證。聰明的老闆會用人文關懷和對未來的展望（畫大餅）來留住一部分人才，但往往很難奏效，有能力的人很少給老闆畫餅的機會。

這裏感慨一下，如果在創業初期，有那麼一幫人願意跟著你幹，那已經是上天的饋贈。經歷多次的招聘之後你會發現，在創業初期招聘一個合適的人是多麼多麼的難。往往是沒能力的沒辦法用，有能力的不屑與你為伍。

如果老闆是職業經理出身，能夠將員工管理的心服口服還好。反之，CTO的橋樑作用也是創業公司成敗的決定性因素。

必須百分之百確保系統可控

這裏講的是組建運維部門和測試部門的重要性。創業初期，運維的工作往往由技術人員身兼，這樣的結果往往是一團糟糕。很多大型網際網路公司有專門的運維部門還經常出現安全和誤操作的事故，試想一下，如果這些事情由身兼百職或不擅長運維工作的技術人員來擔任，後果會是什麼樣子。每個崗位存在即合理，初期無法保障，後期必須跟上。

系統與人員的冗餘

作為老闆往往希望每一分錢都花在刀刃上，系統資源恰好百分之百利用，人員每天工期排滿恰好加班加點能夠完成。這難道不是最完美的安排嗎？各項資源百分之百利用，不浪費一丁點。創業初期，這往往是不懂技術不懂管理的老闆的通病，後果是要用更多的代價來彌補這百分之百的完美。

如果一個產品的服務百分之百的利用著資源，那麼當一個促銷活動或一個小訪問峰值發生時，系統的資源利用呈現百分之二百的狀況，系統是否也完美的癱瘓了？沒有系統資源的冗餘就沒有應對突發狀況的能力。與系統的癱瘓相比，資源的冗餘是最佳的方案。

再說說人員冗餘的事，在創業初期往往是身兼百職，如果每個員工都把時間計劃排的滿滿的，這樣效果是否最佳？首先不說員工情緒上的反抗（被工期壓的喘不過氣），與身體上的疲憊，單說如果工期是滿的，沒有任何機動的應急力量，這時來一個緊急的時間稍長的任務，是不是所有的計劃都被打亂，如果原定計劃中也有緊急的任務是不是會造成重大損失？另外，如果其中一個員工離職或生病，沒有替補人員，緊急任務將如何處理，這將是多麼恐怖的一件事？

從那以後，我就知道，系統必須要用冗餘，架構的冗餘、裝置的冗餘、技術的冗餘，包括人力上都要稍微的冗餘，而不是所有的技術人員都投入在業務上。我的方法是分配出20%的人力，在技術架構上實現超前部署。

風控，拒絕「羊毛黨」

「薅羊毛」的事件經歷的太多，本人也管理過金融風控相關的專案，深知這一塊的重要性，也是創業初期最容易被忽略掉的地方（因為它不創造價值，價值的守護者身份又不容易被看到）。薅羊毛只是最簡單的風險行為，有的甚至直接導致資金損失、系統安全或生態崩潰等重大問題。

針對羊毛黨，簡單的可以借鑑騰訊和阿里的系統，它分為兩個等級，其中第一個等級就是我們常用的驗證碼，做一些簡單的人工判斷、人工學習，例如通過頁面拖動的時間、停頓、失誤率來判斷出這個註冊的物件是人還是機器。在這一塊，前些時日就遇到被機器刷註冊的情況。

另外，就是通過資料分析建立完整的使用者安全等級：可信、可疑和嚴重。針對不同人的行為做出不同的措施，在每個關鍵節點設定關卡，提高風險抵抗能力。

個人小結

閱讀過很多類似的CTO管理的文章，唯獨這篇讓我產生很多共鳴，只因這篇文章中提到的事項幾乎在我最近的工作經歷中一一驗證。因此花費幾個小時的時間寫了這篇文章的讀後感。雖然經歷十分相似，但對作者提出的一些解決方案和認知並不沒有完全贊同，也發表了個人的觀點和看法。千變萬化，適者生存，纔是這個世界多彩的呈現。踏上CTO的船，後面要學習和提升的東西是無限多的，但從更長的人生層面來說，每天的學習和提升也是必不可少的。