架構師 vs 創業者

        今年初,我以系統架構師的頭銜離開了前公司,來到了一個才 start-up 三個月左右的新創公司當 Team Lead,帶著五、六個人的開發團隊力挽狂瀾、力保三個月後能讓該公司的新創產品能順利上線。

        這段時間我算是忙到昏天暗地,每天工作時間超過十二小時,甚至還有做到清晨四點下班,然後早上十點又繼續上班。可以說沒什麼體力心力寫部落格,任其荒廢了好一段時間。

        這段時間,我不斷受到內心或是外在所謂『架構師』和『創業家』角色之間的拉扯。但想想自己當初跳脫上一間公司的角色來到這裡,諸多原因之一,就是我想認真學習如何成為一個『創業者』!

        但是,架構師和創業家在思維上是很衝突的。

        架構師的使命是預測系統瓶頸和設計可以符合未來趨勢進行擴充與成長的架構,並且追求高度一致性的架構美學和可維護性,某種程度說來,架構師是種『期望在沒有資源限制下,做出盡善盡美的系統』的主導性角色

        而創業者追求的是,在有限的資源內以低成本來快速回應市場需求,在兼顧股東期望、穩扎穩打下逐步改進產品來適應市場

        於外,手握任務指派和帶領團隊權責的我,常常處在現任架構師、專案經理和公司 CEO 拉扯的中間。

        對公司而言,Team Lead 必須緊緊牢扣承諾給股東的上線時程,因為這關係到公司能不能贏得投資者的信賴和持續挹注資金的意願,也是 CEO 和專案經理關注的重點。對架構師而言, Team Lead 應該要依照他不斷分析到的系統弱點、與既定的架構作施工,系統的完善是他在乎的。

        於內,我內心常常也是自我對話,到底現在該不該做這個架構,還是只要先讓功能可以運作就好?現在選擇不做,是不是未來就更不可能回頭做?

        但是資源永遠不夠用,這時候就必須面對取捨。

        在一次多方會談,CEO 提到:「不是所有的問題都一定要透過技術來解決。

        的確,技術人員最容易有的盲點,就是把一切的問題變成『技術問題』。如果這個問題是可以透過營運面 ( Operation ) 來解決,那就不該因這樣的問題而卡住系統上線的時間。這的確也符合『精實創業 Lean Startup』的哲學。

        對創業者而言:有時候,『避開』問題比『解決』問題更務實得多。

        擔心資料被大量查詢而拖累主交易系統?身為架構師的自己可能會思考如何開發 CACHE 機制並且保持資料同步的複雜設計,而創業者決定多花點錢買獨立的設備隔離在外,就算被查到爆量也不影響主交易系統。

        擔心同時間大量使用者湧入登入系統?身為架構師會思考如何獨立出 Login Server 並且設計 SSO ( Single-SignOn ) token 串聯其他系統,分散登入作業的負擔。創業者則決定簡單加上隨機亂數延遲來錯開同時間的登入請求。

        擔心記憶體不足?架構師思考分散式快取 ( Distributed-Cache ) 的機制和開發。創業者說多給你一萬塊幫我多插幾條 RAM 就好。

        就如我們在開發時遇到如果強制跑在 64 位元模式會出現一些執行錯誤的狀況,過去若我以架構師的身份,應該會花時間做各種實驗找出問題的癥結點,面對然後解決它。然而身為無論如何要讓產品推上線的創業者的 Team Lead 角度,我決定不花任何時間釐清原因,而選擇先以 32 位元模式讓系統得以正常運作,以便進行後續開發。

        現在選擇避開,當然日後仍有可能必須回頭血債血還,而且問題可能被埋得更深,可能會有利息效應,但這是創業者必須承擔的風險

        為何我們買房子寧願承擔房貸的利息,也不選擇全部以自備款交易?其中一個原因是期待未來收益會多過利息的支付,這是一個機會成本的選擇。而我們能否真的擴張營運到需要回頭解決 64 位元的問題,卻也是個未知數。

        如果我在學習如何把自己轉換成一個創業者,勢必未來有更多和過往的自己互相衝突的地方。 

留言

這個網誌中的熱門文章

SQL Deadlock 的處理經驗談

網站效能不佳?談『如何判定系統變慢原因』的簡易 SOP