給產品經理的提示：將產品待辦事項與產品願景聯繫起來

基於產品的敏捷開發團隊面臨的持續挑戰之一是將他們“現在”正在做的事情映射到產品應該在 2-3 年後實現的目標。

這不是因為團隊不知道他們在做什麼，而是更多地是因為他們可能過於專注於他們的日常任務，總是會削弱他們“當前”工作在大局中影響的敏感性。 今天在執行過程中做出的決定或選擇可能會對未來產生重大影響，尤其是在產品不斷發展的時候。

讓我們舉一個現實生活中的例子。

我是敏捷團隊的一員，該團隊正試圖為網站內容引入文本翻譯服務。 做出了決定，並使用了第三方機器翻譯工具。 然而，產品路線圖最終提到，在未來，用戶應該能夠糾正並提供自己的上下文翻譯，這意味著翻譯能力應該具有人工智能，以便它可以根據反饋自行學習。
鑑於這種發展，做出的選擇並不恰當，因此需要進行相當程度的返工，因為大局與敏捷團隊在衝刺中的任務無關。

有人可能會爭辯說，團隊可以有意識地努力獲取這些信息，但關鍵是為什麼不能在現有的敏捷工具和儀表板中捕捉這些“長期”目標？

敏捷團隊在開發週期中執行定義明確的特定任務，但這是否意味著它必須以對產品進化漠不關心為代價？ 不，我不這麼認為。

據我所知，在敏捷團隊的日常運作中，沒有快速的工具或框架可以向敏捷團隊提倡或推薦這些信息，但是這樣的視圖可以在現有視圖中創建嗎？ 值得一試？ 讓我們看看我們該怎麼做。

我們將從敏捷中最常見的工件——產品待辦列表開始。
根據 SCRUM 研究所，產品 backlog 是項目中需要完成的事情的列表。 這些東西可以包括增強和/或錯誤。 除非團隊知道項目的優先級結構是什麼，否則編號列表沒有幫助。 這就是產品負責人介入的地方，他全面負責與利益相關者合作以獲得明確的需求，解決相互依賴關係，並獲得產品積壓項目的優先列表。

在這個過程中，一個更大的、依賴的工作項可能會被進一步分解成小部分，以便於團隊開發。 這些產品待辦事項被分解成更小的塊，並在 2 到 4 週的 sprint 週期內執行，回答了產品開發的“如何”部分。

另一方面，產品積壓項目也映射到產品的“正北” ，通常被稱為產品願景。 這是產品的理想狀態，通常通過多個版本發布來實現，並與目標受眾或客戶的需求及其為他們帶來的價值密切相關。

將敏捷團隊與客戶（包括產品待辦事項和願景）聯繫起來的這個元素鏈可以表示為：

敏捷團隊與客戶需求之間的遙遠聯繫……

由於缺乏將 sprint 與產品願景明確聯繫起來的觀點，產品負責人經常會面臨風險，他們過於關注“如何”部分，而忽略了“什麼”的更大而重要的目標，這可能會導致被誤導的優先級。

我在這裡討論的方法是創建一個簡單而強大的視圖來鏈接這兩個組件。 這被稱為產品視覺矩陣（PVM）。 目標是將產品的願景與細化的開發項目聯繫起來。 該矩陣成為分析團隊在產品開發方面的進展的關鍵因素。 它還用作組織高級管理人員的產品儀表板，並讓他們了解產品目標的可實現性。

顧名思義，PVM 是一個矩陣，其中的列代表正在捕獲的維度（從微觀到宏觀）。 讓我們藉助一個食品訂購應用程序來理解 PVM，其願景是為用戶提供食品體驗，起點是食品訂購。 示例矩陣如下所示：

產品願景矩陣可以包含以下字段：

• 產品版本：這是正式發布里程碑的產品版本，通常是客戶收到的。
• Big Rock Item：這也是某個功能所屬的類別或主題。 這些項目也可以是產品願景的長期產品需求領域。
• 功能：這是正在開發的產品功能。 該功能可以屬於一個或多個主題（大搖滾項目）。
• Sprint ID：這是正在開發功能的 sprint 編號。
• 開發狀態：該字段表示開發的進度（計劃、設計完成、開發完成、測試和發布）。

請注意，矩陣的結構在這裡是指示性的。 在確定可以捕捉產品願景的列時，可以更有創意。

這種方法的優點是每個團隊成員對整體產品目標的清晰可見性。 對於不斷發展的產品，團隊成員應該對大局有更好的理解。 這不僅使他們能夠有效地做出貢獻，而且使他們能夠承擔更多的責任。 結果是一個更加專注和適應性強的團隊，他們始終關注客戶的脈搏，並認識到他們的衝刺可以為產品的願景和最終成功做出貢獻。

從世界頂級大學在線學習產品管理課程。 獲得碩士、Executive PGP 或高級證書課程以加快您的職業生涯。

為您推薦的特色課程：杜克 CE 的設計思維認證課程