建站
咨詢
售后
建站咨詢
新聞中心
衡量技術(shù)團(tuán)隊(duì)的效能，是不是只要擺出一堆數(shù)字指標(biāo)就行?對(duì)交付價(jià)值的定義，通常有哪些誤區(qū)?好的量化指標(biāo)，一定會(huì)帶來好的結(jié)果嗎?本文從定義、衡量交付價(jià)值、研發(fā)成本、交付時(shí)長以及細(xì)化指標(biāo)四個(gè)方面，分享如何量化效能。
成都創(chuàng)新互聯(lián)專注于馬邊彝族企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,商城網(wǎng)站開發(fā)。馬邊彝族網(wǎng)站建設(shè)公司,為馬邊彝族等地區(qū)提供建站服務(wù)。全流程定制網(wǎng)站設(shè)計(jì)，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，成都創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)
一 背景
項(xiàng)目管理的理論有很多，但大多是從理念和方法論的角度出發(fā)。當(dāng)在一個(gè)團(tuán)隊(duì)推行項(xiàng)目管理的某種實(shí)踐的時(shí)候，不免被挑戰(zhàn)的一個(gè)問題：“如何衡量技術(shù)團(tuán)隊(duì)的效能”。于是不得不試圖去把邏輯題轉(zhuǎn)成數(shù)學(xué)題，用數(shù)字指標(biāo)去證明一些“不證自明”的方法論。
但如果我們只是擺出一些指標(biāo)，不可避免地會(huì)陷入“上有政策、下有對(duì)策”的循環(huán)(只要不加其他約束，數(shù)字還不是想怎么優(yōu)化怎么優(yōu)化)。我們也應(yīng)該能看到這些數(shù)字背后，需要堅(jiān)持的一些原則，和需要遵守的一些硬性標(biāo)準(zhǔn)。
假設(shè)目標(biāo)是提高技術(shù)團(tuán)隊(duì)的效能，會(huì)得到如下OKR(Objectives and Key Results，目標(biāo)與關(guān)鍵成果法)：
O：
- 提高技術(shù)團(tuán)隊(duì)的效能
KR：
- 增加總的價(jià)值交付率和交付質(zhì)量
- 增加單位研發(fā)成本的平均交付價(jià)值
- 降低單位價(jià)值的平均交付時(shí)長
本篇側(cè)重點(diǎn)在如何量化，而不是如何提高。所以接下來繼續(xù)分解，我們要做的事情就是：
- 定義、衡量交付價(jià)值
- 定義、衡量研發(fā)成本
- 定義、衡量交付時(shí)長
- 細(xì)化指標(biāo)
二 如何定義交付價(jià)值?
1 這里可能會(huì)存在兩個(gè)誤區(qū)
誤區(qū)1：交付的價(jià)值就是產(chǎn)出的方案、代碼的數(shù)量和質(zhì)量
這樣衡量交付價(jià)值，就很少有人愿意建設(shè)公共設(shè)施了(因?yàn)橘|(zhì)量好不好很難量化，建設(shè)公共設(shè)施初期的耗時(shí)往往明顯大于直接完成業(yè)務(wù)需求)，也很少有人愿意使用公共設(shè)施(因?yàn)橛脛e人的，不如自己建，還能拿個(gè)結(jié)果)。而對(duì)于技術(shù)團(tuán)隊(duì)，長期創(chuàng)造價(jià)值的能力，離不開公共設(shè)施的完備和對(duì)公共設(shè)施的使用。
誤區(qū)2：交付的價(jià)值就是業(yè)務(wù)KPI中指標(biāo)的增量
有很多功能并不帶來直接的增量，或者比較難以衡量，但可能帶來公司的競爭壁壘，如產(chǎn)品的體驗(yàn)。這樣衡量交付價(jià)值，帶來的問題就是，大家都只關(guān)注短平快的增量功能(比如營銷)，最終產(chǎn)品的競爭力下降。
2 我目前的答案：交付價(jià)值是需求背后的客戶價(jià)值
不完全是技術(shù)方案、代碼的數(shù)量和質(zhì)量，也不完全是KPI指標(biāo)的增量。交付價(jià)值就是按照用戶的需要，對(duì)用戶提供的整個(gè)產(chǎn)品、服務(wù)的數(shù)量和質(zhì)量。這個(gè)定義幾乎是不證自明的，但是把交付價(jià)值定義為客戶價(jià)值，會(huì)不會(huì)讓這件事情更加復(fù)雜，變得更加不可能量化?這就需要我們轉(zhuǎn)變一下思路，通過按照優(yōu)先級(jí)加權(quán)的需求的工作量來衡量。
按照優(yōu)先級(jí)加權(quán)的需求的工作量代表著客戶價(jià)值，這里做一些基本假設(shè)(假設(shè)不成立的場景可以作為另外的問題解決)。
假設(shè)1：技術(shù)的上游(一般是業(yè)務(wù)、產(chǎn)品)對(duì)于客戶價(jià)值的判斷是基本準(zhǔn)確的
我們知道業(yè)務(wù)是會(huì)試錯(cuò)的，給業(yè)務(wù)小成本試錯(cuò)的機(jī)會(huì)、在業(yè)務(wù)試錯(cuò)的過程中沉淀一些通用的產(chǎn)品技術(shù)能力，往往不是局部最優(yōu)，但是全局最優(yōu)。
假設(shè)2：技術(shù)的上游會(huì)按照客戶價(jià)值推演出優(yōu)先級(jí)然后給技術(shù)提需求
假設(shè)3：技術(shù)的上游提給技術(shù)的需求是充分的(不存在業(yè)務(wù)產(chǎn)品人員配置的缺失而導(dǎo)致需求質(zhì)量數(shù)量不足的情況)
基于這幾個(gè)假設(shè)，上游提出的需求可能就很大程度上代表著客戶價(jià)值，研發(fā)在非功能性需求方面對(duì)上游的需求做補(bǔ)充。
三 衡量交付價(jià)值
交付價(jià)值有個(gè)非常主觀但有效的衡量方式，是上游(一般是產(chǎn)品業(yè)務(wù))的滿意度。背后的邏輯是，交付價(jià)值(背后代表的客戶價(jià)值)往往很難量化，而產(chǎn)品業(yè)務(wù)的滿意度，體現(xiàn)了技術(shù)與業(yè)務(wù)是否很好的協(xié)同，也反映了技術(shù)是否很好的交付價(jià)值。
需求的工作量不應(yīng)該通過人日來評(píng)估，因?yàn)椴煌瑘F(tuán)隊(duì)，對(duì)于相同功能點(diǎn)的開發(fā)時(shí)長是不同的。需求的工作量的單位應(yīng)該是分解到最后的功能點(diǎn)數(shù)量。再細(xì)化一些，對(duì)于服務(wù)端是領(lǐng)域模型、領(lǐng)域服務(wù)數(shù)量，流程分支節(jié)點(diǎn)數(shù)量，對(duì)于前端、交互我不是很了解，但偏展示層可能更多的是頁面區(qū)塊、交互流程、行動(dòng)點(diǎn)的數(shù)量。這些已經(jīng)有量化的可能性了。
四 定義、衡量研發(fā)成本
研發(fā)成本，在一般的工程效能里面有時(shí)候會(huì)被簡單的理解為人日，單純的交付人日的衡量，其實(shí)比較簡單，整個(gè)團(tuán)隊(duì)的 人數(shù)*工作天數(shù)。但容易被流程設(shè)計(jì)者忽視的是，站在企業(yè)成本的視角，交付人日，可能還要按照開發(fā)人員的收入進(jìn)行加權(quán)。從這個(gè)角度來看，技術(shù)團(tuán)隊(duì)效能里面的研發(fā)成本，準(zhǔn)確的來說就是公司對(duì)于研發(fā)的金錢投入，包括購買服務(wù)器、云服務(wù)、培訓(xùn)、行政投入。
這部分對(duì)于提升效能的啟發(fā)是：
- 哪些功能自研、哪些功能靠購買，有時(shí)候真的得算一筆帳。
- 軟件開發(fā)是一個(gè)邊際成本遞減的行業(yè)，如何讓功能更簡單的得到復(fù)用，可能是對(duì)效能提升最有幫助的部分之一(復(fù)用50個(gè)人日的功能模塊，就幾乎等于省了50人日的研發(fā)成本。當(dāng)然也可能存在復(fù)用及后期維護(hù)的成本大于新建成本的情況，需要有良好的設(shè)計(jì)去規(guī)避)。
五 定義交付時(shí)長
我自己之前曾經(jīng)陷入一個(gè)誤區(qū)，認(rèn)為交付時(shí)長就是從開始開發(fā)，到完成上線，這個(gè)就是交付時(shí)長。但是回到客戶價(jià)值這個(gè)維度來思考，技術(shù)團(tuán)隊(duì)交付時(shí)長(這個(gè)時(shí)候可能說產(chǎn)研團(tuán)隊(duì)更合適一些)，應(yīng)該是從業(yè)務(wù)的一個(gè)想法，到驗(yàn)證、立項(xiàng)、完成發(fā)布、灰度，到最終用戶可以真正使用的時(shí)長。
于是單位價(jià)值的平均交付時(shí)長，就變成了以下公式：
六 如何衡量交付時(shí)長
衡量交付時(shí)長其實(shí)也比較簡單，記錄下業(yè)務(wù)提出該功能的時(shí)間以及功能開發(fā)的時(shí)間。難點(diǎn)可能是整個(gè)價(jià)值流交付過程中細(xì)化的指標(biāo)，而細(xì)化的指標(biāo)更能幫助我們發(fā)現(xiàn)問題。于是我們可以從一般項(xiàng)目的生命周期來看，哪些節(jié)點(diǎn)的時(shí)長會(huì)影響我們的交付：
- 需求立項(xiàng)到評(píng)審的時(shí)長
- 需求評(píng)審到技術(shù)方案評(píng)審的時(shí)長(如果項(xiàng)目很大可能會(huì)有多個(gè)層次的設(shè)計(jì)方案)
- 技術(shù)方案評(píng)審?fù)瓿傻介_發(fā)完成自測的時(shí)長
- 自測的時(shí)長
- 多端聯(lián)調(diào)的時(shí)長
- 測試的時(shí)長
- bug驗(yàn)證的時(shí)長，bug的數(shù)量(reopen可以數(shù)量+1)
- 環(huán)境部署等待的時(shí)長
- 代碼合并的時(shí)長(主干發(fā)布的情況下)
- 回歸的時(shí)長
- 發(fā)布的時(shí)長
- 灰度的時(shí)長
這部分對(duì)于提升效能容易忽視或有啟發(fā)的點(diǎn)是：
- 需求的拆分成基本的功能閉環(huán)進(jìn)行迭代(以不引入或少引入測試的重復(fù)回歸為標(biāo)準(zhǔn))，或許能比較有效的降低需求價(jià)值量的平均交付時(shí)長。
- 自測充分、減少bug數(shù)量，最終減少聯(lián)調(diào)、測試回歸的次數(shù)和時(shí)長，在一定的單測覆蓋率要求以前，是收益大于成本的。
- 代碼合并有時(shí)候沖突解決很麻煩，會(huì)導(dǎo)致一次部署的時(shí)間很長，且代碼合并引入了更多次的測試回歸工作(這可能是某些BU往主干開發(fā)分支發(fā)布走的原因之一)。所以基于業(yè)務(wù)的理解，進(jìn)行應(yīng)用的拆分，減少單個(gè)應(yīng)用的并發(fā)數(shù)量，也可以提升研發(fā)效能。
- 在缺乏有效的項(xiàng)目管理的情況下，資源的相互等待可能是項(xiàng)目延期的一大因素，有時(shí)候某端開發(fā)完了，另一端資源沒到位，一直不能聯(lián)調(diào)提測。項(xiàng)目管理的同學(xué)對(duì)于資源目前的分工和瓶頸應(yīng)該給上游及時(shí)的反饋。
容易陷入誤區(qū)的點(diǎn)是：
- 技術(shù)方案(架構(gòu)、詳細(xì)設(shè)計(jì))的評(píng)審既然是很大的一塊耗時(shí)，是不是可以直接寫代碼，少寫方案。我理解在技術(shù)方案寫不熟練的情況下，寫技術(shù)方案確實(shí)比較耗時(shí)。但是技術(shù)方案體現(xiàn)的是分析設(shè)計(jì)的過程和結(jié)果，這部分如果不寫出來，增加的是大量的溝通成本。而分析設(shè)計(jì)就算不寫出來，這部分工作量在編寫代碼的時(shí)候也是沒辦法省略掉的，只是變成了在大腦中進(jìn)行(也許在大腦中真的不如在紙上寫出來來的快和清晰，真的省略了設(shè)計(jì)，最終就會(huì)成為技術(shù)負(fù)債)。我個(gè)人感覺對(duì)于多大的需求需要技術(shù)方案評(píng)審的比較好的實(shí)踐，是以Code Review能否不基于技術(shù)方案直接閱讀代碼為準(zhǔn)。
七 最后
但我仍然認(rèn)為，好的量化的指標(biāo)往往是好的結(jié)果的必要不充分條件。簡單粗暴的優(yōu)化某項(xiàng)指標(biāo)往往會(huì)因?yàn)閮蓚€(gè)問題而使得最終的結(jié)果背道而馳：
某項(xiàng)指標(biāo)變好，帶來的是其他指標(biāo)的降低，局部最優(yōu)并非全局最優(yōu)(如：取消技術(shù)方案的編寫和評(píng)審，造成的是編碼時(shí)間或者后期維護(hù)時(shí)間的增加)。
效能是多個(gè)變量共同作用的結(jié)果，缺乏理論基礎(chǔ)和方法論的情況下，很可能在短期優(yōu)化指標(biāo)的時(shí)候，忽略了長期的團(tuán)隊(duì)成長、系統(tǒng)能力沉淀等因素;或是忽視了業(yè)務(wù)方滿意度等難以量化的因素。
所以，效能的優(yōu)化，不止應(yīng)該有指標(biāo)，還應(yīng)該有路徑，而路徑往往是最難的部分。
文章題目：如何量化技術(shù)團(tuán)隊(duì)的效能？
網(wǎng)站路徑：http://m.5511xx.com/article/cdpdpgd.html
