讀者受益

研發效能定義：知道研發效能是什麼？（對「研發效能」的定義有一個經得起推敲的參考）
研發效能提升：知道如何提升技術團隊的研發效能？（對提升自己所在團隊研發效能有一些想法/靈感）
技術的價值：當被問到自己（技術/技術人）的價值時，能從容的去回答
職業發展：關於自己的職業發展，可以想的更清楚
成長抓手：關於自己在工作中成長的抓手，可以拿捏得更精準

前言

在過去的半年多時間，丁香園前端團隊通過對「研發流程的規範和自動化改造」，保守估計「每個月公司前端技術團隊相比於年初節省了 1/4 的工作時間」（每個月可以節省一週左右的工作時間）。

本文是在第二屆繽紛·濱江前端沙龍直播分享對應的文字稿，希望直播+圖文的形式可以儘可能的把「研發效能提升」過程中的思考和實踐講清楚，同時讓觀衆/讀者有真實的收穫。

這似乎是一件不容易的事情。難點在哪裏呢？

話題寬泛：研發效能是一個很 「寬泛的話題」，它涉及了不同編程技術的應用、項目管理等不同方面的內容。
話題務虛：相比於編程而言，研發效能是一個 「務虛的話題」，容易讓聽衆覺得分享的內容沒什麼用。
認知差異：不同人由於工作經歷、工作經驗、所處團隊規模等因素不同，導致對研發效能的 「認知存在差異」。

但是我還是想試一試，因爲這樣的一個過程真切的對一個 50 人規模的前端團隊帶來了積極正向的變化（甚至助力到了到了非前端的技術同學）。我希望「以故事的形式」能給大家帶來觸動，引發一些思考和共鳴。

接下來我們「以時間線爲切入點」，一起來感受一下「Jarvis 提效之旅」這個故事。

故事背景

在故事開始前，我們先來了解一些故事的背景，以便於有更深入一些的代入感。

丁香園前端團隊架構

爲什麼需要在背景中介紹一下組織架構呢？因爲不同的組織架構可能會導致故事沿着不同的路徑發展。

丁香醫生主要前端項目

介紹主要前端項目，一方面是相對豐富的項目類型和數量提供了各種想法落地的肥沃土壤；另一方面研發效能提升是以以每個項目類型攻關的方式推進的，這些項目在某種程度上也是一個抓手。

前端研發工作流程

技術團隊研發效能提升是一個很大的話題，我們可以從前端工程師的日常工作着眼。首先拋出一個問題：前端工程師從「需求開始開發」到「需求成功發佈」的過程中，通常需要經歷幾個階段以及多少個環節？

前端工程師工作中必經的階段是容易回答的，因爲「每一個軟件工程師都會經歷這4個階段：準備階段、開發階段、測試驗收階段、發佈階段」。在這4個階段基礎上，「如果只有1名前端工程師在支持業務需求」，那麼「他會經歷」如下「9個環節」。隨着業務需求的增多，會出現1名工程師不足以支持所有業務需求的情況。此時，前端工程師難免需要與他人協作來一起完成業務需求的交付。涉及到多人協作，流程的複雜度就會上升，同時會需要制定一些基礎的統一的協作規範，來保證協作流程是順暢的。此時，「爲了確保前端協作流程是順暢的，每一個前端工程師的工作至少會經歷如下13個環節」。丁香醫生的前端團隊，經歷了隨着業務發展團隊人數逐步增多的階段，同樣我們也面臨過業務快讀迭代對前端團隊交付能力的挑戰。在面臨快速交付業務需求的挑戰時，我們會發現在上述多人協作過程中的13個環節中存在着一些問題。面臨的問題可以細化爲：

（單人維護、多人交叉） 「維護項目成本較高，交付效率有提升空間」

團隊各個項目基礎規範不一致
團隊成員對業務需求的熟悉度、業務理解程度不一致

「交付質量需要提高」

自我編寫代碼 Review 不仔細
不熟悉他人編寫代碼，改動前思考不充分、改動後自測不充分

「團隊氛圍需要加強」

新老成員協作默契度有待提高
團隊技術交流較少
團隊成員疲於交付業務需求，缺少技術輸入

