當一位新創公司的技術總監（CTO）或技術創辦人不是一件簡單的事情，而且很多新創公司的技術創辦人犯的錯誤都是可以避免的。
1.搞不清楚工程專業和職務分配
雖然工程師都要寫程式，但事實上每一位工程師的專業和適合的職務都不一樣。舉例說明，資料科學工程師（Data Scientist, Data science engineer）、系統工程師（Systems Engineer）、DevOps工程師、前端介面工程師與解決方案工程師等，所需技能和適合職務都不同，而這些專業都需要時間培養，沒辦法馬上互轉。
可惜的是，通常一家公司的CTO的背景都是上面其中一種，因此都有偏見，這也是新創公司在科技管理上很大的盲點。
打個比方，一位資料科學（尤其是學術界）出身的CTO，其經驗多專注於資料採集、資料篩選和訓練機器學習模型，很少需要設計一可應付高流量、高附載與無間斷性的軟體架構。因為自己不懂、認為不重要，因此請的人也常常不懂且認為不重要，這種CTO可能會做出叫機器學習博士去設計伺服器資源配置的蠢事。
最簡單的解決方法，就是多了解不同工程專業在工程組織內的重要性，而不是從自己的工程專業評估什麼重要、什麼不重要。
2.每天想開發，沒時間想除錯
軟體開發最大的時間成本是用在哪裡？不是開發，而是維護和除錯。而多數資淺的CTO，常常只注重開發，完全沒有為維護和除錯做準備。
每當產品發生問題，很多CTO只能帶隊慢慢閱讀logs和錯誤訊息，但很多問題發生以後就很難模擬當時情況。若沒有為除錯做準備，開發團隊常常光確認問題發生的位置就花上幾個小時。故此，在開發之餘，CTO應該要輔導團隊進行基本的測試、系統控管和問題分析，問題發生時才不會兵荒馬亂。
首先，測試的部分，不光是功能性測試（functional testing）就可以了，因為任何功能都可能因為小部分變動而改變，當問題發生時，功能性測試沒有辦法告訴你問題在哪裡。
故此，團隊應養成習慣至少對公司的核心技術設計基本的單元性測試（unit testing）和整合測試（integration testing），確保軟體核心的各函式庫和商業邏輯執行無誤。當問題發生時，單元性和整合測試至少可快速地告訴團隊問題發生的位置，節省大量的除錯時間。
再來，很多團隊只使用AWS Cloudwatch或類似的陽春控管和警鈴服務偵測錯誤，這類控管很難幫助團隊蒐集更全面、更完整的資訊。
CTO應該要養成習慣控管整個平台，從平台每天的網路連線、前端介面載入、伺服端程式碼執行到資料庫效率的一切執行速度和各類錯誤都要有基本的概念（NewRelic提供很完整的入門級的工具）。
最後，資料庫常常是許多軟體平台的瓶頸，一些控管軟體和效能分析軟體（Performance Profiler）可提供資料庫查詢效能分析。
這些很簡單的控管和分析都可以幫助團隊在瓶頸發生前未雨綢繆。
3.沒有責任感、推卸責任
說到責任感，這是年輕CTO常常犯得錯誤。原因很簡單：因為一位工程師和一位CTO的責任範圍不同，而通常剛當CTO的工程師心理上還沒有準備好要為整個團隊的工作負責。
理論上，一位CTO不單單要為自己寫的程式碼負責，更要為任何他管轄範圍內的生產力負責。
一位沒經驗的CTO常常碰到問題就會把責任推至其他隊友身上，甚至將其他工程師推到創辦人面前頂罪，這是非常荒唐糟糕的做法。
身為一位CTO，當問題發生時，你該做的第一件事情是安撫其他創辦人、穩定軍心，在最短的時間內訂出解決問題的時間表，給整個公司一個交代。
4.不懂得平行和垂直分工
什麼是工程上的平行和垂直分工？
假設你設計的平台和商業邏輯有許多不同的軟體介面和元件，可視為針對各介面或元件進行分工為垂直分工；但同時，你可能會有不同的版本、客戶、功能群組，而針對不同版本、客戶和功能群組進行分工可視為平行分工。
通常新創公司在草創時期，因人手不夠，以平行分工為主：每一位團隊成員可能需要負責服務一位客戶、負責開發一個版本（如網頁版本、行動app版本）。但是，這種分工模式當公司的人力資源和客戶人數開始成長時，很快地就會碰到問題。
這可以回溯到先前討論過的不同類型的工程師，當公司成長到一個程度時，專注於機器學習或是演算法的工程師，不應有事沒事被拉去做使用者介面，否則團隊成員都會變成技能多而不精的通才。
當公司成長到一定程度，必須從平行分工轉為垂直分工，讓各類工程專業發揮所長。打個比方，如果你的公司做影音串流，那做資料壓縮的工程師，應該是這方面的專家，而不是叫團隊隨便一位工程師跑來土法煉鋼。
可惜的是，很多新創公司會因為事情太多、管理不當，不知道如何有效管理人手，而持續用平行分工應付新功能與新客戶，最後導致軟體品質出問題，未來需要繳學費來還。
5.不懂裝懂
創業家都有的特質是什麼？沒別的，就是過度自信。較資淺新創公司的CTO和技術創辦人也不例外。
這也回到不同工程專業的差異，創業家通常都固執己見，多方學習說得簡單，真正捲起袖子做事時，CTO通常很多話是聽不進去的。最嚴重的是團隊擴張時，CTO認為自己的作法永遠是對的，對新進工程師的建議嗤之以鼻。
這是非常大的問題，因為新創的CTO一開始什麼都得做，自然變成通才。而後進員工因為垂直分工，通常工程專業會比CTO更在行。如果CTO以為自己最行，反而會衍生出外行帶領內行的笑話，不少新創的工程團隊最後鬧翻都是從這邊開始。
以上是一些自身和輔導新創的經驗談，希望對於訓練中的CTO或是在尋找共同創辦人的朋友多少有些幫助。
《數位時代》長期徵稿，針對時事科技議題，需要您的獨特觀點，歡迎各類專業人士來稿一起交流。投稿請寄edit@bnext.com.tw，文長至少800字，請附上個人100字內簡介，文章若採用將經編輯潤飾，如需改標會與您討論。
（觀點文章呈現多元意見，不代表《數位時代》的立場。）
