最近與某互聯(lián)網(wǎng)公司架構(gòu)師討論了研發(fā)效能中的問題，整理分享如下。

01 視角

有許多評估團(tuán)隊(duì)產(chǎn)出的辦法，比如代碼行、功能點(diǎn)、故事點(diǎn)和故事卡數(shù)量，這種度量方式不僅存在偏差，而且是一種非常局部的度量方式，現(xiàn)在都已不再適用。更有許多研發(fā)團(tuán)隊(duì)存在著這種情況，開發(fā)編碼的效率很高，測試和部署工作量大，成為瓶頸，或者需求澄清和排程的時(shí)間長，壓縮了開發(fā)時(shí)間，無法詳細(xì)地設(shè)計(jì)和驗(yàn)證，質(zhì)量下滑拖累了效率。從而導(dǎo)致最后效能問題“每天工作投入度和響應(yīng)上，自己感知已經(jīng)夠快了，業(yè)務(wù)還說我們慢，原因在哪里我也說不清楚”。

這里的關(guān)鍵點(diǎn)在于，效能為誰度量，即以誰的視角來看待效能？由于研發(fā)最終的目標(biāo)是交付到業(yè)務(wù)，那效能最終面對的還是業(yè)務(wù)視角。

02 感知

很多時(shí)候業(yè)務(wù)感知的“慢”，在于需求的端到端交付周期過長，也在于過程的信息不透明。“一個(gè)小需求，也要那么久才能上線！”而開發(fā)感知到的是，需求的評估、排程和跨組/團(tuán)隊(duì)協(xié)同過程太耗時(shí)了，是因?yàn)樵谶@個(gè)過程中等待太久，才導(dǎo)致周期拉得很長。

一個(gè)需求從提出到發(fā)布，通常會(huì)經(jīng)過分析、澄清、計(jì)劃、設(shè)計(jì)、開發(fā)、測試、部署到正式發(fā)布幾個(gè)階段。

那么在各個(gè)環(huán)節(jié)中，究竟多長時(shí)間是合適的呢？精益思想給出了一個(gè)度量方法，就是最小積壓，理想狀態(tài)下是做到零庫存，即沒有需求積壓。如果業(yè)務(wù)持續(xù)不斷地接收到產(chǎn)出物，同時(shí)看到新需求不斷進(jìn)入處理過程，就很難感知到“很慢”了。

舉個(gè)例子，同樣是等，在星巴克你能看到你的杯子正在什么位置，咖啡師正在準(zhǔn)備什么；外賣下單后，你能看到騎手的位置和狀態(tài)，就能緩解等待的焦慮。而在研發(fā)過程中，因?yàn)樾畔⒉煌该鲙淼男枰降摹皶?huì)議”實(shí)在是太多了。

03 時(shí)間

近些年我們推崇的是使用時(shí)間來度量效能，并且在數(shù)個(gè)咨詢項(xiàng)目上通過這種度量方式驅(qū)動(dòng)，成功地幫助團(tuán)隊(duì)找到了改進(jìn)點(diǎn)，優(yōu)化了整體的交付周期。

三個(gè)關(guān)鍵的時(shí)間度量指標(biāo)是：

Lead Time（前置時(shí)間）：業(yè)務(wù)感知效能的重要指示燈，是指從業(yè)務(wù)提出需求到最終需求發(fā)布到業(yè)務(wù)的時(shí)間間隔（自然日）。如需求于9月1日提出，9月30日發(fā)布，那Lead Time就為29天。又被稱為需求端到端交付周期。

Cycle Time（周期時(shí)間）：研發(fā)內(nèi)部效能的重要指示燈，是指開發(fā)團(tuán)隊(duì)接受需求到交付業(yè)務(wù)驗(yàn)收的時(shí)間間隔（自然日），覆蓋了分析、設(shè)計(jì)、編碼、測試及修復(fù)缺陷的時(shí)間。通常也稱之為交付周期。

Takt Time（節(jié)拍時(shí)間）：研發(fā)節(jié)奏制定的重要參考值，是指開發(fā)團(tuán)隊(duì)在周期時(shí)間內(nèi)完成需求的平均時(shí)間。比如周期時(shí)間為29天，共產(chǎn)出10個(gè)需求，節(jié)拍時(shí)間就為2.9天。精益的理想狀態(tài)是單件流，即最小的批量不間斷流轉(zhuǎn)，節(jié)拍時(shí)間就是縮小批量大小，邁向不間斷流轉(zhuǎn)的重要依據(jù)。