基於上述問題，我們不斷完善優化前端工作流程（比如：前端工作流程中引入了 CodeReview 機制並堅持認真去做 CodeReview），同時開始逐步統一團隊內部的基礎規範（比如：落地小程序研發體系等）。大概在 2019 年 Q3，通過技術產品團隊的緊密配合以及前端團隊內部對規範、流程的不斷優化，做到了可以持續順暢的常規產品需求每週發佈 1~2 次。此時，丁醫前端團隊內部的工作流程中至少有 27 個環節。

前端工作中存在的痛點

雖然通過 CodeReview 機制、統一基礎規範、優化並標準化前端工作流程帶來了交付效率的提高，但是也帶來了「新的問題」，並且有一些「頑疾問題」並沒有被解決。

新的問題是由於增加了基礎的協作規範、技術規範，導致「工作流程中環節較多」。環節增多，意味着「人爲失誤」的概率提高了。

頑疾問題是流程中「某些環節的操作是繁瑣的」。典型的例子是微信官方提供的小程序“分佈式”構建發佈能力，在多人協作中不僅操作步驟多，還容易出現構建失敗等問題。再比如：前端工程師的「研發輔助工具分散」，需要不斷的在代碼編輯器、GitLab、Wiki、企業微信、項目管理軟件等系統中切換，每一次的切換其實都在消耗前端工程師的工作時間。

這些問題是單一前端團隊中可能存在的問題。2020 年公司前端團隊經歷了兩個跨團隊的前端項目，一個是疫情地圖項目，另一個是丁香直播項目。由於我親身參與了兩個項目研發工作，深感不同前端團隊在項目管理方式、技術規範、協作規範等方面的差異性。這些因素給跨團隊協作項目帶來的一定的成本。

綜上，前端團隊工作中主要存在如下痛點：

基於時間線的提效故事

在瞭解了故事背景後，我們的提效故事正式開始。

故事主角：工程化平臺 Jarvis

Jarvis 是一個 B/S 架構的系統，下圖是 Jarvis 的工作臺頁面：

Jarvis 定位

我們先來看一下 Jarvis 在技術同學研發工作中所處的位置：

Jarvis 功能設計

接着，我們看一下 Jarvis 包含了哪些功能：

Jarvis 技術方案

最後，我們來看一下 Jarvis 大致的技術實現方案：（在此，我們只是看一下 Jarvis 技術方案的概覽，未來或許會針對技術實現細節做一個分享。）

接下來我們一起看一下 Jarvis 是如何誕生及成長的。

2019 Q1：面臨研發效能的挑戰

故事要從丁香醫生前端團隊講起，記得那是 2018 年的第一場雪，比以往來的更晚了一些。在 Q4 尾巴的時候，我被問到了一個問題：**我對丁香醫生業務的價值是什麼？**當時我的回答大概是：我做了 XXX 等具有較高複雜度的需求，我帶領團隊做了 XXX 的事情，跨部門做成了 XXX 事情。但是這個答案似乎沒有讓提問者滿意，於是我陷入了持續的思考中。

從「我對業務的價值」這個問題出發，引發了「技術的價值是什麼」、「技術人的價值是什麼」、「接下來我做什麼事情纔是有價值的」、「技術與業務的邊界在哪裏（比如：業務創新技術要不要負責）」？等一系列思考。坦言，曾經迷茫過一段時間，想不清問題的答案。

不僅自己有困惑，此時技術團隊也在面臨着來自業務方一些挑戰（重點關注綠色背景部分）：

困惑雖在，可時間依舊在往前走。在這個過程中，嘗試去做了幾件事情。

一件事情是 「小程序開發指南」。本質是積極對重點迭代的丁香醫生小程序項目進行技術優化（發起技術討論，重構、抽離、封裝），然後 「沉澱」成 「技術文檔」，供團隊內部及兄弟團隊查閱和交流。開發指南完成後，感覺文檔對於開發效率、交付質量的提升並不夠，於是進一步去 「抽象封裝 npm 包」、完善 「小程序組件庫 DXDesign」。
一件事情是梳理公司前端團隊的 「前端業務組件體系」。這是首次從公司前端團隊甚至是技術團隊視角來審視、整理已有的技術沉澱。過程中最大的收穫應該是 「看待事物的視角變得開闊」。
一件事情是 「閱讀和交流」。去看一些項目管理的書、一些雜七雜八的技術類的學習資料，有時候有了一些想法或者收穫還會跑去和產品負責人交流。

雖然做了點事情，但是心中的困惑並沒有完全得到答案。只能帶着困惑繼續前行。

