第二屆搞基建|芋頭 - 如何在大前端團隊實現基建價值突破

前端早早聊大會，前端成長新起點，幫你提前二十天，站在新的起跑線，目標成為用得上，聽得懂，抄得走的前端大會，計劃 2020 年辦 12 期，由前端早早聊與掘金聯合舉辦。

• 第一期 2020.1.11 在杭州舉辦，主題 「前端轉管理」，450 人報名參加，反響強烈
• 第二期 2020.2.29 線上上直播，主題 「前端搞基建」，760 人報名參加，反響強烈
• 第三期 2020.3.28 線上上直播，主題 「前端搞搭建」，報名請加關注「前端早早聊」公眾號跟進歷屆大會 PPT/錄播視訊/圖文講稿，回覆 "大會" 二字獲取。

第三屆報名連結：www.huodongxing.com/go/tl3

• 團隊成立 3 年|小爝 - 如何推動基礎架構專案落地
• 團隊成立 4 年|堂主 - 如何推動前端團隊的基礎設施建設
• 團隊成立 5 年|Scott - 如何在人單力薄時立項推動基建
• 團隊成立 6 年|芋頭 - 如何在大前端團隊實現基建價值突破
• 團隊成立 12 年|崇志 - 如何設計大型前端團隊基建路線

本文是第四場講師 - 芋頭的講稿文字版，來看看他是如何講的，視訊及 PPT 未來在公眾號放出。

第一部分 個人和團隊介紹

個人介紹

• 大搜車資深技術專家
• 大無線相關架構、創新團隊管理
• 從業 10 年，做過和帶過前端、客戶端、服務端
• 熱愛分享，活躍於技術社群
• 沒夢想，有活幹就很開心了

團隊介紹

• 300 左右無線相關開發人員
• 整體創新和沉澱意識在集團內也是非常突出的
• 綜合型團隊較多，上升空間大
• 從 17 年開始就成立幾十人的無線基礎設施團隊
• 前端、客戶端、Node.js 領域均有較為成熟的基礎沉澱

個人和團隊職責變化歷程

公司 13 年開始組建開發團隊不久之後我就加入了，最開始負責公司的前端開發相關事宜，因為我以前就是在天貓做前端的。不過雖然主業是前端，但是我當時一直覺得自己應該是要走全棧道路的，首先因為開發完整的應用，肯定不止是前端一個角色的事情，另外就是前端的生態當時已經開始顯露出邊界擴充套件的苗頭，特別是 Node.js 的火熱，所以在團隊還沒有引入過多技術棧和做過多沉澱的時候，我自己率先去做了這方面的沉澱，具體就是花了大量的時間去學習和實踐 Node.js 開發，而且是奔著完成完整的產品的前後端開發去的，雖然最後沒有說對 Node.js 的底層挖掘有多深入，但是的確讓團隊具備了初步的使用 Node.js 做開發的條件。當時在公司剛啟動的過程中，分工不是特別明確，還自學並做過一段時間的 Java 開發，這個經歷對我來說也是很重要的，這些都是團隊後來擴充套件價值邊界的基礎，所以探討基礎設施建設，為長遠沉澱的思路是貫穿始終的，是一切的基礎。

從這張路線圖來看，其中最重要的幾個拐點：

• 開始有意識的沉澱
• 開始用 Node.js 做業務
• 開始做資料視覺化業務
• 開始整合客戶端開發
• Node.js 下沉基礎服務
• 架構常態化、體系化
• 集團業務多樣性，團隊分散
• 基礎設施體系化、產品化、邊界擴充
• 綜合型團隊

最終團隊的沉澱和發展，一個是這個過程中的契機決定的，一個是公司業務發展狀況決定的，一個是自我沉澱的意識決定的，同時也是團隊積累的方法論決定的。

這裡我們不展開其他話題了，主要是這些過程，大家可以參考，可以拿去對映自己的公司，自己的團隊，用以說服老闆，為老闆提供思路等。