度量了這幾個(gè)時(shí)間，那又如何來說明效能呢？

04 浪費(fèi)

前面提到精益給出的度量標(biāo)準(zhǔn)，即最小積壓。在交付的各個(gè)環(huán)節(jié)中等待的任務(wù)，都是積壓，即是浪費(fèi)。對研發(fā)中的浪費(fèi)，我們設(shè)定在計(jì)劃啟動(dòng)之后進(jìn)行統(tǒng)計(jì)，并分類原因：

• 進(jìn)入開發(fā)階段而未投入實(shí)際工作量：比如一次領(lǐng)了太多的任務(wù)，其中幾個(gè)任務(wù)并沒有產(chǎn)出，計(jì)為浪費(fèi)，因計(jì)劃不當(dāng)引起。
• 完成開發(fā)等待評審/測試：由于不同角色的協(xié)作不流暢引起。
• 重做/返工：由于需求理解不正確或?qū)崿F(xiàn)不正確引起。
• 完成測試后等待驗(yàn)收：由于不同職能的協(xié)作不流暢引起。

根據(jù)大量的咨詢經(jīng)驗(yàn)，許多效能問題，只需要消除浪費(fèi)就能夠顯著地提升，這個(gè)提升比率最低在40%，最高在89%；一些跨團(tuán)隊(duì)協(xié)作的痛點(diǎn)，僅僅通過統(tǒng)一拆分任務(wù)和計(jì)劃方式，就將協(xié)同任務(wù)的節(jié)拍時(shí)間下降了40%之多。

05 工作方式

推行敏捷最重要的就是帶給大家一種全新的工作方式：從一種自上而下領(lǐng)導(dǎo)式的計(jì)劃和管理，變成自下而上的團(tuán)隊(duì)合作達(dá)成目標(biāo)。為達(dá)成這個(gè)轉(zhuǎn)變，團(tuán)隊(duì)需要掌握幾項(xiàng)技能：

設(shè)定目標(biāo)：從業(yè)務(wù)和用戶的視角理解需求，了解業(yè)務(wù)價(jià)值、使用者和痛點(diǎn)，而不僅僅是功能說明清單。

需求分解：”需求跨不跨迭代“、”需求分幾個(gè)迭代開發(fā)完成“，也是迭代式開發(fā)中的一個(gè)常見問題。正確答案是：在敏捷開發(fā)里，無論選擇哪類需求載體，特性、用戶故事還是任務(wù)，都不應(yīng)該在計(jì)劃階段設(shè)定為跨迭代交付，除非迭代目標(biāo)沒達(dá)成，在評審會(huì)議上轉(zhuǎn)入下一個(gè)迭代。沒有正確的需求分解方法，是排不出正確的迭代計(jì)劃的。

任務(wù)估算：ESTIMATE翻譯為估算一直以來都被視為一種對交付時(shí)間的承諾，所以讓開發(fā)團(tuán)隊(duì)感覺很難操作。如果用中文更準(zhǔn)確的表達(dá)應(yīng)為“評估”，估算技術(shù)，是一種從時(shí)間上量化交付周期和風(fēng)險(xiǎn)的手段。比如采用斐波那契數(shù)列進(jìn)行估算，就能夠很好地為不確定的風(fēng)險(xiǎn)添加緩沖時(shí)間。

迭代/看板計(jì)劃：許多團(tuán)隊(duì)僅僅是劃分了一個(gè)更小的周期，就把它當(dāng)作迭代。甚至還有團(tuán)隊(duì)劃分出來的是開發(fā)人員的一個(gè)容量包，比如兩周的工作量，排進(jìn)一個(gè)迭代，迭代N的交付物，是測試團(tuán)隊(duì)在迭代N+1的測試版本，然后在N+1迭代中又?jǐn)D進(jìn)一些不可預(yù)測的缺陷修復(fù)工作量，最后在N+2/3迭代中發(fā)布迭代N的需求。這也是許多開發(fā)團(tuán)隊(duì)自稱已做到“兩周一迭代”而業(yè)務(wù)覺得沒啥變化的原因：真實(shí)的”需求迭代“應(yīng)該在六到八周左右，差不多一個(gè)半月到兩個(gè)月?？窗逵质橇硪环N工作計(jì)劃方式，需要比迭代更細(xì)致的優(yōu)先級排序，形成任務(wù)隊(duì)列。在看板上，團(tuán)隊(duì)自頂向下拉動(dòng)任務(wù)卡至交付泳道。