2019 Q3：得到啓發初步實踐

在 Q3 發生了幾件事情，給我以及團隊帶來了啓發。

一件是去上海蔘加了 Teambition 組織的「企業敏捷轉型研討會」，對研發效能有了一個初步的認知，對研發效能提升方法有了一個初步的印象。
一件事去參加了雲棲大會的研發效能專場，見識到了更有經驗的前輩是如何看待、解決問題的，見識到了其他企業是如何用技術手段解決研發過程中問題。讓我知道面臨的這些問題其實基本上是行業通病，且是可以被改善、解決的。
一件事情是團隊同學去北京參加了 GMTC。帶回來了一些其他公司的前端技術實踐思路。其中之一就是京東優化小程序構建過程的解決方案。恰好，我們團隊也在面臨這個問題：小程序官方的分佈式構建步驟繁瑣且容易出錯。

這些事情碰撞交織在一起，冥冥之中起了化學反應。熱血青年們感覺熱血沸騰，按捺不住心中的想法，個個擼起了袖子摩拳擦掌。

理想是豐滿的，現實是骨感的。從 0 到一個成熟的構建系統之間，絕不是僅有熱血激情就夠了。我們面臨的問題是如何在業務快速迭代過程中，找到一個可以撬動“地球”的支點。「想都是問題，做纔有答案」。最終，我們決定先做一個小程序自動構建的命令行工具，並且將工具推廣到兄弟團隊使用。有了這個命令行工具 weapp-release後，依舊需要在開發者的機器上進行構建、上傳，還是存在出錯空間（比如：不同在開發者去負責構建上傳時開發者工具及構建環境的差異性、同一個開發者偶爾的操作失誤）。兄弟團隊也在面臨同樣的困惑。

於是不同的前端團隊產出了自己的解決方案：

團隊	方案	服務端	部署機器
丁香醫生	基於「weapp-release」的構建服務 + jQuery 操作頁面	Node.js	內網 Mac Mini
CHD	基於「weapp-release」的構建服務 + React 操作頁面	Go	內網 Windows 臺式機
toH	基於「weapp-release」的構建服務 + VS Code 插件	Node.js	內網樹莓派

2019 Q4：嚐到甜頭持續探索

在日常工作中，大家體會到了小程序構建服務「自動化」帶來的便利後，每次構建成功後需要人主動去查看構建結果。恰好企業微信開放了企業微信機器人的通知能力，於是我們擴展了小程序構建服務，支持了構建結果自動通知給開發者。這樣的嘗試得到了團隊成員的一致肯定，我們嚐到了「自動化」帶來的甜頭。

隨後我們發現小程序開發日常工作流程的 Code Review、發佈後通知等操作同樣具備「流程相對固定、操作重複性較高、人爲操作容易出錯」等特點，就有了把工作流程進一步「規範化」、「自動化」的想法。

當把小程序項目從開始開發到發佈的工作流程「標準化」「自動化」之後，會發現 web 等其他類型項目也是可以這樣做。於是我們擴展了服務，讓小程序類型和 Web 類型項目均享受到便利。

2020 Q1：前端工程化平臺 Jarvis V1.0

「自動化會激活技術人員的創造力」。甚至讓我產生了一種我們團隊「想把一切工作全部自動化」的幻覺。

我們發現技術同學、業務方同學較頻繁需要應用的路由說明文檔、用戶行爲埋點說明文檔，完全依靠技術同學手工維護也是有成本且易出錯，於是我們把原本需要手動維護的文檔也全部自動化生成了。

慢慢的，我們把最初的小程序構建服務做成了一個包含小程序自動發佈、工作流自動化、文檔自動化等能力的服務，同時也把客戶端從一個簡單的 jQuery 頁面升級爲了基於 AntDesign 的 Web 應用。團隊夥伴受到了鋼鐵俠助手名字的啓發，給這個服務起了一個名字叫做 Jarvis。圖片來源於網絡

在這個過程中，面臨過幾個選擇。我把它們稱爲故事的插曲。這些選擇如今看上去沒什麼，不過當時做選擇時還是經歷了一些心路歷程的。

插曲：Jarvis VS Dust

在 Jarvis 演進的過程中，公司的前端基礎平臺也在開發一個名爲 Dust 的系統，目標也是提升前端同學的工作效能。雖然兩個系統的起點不一樣（Jarvis 以小程序自動化構建爲起點，Dust 以改善 Web 項目發佈爲起點），但是隨着系統各自的的迭代，終究會有功能重疊的情況出現。

