讀者受益

• 研發(fā)效能定義：知道研發(fā)效能是什么？（對(duì)「研發(fā)效能」的定義有一個(gè)經(jīng)得起推敲的參考）
• 研發(fā)效能提升：知道如何提升技術(shù)團(tuán)隊(duì)的研發(fā)效能？（對(duì)提升自己所在團(tuán)隊(duì)研發(fā)效能有一些想法/靈感）
• 技術(shù)的價(jià)值：當(dāng)被問(wèn)到自己（技術(shù)/技術(shù)人）的價(jià)值時(shí)，能從容的去回答
• 職業(yè)發(fā)展：關(guān)于自己的職業(yè)發(fā)展，可以想的更清楚
• 成長(zhǎng)抓手：關(guān)于自己在工作中成長(zhǎng)的抓手，可以拿捏得更精準(zhǔn)

前言

在過(guò)去的半年多時(shí)間，丁香園前端團(tuán)隊(duì)通過(guò)對(duì)「研發(fā)流程的規(guī)范和自動(dòng)化改造」，保守估計(jì)「每個(gè)月公司前端技術(shù)團(tuán)隊(duì)相比于年初節(jié)省了 1/4 的工作時(shí)間」（每個(gè)月可以節(jié)省一周左右的工作時(shí)間）。

本文是在第二屆繽紛·濱江前端沙龍直播分享對(duì)應(yīng)的文字稿，希望直播+圖文的形式可以盡可能的把「研發(fā)效能提升」過(guò)程中的思考和實(shí)踐講清楚，同時(shí)讓觀眾/讀者有真實(shí)的收獲。

這似乎是一件不容易的事情。難點(diǎn)在哪里呢？

• 話題寬泛：研發(fā)效能是一個(gè)很「寬泛的話題」，它涉及了不同編程技術(shù)的應(yīng)用、項(xiàng)目管理等不同方面的內(nèi)容。
• 話題務(wù)虛：相比于編程而言，研發(fā)效能是一個(gè)「務(wù)虛的話題」，容易讓聽(tīng)眾覺(jué)得分享的內(nèi)容沒(méi)什么用。
• 認(rèn)知差異：不同人由于工作經(jīng)歷、工作經(jīng)驗(yàn)、所處團(tuán)隊(duì)規(guī)模等因素不同，導(dǎo)致對(duì)研發(fā)效能的「認(rèn)知存在差異」。

但是我還是想試一試，因?yàn)檫@樣的一個(gè)過(guò)程真切的對(duì)一個(gè) 50 人規(guī)模的前端團(tuán)隊(duì)帶來(lái)了積極正向的變化（甚至助力到了到了非前端的技術(shù)同學(xué)）。我希望「以故事的形式」能給大家?guī)?lái)觸動(dòng)，引發(fā)一些思考和共鳴。

接下來(lái)我們「以時(shí)間線為切入點(diǎn)」，一起來(lái)感受一下「Jarvis 提效之旅」這個(gè)故事。

故事背景

在故事開始前，我們先來(lái)了解一些故事的背景，以便于有更深入一些的代入感。

丁香園前端團(tuán)隊(duì)架構(gòu)

為什么需要在背景中介紹一下組織架構(gòu)呢？因?yàn)椴煌慕M織架構(gòu)可能會(huì)導(dǎo)致故事沿著不同的路徑發(fā)展。

丁香醫(yī)生主要前端項(xiàng)目

介紹主要前端項(xiàng)目，一方面是相對(duì)豐富的項(xiàng)目類型和數(shù)量提供了各種想法落地的肥沃土壤；另一方面研發(fā)效能提升是以以每個(gè)項(xiàng)目類型攻關(guān)的方式推進(jìn)的，這些項(xiàng)目在某種程度上也是一個(gè)抓手。

前端研發(fā)工作流程

技術(shù)團(tuán)隊(duì)研發(fā)效能提升是一個(gè)很大的話題，我們可以從前端工程師的日常工作著眼。首先拋出一個(gè)問(wèn)題：前端工程師從「需求開始開發(fā)」到「需求成功發(fā)布」的過(guò)程中，通常需要經(jīng)歷幾個(gè)階段以及多少個(gè)環(huán)節(jié)？

