最近與某互聯(lián)網(wǎng)公司架構(gòu)師討論了研發(fā)效能中的問(wèn)題，整理分享如下。
有許多評(píng)估團(tuán)隊(duì)產(chǎn)出的辦法，比如代碼行、功能點(diǎn)、故事點(diǎn)和故事卡數(shù)量，這種度量方式不僅存在偏差，而且是一種非常局部的度量方式，現(xiàn)在都已不再適用。更有許多研發(fā)團(tuán)隊(duì)存在著這種情況，開(kāi)發(fā)編碼的效率很高，測(cè)試和部署工作量大，成為瓶頸，或者需求澄清和排程的時(shí)間長(zhǎng)，壓縮了開(kāi)發(fā)時(shí)間，無(wú)法詳細(xì)地設(shè)計(jì)和驗(yàn)證，質(zhì)量下滑拖累了效率。從而導(dǎo)致最后效能問(wèn)題“每天工作投入度和響應(yīng)上，自己感知已經(jīng)夠快了，業(yè)務(wù)還說(shuō)我們慢，原因在哪里我也說(shuō)不清楚”。
這里的關(guān)鍵點(diǎn)在于，效能為誰(shuí)度量，即以誰(shuí)的視角來(lái)看待效能？由于研發(fā)最終的目標(biāo)是交付到業(yè)務(wù)，那效能最終面對(duì)的還是業(yè)務(wù)視角。
很多時(shí)候業(yè)務(wù)感知的“慢”，在于需求的端到端交付周期過(guò)長(zhǎng)，也在于過(guò)程的信息不透明?！耙粋€(gè)小需求，也要那么久才能上線(xiàn)！”而開(kāi)發(fā)感知到的是，需求的評(píng)估、排程和跨組/團(tuán)隊(duì)協(xié)同過(guò)程太耗時(shí)了，是因?yàn)樵谶@個(gè)過(guò)程中等待太久，才導(dǎo)致周期拉得很長(zhǎng)。
一個(gè)需求從提出到發(fā)布，通常會(huì)經(jīng)過(guò)分析、澄清、計(jì)劃、設(shè)計(jì)、開(kāi)發(fā)、測(cè)試、部署到正式發(fā)布幾個(gè)階段。
那么在各個(gè)環(huán)節(jié)中，究竟多長(zhǎng)時(shí)間是合適的呢？精益思想給出了一個(gè)度量方法，就是最小積壓，理想狀態(tài)下是做到零庫(kù)存，即沒(méi)有需求積壓。如果業(yè)務(wù)持續(xù)不斷地接收到產(chǎn)出物，同時(shí)看到新需求不斷進(jìn)入處理過(guò)程，就很難感知到“很慢”了。
舉個(gè)例子，同樣是等，在星巴克你能看到你的杯子正在什么位置，咖啡師正在準(zhǔn)備什么；外賣(mài)下單后，你能看到騎手的位置和狀態(tài)，就能緩解等待的焦慮。而在研發(fā)過(guò)程中，因?yàn)樾畔⒉煌该鲙?lái)的需要同步的“會(huì)議”實(shí)在是太多了。
近些年我們推崇的是使用時(shí)間來(lái)度量效能，并且在數(shù)個(gè)咨詢(xún)項(xiàng)目上通過(guò)這種度量方式驅(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天。又被稱(chēng)為需求端到端交付周期。
Cycle Time（周期時(shí)間）：研發(fā)內(nèi)部效能的重要指示燈，是指開(kāi)發(fā)團(tuán)隊(duì)接受需求到交付業(yè)務(wù)驗(yàn)收的時(shí)間間隔（自然日），覆蓋了分析、設(shè)計(jì)、編碼、測(cè)試及修復(fù)缺陷的時(shí)間。通常也稱(chēng)之為交付周期。
Takt Time（節(jié)拍時(shí)間）：研發(fā)節(jié)奏制定的重要參考值，是指開(kāi)發(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í)間，那又如何來(lái)說(shuō)明效能呢？
前面提到精益給出的度量標(biāo)準(zhǔn)，即最小積壓。在交付的各個(gè)環(huán)節(jié)中等待的任務(wù)，都是積壓，即是浪費(fèi)。對(duì)研發(fā)中的浪費(fèi)，我們?cè)O(shè)定在計(jì)劃啟動(dòng)之后進(jìn)行統(tǒng)計(jì)，并分類(lèi)原因：
根據(jù)大量的咨詢(xún)經(jīng)驗(yàn)，許多效能問(wèn)題，只需要消除浪費(fèi)就能夠顯著地提升，這個(gè)提升比率最低在40%，最高在89%；一些跨團(tuán)隊(duì)協(xié)作的痛點(diǎn)，僅僅通過(guò)統(tǒng)一拆分任務(wù)和計(jì)劃方式，就將協(xié)同任務(wù)的節(jié)拍時(shí)間下降了40%之多。
推行敏捷最重要的就是帶給大家一種全新的工作方式：從一種自上而下領(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ù)和用戶(hù)的視角理解需求，了解業(yè)務(wù)價(jià)值、使用者和痛點(diǎn)，而不僅僅是功能說(shuō)明清單。
需求分解：”需求跨不跨迭代“、”需求分幾個(gè)迭代開(kāi)發(fā)完成“，也是迭代式開(kāi)發(fā)中的一個(gè)常見(jiàn)問(wèn)題。正確答案是：在敏捷開(kāi)發(fā)里，無(wú)論選擇哪類(lèi)需求載體，特性、用戶(hù)故事還是任務(wù)，都不應(yīng)該在計(jì)劃階段設(shè)定為跨迭代交付，除非迭代目標(biāo)沒(méi)達(dá)成，在評(píng)審會(huì)議上轉(zhuǎn)入下一個(gè)迭代。沒(méi)有正確的需求分解方法，是排不出正確的迭代計(jì)劃的。
任務(wù)估算：ESTIMATE翻譯為估算一直以來(lái)都被視為一種對(duì)交付時(shí)間的承諾，所以讓開(kāi)發(fā)團(tuán)隊(duì)感覺(jué)很難操作。如果用中文更準(zhǔn)確的表達(dá)應(yīng)為“評(pí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ì)劃分出來(lái)的是開(kāi)發(fā)人員的一個(gè)容量包，比如兩周的工作量，排進(jìn)一個(gè)迭代，迭代N的交付物，是測(cè)試團(tuán)隊(duì)在迭代N+1的測(cè)試版本，然后在N+1迭代中又?jǐn)D進(jìn)一些不可預(yù)測(cè)的缺陷修復(fù)工作量，最后在N+2/3迭代中發(fā)布迭代N的需求。這也是許多開(kāi)發(fā)團(tuán)隊(duì)自稱(chēng)已做到“兩周一迭代”而業(yè)務(wù)覺(jué)得沒(méi)啥變化的原因：真實(shí)的”需求迭代“應(yīng)該在六到八周左右，差不多一個(gè)半月到兩個(gè)月?？窗逵质橇硪环N工作計(jì)劃方式，需要比迭代更細(xì)致的優(yōu)先級(jí)排序，形成任務(wù)隊(duì)列。在看板上，團(tuán)隊(duì)自頂向下拉動(dòng)任務(wù)卡至交付泳道。
規(guī)矩千萬(wàn)條，最后都落墻角。工作方式大家都口頭接受了，但一執(zhí)行又全跑歪，又該怎么辦呢？
討論中架構(gòu)師談到，不止研發(fā)效能，還包括架構(gòu)和代碼質(zhì)量，都已經(jīng)制定了嚴(yán)格的標(biāo)準(zhǔn)，團(tuán)隊(duì)也接受了，但就是很難執(zhí)行，現(xiàn)在針對(duì)一個(gè)200人級(jí)別的大型重構(gòu)項(xiàng)目，不得不組建近30人的治理團(tuán)隊(duì)，負(fù)責(zé)評(píng)審代碼和接口，以避免架構(gòu)質(zhì)量走偏。
我認(rèn)為，這是一種治標(biāo)不治本的方式。結(jié)果有偏差，問(wèn)題的根源在哪里？代碼已經(jīng)不合格了，評(píng)審、退回、重做和返工都是浪費(fèi)。效能的改進(jìn)是致力于消除這種浪費(fèi)，而許多技術(shù)型管理者關(guān)注和控制的落腳點(diǎn)在最終結(jié)果，而不是原因。有沒(méi)有親自到現(xiàn)場(chǎng)走查一下，這些不合格的代碼、接口是怎么寫(xiě)出來(lái)的呢？
許多規(guī)范只是原則，而開(kāi)發(fā)人員執(zhí)行的是操作。比如說(shuō)一個(gè)接口的設(shè)計(jì)規(guī)范明明要求：滿(mǎn)足向前兼容。但開(kāi)發(fā)出來(lái)的新版本卻把舊的功能破壞了。開(kāi)發(fā)人員很可能并不知道什么叫“向前兼容”，這些原則對(duì)并不了解它們的人來(lái)說(shuō)，根本不具備指導(dǎo)意義。如果改成：
禁止修改不熟悉的代碼，如要修改，請(qǐng)和代碼編寫(xiě)者或技術(shù)負(fù)責(zé)人溝通，并編寫(xiě)對(duì)應(yīng)的單元測(cè)試，以避免破壞系統(tǒng)功能。
禁止修改已發(fā)布的接口實(shí)現(xiàn)代碼，應(yīng)該使用擴(kuò)展的方式添加新的代碼功能。
如果要停用某個(gè)接口，必須添加注解。示例：@Deprecated
這類(lèi)問(wèn)題就可以避免了。
許多開(kāi)發(fā)人員并沒(méi)有養(yǎng)成高效的工作習(xí)慣。每天第一時(shí)間處理什么任務(wù)？接到任務(wù)后第一時(shí)間處理什么？下班之前哪些事項(xiàng)必須收尾？每個(gè)人在動(dòng)手開(kāi)動(dòng)這一切時(shí)，指導(dǎo)他的，是他過(guò)去的經(jīng)驗(yàn)、習(xí)慣和思維方式，而不是在某個(gè)會(huì)議上突然聽(tīng)到的聲音。把具體的工作步驟成文，并輔導(dǎo)團(tuán)隊(duì)逐步形成習(xí)慣，結(jié)合績(jī)效對(duì)過(guò)程標(biāo)準(zhǔn)的考核，才能杜絕頻繁返工、銜接不暢的浪費(fèi)。每個(gè)10人左右的小團(tuán)隊(duì)內(nèi)，一定要有人單對(duì)單的輔導(dǎo)，這就是公司作為一個(gè)有效的組織，而非一群人的關(guān)鍵原因。許多技術(shù)人員的關(guān)注點(diǎn)在于系統(tǒng)，而未關(guān)注到系統(tǒng)開(kāi)發(fā)的過(guò)程，而這個(gè)過(guò)程中，最本質(zhì)的就是人的行為，造成了研發(fā)效能的根本影響。
場(chǎng)量科技是一家專(zhuān)注于產(chǎn)品創(chuàng)新與效能優(yōu)化的平臺(tái)服務(wù)商，我們基于十余年的知名企業(yè)咨詢(xún)經(jīng)驗(yàn)，圍繞產(chǎn)品創(chuàng)新提供工具與數(shù)據(jù)交易平臺(tái)，并幫助企業(yè)優(yōu)化產(chǎn)品研發(fā)效能。
聯(lián)系客服