現在團隊大體的情況

我們團隊的組織架構其實一直在演化，有時候可能半年兩次的調整頻率，背後也是有一些原因在裡面的，這個等會兒會有專門的探討，這裡是我們過年之前大體的組織組成，其實可能 2 周後就不是這樣了，最近我又有一些新的思路，可能變化會很大。

首先，我負責的團隊是偏基礎設施輸出的，但是又不是那麼絕對，為什麼會是這樣的組織結構呢？是多種原因造成的，一個是團隊在做技術設施過程中，嘗試直接影響業務，最終做的一些創新的方向，演變成了創新平臺（類似於創新實驗室的定位，通過技術挖掘直接改變業務程式），另外一部分是純粹的架構是很難穩定的獨立存在的，所以基礎設施團隊在到達一定階段之後，需要和業務有一些交叉的邊界，特別是前端領域，千萬不能一條繩子上栓死，不管做什麼最終衡量價值一定是對業務、商業的影響，在前期，團隊和業務爆炸增加，很多架構上的問題需要專人解決，一旦解決可以大幅提效，但是當核心痛點得到解決之後，打磨和挖掘是需要的，但是如果大量人力還是耗在一些需要做但是不緊急的事情上，價值會慢慢削弱，所以，作為佈局的人，需要認清這方面的事實。

目前來看，我們團隊現在的整體組織架構是比較健康的：

• 基礎設施，這部分已經比較成熟，更多是標準化、打磨、產品化。
• 基礎服務，Node.js 的練兵場，也是直接影響業務的前沿陣地，當然一些小的基礎服務也很成熟了，大的基礎服務，還需要服務公司雲平臺、PaaS 平臺的建設輸出，這是具有長遠價值，而且很深刻的事情。
• 創新實驗室，高精尖，探索業務最前沿，利用基礎沉澱大幅提升業務能力，也是團隊邊界探索的前沿陣地。
• 業務團隊，前後端一體團隊，一個是利用基礎設施更快的孵化業務，一個是成為基礎設施的試煉場，雙贏，同時也是團隊承擔更多責任的突破口。

第二部分 核心基建介紹

本節，我會簡單羅列一下我們的基建覆蓋場景，因為內容太多，所以沒有把內容展開，也沒有講某個領域我們具體做了什麼，我會適當展開一下，大家感興趣可以會後找我，或者只是把這個當做一個目錄參考。

對於我們做過的基建，我也簡單的做了一下分類：

• 應該有的：最基本的，必備的，行業常見的，完整的，專人負責的，到了某個階段必須要有的基礎設施。
• 日常沉澱：可以沒有，但是有了可以在某個領域提效的，通過長時間有意識積累出來的，偏最佳實踐的基礎設施。
• 影響生存的：做不好，這個領域就混不下去的，例如 Node.js 基建。
• 創新探索的：端的領域擴充，全棧領域擴充，創新價值探索的，往往是一些看起來可有可無，但是可以給業務帶來巨大想象力的事情。
• 產品化探索：慢慢將基礎設施產品化，而不是純粹是技術方面的輸出。

具體內容，這裡不展開了，這個章節還是希望能夠提供一個索引目錄，當大家沒有思路的時候，可以從這裡面尋找一下是否有可參考價值的內容。

另外，在這些目錄之外，簡單總結下經驗：

• 從日常痛點中挖掘基建內容
  • 時刻抱有沉澱意識，不管是大到大型系統，還是小到一個方法，時刻考慮提效、複用、可維護
  • 培養有以上意識的人，給予足夠空間和引導
• 主動挖掘業務痛點
  • 不要等待別人指派任務，經常停下來看看業務上、商業上、產品上，有沒有通過技術手段可以高效解決的問題，例如偏創新的沉澱，業務不敢想或者想不到，我們站在他們的角度去想想
