需求的工作量不應(yīng)該通過人日來評估，因?yàn)椴煌瑘F(tuán)隊(duì)，對于相同功能點(diǎn)的開發(fā)時長是不同的。需求的工作量的單位應(yīng)該是分解到最后的功能點(diǎn)數(shù)量。再細(xì)化一些，對于服務(wù)端是領(lǐng)域模型、領(lǐng)域服務(wù)數(shù)量，流程分支節(jié)點(diǎn)數(shù)量，對于前端、交互我不是很了解，但偏展示層可能更多的是頁面區(qū)塊、交互流程、行動點(diǎn)的數(shù)量。這些已經(jīng)有量化的可能性了。
四 定義、衡量研發(fā)成本
研發(fā)成本，在一般的工程效能里面有時候會被簡單的理解為人日，單純的交付人日的衡量，其實(shí)比較簡單，整個團(tuán)隊(duì)的人數(shù)*工作天數(shù)。但容易被流程設(shè)計者忽視的是，站在企業(yè)成本的視角，交付人日，可能還要按照開發(fā)人員的收入進(jìn)行加權(quán)。從這個角度來看，技術(shù)團(tuán)隊(duì)效能里面的研發(fā)成本，準(zhǔn)確的來說就是公司對于研發(fā)的金錢投入，包括購買服務(wù)器、云服務(wù)、培訓(xùn)、行政投入。
這部分對于提升效能的啟發(fā)是：
哪些功能自研、哪些功能靠購買，有時候真的得算一筆帳。
軟件開發(fā)是一個邊際成本遞減的行業(yè)，如何讓功能更簡單的得到復(fù)用，可能是對效能提升最有幫助的部分之一（復(fù)用50個人日的功能模塊，就幾乎等于省了50人日的研發(fā)成本。當(dāng)然也可能存在復(fù)用及后期維護(hù)的成本大于新建成本的情況，需要有良好的設(shè)計去規(guī)避）。
五 定義交付時長
我自己之前曾經(jīng)陷入一個誤區(qū)，認(rèn)為交付時長就是從開始開發(fā)，到完成上線，這個就是交付時長。但是回到客戶價值這個維度來思考，技術(shù)團(tuán)隊(duì)交付時長（這個時候可能說產(chǎn)研團(tuán)隊(duì)更合適一些），應(yīng)該是從業(yè)務(wù)的一個想法，到驗(yàn)證、立項(xiàng)、完成發(fā)布、灰度，到最終用戶可以真正使用的時長。
于是單位價值的平均交付時長，就變成了以下公式：
需求的交付價值量/需求功能真正被用戶使用的時間-業(yè)務(wù)提出該功能、產(chǎn)品立項(xiàng)的時間
六 如何衡量交付時長
衡量交付時長其實(shí)也比較簡單，記錄下業(yè)務(wù)提出該功能的時間以及功能開發(fā)的時間。難點(diǎn)可能是整個價值流交付過程中細(xì)化的指標(biāo)，而細(xì)化的指標(biāo)更能幫助我們發(fā)現(xiàn)問題。于是我們可以從一般項(xiàng)目的生命周期來看，哪些節(jié)點(diǎn)的時長會影響我們的交付：
需求立項(xiàng)到評審的時長
需求評審到技術(shù)方案評審的時長（如果項(xiàng)目很大可能會有多個層次的設(shè)計方案）
技術(shù)方案評審?fù)瓿傻介_發(fā)完成自測的時長
自測的時長
多端聯(lián)調(diào)的時長
測試的時長
bug驗(yàn)證的時長，bug的數(shù)量（reopen可以數(shù)量+1）
環(huán)境部署等待的時長
代碼合并的時長（主干發(fā)布的情況下）
回歸的時長
發(fā)布的時長
灰度的時長
這部分對于提升效能容易忽視或有啟發(fā)的點(diǎn)是：
需求的拆分成基本的功能閉環(huán)進(jìn)行迭代（以不引入或少引入測試的重復(fù)回歸為標(biāo)準(zhǔn)），或許能比較有效的降低需求價值量的平均交付時長。
自測充分、減少bug數(shù)量，最終減少聯(lián)調(diào)、測試回歸的次數(shù)和時長，在一定的單測覆蓋率要求以前，是收益大于成本的。
代碼合并有時候沖突解決很麻煩，會導(dǎo)致一次部署的時間很長，且代碼合并引入了更多次的測試回歸工作（這可能是某些BU往主干開發(fā)分支發(fā)布走的原因之一）。所以基于業(yè)務(wù)的理解，進(jìn)行應(yīng)用的拆分，減少單個應(yīng)用的并發(fā)數(shù)量，也可以提升研發(fā)效能。
在缺乏有效的項(xiàng)目管理的情況下，資源的相互等待可能是項(xiàng)目延期的一大因素，有時候某端開發(fā)完了，另一端資源沒到位，一直不能聯(lián)調(diào)提測。項(xiàng)目管理的同學(xué)對于資源目前的分工和瓶頸應(yīng)該給上游及時的反饋。
容易陷入誤區(qū)的點(diǎn)是：
技術(shù)方案（架構(gòu)、詳細(xì)設(shè)計）的評審既然是很大的一塊耗時，是不是可以直接寫代碼，少寫方案。我理解在技術(shù)方案寫不熟練的情況下，寫技術(shù)