[[382869]]

2020 年，諸多不易，大家都是披荊斬棘砥礪前行；在這一年我在技術、產品、行業認知上也是起起伏伏，在挫折、摔打中不斷地深化自己對行業的認知，融入制造團隊，打磨產品，構建更順滑的體驗與交付能力。從技術與產品的視角看，2020 我的核心關注點如下：

• 研發效能，以盡可能小的技術團隊保障全線產品的按時上線、交付。我們的產品涵蓋了典型的 工業互聯網/MES/CRM/電商系統，跨越了 Web/移動端/小程序/桌面端等多個觸達點，服務于海內外客戶（需要維護跨地域的公/私有云及邊緣節點）。
• 技術賦能，挖掘并驅動業務發展，單點突破與全線貫通齊頭并進，以正合，以奇勝。我們需要某些產品點打動客戶，但是如果不能給客戶提供完整的解決方案，是無法得到最好的認可。

做時間的朋友：八大體系超千篇數百萬字技術筆記

天地逆旅，時光飛逝，歲月如梭，年近而立也是愈發感覺有急迫感；每次回顧過去十年的職業生涯，想起自己曾經學過、做過很多，但是也忘了很多，不由地內心惶惑。此時唯有自己做的這數百萬字筆記體現了技術一途上留下的痕跡： 在線閱讀：ng-tech.icu/books ，書籍托管于 Github： https://github.com/wx-chevalier

今年我會針對每個系列編寫專門的導讀文章，希望能與更多的人分享我看到的、學到的、記下的。

既能組裝也能造輪子：模板、庫、項目的沉淀

經歷了不同的大廠與創業團隊，對于技術人員而言需要具備極強的機動性、靈活性；在小型的創業團隊中不能墨守成規，照搬大廠的規范、流程、制度以及技術架構。另一個方面，也不能因為是小團隊就忽略了對于架構、編程規范（如 Lint）、重構（如 Code Review）等的堅持，否則隨著業務發展迅速增加的技術負債終會顯示出它的破壞力。就如筆者在《 SoftwareArchitecture-Series 》中關于所謂復雜性的討論，軟件架構的核心價值，即是控制系統的復雜性，將核心業務邏輯和技術細節的分離與解耦；互聯網軟件系統架構的設計不是一蹴而就，而需要漸進、持續、多次設計的。

作為創業團隊的技術人員，核心矛盾是提高生產力，提高團隊的研發效能。我們既要能發現現有的輪子，去快速組裝他們，去支撐業務需求；也要能造輪子，去完成團隊自身的工具化與工程化。同時也不能盲目追新，很多令人激動的新技術、新特性，但是也要考慮到新技術本身的不確定性、團隊成員的學習成本。這里以 Web 開發做簡單示例，在 wx-fe 主題下大概有十來個項目，其典型包括：

• m-fe-* 系列 : 微前端工程化系統項目，包含了前端開發基礎腳手架、React/Vue/Node/Electron/Taro 以及各種微前端模板。
• micro-components 系列 ：包含 Web 電子白板、Excel 全棧解決方案等一系列項目。
• ueme-* 系列 : 構建用戶體驗中臺系列項目。

這部分筆者會在單獨的專題中進行討論，此處僅引出筆者的代碼庫的沉淀。

雜談：程序員的職業轉折，小團隊與大團隊

不覺入行已有十年，十年蒼狗，我卻是一直懷著對行業的焦慮前行，35 的檻一直如達摩克里斯之劍；不過回頭來看，至少對于身邊認識的很多前輩，在這個時代以 IT/編程為敲門磚進入某個行業/領域是極好的選擇。只要是真正的有心人，能夠在日常工作中進行人脈、管理、行業等等多維度的積累，是肯定能打破職業生涯的桎梏，完成轉型的。技術好的，不妨進入一些傳統行業。只要跨過了行業門檻，有公平競爭的機會，以更現代化的產品與研發效率，也是有可能進行降維打擊的。

但是，需要特別強調的是，無論進入哪個行業，必須心懷敬畏；毫無行業經驗的人，看了幾個 PPT 就揚言要顛覆行業，不覺得是對于前人的不尊重嗎？同時不能太過畫餅，于己于人皆是如此，反對強行讓別人為自己的夢，或者錯誤買單。很多人既要獨斷專行的權利，卻不愿意承擔責任義務。

職責的變化