此時面臨的是 Jarvis 的定位以及要不要做下去的問題。促使做出最終選擇有以下 3 個方面的思考：

Jarvis 對團隊是否有價值？
Jarvis 對公司是否有價值？
需要朝着共贏的方向走

綜合考慮後，最終的決定是：

Jarvis 會繼續做下去
Jarvis 拆分出獨立的小程序構建服務給 Dust 調用
Jarvis 自身不會去迭代發佈功能，發佈能力統一使用 Dust

更多關於這個選擇的思考可見《Jarvis vs Dust》。

插曲：該如何做下去？

明確了會繼續做下去以及自身定位後，其實還不夠。還要回答的一個問題是：接下來如何做纔可以變得更好？當時我們給出的答案是：

足夠好用
迭代（變得更好）足夠快

2020 Q2：共建 Jarvis

當 Jarvis 已經在丁香醫生前端團隊良好落地後，我們會發現公司其他前端團隊的夥伴在工作中仍然面臨着一些我們已經解決過的問題，於是萌生了讓 Jarvis 服務於更多前端工程師的想法。經過和前端基礎平臺及各業務線前端團隊的深入溝通後，我們啓動了 Jarvis 共建計劃，旨在讓更多的前端工程師工作更加順暢、愉悅感更多一些，從而提升公司前端團隊的研發效能。

心理建設

共建兩個字說起來容易，真正實施起來還是具有一定的挑戰的。在共建想法誕生之初，我們進行了一定的心理建設，確定瞭如下共建原則：

「務實」：一切要以解決工作中實際痛點爲基礎
「聚焦價值本身」：不在意項目歸屬，只關注系統是否足夠好用，能否爲公司帶來價值
「兜底方案」：做好即使付出很多，最終也會失敗的心理準備

起步階段

接着，就是需要將想法付諸實際行動了。起步階段，我們主要做了如下幾件事：

「獲得支持」：闡述 Jarvis 的價值，獲得 Boss 的認可，獲得前端架構組的人力支持
「真誠溝通」：和各前端團隊 TL 溝通（摸底調研、初步達成共建共識、明確小組中參與共建的 owner）
「建立運作機制」：吸引跨團隊感興趣成員，成立虛擬研發小組；建立信息同步機制（線下週會、線上交流羣等）
「以優勢爲抓手」：以小程序項目爲切入點，先把各個團隊所有小程序項目接入 Jarvis

實施階段：制定明確的共建計劃，保證計劃良好執行

爲了共建工作可以有序的開展，我們制定瞭如下的共建計劃。計劃中明確了目標、如何做以及各個子階段的關鍵結果。

實施階段：善用看板工具

關於 Jarvis 的項目管理，我們採用了基於 GitLab Issue 管理工具的看板機制。這個做法使得項目的進展情況一目瞭然，相關 Issue 的討論會即時記錄下來以便於後續的回溯。基於 GitLab 做項目管理的另一個好處是，我們可以將 Git 倉庫相關信息（版本信息等）方便的在 Jarvis 中進行呈現，可以讓用戶瞭解到系統最近的變化：

Jarvis 使用情況

經過 Q2 的持續溝通與付出，成功的將各個前端團隊全部的/活躍的項目接入 Jarvis，Jarvis 在公司前端團隊全面落地。

我們可以看一下 2020.07 的 Jarvis 使用數據：

事項	總次數	日均次數
發佈	3207	107
通知	6128	204
服務不可用	0	0
發佈節省時間（以1min計算）	3207*1/60=53.45h=2.2天	1.4h
通知節省時間（以2min計算）	6128*2/60=204h=8.5天	6.8h

這些數據正是前文提到的「保守估計「每個月公司前端技術團隊相比於年初節省了 1/4 的工作時間」」這個結論的基礎。

2020 Q3：更穩定、更易用，探索提效邊界

當時間到了 2020 Q3，我們的重心確定爲讓 Jarvis 變得更穩定、更易用，此外我們開始希望可以讓 Jarvis 能夠幫助更多的技術同學。於是我們做成了如下這些事情：

Jarvis 遇到的困難

在 Jarvis 落地的過程中遇到了一些困難和挑戰，在此不一一贅述，畢竟凡是過往皆爲序章。

