第 20 章：現形探索的考量

昨天聊到交付的視野，像是一個要交付項目的佇列清單，依照遠近用不同的方式去呈現。在進行產品開發時，若要在短期內提升單位時間交付價值的量，首先就是改善開發流動的順暢度會是最有效益的。但隨著隨著交付的狀況越穩定，就會像昨天聊到交付的視野，依照遠近用不同的方式去呈現一個要交付項目的佇列清單，開始討論價值與排序，讓價值高的先做，價值低的應該往下放甚至捨棄。但若這邊的實踐也逐漸穩定時，就越該把視線放在需求到底怎麼進到這個佇列清單的。

這三個階段就像是下圖從右到左的部分。最右邊是交付的流暢度，用看板與代表目標的箭靶的概念去示意；中間的排序與精練的過程，用列表式的 Product Backlog 來示意；左邊的則是需求與想法的篩選，用一個漏斗搭配不同的濾鏡來呈現。今天要來聊的就是最左邊漏斗的部分。

我們想要建造的東西總是超過我們擁有的時間或資源——屢試不爽
——《使用者故是對照》

產品的需求來自四面八方、永無止盡，若是永遠照單全收，那麼光是權衡所有項目的排序，就可以像是黑洞一樣把團隊（或至少是 Product Owner）的時間吃光。所以並不是每個需求都會進到排序等待交付的清單裡，有些是收到時直接仍了，有些是提出時間過久已經沒有意義，有些是跟今年度目標與策略無關，所以先封存再說。

這些篩選掉的種種考量，原本可能都只潛藏在管理層或者 Product Onwer 的腦袋裡，開發團隊只管按照要交付的佇列去開發。對團隊來說，會對產品相對沒有認同感，不知道自己在為怎樣的客群打造怎樣的產品，也可能對於公司為什麼現在要自己開發這些項目不了解，甚至不諒解。

然而，通常第一線打造產品的人，才會是最能判斷產品好用與否的一群人。因為在打造過程，他們會不斷地使用、打磨，如果這時候能讓樣的一群人，了解篩選想法背後的考量，了解產品的發展方向，都可能在他們與產品的接觸過程中，蹦出更適合的想法。也可以提供他們的觀點與視角，去補充篩選的考量豐富度。

當探索這些想法、並進行篩選的種種考量，透過某些形式挖出來後，並逐漸擴散到團隊後，Product Owner 與團隊會逐漸在同一戰線，而且 Product Owner 會有戰友幫忙去檢視，不再是壓力全壓在身上，反而無法專心做好排序的判斷。

而昨天依靠的是各種方式，擴大視野將價值與排序的考量給挖了出來，今天就來分享可以透過什麼方式協助現形探索與篩選背後的考量，又可以怎麼透過工具實作出來。

Product Roadmap

這類現形方式，廣為人知的或許就是 Product Roadmap 了吧！它將產品從願景到目標，從目標到策略，再從策略到數個史詩級項目給串連起來，而願景包含了某些客群的渴望，策略則對應到了市場的現況，史詩級項目則是應對現況的解決方案，這些背後的資訊都是幫助產品方向的決策者，知道現在該聚焦什麼的濾鏡。

筆者會用 Miro 去呈現簡化版的 Product Roadmap，乍看之下有點像是 Release Plan 更大時間維度的版本，但去看待這些事情的視野也會更高，看得沒那麼細，整體的輪廓反而更清晰。

不只是呈現策略與史詩級項目的關係，也會將相關數字或背景故事給羅列出來。比如說怎麼驗證我們達成策略？是有什麼樣的效果展現？會使用這個策略背後的故事又是什麼？

若想知道 Product Roadmap 更詳盡的介紹，可以參考《產品路線圖：從革新到蛻變》一書。這邊也推薦可以參照 《OGSM打造高敏捷團隊》一書。

定期去整理 Product Backlog

另外一個好的方式就是定期與 Product Owner 整理 Product Backlog，這邊說的整理其實就是砍掉不再需要的 PBI，讓 Product Backlog 的數量能為持再一個能夠聚焦、排序也不會太難的程度。

透過一個個 PBI 去討論要不要刪除，可以去揭露篩選背後的考量是什麼。

但通常做這件事情時，總會有一個阻礙是擔心刪掉的 PBI 日後可能還可以參照一些資訊。筆者這邊的做法是在專案管理工具中，新增一個狀態叫做 “Discard” 或是 “Abandoned”，當要篩選這些 PBI 時就改成這類狀態，當作完成，這樣就可以盡情地以產品當前需要什麼的考量去討論了。