• 適當時機打造正規軍
  • 正規軍需要有正確的職責定義，需要自我挖掘和解決問題，強調產品思維，團隊價值可感知
• 邊界試探
  • 行政上，向上說服，或者是技術上，不斷打破邊界是非常必要的，最基本的，不要給自己設界

第三部分 典型專案簡介

除了提供以上的目錄索引之外，雖然鑑於時間有限，不能針對某些內容展開詳情，如果是這樣，可能每個事情都可以講 1 個小時，但是又想既然提到這些內容，還是應該簡單展開幾個內容，表面介紹一下，可能會給聽的同學帶來一點更具體的價值，所以這一章節，我想簡單介紹下幾個事情的大體解決思路或者方案，正好關注某一塊事情的同學可以借鑑或者探討。

移動標準容器和移動平臺

現在很多網際網路公司的業務都是基於移動端開展的，所以移動端的基礎設施是很重要的，而移動端的發展趨勢，整體又是在向跨端開發的方向演進，不管是 H5，還是 RN，還是現在流行的 Flutter，我們把這類業務執行的環境成為“容器”，容器和容器之間偏向於獨立，每個容器是一個業務單元或者一個執行環境，之間通過路由排程，另外也通過路由可以和 Native 原有的生態互相排程，可以說“容器”是承載移動端業務最核心的部分，其他基礎設施要麼隱藏其後，要麼直接和它關聯，容器是業務和基礎設施之間互通的唯一出口。

針對容器這塊，初期我們做了大量的工作，把公司大部分移動端業務都從 Native 開發轉移到 H5 和 RN 的技術棧上，其實使用 H5 和 RN 本身並沒有太高的技術壁壘，只是把問題放到場景裡就會變得複雜，團隊的構成，業務的性質和量，組織架構，都會帶來很多問題需要解決，而作為基礎設施的開發，需要不斷去平衡和解決這其中出現的問題，克服重重困難把方案落地，最終解決根本的痛點。

這個問題，在做 RN 落地的時候，體會最為明顯，大概講一下落地 RN 需要考慮的問題：

• 團隊構成，移動端相關業務，客戶端居多
• 業務性質，偏 B 端，業務線多，短期內指數級增長
• 組織架構，業務線之間關係比較獨立
• 技術問題，平臺差異仍然存在，效能和體積等

針對這些問題需要做的解決方案：

• 面向 Native 開發友好，不需要花大量時間學習 React，甚至 JS，不需要花時間瞭解 RN 固有的一些機制和問題
• 面向傳統流程友好，開發、部署、聯調、提測、釋出、更新，原有 APP 的流程習慣儘量不破壞，否則需要改變一大批人的工作習慣
• 業務粒度控制，業務單元隔離
• 平臺差異抹平，業務變薄，基礎變厚，犧牲靈活性，帶來標準化等

最終我們對 H5 和 RN 開發的諸多賦能慢慢演化成這些部分。

關於整個移動端開發，除了容器和業務開發比較緊密之外，其實我們的輸出是更大的一個整體，這個整體的價值輸出，可能不限於開發上的提效，還包含一些產品層面的沉澱，甚至是商業上的沉澱。

移動平臺分幾個階段？

• 第一階段，偏工程層面，開發標準化，執行環境標準化，平臺基礎能力標準化
• 第二階段，偏產品層面，與業務無關的能力標準化平臺化，賦能快速搭建（不止是開發層面）新的業務 APP
• 第三階段，偏業務層面，賦能內部 APP 業務層面平臺化，應用互通
• 第四階段，偏行業層面，平臺化 APP 的能力對行業開放，另外助力生態公司快速搭建自己的 APP

這幾個階段不一定是遞進，有交合，也要有孵化沉澱的意識，有些事情從現在可能就要考慮未來的形態。

具體可以做哪些事情？我認為核心兩個方面：