基於故事的覆盤

接下來是基於 Jarvis 成長過程的覆盤，內容可能會有些抽象。如果疑惑或者認爲不正確的地方，歡迎交流。

故事時間線：Jarvis 發展過程

我們先來看一下 Jarvis 的發展過程，來系統性的看一下事情的全貌：

研發效能提升思路

聽了這樣一個故事，當面對其他技術團隊需要提升研發效能的場景時，我們可以如何思考呢？

針對前端（軟件研發工程師）工作中存在的痛點，可以將其大致歸類爲4個方面的問題：研發效率、交付質量、交付過程、團隊協作。我們可以選擇「分而治之」的思路，針對每一類的問題明確解決思路：

**研發效率：利用自動化手段，**通過將操作自動化和半自動化，提升前端工程師的研發效率
「交付質量」：通過 「減少」工作流程中 「人爲失誤」，提升前端工程師的交付質量
「交付過程」： 「減少」不同研發輔助系統間的切換、主動/被動 「打擾」， 「提升」開發過程中的 「工作體驗」，使研發過程更順暢
「團隊協作」： 「將前端項目基礎規範標準化，統一前端工程師工作習慣」，降低跨團隊協作成本

我們可以進一步將解決思路抽象爲幾個關鍵詞：

「自動化」
「標準化」
「統一化」
「以人爲本（視人爲人）」

「標準化、自動化、統一化」對於技術人來說，比較好理解。以人爲本想傳遞的是：前端團隊對每一位前端工程師工作體驗的重視。我們終究要做到視人爲人，讓每一個軟件研發人員儘可能的全情投入、愉悅舒心的去工作。

技術的價值

前文提到的問題：

技術人要對業務創新負責嗎？
技術/技術人的價值在哪裏？

你的答案會是什麼呢？

以有限的閱歷，目前我給出的答案是：

技術人不用爲業務創新負責。但是業務輸入和業務成功對技術人來說是一件非常重要的事情，我們在工作中還是需要儘自己最大的能力去業務做貢獻（這其中就包括技術人通過對技術的認知與遠見，來輔助業務進行創新）。
技術的價值在於持續交付。只有將技術進行應用，纔可以發揮出技術的價值。而技術人的價值就是用自己的技術能力來全力保證技術被良好的應用。

技術的價值分層

如果僅僅說「技術的價值在於持續交付」，太過於抽象了。實際上，持續交付這件事情是可以分層來看待的。我會把它分成漸進的 4 層來看：

技術的基本價值： 「交付」價值
技術的增值： 「優質高效」交付價值
技術資產： 「持續順暢」優質高效交付
技術終極價值：持續順暢優質高效交付 「有效」價值

不同層級的價值的關注點不一樣，對技術人的能力要求也不一樣。在一定程度上可以對標到目前市面上不同公司職級體系中的職級級別。

研發效能

文字洋洋灑灑寫到這裏，終於到了故事的起源：研發效能。如果不知道研發效能意味着什麼、該如何定義研發效能，那麼最好還是不要急着去提升它。

如果純粹的去看研發效能這四個字，會相對的空洞。目前我傾向於將研發效能定義爲「技術產品團隊持續順暢優質高效交付有效價值」的能力。這個定義中有四個關鍵的點，分別是：「聚焦於交付質量的「優質」、聚焦於交付效率的「高效」、聚焦於交付過程的「持續順暢」以及聚焦於業務需求價值的「有效價值」」。從圖中可以看出，Jarvis 立足於交付質量、交付效率和交付過程，在提升技術團隊研發效能的路上努力前行。

如何度量研發效能

當我們去做一件事情時，通常會希望去度量事情的結果。研發效能這種相對抽象的概念，雖然沒有辦法做到精準衡量，但是還是可以通過一些數據指標來側面印證。

以下衡量指標目前還沒有在 Jarvis 中全部得到實踐，在此列出來僅供參考。

Jarvis 的價值

在不同的場合下，都需要去回答「Jarvis 的價值」這個問題。坦言，感覺這個問題不好回答。因爲千人千面，每個人對 Jarvis 的理解和使用程度不一致、對研發工作中痛點的感觸不一致、對技術價值的追求度不一致、所處職位（公司價值體系的落腳點）不一致，藉此文字梳理的機會，進行一個正面的回答。

首先，對於公司的價值