我從 2014 年開始一直陸陸續續參與創業團隊的工作，期間也在大廠工作了三年；頗有感觸的一點是，創業對于純技術背景的同學并不友好，往往技術越強，落差越大。譬如心態的轉變，很多技術背景的管理者往往會不適應類似于接口協調這樣的工作，覺得似乎是在浪費生命。但是需要慢慢地將自己從日常工作中抽身出來，為團隊保駕護航，上善若水，水利萬物而不爭；然后慢慢起身遠眺，做更偏重于協調，以業務整體績效為目標的事情。此時在團隊溝通上也需要注意技巧，良好的組織氣氛，是提升團隊研發效能的重要保障。就像玩游戲一樣，對于團隊、對于自己，想要翻越某些藩籬的時候，需要不斷地給予正向反饋。無論是公司、團隊的管理，還是自我管理，成就感都是非常不錯的活力棒與路標；而保證自己在日常工作或者 Side Project 中獲得成就感的一種前提，就是盡可能細粒度的切分任務。

此外，研發往往有明確的目標、指標，但是在未知行業中，要提取、抽象出指標卻并非易事，并且目標也是不斷的變化；這點在大公司中往往是由 PD、PM 去屏蔽，但是在創業團隊中缺頗為考驗技術人員的辨識能力。譬如目標和過程的區分。最初我們以為目標是：客戶能夠用上我們的軟件與解決方案，后來發現這只是實現最終商業目標的過程，后來發現我們需要的過程是建立聯接而不是拘泥于軟件使用這件事。競爭意識損害競爭力，同樣達成目標的執念有時反而會損害執行力，很多開始以為的階段目標反而會成為你要征服的最高的巔峰。

團隊的組成

在創業型小團隊中，團隊構成不穩定。開發往往身兼數職，不僅僅實現功能，經常要處理用戶反饋和投訴，還要和產品討論需求、和設計討論界面實現，甚至有時要修電腦、裝軟件、解決疑難雜癥。同時創業期的產品可能質量要求不高。用戶量級小，即使質量稍差也能接受。做的功能亦不太考慮可擴展性，能用就行。技術視野狹隘。整體業務場景少，技術以使用為主，很少深挖底層原理和實現。產品的生命周期不可預測。做了 1、2 年的產品，可能因為各種原因而無法上線。但是，小團隊也同樣具備優勢。人數少的優勢，使得團隊易于扁平，決策層到執行層是直接關系，甚至有時執行層也參與決策。指令下達速度快，溝通成本降低。而且作為早期參與者，在渡過艱難的生存期之后，更容易成為核心人員。核心代表著股份與期權，持股干活更是動力十足。再往后，如果團隊能夠擴招，核心人員往往是管理人員的首選。

合適的人才是團隊的基石，招聘也是團隊長久的任務與挑戰；特別是對于技術負責人，往往也需要承擔起招聘。早期的團隊往往是內部推薦，或者以人帶人，應當盡量招聘合適的人才，過低或者過高往往都會加重團隊的管理成本。在第一輪快速擴張之后的平穩期，穩定是重中之重，同時注意流水不腐，戶樞不蠹。同時團隊無論大小，即使沒有專門的 HR，也需要盡量保證面試流程的正規性，并且針對不同的面試者展示團隊不同的優勢：氛圍良好/極客文化/快速發展/行業優勢等等。不過隨著團隊的迅速擴張，人員擴充本身是熵增的過程，但是熵增也意味著混亂與無序，作為技術團隊的領導者，需要不斷地進行重新定位與角色轉變。從早期的核心開發者，到漸進的團隊協調者，再到團隊的管理者。

健康的團隊，應該是離開任何人都可以正常運轉；反過來看，如果核心成員發現自己在團隊中的地位是無可替代的，反而需要有危機感，寧可犧牲些可用性，也要換取些分區容忍性。技術負責人首先要能夠將任務合理劃分，將業務型的與通用型的模塊化切割開來，盡可能地定義明確邊界與交互的接口協議。這樣就能夠將任務打包給兼職/實習人員，盡可能地實現調度優化。

結語

前兩日有校友撰文寫道：人生之路，不似揮舞劍花那般行云流水，更若一首平仄絕句，錯落有致。面對道路的蜿蜒，唯有攜著“柳暗花明又一村”的篤定堅守，才能穿過眼前橫亙的“山重水復”。國學大師陳寅恪曾說，“唯此獨立之精神，自由之思想，歷千萬祀，與天壤而同久，共三光而永光。”于個人，既要失敗要乘早，窮人家的孩子承擔不起失敗的代價。不過也要隨時轉換，如多年前一次失敗的創業，創業痛苦的并不是燦爛熱烈的死去，而是將死不死，雖靜美卻無心賞秋葉。

最后，謹以此文，致敬認識的或者不認識的創業者，也是贈言給身邊走在創業路上的朋友。