• 第一個方面，移動架構的基礎沉澱，意義：集團所有業務線 基礎複用、H5/RN 跨業務遷移複用、高效標準的工程能力。賦予這些意義的能力，包含：

  • 基礎的執行環境（容器/路由/公共元件等）
  • 業務開發提效設施（開發腳手架/持續整合/釋出更新）
  • 配套的基本的開發系統（託管/日誌/報警）

• 第二個方面，快速低成本搭建或完善 APP 的能力，於內部、子公司、生態公司、行業公司。賦予這些意義的能力，包含：

  • 開發基礎設施層面的快速搭建（包含第一個方面的所有能力）
  • 產品層面的快速搭建（訊息中心、閃屏、更新、客服、IM、掃一掃、搖一搖，資料等）
  • 業務層面的快速搭建（業務單元化後在 APP 間無縫遷移，外部業務快速整合等能力）

持續構建和持續部署

接下去介紹下我們再持續整合方面做的嘗試，嚴格來說，我們提供的不是持續整合的流程最佳實踐（團隊太多，整個流程不急著標準化），而是持續構建和部署的能力。

這裡面的複雜度主要是：

• 技術棧很多，Vue、React、React Native、iOS、Android、小程式、Node.js。
  • 上層抹平技術棧
• 業務線和專案很多，前端專案接近 1000 個，RN 專案接近 300 個
  • 打包資源要保證
  • 構建部署方式需要標準化、集中化

最終，我們把所有無線的技術棧的整合流程做了抽象，每個技術棧的腳手架來適配，例如：

• 環境抽象（測試/穩定/預發等）
• 動作抽象（建立/打包/部署等）

然後把所有這些抽象到一個集中的服務中，提供出 PaaS 服務，上層只需要告訴我專案是什麼技術棧，需要做什麼動作，其他就可以不關心了，當然我們也有預設的上層最佳實踐實現，但是業務也可以自己構建上層的持續整合流程。針對集中打包部署的效能問題，引入 tekton 叢集流水線處理任務。

這裡，其實我們提供的不是一個持續整合的基礎設施，而是持續整合更底層的抽象沉澱，未來它可以適應業務各個階段不同的訴求，屬於基建底層的基建。

Node.js 框架生態

每個前端團隊都應該關注一下團隊在 Node.js 方面的積累和沉澱，Node.js 在我們團隊現在發揮著各種各樣的作用，其中很多領域不是一天兩天的沉澱可以做到的。

例如：

• 前端生態本身，腳手架、持續整合中的各種服務、資源管理、開發用的服務等，脫不開 Node.js 。
• 創新應用的探索，不管是偏技術的，還是偏產品的，要完成一個完整價值的輸出，服務端總是脫不開的，有了 Node.js 沉澱，任何應用都可以你們自己團隊內部孵化，而不需要依賴外部共建。
• 業務開發或者服務開發，模糊大前端團隊邊界，公司大了，職位高了，職責會越來越要求綜合，你的職責就是解決問題，而不是解決前端問題。

為了做到這些，我們在 Node.js 探索的過程中，一直在刻意沉澱：

• 早期，在團隊內探索，前端生態的，甚至是一些小功能嘗試 Node.js 實現。
• 後來，Node.js 嘗試做獨立業務，過程沉澱一些最最基礎的 SDK 和最佳實踐，例如配置管理，非同步任務、一些常見庫的選型固定等。
• 後來，Node.js 嘗試做底層服務，穩定性和效能要求等加深，慢慢在社群框架上固定選型，上層封裝腳手架、配置管理、介面管理、文件管理等。
• 後來，更進一步模糊和 Java 生態相比的弱勢和差異，Dubbo 接入，全鏈路接入，訊息佇列，非同步任務等完全和 Java 打通（而不是重新造輪子），這個階段結束時，做技術選型，技術棧的差異已經不成理由。

正是有這些基建，保證了 Node.js 生態的發展，同時間接促進了團隊承擔更多的責任。