前端工程師工作中必經(jīng)的階段是容易回答的，因?yàn)?strong style="font-family: Optima-Regular, Optima, PingFangTC-Light, PingFangSC-light, PingFangTC-light;font-size: 14px;letter-spacing: 2px;text-align: left;white-space: normal;word-spacing: 2px;color: rgb(145, 109, 213);">「每一個(gè)軟件工程師都會(huì)經(jīng)歷這4個(gè)階段：準(zhǔn)備階段、開發(fā)階段、測(cè)試驗(yàn)收階段、發(fā)布階段」。在這4個(gè)階段基礎(chǔ)上，「如果只有1名前端工程師在支持業(yè)務(wù)需求」，那么「他會(huì)經(jīng)歷」如下「9個(gè)環(huán)節(jié)」。隨著業(yè)務(wù)需求的增多，會(huì)出現(xiàn)1名工程師不足以支持所有業(yè)務(wù)需求的情況。此時(shí)，前端工程師難免需要與他人協(xié)作來(lái)一起完成業(yè)務(wù)需求的交付。涉及到多人協(xié)作，流程的復(fù)雜度就會(huì)上升，同時(shí)會(huì)需要制定一些基礎(chǔ)的統(tǒng)一的協(xié)作規(guī)范，來(lái)保證協(xié)作流程是順暢的。此時(shí)，「為了確保前端協(xié)作流程是順暢的，每一個(gè)前端工程師的工作至少會(huì)經(jīng)歷如下13個(gè)環(huán)節(jié)」。丁香醫(yī)生的前端團(tuán)隊(duì)，經(jīng)歷了隨著業(yè)務(wù)發(fā)展團(tuán)隊(duì)人數(shù)逐步增多的階段，同樣我們也面臨過(guò)業(yè)務(wù)快讀迭代對(duì)前端團(tuán)隊(duì)交付能力的挑戰(zhàn)。在面臨快速交付業(yè)務(wù)需求的挑戰(zhàn)時(shí)，我們會(huì)發(fā)現(xiàn)在上述多人協(xié)作過(guò)程中的13個(gè)環(huán)節(jié)中存在著一些問(wèn)題。面臨的問(wèn)題可以細(xì)化為：

• （單人維護(hù)、多人交叉）「維護(hù)項(xiàng)目成本較高，交付效率有提升空間」
• 團(tuán)隊(duì)各個(gè)項(xiàng)目基礎(chǔ)規(guī)范不一致
• 團(tuán)隊(duì)成員對(duì)業(yè)務(wù)需求的熟悉度、業(yè)務(wù)理解程度不一致
• 「交付質(zhì)量需要提高」
• 自我編寫代碼 Review 不仔細(xì)
• 不熟悉他人編寫代碼，改動(dòng)前思考不充分、改動(dòng)后自測(cè)不充分
• 「團(tuán)隊(duì)氛圍需要加強(qiáng)」
• 新老成員協(xié)作默契度有待提高
• 團(tuán)隊(duì)技術(shù)交流較少
• 團(tuán)隊(duì)成員疲于交付業(yè)務(wù)需求，缺少技術(shù)輸入

基于上述問(wèn)題，我們不斷完善優(yōu)化前端工作流程（比如：前端工作流程中引入了 CodeReview 機(jī)制并堅(jiān)持認(rèn)真去做 CodeReview），同時(shí)開始逐步統(tǒng)一團(tuán)隊(duì)內(nèi)部的基礎(chǔ)規(guī)范（比如：落地小程序研發(fā)體系等）。大概在 2019 年 Q3，通過(guò)技術(shù)產(chǎn)品團(tuán)隊(duì)的緊密配合以及前端團(tuán)隊(duì)內(nèi)部對(duì)規(guī)范、流程的不斷優(yōu)化，做到了可以持續(xù)順暢的常規(guī)產(chǎn)品需求每周發(fā)布 1~2 次。此時(shí)，丁醫(yī)前端團(tuán)隊(duì)內(nèi)部的工作流程中至少有 27 個(gè)環(huán)節(jié)。

前端工作中存在的痛點(diǎn)

雖然通過(guò) CodeReview 機(jī)制、統(tǒng)一基礎(chǔ)規(guī)范、優(yōu)化并標(biāo)準(zhǔn)化前端工作流程帶來(lái)了交付效率的提高，但是也帶來(lái)了「新的問(wèn)題」，并且有一些「頑疾問(wèn)題」并沒(méi)有被解決。

新的問(wèn)題是由于增加了基礎(chǔ)的協(xié)作規(guī)范、技術(shù)規(guī)范，導(dǎo)致「工作流程中環(huán)節(jié)較多」。環(huán)節(jié)增多，意味著「人為失誤」的概率提高了。

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

這些問(wèn)題是單一前端團(tuán)隊(duì)中可能存在的問(wèn)題。2020 年公司前端團(tuán)隊(duì)經(jīng)歷了兩個(gè)跨團(tuán)隊(duì)的前端項(xiàng)目，一個(gè)是疫情地圖項(xiàng)目，另一個(gè)是丁香直播項(xiàng)目。由于我親身參與了兩個(gè)項(xiàng)目研發(fā)工作，深感不同前端團(tuán)隊(duì)在項(xiàng)目管理方式、技術(shù)規(guī)范、協(xié)作規(guī)范等方面的差異性。這些因素給跨團(tuán)隊(duì)協(xié)作項(xiàng)目帶來(lái)的一定的成本。

綜上，前端團(tuán)隊(duì)工作中主要存在如下痛點(diǎn)：

基于時(shí)間線的提效故事

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

故事主角：工程化平臺(tái) Jarvis

Jarvis 是一個(gè) B/S 架構(gòu)的系統(tǒng)，下圖是 Jarvis 的工作臺(tái)頁(yè)面：

Jarvis 定位

