過去四年，David Mack 一直在 SketchDeck 擔(dān)任 CTO ，如今，他即將離職并交棒給他的團(tuán)隊。在離開之際，他反思了作為 CTO 這四年來的經(jīng)驗教訓(xùn)，以及如果再來一次，他應(yīng)該在剛開始擔(dān)任 CTO 的時候注意的事情。包括最初的決策、技術(shù)選擇和人才招聘等方面的思考，希望給新晉 CTO 一些啟發(fā)。
反思過去的經(jīng)驗教訓(xùn)是一段充滿激情的美妙經(jīng)歷，與傳統(tǒng)工作相比，創(chuàng)業(yè)是一個相反的過程：最開始你并不知道公司能否啟動，也不確定這能否變成一個全職的工作；隨著公司的發(fā)展壯大，你開始面對各種蜂擁而至的問題，而且大多數(shù)問題你之前都沒有碰到過。在這段時間里你會以飛快的速度積累并掌握各種知識和經(jīng)驗。
創(chuàng)業(yè)公司雖然靈活，但你最開始作出的決策將會在以后的時間里產(chǎn)生影響。一開始對基礎(chǔ)設(shè)施、框架以及編程語言的選擇，會影響相當(dāng)長的一段時間。隨著業(yè)務(wù)的發(fā)展，需要增加的功能和子系統(tǒng)越來越多，其中的每一項都會在未來影響后續(xù)的選擇，而當(dāng)公司進(jìn)入快速發(fā)展期的時候，你會發(fā)現(xiàn)根本沒有辦法停下來考慮重構(gòu)。
我對于我們最開始的選擇還是比較滿意的：Amazon Web Services 、Elastic Beanstalk 、Firebase 、AngularJS 、Coffeescript 、Kafka 、Simple Queue System 、SocketStream 、Docker 、SemaphoreCI 、MySQL 。其中，只有 AngularJS 和 MySQL 兩個在后續(xù)的擴(kuò)展上帶來問題。我們的 AngularJS 代碼是寫在一個文件上的，該文件后來變得很大，導(dǎo)致初次下載的時候需要耗費一段時間，而且在系統(tǒng)運行時也感覺很慢。MySQL（ 用的是 RDS ）由于 BI 查詢的復(fù)雜度增加而崩潰了好幾次，并且不好修復(fù)。
一項技術(shù)的生命周期出乎意料地短。我們用到的 CoffeeScript 和 AngularJS 就是現(xiàn)在已顯得過時了的組件（我們打算遷移到 TypeScript 和最新版的 AngularJS ），但它們在我們選用的當(dāng)時都是比較前沿的。另外比較幸運的是，我對新技術(shù)的鐘情并沒有造成什么嚴(yán)重的問題。我很慶幸選擇了 CoffeeScript ，在過去這幾年里，它那簡明的語法幫助我大大地提升了開發(fā)效率。
經(jīng)歷了上述這些事情后，我意識到，需要提前對技術(shù)的更新?lián)Q代做好時間安排和策略準(zhǔn)備。對于每一項技術(shù)的選定，你都有要有承受長期的“技術(shù)債”的心理準(zhǔn)備。
同樣地，你寫的組件和庫也會被長時間地使用。不管寫得好壞，你都幾乎不會再去動它。因此你最好在開始的時候多花一些時間進(jìn)行設(shè)計和構(gòu)建，以方便日后的維護(hù)。
我對那些暫停開發(fā)新功能并重寫整個系統(tǒng)的“重構(gòu)”做法一向是反感的。這曾讓很多項目陷入死亡的漩渦?！巴榆娷娨?guī)”里面有一條說得很好：
試著讓這個世界比你認(rèn)識它的時候好一點 —— Robert Baden Powell ，童子軍與女童軍的創(chuàng)始人。
于是我們嘗試在代碼中進(jìn)行一些小改進(jìn)。有時候想通盤考慮整個代碼庫的狀態(tài)（往往都是不完美的狀態(tài)）會讓人感到頭大，所以我會專注于持續(xù)、小幅的改進(jìn)。
最后，關(guān)于測試的一些提醒：讓我們的團(tuán)隊編寫測試代碼真的是難于登天。我給我們系統(tǒng)中的很多部分都編寫了測試用例，并配置好了測試服務(wù)器，在每次有代碼提交的時候會自動運行。盡管如此，我還是很少看到其他人添加新的測試用例。我本希望團(tuán)隊能自發(fā)地重視測試，但是，并沒有。對此，我的一些解決思路是：
組織定期的講座重溫如何編寫測試用例；
要求重要的功能必須包含至少一個測試用例；
優(yōu)化測試服務(wù)器，讓自動化測試在 10 秒內(nèi)完成，而不是 10 分鐘，讓程序員及時看到測試結(jié)果。
除了技術(shù)決策以外，CTO 的另外一大責(zé)任是人員管理。CTO 每天的大部分時間會花在管理與領(lǐng)導(dǎo)、招人與解雇等事務(wù)之中。我不得不一邊學(xué)習(xí)如何管理一邊推進(jìn)工作，所以不可避免會犯一些錯誤。
不管我閱讀過多少次“員工是公司最重要的資產(chǎn)”，我都沒有準(zhǔn)備好應(yīng)對招聘這么讓人筋疲力盡的事情。如果你剛開始著手招聘，那我要提醒你：你可能要在上面花很長的時間，也可能要拒絕掉很多人，才能找到讓你滿意的那位。在此之前我從來沒有想到，優(yōu)秀的創(chuàng)業(yè)團(tuán)隊成員竟然如此稀少，我竟需要花如此之多的精力才能找到他們。
選擇招聘的時機(jī)也是另外一個棘手問題：這個職位是現(xiàn)在就要招，還是晚點？哪個職位要先招？這些問題在你得到投資之后會尤其突出，因為你會覺得應(yīng)該要把這些錢派上用場。幸好，Michael Siebel 和 YC 給我們提供了一些很有用的建議：
當(dāng)你感覺某個職位需求非常迫切的時候才開始招聘（比如快趕不上合同進(jìn)度了的時候）；
招人是為了滿足業(yè)務(wù)發(fā)展的需要，不能本末倒置（這條主要適用于還沒有形成規(guī)?；?、可持續(xù)的業(yè)務(wù)流程的早期公司）；
不要招人來做一些你都還沒想明白的事情（一些特殊的候選人也許能給公司帶來新的動力，但通常最靠譜的辦法還是靠創(chuàng)始人調(diào)整公司資源以適應(yīng)新的發(fā)展）。
綜上所述，如果你不確定某個崗位是否需要招聘，那可能就是太早了。我們犯過的錯誤就是：過早地招人來做一些我們自己并不擅長的增長方案，結(jié)果基本上是以失敗告終。
員工管理基本上一路走來都比較順利 —— 定期開展開誠布公的檢查，明確什么是該做的，什么是不該做的，這些措施讓我和我的員工保持著良好的關(guān)系。
解雇員工則比較艱難。你可以在別處找到很多有用的建議，我這里只簡單說一點：你的直覺通常很早就告訴你應(yīng)該解雇某個人，但你往往要經(jīng)過很長時間才能接受這個事實并著手實施，而且實施過程通常很困難。擁有良好的檢查制度可以幫助雇傭雙方做好最壞結(jié)果的準(zhǔn)備。另外，如果安排合適的個人發(fā)展計劃，有些人的水平能得到提升甚至達(dá)到優(yōu)秀，每個人都應(yīng)該有這樣的機(jī)會。
伴隨公司發(fā)展的一大樂趣就是看到一些優(yōu)秀的人才在各自的領(lǐng)域冒出頭來，成為新的領(lǐng)導(dǎo)者。在此，我要向我的整個團(tuán)隊致以誠摯的敬意和祝賀。
查看原文：https://medium.com/sketchdeck-developer-blog/what-i-wish-i-knew-when-i-became-cto-fdc934b790e3