「研發效率：「通過將操作自動化和半自動化，提升軟件研發工程師的」研發效率」
「交付質量：「通過減少流程中人爲參與、增強開發過程中的技術校驗，提升工程師的」交付質量」
「交付過程」：減少不同研發輔助系統間的切換、主動/被動打擾，使工程師的研發 「實施過程」更加順暢
「團隊協作」：統一工程師的工作習慣，自動將信息同步給工作流程相關同學，自動生成業務方需要的技術文檔，降低跨團隊 「協作成本」

其次，對於前端團隊的價值

「溝通」：加強了不同前端團隊之間的交流
「技術沉澱」：加強了 Node.js、MySQL 等技術在前端團隊的沉澱
「團隊氛圍」：將「追求交付效率和質量」的思想通過實際行動來踐行，影響更多的前端工程師朝着「優質高效」方向發展

最後，對於個人的價值

「技術沉澱」：參與項目開發的同學可以獲得 React、Node.js 等技術的成長
「技術視野」：參與討論、提出改進建議的同學可以獲得技術視野的開拓（可以和身邊的工程師更多的交流、瞭解不同業務線的項目管理、技術應用情況等、瞭解前端行業中對前端工程化的一些思考）
「工作舒適度」：使用 Jarvis 的同學可以獲得不同程度的工作舒適感的提升

雖然可以從三個維度來闡述 Jarvis 的價值，但是現實中也收到了類似這樣的反饋：

Jarvis 核心的只有通知服務，連發布都是使用了 Dust 的能力
不同團隊 CodeReview 執行程度不一致，在這一環節的工作流程上，Jarvis 並沒有做到統一
有沒有 Jarvis，工作能有什麼不同？

收到這些反饋時，有時候是做不到心如止水的。不過沒有變過的是，我們最終依舊選擇讓 Jarvis 繼續成長下去。希望可以讓初心走的更遠些，希望 Jarvis 可以幫助更多的技術人員工作更順暢更舒適。

Jarvis 的侷限性

Jarvis 當下是具有一定的侷限性的。未來還有很長的路可以走。

首先是系統功能本身的侷限性。第一，Jarvis 尚未支持 Java 項目的提效，而在實際業務的技術項目中 Java 項目佔比較高。第二，Jarvis 尚未支持前後端項目整體的聯動提效（比如：與運維、DBA 的各個系統打通）。這些事情目前在推進，但是遇到了一些新的困難。

上面提到的困難，在某種程度上來說是好解決的。Jarvis 真正的侷限性在於，研發效能終究是在說一個團隊的做事效率。一個團隊中可以有各種各樣的規則來確保大家行爲一致，但是這其中最大的變量是團隊中的人。工具和系統再好用，也抵不過人爲的效率瓶頸。並且即使工具和系統在一個團隊進行了統一，但是使用者在使用時並不理解、在意其帶來的價值，這也會使研發效能打折扣。讓一個軟件工程師全情投入的去工作，僅僅通過工具是不夠的，還需要整個技術團隊的文化建設和團隊氛圍建設。那麼，技術團隊的文化好氛圍佳就可以了嗎？其實也不是，最好是再輔以業務上的持續創新和成功，給到軟件工程師持續的業務輸入和業務反饋。如此這些要求，對一個組織來講是一個較高的標準了。即使困難，技術人還是可以考慮朝着這個方向去探索去破局，想盡辦法去成就業務成就自己。

故事的尾聲

研發效能提升、技術同學成長是永恆的話題，需要技術人持續去探索和實踐。技術人要助力業務成功，這是宿命；技術人要爲自身技術成長負責，這也是宿命。希望通過 Jarvis 的故事可以：

觸動一些技術同學，讓其更理解自身的價值定位，從而獲得更好的職業成長
助力一些技術同學，讓其可以在自己所處的技術團隊發光發熱，提升團隊的研發效能，從而助力公司業務發展

由於筆者閱歷有限，以上關於研發效能的思考與實踐，僅拋磚引玉，歡迎多交流。

最後，向《研發效能提升和敏捷實施 36 計》這門課程及講師致敬，深深感謝爲 Jarvis 成長貢獻力量的夥伴們。

用錢生錢，談談我對財富自由的理解

關注下方公衆號，回覆 電子書，獲得 160 本精華電子書哦。

本文分享自微信公衆號 - 全棧修煉（QuanZhanXiuLian）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。

前端團隊研發效能提升的探索與實踐