我們先來(lái)看一下 Jarvis 在技術(shù)同學(xué)研發(fā)工作中所處的位置：

Jarvis 功能設(shè)計(jì)

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

Jarvis 技術(shù)方案

最后，我們來(lái)看一下 Jarvis 大致的技術(shù)實(shí)現(xiàn)方案：（在此，我們只是看一下 Jarvis 技術(shù)方案的概覽，未來(lái)或許會(huì)針對(duì)技術(shù)實(shí)現(xiàn)細(xì)節(jié)做一個(gè)分享。）

接下來(lái)我們一起看一下 Jarvis 是如何誕生及成長(zhǎng)的。

2019 Q1：面臨研發(fā)效能的挑戰(zhàn)

故事要從丁香醫(yī)生前端團(tuán)隊(duì)講起，記得那是 2018 年的第一場(chǎng)雪，比以往來(lái)的更晚了一些。在 Q4 尾巴的時(shí)候，我被問(wèn)到了一個(gè)問(wèn)題：**我對(duì)丁香醫(yī)生業(yè)務(wù)的價(jià)值是什么？**當(dāng)時(shí)我的回答大概是：我做了 XXX 等具有較高復(fù)雜度的需求，我?guī)ьI(lǐng)團(tuán)隊(duì)做了 XXX 的事情，跨部門做成了 XXX 事情。但是這個(gè)答案似乎沒(méi)有讓提問(wèn)者滿意，于是我陷入了持續(xù)的思考中。

從「我對(duì)業(yè)務(wù)的價(jià)值」這個(gè)問(wèn)題出發(fā)，引發(fā)了「技術(shù)的價(jià)值是什么」、「技術(shù)人的價(jià)值是什么」、「接下來(lái)我做什么事情才是有價(jià)值的」、「技術(shù)與業(yè)務(wù)的邊界在哪里（比如：業(yè)務(wù)創(chuàng)新技術(shù)要不要負(fù)責(zé)）」？等一系列思考。坦言，曾經(jīng)迷茫過(guò)一段時(shí)間，想不清問(wèn)題的答案。

不僅自己有困惑，此時(shí)技術(shù)團(tuán)隊(duì)也在面臨著來(lái)自業(yè)務(wù)方一些挑戰(zhàn)（重點(diǎn)關(guān)注綠色背景部分）：

困惑雖在，可時(shí)間依舊在往前走。在這個(gè)過(guò)程中，嘗試去做了幾件事情。

• 一件事情是「小程序開發(fā)指南」。本質(zhì)是積極對(duì)重點(diǎn)迭代的丁香醫(yī)生小程序項(xiàng)目進(jìn)行技術(shù)優(yōu)化（發(fā)起技術(shù)討論，重構(gòu)、抽離、封裝），然后「沉淀」成「技術(shù)文檔」，供團(tuán)隊(duì)內(nèi)部及兄弟團(tuán)隊(duì)查閱和交流。開發(fā)指南完成后，感覺(jué)文檔對(duì)于開發(fā)效率、交付質(zhì)量的提升并不夠，于是進(jìn)一步去「抽象封裝 npm 包」、完善「小程序組件庫(kù) DXDesign」。
• 一件事情是梳理公司前端團(tuán)隊(duì)的「前端業(yè)務(wù)組件體系」。這是首次從公司前端團(tuán)隊(duì)甚至是技術(shù)團(tuán)隊(duì)視角來(lái)審視、整理已有的技術(shù)沉淀。過(guò)程中最大的收獲應(yīng)該是「看待事物的視角變得開闊」。
• 一件事情是「閱讀和交流」。去看一些項(xiàng)目管理的書、一些雜七雜八的技術(shù)類的學(xué)習(xí)資料，有時(shí)候有了一些想法或者收獲還會(huì)跑去和產(chǎn)品負(fù)責(zé)人交流。

雖然做了點(diǎn)事情，但是心中的困惑并沒(méi)有完全得到答案。只能帶著困惑繼續(xù)前行。

2019 Q3：得到啟發(fā)初步實(shí)踐

在 Q3 發(fā)生了幾件事情，給我以及團(tuán)隊(duì)帶來(lái)了啟發(fā)。

• 一件是去上海參加了 Teambition 組織的「企業(yè)敏捷轉(zhuǎn)型研討會(huì)」，對(duì)研發(fā)效能有了一個(gè)初步的認(rèn)知，對(duì)研發(fā)效能提升方法有了一個(gè)初步的印象。
• 一件事去參加了云棲大會(huì)的研發(fā)效能專場(chǎng)，見(jiàn)識(shí)到了更有經(jīng)驗(yàn)的前輩是如何看待、解決問(wèn)題的，見(jiàn)識(shí)到了其他企業(yè)是如何用技術(shù)手段解決研發(fā)過(guò)程中問(wèn)題。讓我知道面臨的這些問(wèn)題其實(shí)基本上是行業(yè)通病，且是可以被改善、解決的。
• 一件事情是團(tuán)隊(duì)同學(xué)去北京參加了 GMTC。帶回來(lái)了一些其他公司的前端技術(shù)實(shí)踐思路。其中之一就是京東優(yōu)化小程序構(gòu)建過(guò)程的解決方案。恰好，我們團(tuán)隊(duì)也在面臨這個(gè)問(wèn)題：小程序官方的分布式構(gòu)建步驟繁瑣且容易出錯(cuò)。

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

