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