元件庫和功能庫

最後，分享下比較基礎的元件庫沉澱吧，這部分沉澱是比較基礎的，也是早期做了之後發揮價值比較大的部分，主要分為兩部分，UI 元件庫和功能元件庫。

UI 元件庫，我們全部都是自建，當然我並不推薦硬造輪子，自建的主要原因還是配合公司自己的設計規範去做落地，過程中我們也會直接借鑑一些社群元件庫的設計來實現，同時，在建設過程中，面向集團內跨業務的一些訴求，我們在所有元件庫之上做了一個統一的主題色管理機制，配合 APP 還可以自動切換主題，另外就是做了一些業務元件管理的能力，拋開最基本的 UI 元件，一起共建有一些業務特點的業務元件。

在功能元件方面，更多是來自於業務的沉澱，例如 分享庫，整合所有平臺的分享能力，然後內建一些分享鑑權的實現等，最終暴露給業務，是一個簡單配置即可擁有強大功能的庫，基本可以解決公司所有業務的分享相關問題。類似的元件還有很多。

另外，針對元件庫和功能庫，早期可以投入專門的人力去開發，但是後續維護，需要慢慢向共建轉變，這個也是我們的一個經驗教訓，之前有開發夥伴一直專門負責元件庫的開發和維護，投入產出比隨著時間推移，會慢慢降低。

創新平臺

從 18 年底開始，我就一直在想“端”這個詞的另一層含義，前端、客戶端、服務端，我們都趟過，但是這還不是全部，我當時就在想“端”可以有更多機會和價值，放眼到行業裡，雲端、裝置端等概念都如雨後春筍般冒出，對映到公司內，技術上、業務上，都有可以匹配的點，所以後來就下定決心，團隊邊界一定要向裝置端這個領域延伸，當然真正的延伸是需要業務上的突破口的，脫離開業務去做物聯網去做裝置控制意義不大。

後來隨著公司業務發展，19 年初的時候，我們敏銳的發現不少新業務想要嘗試新穎的銷售和營銷方式，其中涉及到很多裝置的場景，於是我們順著這些場景去挖掘（甚至比業務看的更超前），慢慢幫助業務實現目標，另外也在設計實現的時候刻意分層，思考未來底層的沉澱和更多場景的賦能。所以後來就有了 SoucheOS 和 Souche IoT 最最基本的基礎設施，把裝置能力和遠端控制能力做了去業務場景的抽象，有了這些能力，我們可以快速在上層適配各種業務場景，並且順便把集團內的辦公裝置線上化、測試機線上等支援了。另外這塊還有對一些社交軟體的控制能力，這個也是基於裝置底層能力的挖掘，配合裝置平臺，可以輕鬆實現遠端和群控。

第四部分 組織架構的探索

分享完了一些具體的內容，接下去想和大家探討下在基建過程中的其他演化和思考，首當其衝的是組織架構的變化，平常大家都會講，技術不分優劣，更重要的是看場景。組織架構就是場景之一，不同的組織架構下可能需要不同的做事思路，也會產生對基建的不同訴求。不過同時，為了做好基建，也需要不斷調整組織架構。這裡的組織架構可能更多是一內一外，上層組織架構決定了要做什麼事情要怎麼做事情，而為了做好事情，需要不斷調整優化內部組織架構。

內部組織架構調整重點的考量：

• 基建重點是不斷轉移的，伴隨組織架構的調整
• 基於技術棧組織，還是基於專案輸出組織，看階段，看團隊
• 純粹的驅動力人才培養
• 業務和基建，創新和基礎，相輔相成

第五部分 專案管理的探索

基建專案的管理，從來不是一件容易事，這有多方面影響：