理想是豐滿的，現(xiàn)實(shí)是骨感的。從 0 到一個(gè)成熟的構(gòu)建系統(tǒng)之間，絕不是僅有熱血激情就夠了。我們面臨的問(wèn)題是如何在業(yè)務(wù)快速迭代過(guò)程中，找到一個(gè)可以撬動(dòng)“地球”的支點(diǎn)。「想都是問(wèn)題，做才有答案」。最終，我們決定先做一個(gè)小程序自動(dòng)構(gòu)建的命令行工具，并且將工具推廣到兄弟團(tuán)隊(duì)使用。有了這個(gè)命令行工具 weapp-release后，依舊需要在開發(fā)者的機(jī)器上進(jìn)行構(gòu)建、上傳，還是存在出錯(cuò)空間（比如：不同在開發(fā)者去負(fù)責(zé)構(gòu)建上傳時(shí)開發(fā)者工具及構(gòu)建環(huán)境的差異性、同一個(gè)開發(fā)者偶爾的操作失誤）。兄弟團(tuán)隊(duì)也在面臨同樣的困惑。

于是不同的前端團(tuán)隊(duì)產(chǎn)出了自己的解決方案：

2019 Q4：嘗到甜頭持續(xù)探索

在日常工作中，大家體會(huì)到了小程序構(gòu)建服務(wù)「自動(dòng)化」帶來(lái)的便利后，每次構(gòu)建成功后需要人主動(dòng)去查看構(gòu)建結(jié)果。恰好企業(yè)微信開放了企業(yè)微信機(jī)器人的通知能力，于是我們擴(kuò)展了小程序構(gòu)建服務(wù)，支持了構(gòu)建結(jié)果自動(dòng)通知給開發(fā)者。這樣的嘗試得到了團(tuán)隊(duì)成員的一致肯定，我們嘗到了「自動(dòng)化」帶來(lái)的甜頭。

隨后我們發(fā)現(xiàn)小程序開發(fā)日常工作流程的 Code Review、發(fā)布后通知等操作同樣具備「流程相對(duì)固定、操作重復(fù)性較高、人為操作容易出錯(cuò)」等特點(diǎn)，就有了把工作流程進(jìn)一步「規(guī)范化」、「自動(dòng)化」的想法。

當(dāng)把小程序項(xiàng)目從開始開發(fā)到發(fā)布的工作流程「標(biāo)準(zhǔn)化」「自動(dòng)化」之后，會(huì)發(fā)現(xiàn) web 等其他類型項(xiàng)目也是可以這樣做。于是我們擴(kuò)展了服務(wù)，讓小程序類型和 Web 類型項(xiàng)目均享受到便利。

2020 Q1：前端工程化平臺(tái) Jarvis V1.0

「自動(dòng)化會(huì)激活技術(shù)人員的創(chuàng)造力」。甚至讓我產(chǎn)生了一種我們團(tuán)隊(duì)「想把一切工作全部自動(dòng)化」的幻覺(jué)。

我們發(fā)現(xiàn)技術(shù)同學(xué)、業(yè)務(wù)方同學(xué)較頻繁需要應(yīng)用的路由說(shuō)明文檔、用戶行為埋點(diǎn)說(shuō)明文檔，完全依靠技術(shù)同學(xué)手工維護(hù)也是有成本且易出錯(cuò)，于是我們把原本需要手動(dòng)維護(hù)的文檔也全部自動(dòng)化生成了。

慢慢的，我們把最初的小程序構(gòu)建服務(wù)做成了一個(gè)包含小程序自動(dòng)發(fā)布、工作流自動(dòng)化、文檔自動(dòng)化等能力的服務(wù)，同時(shí)也把客戶端從一個(gè)簡(jiǎn)單的 jQuery 頁(yè)面升級(jí)為了基于 AntDesign 的 Web 應(yīng)用。團(tuán)隊(duì)伙伴受到了鋼鐵俠助手名字的啟發(fā)，給這個(gè)服務(wù)起了一個(gè)名字叫做 Jarvis。   圖片來(lái)源于網(wǎng)絡(luò)

在這個(gè)過(guò)程中，面臨過(guò)幾個(gè)選擇。我把它們稱為故事的插曲。這些選擇如今看上去沒(méi)什么，不過(guò)當(dāng)時(shí)做選擇時(shí)還是經(jīng)歷了一些心路歷程的。

插曲：Jarvis VS Dust

