談 Jira priority 的不足與 FMEA

Introducing FMEA and SOD

Jira 是目前市面上最多人用的軟體專案管理系統,Jira 的工作流程是以「敏捷」為主,所謂的敏捷是一種軟體開發的流派或理論,敏捷的主要精神是快速迭代,在搭建出可用的 MVP 後就推出市場,一方面大幅縮短 time to market 時間,一方面藉由 MVP 驗證市場反應與取得用戶回饋,再以這些資訊對 MVP 進行下一輪的改版,如此往復的迭代著。

敏捷的迭代流程其實也是持續改善的精神,與既有的 PDCA 相當類似,不過個人認為,PDCA 的 Plan 更追求於建構完完整整的計畫,不具有 MVP 的概念。

回頭說 Jira,Jira 專案是由無數張的工卡構成,可以把工卡理解成便利貼,工卡可以代表一項工作、一個問題、一個 bug、一項測試,或者由它們組成的一個群組。

施工人員(簡稱工人)在處理工卡時,一般都是依照工卡的 priority 來決定施工的順序,因此建立工卡時,除了工卡身的粒度大小與可實現性外,如何適當的認定一張工卡的優先度也對專案施工有著決定性的影響,因為回到敏捷或持續改善的觀點來看,改善需求是無限的,因此工卡也會是無限的,但資源(人力、時間、金錢)卻是有限的,因此低優先度的工卡往往會被累積然後忽略。(除非因為某些新因素的影響而使低優先度的工卡提高優先度,但往往低優先度工卡早就被遺忘在工卡堆內而又另開一張重複的高優先度的工卡,不過這是另外一個話題了。)

優先度

前面提到施工的順序會依照優先度來排序,然而很少有人認真去探究優先度本身該如何決定,不論是 Jira 的文件或是其它第三方文章都未有深入探究,彷彿優先度的認定是人類天生的本能似的,特別是在軟體產業,自從敏捷被拱上神壇之後幾乎成為不可質疑的標準(關於敏捷與商業流程如何的脫節與不相容又是另一個話題了。),Jira 也跟著雞犬升天成為實施敏捷開發的不可質疑的一部分。(Jira 本身的 UX 就是很大的問題,在 UX 當道的時代竟然大家對 Jira 的容忍度這麼高令我很訝異。)

再把話題拉回來,一般的團隊會把 Jira 的優先度設成三到五級,看似很直覺,P0 ~ P5,嚴重到輕微,但若深入思考,什麼應該是嚴重?什麼應該是輕微?

試想下面的案例:

  1. 某個日記 app 儲存超過六萬個字 buffer 會爆掉,講嚴重一點好了,手機會爆炸。試問優先度如何?
  2. 日記 app 的 Twitter 登入功能壞掉,試問優先度如何?

在上面的兩個例子,用不同的觀點看會得到截然不同的優先度,如果用保護生命財產的觀點看,案例一顯然是超嚴重的嚴重;如果是用影響用戶體驗的觀點看,案例一顯然微不足道(誰一篇日記會寫到六萬字?),反而是案例二更加優先。

當然每個人心中都有一把尺,但如何讓優先度的認定盡量站在更一致的基準上,顯然 Jira 沒有考慮到,而且因為 Jira 的不可質疑,也沒人提出過「這樣真的可以嗎?」的疑問。

如何用更嚴謹的基準認定優先度?在此為您介紹 FMEA。

FMEA

在說 FMEA 前先介紹本人以往從事的汽車產業,汽車產業供應鏈以最末端的品牌為主體,品牌(TOYOTA、BMW、Tesla 等)在汽車供應鏈體系稱為中心廠,中心廠決定大部分的零組件規格,並向協力廠下單。

因為汽車必須受到政府特殊的安全監管,也就是汽車如果上市後發現零組件缺陷,政府可以要求中心廠召回維修,一旦發生就會造成巨大的成本支出,如果未召回導致消費者死傷,需要負擔更龐大的集體訴訟賠償,所以中心廠會極力的避免任何有缺陷的零組件進入組裝,具體的手段就是透過各大車廠與學界組織成立的 IATF 16949 管理標準來規範協力廠的一切流程。IATF 16949 可以視為 ISO 9001 的擴充,它規範的不僅是品質,包括營業、研發、製造、管理、財會都在 IATF 16949 的規範內被管控(其實 ISO 9001 也越管越寬了),並且追朔三層供應鏈,也就是中心廠會稽核到協力廠的供應商的供應商。

為了符合汽車對安全品質的追求,以及避免後續的召回成本,在認定產品問題與與缺陷方面,汽車產業採用了更嚴謹的系統來判定問題的「優先度」,這樣的問題評斷系統就是 FMEA

FMEA,即 failure mode and effects analysis,中文叫「失效模式與影響分析」,聽起來很高大上,其實就是判定問題優先度的一套規範系統,FMEA 在判定問題的優先度上採用了積分制的 RPN 指標來決定,RPN 即風險優先級數(risk priority numbers),為以下三項參數的乘積(即 RPN = S * O * D):

  • Severity,嚴重度,一項功能或特性失效影響的嚴重度。
  • Occurrence,發生度,一項功能或特性失效發生的頻度。
  • Detection,檢知度,一項功能或特性失效被檢測出的難度。

在汽車產業 SOD 的給分是有具體的表格可以參考的,不過因為都是以汽車產業為出發點的描述,就不收錄了。

借鑒汽車產業對於問題優先度的評判系統,我們可以用更加一致的標準看待上面兩個案例:

  • 案例一:嚴重度 10(很嚴重)、發生度 3(不太會發生)、檢知度 2(buffer 能吃多少應該是已知的並且被定義被納入測試的),RPN = 10 * 3 * 2 = 60。
  • 案例二:嚴重度 2(Twitter 台灣沒人用且可以用其它方式登入)、發生度 6(一按就壞)、檢知度 1(一定會被測到),RPN = 2 * 6 * 1 = 12。

註:最新版的 FMEA 規範把 RPN 指數取消,改採分級制,可參閱〈對於新版FMEA所應有的認知〉,不過以 SOD 為基礎來決定優先度還是不變的。

結語

雖然敏捷和 Jira 都被拱上神壇,聽起來又很潮,不過對於優先度的認定標準上,顯然不及陳年的 FMEA 嚴謹與系統化,當然,目前資訊產業是顯學,不可能把這麼潮的敏捷的 Jira 去套那陳年的 FMEA 原則,FMEA 也不是一夜之間就發展出來的,中間也是經歷了幾十年的歷史教訓後才發展出全汽車產業共通的規範,同樣的歷史也大概會重演在軟體產業上,希望 Tesla 能把更嚴謹的管理體系導入我們潮潮的軟體產業。

還有一個在軟體產業令我難以接受的點—在任何在乎品質的製造業都聽過「品質是習慣出來的」,然而在軟體業卻還停留在「品質是檢驗出來的」這樣的落伍思維,這點以後會再專文吐嘈。