• 角色單一，不像正常專案一樣有做規劃的、做項管的、做質量的、做銷售的，在基建專案裡，可能都是一個人
• 開發人員容易糾結於技術本身，忽略溝通、管理、可控等環節的重要性
• 技術專案複雜度較高，如何群策群力，同時又能正確一致地決策

所以，我們發現專案管理的幾個重點：

• 如何立項一個有價值的專案
• 如何推動專案最終實現交付
• 如何將專案推向你的目標場景和使用者，產生最終的價值

在我們團隊，做過很多嘗試，這裡只把一些可能有參考價值的方法介紹一下：

立項

立項包含多個層面，例如方向的確立，專案的確立，迭代的確立。

• 長遠規劃
  • 對於方向的確立，例如在做裝置平臺之前，我們是有對這個事情的想象和探討的，對我個人來說，偶爾會停下來，排除干擾，思考一下一些大方向的可能性，這些思考會站在一些假設之上，例如我們未來業務會向什麼方向傾斜，所以我們未來可能會有個什麼平臺，最完美狀態是什麼樣的，如何在業務中發揮極大價值，不過這些想象可能永遠都達不到，但是價值是可以不斷分層和降級的，想的足夠遠，但是也要分解成階段回到當下。在我思路比較活躍的時候，我會把這些想法寫成“長遠規劃”，然後講給團隊裡的骨幹聽，探討一下，或者同步下站在比較高的角度對這些事情的想象，如果你認同，可以參考，把事情一步一步做成，如果不認同，可以發表你的想法

舉幾個之前長遠思考過的幾個方向：

• 開放平臺服務 -> 開放平臺產品 -> 雲平臺工作視窗 -> PaaS ISV 工作視窗 -> 服務場景管理編排 -> 移動開放平臺等，我們做的當然還遠遠不夠，未來要做什麼，可以參考的方向很多。
• 移動端基礎設施->運營平臺-> PaaS 開發平臺，賦能內部、集團、行業，mPaaS 是可參考的標品。
• 等等，通常這些思考，會參考行業產品，考察業務、商業上的發展等

• 調研報告
  • 長遠規劃可能更偏向理想情況，真正要開始一個專案，需要做更為細緻的分析，確保接下去投入的資源是有價值、可持續的
  • 這些事情，其實有點類似於產品經理需要做的事情，做使用者調研，需求調研，或者是自己分析出來的痛點，但是在整理想法後，也是需要和對應的業務方勾兌交流，修正思路

這裡，其實最好能引入一些產品方法論，例如“使用者故事”，需求分析文件，從不同型別的使用者的角度，開始分析背景、問題、思路、方案、改進後的使用者路徑、感受等。我一直想跟大家強調，做技術設施，一定要鍛鍊自己的產品分析能力，因為沒有人會幫你去分析整個事情的來龍去脈，需要靠自己去挖掘方向和需求，如果你還是一直等待需求的出現，那你是走不遠的。

• 可行性方案
  • 最終，在確定一個專案之前，需要有書面可行性方案，並且組織參與者和相關者對可行性方案進行評審，並做修正

不過這些流程都不是絕對的，看專案型別可以適當調整，並不是絕對的所有專案都要經過最細緻的流程，有時候，過於細緻的流程，雖然可以保證事情的可控，但是也會拖慢進展，有些技術專案，反而是越快越好，需要快速試錯，這其中平衡，還需不斷調整。

推進

基建專案，如果是一個人或者一帶一，推進問題可能還不大，但是通常很多會涉及到跨技術棧角色的合作，甚至是跨團隊的合作，要保證這樣的專案更好地落地，還是需要較為規範的專案管理方式的，其實這裡和普通的業務專案沒有太大的差別，技術方案評審，排期，介面文件等。

這裡提到架構設計，不過說實話，一個系統剛開始的時候，很難給出完整的 C4 架構設計，這裡提到的 C4 架構設計，更多是在專案迭代過程中，逐漸梳理細化出來的，用以向外同步資訊和內部參考迭代。