在 Jarvis 演進(jìn)的過(guò)程中，公司的前端基礎(chǔ)平臺(tái)也在開發(fā)一個(gè)名為 Dust 的系統(tǒng)，目標(biāo)也是提升前端同學(xué)的工作效能。雖然兩個(gè)系統(tǒng)的起點(diǎn)不一樣（Jarvis 以小程序自動(dòng)化構(gòu)建為起點(diǎn)，Dust 以改善 Web 項(xiàng)目發(fā)布為起點(diǎn)），但是隨著系統(tǒng)各自的的迭代，終究會(huì)有功能重疊的情況出現(xiàn)。

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

1. Jarvis 對(duì)團(tuán)隊(duì)是否有價(jià)值？
2. Jarvis 對(duì)公司是否有價(jià)值？
3. 需要朝著共贏的方向走

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

• Jarvis 會(huì)繼續(xù)做下去
• Jarvis 拆分出獨(dú)立的小程序構(gòu)建服務(wù)給 Dust 調(diào)用
• Jarvis 自身不會(huì)去迭代發(fā)布功能，發(fā)布能力統(tǒng)一使用 Dust

更多關(guān)于這個(gè)選擇的思考可見(jiàn)《Jarvis vs Dust》 。

插曲：該如何做下去？

明確了會(huì)繼續(xù)做下去以及自身定位后，其實(shí)還不夠。還要回答的一個(gè)問(wèn)題是：接下來(lái)如何做才可以變得更好？當(dāng)時(shí)我們給出的答案是：

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

2020 Q2：共建 Jarvis

當(dāng) Jarvis 已經(jīng)在丁香醫(yī)生前端團(tuán)隊(duì)良好落地后，我們會(huì)發(fā)現(xiàn)公司其他前端團(tuán)隊(duì)的伙伴在工作中仍然面臨著一些我們已經(jīng)解決過(guò)的問(wèn)題，于是萌生了讓 Jarvis 服務(wù)于更多前端工程師的想法。經(jīng)過(guò)和前端基礎(chǔ)平臺(tái)及各業(yè)務(wù)線前端團(tuán)隊(duì)的深入溝通后，我們啟動(dòng)了 Jarvis 共建計(jì)劃，旨在讓更多的前端工程師工作更加順暢、愉悅感更多一些，從而提升公司前端團(tuán)隊(duì)的研發(fā)效能。

心理建設(shè)

共建兩個(gè)字說(shuō)起來(lái)容易，真正實(shí)施起來(lái)還是具有一定的挑戰(zhàn)的。在共建想法誕生之初，我們進(jìn)行了一定的心理建設(shè)，確定了如下共建原則：

• 「務(wù)實(shí)」：一切要以解決工作中實(shí)際痛點(diǎn)為基礎(chǔ)
• 「聚焦價(jià)值本身」：不在意項(xiàng)目歸屬，只關(guān)注系統(tǒng)是否足夠好用，能否為公司帶來(lái)價(jià)值
• 「兜底方案」：做好即使付出很多，最終也會(huì)失敗的心理準(zhǔn)備

起步階段

接著，就是需要將想法付諸實(shí)際行動(dòng)了。起步階段，我們主要做了如下幾件事：

• 「獲得支持」：闡述 Jarvis 的價(jià)值，獲得 Boss 的認(rèn)可，獲得前端架構(gòu)組的人力支持
• 「真誠(chéng)溝通」：和各前端團(tuán)隊(duì) TL 溝通（摸底調(diào)研、初步達(dá)成共建共識(shí)、明確小組中參與共建的 owner）
• 「建立運(yùn)作機(jī)制」：吸引跨團(tuán)隊(duì)感興趣成員，成立虛擬研發(fā)小組；建立信息同步機(jī)制（線下周會(huì)、線上交流群等）
• 「以優(yōu)勢(shì)為抓手」：以小程序項(xiàng)目為切入點(diǎn)，先把各個(gè)團(tuán)隊(duì)所有小程序項(xiàng)目接入 Jarvis

實(shí)施階段：制定明確的共建計(jì)劃，保證計(jì)劃良好執(zhí)行

為了共建工作可以有序的開展，我們制定了如下的共建計(jì)劃。計(jì)劃中明確了目標(biāo)、如何做以及各個(gè)子階段的關(guān)鍵結(jié)果。

實(shí)施階段：善用看板工具

關(guān)于 Jarvis 的項(xiàng)目管理，我們采用了基于 GitLab Issue 管理工具的看板機(jī)制。這個(gè)做法使得項(xiàng)目的進(jìn)展情況一目了然，相關(guān) Issue 的討論會(huì)即時(shí)記錄下來(lái)以便于后續(xù)的回溯。基于 GitLab 做項(xiàng)目管理的另一個(gè)好處是，我們可以將 Git 倉(cāng)庫(kù)相關(guān)信息（版本信息等）方便的在 Jarvis 中進(jìn)行呈現(xiàn)，可以讓用戶了解到系統(tǒng)最近的變化：

Jarvis 使用情況

經(jīng)過(guò) Q2 的持續(xù)溝通與付出，成功的將各個(gè)前端團(tuán)隊(duì)全部的/活躍的項(xiàng)目接入 Jarvis，Jarvis 在公司前端團(tuán)隊(duì)全面落地。

