這幾天看到不少朋友轉貼 Gipi 大大的文章
產品開發應慎防需求的長鞭效應
https://medium.com/how-gipi-learn/bullwhip-effect-in-product-development-c0b210dd22a
文中提到”有人在統計規格的bug數的嗎？產品團隊會認嗎？”
這個讓我有點感觸, 目前我遇到大多數的團隊
- 大部分測試是良心事業, 所以沒測或是測很少, 因為不會去做 Bug 統計
- 有做測試, 但是把 Bug tracking system 當作電子文件紀錄. 不做統計
- 有做統計, 但是不做分析和改善, 所以團隊之後就不在意
但是我想還是有很多主管, 或是有心的團隊成員像要改變此狀況
這邊有些做法, 可以幫忙減緩跟規格有關的bug的出現
▋在填 Bug 時候要分類
當在填寫 Bug 時, 要有個欄位: “注入階段”
內容可以是: 需求分析階段, 設計和撰寫階段, 測試階段等等
如果可以的話, 也加個欄位: “發現階段”
紀錄這個 Bug 是在哪個階段被發現的
如果有這兩個資訊, 你就可以產生如圖所示的統計, 接著你就可以做一些分析
我們在“不確定時代下的測試管理”課程中, 就會討論 Bug 的管理和統計分析
可是這都是在專案後期做的事, 但是這樣已經晚了
建議在一開始時, 思考以下作法
▋建立 Product Discovery 階段的看板
一般我們使用看板時, 都是針對 Product Delivery 階段來處理
因此, 你會看到Kanban Board 上面會有這些欄位
To Do -> Develop -> Test -> Done
但是有時候沒有效率可能是在 Product Discovery 階段
因此, 你可以在前面加上 Product Discovery的處理流程, 例如
Idea -> Review -> Epic -> Experiment -> Feature -> UX Design -> Story -> Done
一方面可以讓大家知道 Product Discovery 在做什麼, 做得是否很有效率
另一方面, 也讓開發團隊知道, PM 是有做事, 也很辛苦之類的
我們在”如何利用價值流和看板改善開發效能”課程中, 會討論要如何設計此類型看板
▋採用實例化需求的實踐
為了讓產生出來的需求,
開發團隊和 PM 是有共識, 並且了解雙方在說什麼
可以使用 Spec By Examplex來建立需求範例, 確保雙方是有共同的了解
切記, 這裡的重心是對需求有共識, 不是自己懂, 或是自動化
很多團隊就是 RD 自己很高興寫的範例的自動化, 用了 Given When Then
可是 PM or QA 沒有參與, 這樣會生出有共識的需求嗎?
我們在”如何寫出人人有共識的需求”課程中, 會手把手教大家怎麼做
產品開發本身就不是一件容易的事情
沒有一招可以解決所有問題, 你需要有不同的招式來幫忙
只要你有心, 願意開始, 事情總是會有轉機的
發表迴響