另外，一個比較重要的點，是里程碑的分解和制定，基建專案通常體量不可控，如果一開始就設計了一個龐大的完整的方案，交付時間幾個月，這時候就要想想裡面是不是充滿了不可控的風險，這幾個月任何事情都可能發生，業務訴求、組織架構、人員變動，所以一定要把目標分解里程碑，每個里程碑有個階段的產出，注意這裡的里程碑不是把一個長的任務直接切開幾份變成短的任務，而是每個里程碑你交付的可能都是一個最小可用的整體，早期儘快成型，後期迭代優化增加新特性，要養成分解達成的習慣，而不是一蹴而就。

運營

技術運營也是基建的一個逃不開的比較磨人的話題，特別是對於大一點的團隊來說，基建的落地是需要自己去主動推動推廣的，對基建的輸出的要求不是做個庫做個框架這麼簡單，而是輸出一個產品，你需要準備資料，講清楚來龍去脈，講清楚你的理解，講清楚你的優勢，建清楚如何使用，形式可能各種各樣，文件當然是必備的，白皮書也是需要的（文件更多是介紹如何使用，白皮書是告訴別人為啥要用），分享是基本的但不一定是有效的，工作坊是更有效但是成本較高的，需要自己平衡和探索。另外就是技術運營要是持續性的，而不是一次了事，事不關己高高掛起愛用不用。

下圖裡我們給團隊的產品甚至都訂做了文化衫，去強化大家對基建產品的瞭解

第六部分 其他經驗總結

通過剛才講的一些內容，我們簡單總結一下。

要做好基建，較為核心的點：

• 組織架構保障。不管是最初的先行小組，還是後來專門的基建團隊培養，Leader 要做好組織上的保障，為基建爭取空間
• 專案管理推進保障。架構專案的特殊性，需要有方式解決推進管理，確保結果落地
• 沉澱意識。Leader 自己要非常敏感，同時挖掘培養有沉澱意識的同學，沉澱都是來自於日常工作
• 貼近業務價值。不要脫離場景造輪子，無法發揮價值，也得不到上下級的認可。

另外，一些細節的注意點：

• 不要給自己和別人挖坑

  • 不要盲目擴充套件團隊技術棧
  • 完整的開發過程和使用文件
  • 切忌假大空，上來就規劃一個平臺，最終只有一個爛攤子
  • 適當嘗試，適當投入，但也要對風險合理評估，並有規避方案
  • 想的可以儘量遠，但是要回到當下根據實際情況分解節奏

• 但是也要適當造輪子

  • 適合自己的實現，按照自己的路徑迭代
  • 磨鍊團隊技術能力，增加對技術細節的深入，為未來做沉澱
  • 系統思維其實很難養成，需要場景
  • 需要平衡，資源、風險、投入產出比、可持續性，對自己的團隊要有一個正確的認知

• 注重系統思維

  • 學會自己做決策和負責任，而不是執行任務，或者完成交代
  • 更透徹的理解一個問題
    • 不斷追問自己為什麼要做一個事情
    • 理解的起因是否也是基於某個結論
    • 例如：我要做 xx，因為 xx 業務說他們需要 xxx
    • 為什麼要這樣做
  • 層次感，規劃、系統架構、價值體現方面，隨時解耦重組

• 切忌半途而廢

  • 逼自己挖掘深度價值
  • 當然也不要盲目挖掘，確保大方向是對的
  • 慢慢系統化、產品化、嘗試打通任督二脈
  • 切忌浮於表面，蜻蜓點水

• 克服孤獨感

  • 熱愛、相信、投入、開放
  • 主人翁意識，為輸出及其價值負責和決策

第七部分 今日分享總結

最後，大家有問題，可以加我微信探討，或者在行上約我面聊，感謝大家。

第三期 2020.3.28 線上上直播，主題 「前端搞搭建」，掃碼關注「前端早早聊」公眾號參與報名：