我們可以看一下 2020.07 的 Jarvis 使用數(shù)據(jù)：

這些數(shù)據(jù)正是前文提到的「保守估計(jì)「每個(gè)月公司前端技術(shù)團(tuán)隊(duì)相比于年初節(jié)省了 1/4 的工作時(shí)間」」這個(gè)結(jié)論的基礎(chǔ)。

2020 Q3：更穩(wěn)定、更易用，探索提效邊界

當(dāng)時(shí)間到了 2020 Q3，我們的重心確定為讓 Jarvis 變得更穩(wěn)定、更易用，此外我們開始希望可以讓 Jarvis 能夠幫助更多的技術(shù)同學(xué)。于是我們做成了如下這些事情：

Jarvis 遇到的困難

在 Jarvis 落地的過(guò)程中遇到了一些困難和挑戰(zhàn)，在此不一一贅述，畢竟凡是過(guò)往皆為序章。

基于故事的復(fù)盤

接下來(lái)是基于 Jarvis 成長(zhǎng)過(guò)程的復(fù)盤，內(nèi)容可能會(huì)有些抽象。如果疑惑或者認(rèn)為不正確的地方，歡迎交流。

故事時(shí)間線：Jarvis 發(fā)展過(guò)程

我們先來(lái)看一下 Jarvis 的發(fā)展過(guò)程，來(lái)系統(tǒng)性的看一下事情的全貌：

研發(fā)效能提升思路

聽(tīng)了這樣一個(gè)故事，當(dāng)面對(duì)其他技術(shù)團(tuán)隊(duì)需要提升研發(fā)效能的場(chǎng)景時(shí)，我們可以如何思考呢？

針對(duì)前端（軟件研發(fā)工程師）工作中存在的痛點(diǎn)，可以將其大致歸類為4個(gè)方面的問(wèn)題：研發(fā)效率、交付質(zhì)量、交付過(guò)程、團(tuán)隊(duì)協(xié)作。我們可以選擇「分而治之」的思路，針對(duì)每一類的問(wèn)題明確解決思路：

• **研發(fā)效率：利用自動(dòng)化手段，**通過(guò)將操作自動(dòng)化和半自動(dòng)化，提升前端工程師的研發(fā)效率
• 「交付質(zhì)量」：通過(guò)「減少」工作流程中「人為失誤」，提升前端工程師的交付質(zhì)量
• 「交付過(guò)程」：「減少」不同研發(fā)輔助系統(tǒng)間的切換、主動(dòng)/被動(dòng)「打擾」，「提升」開發(fā)過(guò)程中的「工作體驗(yàn)」，使研發(fā)過(guò)程更順暢
• 「團(tuán)隊(duì)協(xié)作」：「將前端項(xiàng)目基礎(chǔ)規(guī)范標(biāo)準(zhǔn)化，統(tǒng)一前端工程師工作習(xí)慣」，降低跨團(tuán)隊(duì)協(xié)作成本

我們可以進(jìn)一步將解決思路抽象為幾個(gè)關(guān)鍵詞：

• 「自動(dòng)化」
• 「標(biāo)準(zhǔn)化」
• 「統(tǒng)一化」
• 「以人為本（視人為人）」

「標(biāo)準(zhǔn)化、自動(dòng)化、統(tǒng)一化」對(duì)于技術(shù)人來(lái)說(shuō)，比較好理解。以人為本想傳遞的是：前端團(tuán)隊(duì)對(duì)每一位前端工程師工作體驗(yàn)的重視。我們終究要做到視人為人，讓每一個(gè)軟件研發(fā)人員盡可能的全情投入、愉悅舒心的去工作。

技術(shù)的價(jià)值

前文提到的問(wèn)題：

1. 技術(shù)人要對(duì)業(yè)務(wù)創(chuàng)新負(fù)責(zé)嗎？
2. 技術(shù)/技術(shù)人的價(jià)值在哪里？

你的答案會(huì)是什么呢？

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

1. 技術(shù)人不用為業(yè)務(wù)創(chuàng)新負(fù)責(zé)。但是業(yè)務(wù)輸入和業(yè)務(wù)成功對(duì)技術(shù)人來(lái)說(shuō)是一件非常重要的事情，我們?cè)诠ぷ髦羞€是需要盡自己最大的能力去業(yè)務(wù)做貢獻(xiàn)（這其中就包括技術(shù)人通過(guò)對(duì)技術(shù)的認(rèn)知與遠(yuǎn)見(jiàn)，來(lái)輔助業(yè)務(wù)進(jìn)行創(chuàng)新）。
2. 技術(shù)的價(jià)值在于持續(xù)交付。只有將技術(shù)進(jìn)行應(yīng)用，才可以發(fā)揮出技術(shù)的價(jià)值。而技術(shù)人的價(jià)值就是用自己的技術(shù)能力來(lái)全力保證技術(shù)被良好的應(yīng)用。

技術(shù)的價(jià)值分層