規(guī)矩千萬條，最后都落墻角。工作方式大家都口頭接受了，但一執(zhí)行又全跑歪，又該怎么辦呢？

06 行為

討論中架構(gòu)師談到，不止研發(fā)效能，還包括架構(gòu)和代碼質(zhì)量，都已經(jīng)制定了嚴(yán)格的標(biāo)準(zhǔn)，團(tuán)隊(duì)也接受了，但就是很難執(zhí)行，現(xiàn)在針對一個(gè)200人級別的大型重構(gòu)項(xiàng)目，不得不組建近30人的治理團(tuán)隊(duì)，負(fù)責(zé)評審代碼和接口，以避免架構(gòu)質(zhì)量走偏。

我認(rèn)為，這是一種治標(biāo)不治本的方式。結(jié)果有偏差，問題的根源在哪里？代碼已經(jīng)不合格了，評審、退回、重做和返工都是浪費(fèi)。效能的改進(jìn)是致力于消除這種浪費(fèi)，而許多技術(shù)型管理者關(guān)注和控制的落腳點(diǎn)在最終結(jié)果，而不是原因。有沒有親自到現(xiàn)場走查一下，這些不合格的代碼、接口是怎么寫出來的呢？

許多規(guī)范只是原則，而開發(fā)人員執(zhí)行的是操作。比如說一個(gè)接口的設(shè)計(jì)規(guī)范明明要求：滿足向前兼容。但開發(fā)出來的新版本卻把舊的功能破壞了。開發(fā)人員很可能并不知道什么叫“向前兼容”，這些原則對并不了解它們的人來說，根本不具備指導(dǎo)意義。如果改成：

禁止修改不熟悉的代碼，如要修改，請和代碼編寫者或技術(shù)負(fù)責(zé)人溝通，并編寫對應(yīng)的單元測試，以避免破壞系統(tǒng)功能。

禁止修改已發(fā)布的接口實(shí)現(xiàn)代碼，應(yīng)該使用擴(kuò)展的方式添加新的代碼功能。

如果要停用某個(gè)接口，必須添加注解。示例：@Deprecated

這類問題就可以避免了。

許多開發(fā)人員并沒有養(yǎng)成高效的工作習(xí)慣。每天第一時(shí)間處理什么任務(wù)？接到任務(wù)后第一時(shí)間處理什么？下班之前哪些事項(xiàng)必須收尾？每個(gè)人在動(dòng)手開動(dòng)這一切時(shí)，指導(dǎo)他的，是他過去的經(jīng)驗(yàn)、習(xí)慣和思維方式，而不是在某個(gè)會(huì)議上突然聽到的聲音。把具體的工作步驟成文，并輔導(dǎo)團(tuán)隊(duì)逐步形成習(xí)慣，結(jié)合績效對過程標(biāo)準(zhǔn)的考核，才能杜絕頻繁返工、銜接不暢的浪費(fèi)。每個(gè)10人左右的小團(tuán)隊(duì)內(nèi)，一定要有人單對單的輔導(dǎo)，這就是公司作為一個(gè)有效的組織，而非一群人的關(guān)鍵原因。許多技術(shù)人員的關(guān)注點(diǎn)在于系統(tǒng)，而未關(guān)注到系統(tǒng)開發(fā)的過程，而這個(gè)過程中，最本質(zhì)的就是人的行為，造成了研發(fā)效能的根本影響。

場量科技是一家專注于產(chǎn)品創(chuàng)新與效能優(yōu)化的平臺(tái)服務(wù)商，我們基于十余年的知名企業(yè)咨詢經(jīng)驗(yàn)，圍繞產(chǎn)品創(chuàng)新提供工具與數(shù)據(jù)交易平臺(tái)，并幫助企業(yè)優(yōu)化產(chǎn)品研發(fā)效能。