需求直通率:產(chǎn)品團(tuán)隊提升效率的一個重要績效指標(biāo)

陳加興
0 評論 9131 瀏覽 14 收藏 6 分鐘
🔗 B端产品需要更多地依赖销售团队和渠道合作来推广产品,而C端产品需要更多地利用网络营销和口碑传播来推广产品..

需求直通率這個提法,來源于制造業(yè)的精益管理體系。即一個成品經(jīng)由多道工序生產(chǎn)時,在每道工序都是一次完成,沒有返工的比率。

經(jīng)常有團(tuán)隊管理者問這樣的問題:每個人都很努力,但進(jìn)度就是控制不了,線上就是bug多;還有些團(tuán)隊說,我們對開發(fā)人員的考核是bug越少越好,對測試人員的考核是bug越多越好,導(dǎo)致開發(fā)測試天然沖突,真不合理,但又沒有更好的辦法。

這些問題的根源在哪里呢?是因為:局部效率不等于系統(tǒng)效率。

每個人都在局部努力,但組織是一個相互作用的系統(tǒng),局部優(yōu)化了,并不等于整體的系統(tǒng)得到了優(yōu)化。管理者,需要站在系統(tǒng)角度,運(yùn)用系統(tǒng)化思維來解決整體的效率問題。

本次分享一個系統(tǒng)效率的重要指標(biāo):需求直通率。

需求直通率

需求直通率這個提法,來源于制造業(yè)的精益管理體系,原有術(shù)語為“直通率(Throughput Yield,TPY)”或“產(chǎn)品直通率”。即一個成品經(jīng)由多道工序生產(chǎn)時,在每道工序都是一次完成,沒有返工的比率。TPY的英文也可表示為First Pass Yield(FPY)。

TPY/FPY = 一次通過工序的成品數(shù)量 / 總投入生產(chǎn)數(shù)量

當(dāng)有多道工序時,可用流通合格率(Rolled Throughput Yield,RPY)來表述整體質(zhì)量,即每道工序直通率的乘積:

RPY = TPY(工序一) * TPY(工序二) * TPY(工序N)

由于產(chǎn)品需求從提出到發(fā)布需要經(jīng)由多個環(huán)節(jié),需求直通率適用的計算方式為RPY。

需求直通率度量的收益

2016年,我們幫助某公司產(chǎn)品線部門進(jìn)行改進(jìn)的咨詢項目中,就首次運(yùn)用了需求直通率這一指標(biāo),最終從需求交接效率、線上缺陷和事件數(shù)量上,都實現(xiàn)了很好的改進(jìn)效果。

當(dāng)時為什么采取這一指標(biāo)呢?

就是因為該產(chǎn)品線的問題實在太多了,需求嚴(yán)重積壓,產(chǎn)品經(jīng)理壓力山大;研發(fā)團(tuán)隊不愿意接需求,認(rèn)為需求問題太多又經(jīng)常變化;測試團(tuán)隊受困于bug分析定位,因為被考核“bug轉(zhuǎn)交次數(shù)”這一指標(biāo)……

所以我們當(dāng)機(jī)立斷,建議團(tuán)隊通過“需求直通率”指標(biāo),讓QA記錄和計算每個環(huán)節(jié)的TPY:

  • 需求一次交接通過率
  • 開發(fā)一次轉(zhuǎn)測通過率
  • 測試一次轉(zhuǎn)驗收通過率
  • 線上缺陷率

需求直通率即上面幾項指標(biāo)的乘積。產(chǎn)品團(tuán)隊一開始感到“要求太高”、“不可思議”、“怎么可能做得到”、“功能哪有不改的”,我們是怎么說服團(tuán)隊接受的呢?

就是不對指標(biāo)的具體數(shù)字提任何要求。先量化,讓團(tuán)隊知道自己的現(xiàn)狀,再由團(tuán)隊自己決定改進(jìn)目標(biāo),我們提供改進(jìn)的方法。這樣一來,大大減輕了團(tuán)隊的壓力。

大家通過QA每個迭代的報告,慢慢建立起了全局的效率感知,三個月改進(jìn),最終取得了需求一次交接通過率達(dá)到60%,線上缺陷率下降40%的效果。

通過對直通率關(guān)注,開發(fā)也漸漸地不再與測試對立,主動通過測試用例來進(jìn)行防御性的檢查。

對需求管理的要求

要實現(xiàn)需求直通率的有效度量,前提是產(chǎn)品經(jīng)理能夠劃分出拉通開發(fā)測試和業(yè)務(wù)驗收的需求顆粒,大家圍繞這個需求顆粒開展協(xié)作,作為直通率的計算單元。

我們推薦的需求顆粒建立在產(chǎn)品特性上,用戶可使用、測試可測、開發(fā)可獨立完成的最小發(fā)布功能單元。

比如說,用戶注冊、登錄、找回密碼、修改密碼,可作為四個獨立的產(chǎn)品特性。

特性劃分和功能點、故事點的不同之處是,后兩者體現(xiàn)的是需求在不同環(huán)節(jié)的工作量,而非用戶視角的功能。

據(jù)我們現(xiàn)在的調(diào)研,很多公司都還未做到基于功能的開發(fā),更多是對一個大的需求文檔進(jìn)行技術(shù)設(shè)計后,分解為許多開發(fā)任務(wù)、測試任務(wù),通過開發(fā)測試計劃在內(nèi)部執(zhí)行。所以要實現(xiàn)團(tuán)隊整體效率的提升,我們推薦由產(chǎn)品經(jīng)理/BA來牽頭,從需求管理上進(jìn)行調(diào)整,建立起直通率全局觀,逐步地帶動團(tuán)隊的整體效率提升。

 

作者:陳加興,場量科技創(chuàng)始人,資深敏捷精益專家,精益企業(yè)認(rèn)證產(chǎn)品概念領(lǐng)導(dǎo)者,微信號:one-oracle。

本文由 @陳加興 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自Unsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發(fā)揮!
专题
15339人已学习13篇文章
本专题的文章分享了数据分析报告写作指南。
专题
13903人已学习12篇文章
4P指产品(Product)、定价(Price)、渠道(Place)、宣传(Promotion)。本专题的文章分享了解读4P营销理论。
专题
15053人已学习14篇文章
RBAC是一套成熟的权限模型,在传统权限模型中,我们直接把权限赋予用户。而在RBAC中,首先把权限赋予角色,再把角色赋予用户。本专题的文章分享了基于RBAC模型的权限设计。
专题
19487人已学习14篇文章
合同管理系统的建设,实现公司对合同的录入登记、审批、履约管理、监控执行、查询、统计等功能。本专题的文章分享了合同管理的设计指南。
专题
19617人已学习13篇文章
本专题分享了内容审核的设计思路。