如果僅僅說(shuō)「技術(shù)的價(jià)值在于持續(xù)交付」，太過(guò)于抽象了。實(shí)際上，持續(xù)交付這件事情是可以分層來(lái)看待的。我會(huì)把它分成漸進(jìn)的 4 層來(lái)看：

1. 技術(shù)的基本價(jià)值：「交付」價(jià)值
2. 技術(shù)的增值：「優(yōu)質(zhì)高效」交付價(jià)值
3. 技術(shù)資產(chǎn)：「持續(xù)順暢」優(yōu)質(zhì)高效交付
4. 技術(shù)終極價(jià)值：持續(xù)順暢優(yōu)質(zhì)高效交付「有效」價(jià)值

不同層級(jí)的價(jià)值的關(guān)注點(diǎn)不一樣，對(duì)技術(shù)人的能力要求也不一樣。在一定程度上可以對(duì)標(biāo)到目前市面上不同公司職級(jí)體系中的職級(jí)級(jí)別。

研發(fā)效能

文字洋洋灑灑寫到這里，終于到了故事的起源：研發(fā)效能。如果不知道研發(fā)效能意味著什么、該如何定義研發(fā)效能，那么最好還是不要急著去提升它。

如果純粹的去看研發(fā)效能這四個(gè)字，會(huì)相對(duì)的空洞。目前我傾向于將研發(fā)效能定義為「技術(shù)產(chǎn)品團(tuán)隊(duì)持續(xù)順暢優(yōu)質(zhì)高效交付有效價(jià)值」的能力。這個(gè)定義中有四個(gè)關(guān)鍵的點(diǎn)，分別是：「聚焦于交付質(zhì)量的「優(yōu)質(zhì)」、聚焦于交付效率的「高效」、聚焦于交付過(guò)程的「持續(xù)順暢」以及聚焦于業(yè)務(wù)需求價(jià)值的「有效價(jià)值」」。從圖中可以看出，Jarvis 立足于交付質(zhì)量、交付效率和交付過(guò)程，在提升技術(shù)團(tuán)隊(duì)研發(fā)效能的路上努力前行。

如何度量研發(fā)效能

當(dāng)我們?nèi)プ鲆患虑闀r(shí)，通常會(huì)希望去度量事情的結(jié)果。研發(fā)效能這種相對(duì)抽象的概念，雖然沒(méi)有辦法做到精準(zhǔn)衡量，但是還是可以通過(guò)一些數(shù)據(jù)指標(biāo)來(lái)側(cè)面印證。

以下衡量指標(biāo)目前還沒(méi)有在 Jarvis 中全部得到實(shí)踐，在此列出來(lái)僅供參考。

Jarvis 的價(jià)值

在不同的場(chǎng)合下，都需要去回答「Jarvis 的價(jià)值」這個(gè)問(wèn)題。坦言，感覺(jué)這個(gè)問(wèn)題不好回答。因?yàn)榍饲妫總€(gè)人對(duì) Jarvis 的理解和使用程度不一致、對(duì)研發(fā)工作中痛點(diǎn)的感觸不一致、對(duì)技術(shù)價(jià)值的追求度不一致、所處職位（公司價(jià)值體系的落腳點(diǎn)）不一致，借此文字梳理的機(jī)會(huì)，進(jìn)行一個(gè)正面的回答。

首先，對(duì)于公司的價(jià)值

• 「研發(fā)效率：「通過(guò)將操作自動(dòng)化和半自動(dòng)化，提升軟件研發(fā)工程師的」研發(fā)效率」
• 「交付質(zhì)量：「通過(guò)減少流程中人為參與、增強(qiáng)開發(fā)過(guò)程中的技術(shù)校驗(yàn)，提升工程師的」交付質(zhì)量」
• 「交付過(guò)程」：減少不同研發(fā)輔助系統(tǒng)間的切換、主動(dòng)/被動(dòng)打擾，使工程師的研發(fā)「實(shí)施過(guò)程」更加順暢
• 「團(tuán)隊(duì)協(xié)作」：統(tǒng)一工程師的工作習(xí)慣，自動(dòng)將信息同步給工作流程相關(guān)同學(xué)，自動(dòng)生成業(yè)務(wù)方需要的技術(shù)文檔，降低跨團(tuán)隊(duì)「協(xié)作成本」

其次，對(duì)于前端團(tuán)隊(duì)的價(jià)值

• 「溝通」：加強(qiáng)了不同前端團(tuán)隊(duì)之間的交流
• 「技術(shù)沉淀」：加強(qiáng)了 Node.js、MySQL 等技術(shù)在前端團(tuán)隊(duì)的沉淀
• 「團(tuán)隊(duì)氛圍」：將「追求交付效率和質(zhì)量」的思想通過(guò)實(shí)際行動(dòng)來(lái)踐行，影響更多的前端工程師朝著「優(yōu)質(zhì)高效」方向發(fā)展

最后，對(duì)于個(gè)人的價(jià)值

• 「技術(shù)沉淀」：參與項(xiàng)目開發(fā)的同學(xué)可以獲得 React、Node.js 等技術(shù)的成長(zhǎng)
• 「技術(shù)視野」：參與討論、提出改進(jìn)建議的同學(xué)可以獲得技術(shù)視野的開拓（可以和身邊的工程師更多的交流、了解不同業(yè)務(wù)線的項(xiàng)目管理、技術(shù)應(yīng)用情況等、了解前端行業(yè)中對(duì)前端工程化的一些思考）
• 「工作舒適度」：使用 Jarvis 的同學(xué)可以獲得不同程度的工作舒適感的提升

雖然可以從三個(gè)維度來(lái)闡述 Jarvis 的價(jià)值，但是現(xiàn)實(shí)中也收到了類似這樣的反饋：

1. Jarvis 核心的只有通知服務(wù)，連發(fā)布都是使用了 Dust 的能力
2. 不同團(tuán)隊(duì) CodeReview 執(zhí)行程度不一致，在這一環(huán)節(jié)的工作流程上，Jarvis 并沒(méi)有做到統(tǒng)一
3. 有沒(méi)有 Jarvis，工作能有什么不同？

收到這些反饋時(shí)，有時(shí)候是做不到心如止水的。不過(guò)沒(méi)有變過(guò)的是，我們最終依舊選擇讓 Jarvis 繼續(xù)成長(zhǎng)下去。希望可以讓初心走的更遠(yuǎn)些，希望 Jarvis 可以幫助更多的技術(shù)人員工作更順暢更舒適。

Jarvis 的局限性

Jarvis 當(dāng)下是具有一定的局限性的。未來(lái)還有很長(zhǎng)的路可以走。

首先是系統(tǒng)功能本身的局限性。第一，Jarvis 尚未支持 Java 項(xiàng)目的提效，而在實(shí)際業(yè)務(wù)的技術(shù)項(xiàng)目中 Java 項(xiàng)目占比較高。第二，Jarvis 尚未支持前后端項(xiàng)目整體的聯(lián)動(dòng)提效（比如：與運(yùn)維、DBA 的各個(gè)系統(tǒng)打通）。這些事情目前在推進(jìn)，但是遇到了一些新的困難。

上面提到的困難，在某種程度上來(lái)說(shuō)是好解決的。Jarvis 真正的局限性在于，研發(fā)效能終究是在說(shuō)一個(gè)團(tuán)隊(duì)的做事效率。一個(gè)團(tuán)隊(duì)中可以有各種各樣的規(guī)則來(lái)確保大家行為一致，但是這其中最大的變量是團(tuán)隊(duì)中的人。工具和系統(tǒng)再好用，也抵不過(guò)人為的效率瓶頸。并且即使工具和系統(tǒng)在一個(gè)團(tuán)隊(duì)進(jìn)行了統(tǒng)一，但是使用者在使用時(shí)并不理解、在意其帶來(lái)的價(jià)值，這也會(huì)使研發(fā)效能打折扣。讓一個(gè)軟件工程師全情投入的去工作，僅僅通過(guò)工具是不夠的，還需要整個(gè)技術(shù)團(tuán)隊(duì)的文化建設(shè)和團(tuán)隊(duì)氛圍建設(shè)。那么，技術(shù)團(tuán)隊(duì)的文化好氛圍佳就可以了嗎？其實(shí)也不是，最好是再輔以業(yè)務(wù)上的持續(xù)創(chuàng)新和成功，給到軟件工程師持續(xù)的業(yè)務(wù)輸入和業(yè)務(wù)反饋。如此這些要求，對(duì)一個(gè)組織來(lái)講是一個(gè)較高的標(biāo)準(zhǔn)了。即使困難，技術(shù)人還是可以考慮朝著這個(gè)方向去探索去破局，想盡辦法去成就業(yè)務(wù)成就自己。

故事的尾聲

研發(fā)效能提升、技術(shù)同學(xué)成長(zhǎng)是永恒的話題，需要技術(shù)人持續(xù)去探索和實(shí)踐。技術(shù)人要助力業(yè)務(wù)成功，這是宿命；技術(shù)人要為自身技術(shù)成長(zhǎng)負(fù)責(zé)，這也是宿命。希望通過(guò) Jarvis 的故事可以：

• 觸動(dòng)一些技術(shù)同學(xué)，讓其更理解自身的價(jià)值定位，從而獲得更好的職業(yè)成長(zhǎng)
• 助力一些技術(shù)同學(xué)，讓其可以在自己所處的技術(shù)團(tuán)隊(duì)發(fā)光發(fā)熱，提升團(tuán)隊(duì)的研發(fā)效能，從而助力公司業(yè)務(wù)發(fā)展

由于筆者閱歷有限，以上關(guān)于研發(fā)效能的思考與實(shí)踐，僅拋磚引玉，歡迎多交流。

最后，向《研發(fā)效能提升和敏捷實(shí)施 36 計(jì)》這門課程及講師致敬，深深感謝為 Jarvis 成長(zhǎng)貢獻(xiàn)力量的伙伴們。