【敏捷方法】02 如何創建產品路線圖?

【敏捷方法】02 如何創建產品路線圖?

來自專欄 智能硬體產品設計

開始之前

筆者根據自身學習和實踐經歷對Scrum框架的流程做了總結,共有7篇。做這個總結的原因,一來是想梳理出一個可以幫助新人將Scrum落地執行的實踐手冊,二來是想通過分享自己的經驗引發大家的思考並指正筆者的不足本文是Scrum框架的第二篇:建立產品路線圖。

產品路線圖簡介

產品路線圖是產品需求在時間軸上的總體視圖,它是產品需求與其完成時間的概覽,可以使用產品路線圖來對需求進行分類、排定優先順序,然後確定發布時間表。產品路線圖宏觀的展示了產品的發展方向以及開發團隊何時實現目標。有效的路線圖不僅是一個強調產品發布和功能的時間表:它是一個動態的文檔,產品負責人會在項目進行過程中根據實際情況不斷更新,所以在創建產品路線圖的初期,對需求、工作量、優先順序、完成時間的估算不要求也無法很精確,這些內容都是隨著項目進行不斷細化調整的。

產品路線圖是產品負責人推動項目發展的重要工具,它告訴我們每個階段應該做什麼。在下圖中,可以看到兩個並行的產品路線圖涵蓋了12個月的開發時間範圍。產品路線圖的第一行是時間軸,第一列是項目名與版本號,版本號與時間軸的交叉點描述的是對應的版本涵蓋的功能特性。這樣就能直觀的看到,要在什麼時間做哪個版本,以及該版本所含哪些功能了。

如果產品負責人計劃在2017Q2末期啟動設計進程,那麼就在二月時知道是時候開始考慮設計所需的開銷和資源。有了這個遠見,就可以提前開始去實施這些計劃,以便資源能夠及時地準備好並保證任務的完成。簡言之,產品路線圖應該能夠讓產品負責人和項目團隊長遠地了解產品計劃,並提供關於實現這些目標和時間節點的指導。

產品路線圖分類

的服務對象可以是某個單一產品,也可以是一組產品。

單一產品路線圖

多產品路線圖

創建產品路線圖步驟

步驟1:識別分解產品需求

產品願景由許多產品特性所構成,產品的需求分為內部需求和外部需求,內部需求來自產品戰略,外部需求來自市場調研,具體方法這裡不展開討論。在產品路線圖中顯示出的需求可能存在不同的層級:主題和特性。主題是需求的邏輯上或業務流程上的分類,特性是指某一具體的功能。比如在設計工具Sketch中,編輯屬於一個邏輯上的分類,編輯就是主題。而對圖層進行放大、縮小、合併等具體功能,就屬於特性。因為放大、縮小、合併等功能從邏輯上分類都屬於對圖層進行編輯,所以特性和主題是從屬關係。總之,這一步要求產品負責人和項目團隊梳理出並確定產品需求(主題和特性),創建最初的產品代辦列表(Product Backlog)。

步驟2:產品需求歸類分組

確認了產品的需求之後,需要對需求進行整理歸類,即:按業務流程或功能邏輯把這些需求分成特定的主題。對需求分組時要考慮的問題包括:產品的使用方式和使用流程?哪些特性是客戶要連續使用的?哪些特性是用戶低頻使用的?提供某一特性後,會對用戶的使用造成什麼影響?項目團隊能否識別出需求的技術相似性或依賴性?用這些問題的答案來確認產品應有哪些主題(分類),然後根據這些主題把特性歸類。

上圖是用MindManager梳理需求的一個例子,文件管理是一個主題,屬於這個主題的特性有:文件導入、文件導出、文件保存和文件刪除四個特性。當然,也可以用Excel進行 梳理。

步驟3:產品需求估算排序

大致估算實現需求所需的工作量,並且對產品需求進行優先順序排序。為需求的價值和工作量估算或者評分是對需求排序的第一步,也是關鍵的一步。

第一步,評估每一項需求的價值,並進行量化(給需求的用戶價值和商業價值打分)。在評估需求的優先順序時,可以根據自身能力和資源選擇合適方法。因為我做的是智能硬體的而不是純互聯網產品,所以在項目的概念驗證階段,會通過面對面訪談和問卷的形式進行目標用戶調研並建立用戶畫像。然後對用戶畫像進行優先順序的初步排序,優先順序高的用戶畫像中的需求一般優先順序就會高於其他的需求。還要考慮需求的商業價值、研發成本、緊急程度、與產品目標的契合程度,還可能用到馬斯洛需求層次理論、KANO模型、雷達圖等。總之,對需求的價值有了判斷之後,要和項目干係人確認並獲得支持,一定要把需求的價值進行量化,給需求的價值打分,這裡的分值只是相對分值。/*篇幅所限,評估需求優先順序的方法在本文中不詳細展開,因為重點是講述敏捷框架,這裡只做簡單概述,如果想了解的人比較多,後面會單獨寫一篇*/

第二步,評估每一項需求的工作量,並進行量化(給完成需求的難易程度打分)。這裡需要獲得開發團隊的支持,由他們來判斷完成每項需求所需要的工作量。和需求的價值量化一樣,需求的工作量也是相對的,選擇一項團隊認為工作量適中的需求來評分,然後將這項需求作為參考系,再通過判斷其他需求與這項參考系需求在實現上難易程度的差距,進而得到對其他需求的工作量分值。估算的準確性,基本上取決於開發團隊的經驗和能力。

這裡經常用到的方法是斐波那契數列方法,斐波那契數列又稱為黃金分割數列,指的是這樣一個數列:1、1、2、3、5、8、13、21、…,這個數列從第三項開始,每一項都等於前兩項之和,隨著數列項數的增加,前一項與後一項之比越來越逼近黃金分割的數值。開發團隊中的每個人用斐波那契數列中的數字給主題或特性打分,先就一個參考系需求的工作量達成一致,然後每個人再根據參考系需求來為其他的主題或特性打分。比如開發團隊就「放大」功能的工作量達成一致為5,那麼「縮小」功能的工作量也會是5。當開發團隊成員給出的分數存在很大差異時,最好讓打最高分和打最低分的人說明原因,可能是對需求的理解出現了偏差,這時要進一步細化需求,讓開發團隊明確功能後再次重新打分,如果這次分歧不大,那麼出現頻率較高的分數即可作為最終分數。

第三步,確定需求的相對優先順序。相對優先順序是指一項需求相對於其他需求的優先程度。相對優先順序=價值/工作量。這個公式可以讓高價值低工作量的需求具備較高的優先順序,使低價值高工作量需求具備較低的優先順序。這樣用價值的分數除以工作量的分數就得到優先順序的分數。確定了優先順序的需求列表就稱為產品待辦列表,有了產品待辦列表之後就可以向產品路線圖中添加發布目標了。

步驟4:確定需求時間框架

第一次創建產品路線圖時,產品需求發布的時間框架是比較粗略的,要思考一下路線圖上各個分組的大致時間框架。然後為項目的發布選擇一個合適的迭代周期(時間增量),比如一周、兩周、一個月、一個季度或固定的天數。然後將產品代辦列表中的需求分配到每個迭代周期中去。隨著項目的進展,要及時更新產品路線圖。

上圖為UXPressia在2017年底發布的產品路線圖,UXPressia將迭代周期設為3個月:Q4 2017、Q1 2018、Q2 2018、Q3 2018、Q4 2018,然後將產品待辦事件一條一條的分配到各個迭代周期中,產品路線圖就這樣完成了。

寫在結尾

如果發現本文有不足之處歡迎留言指正,如果對本文內容有疑問請留言提問,筆者看到會馬上回復或者補充更多內容,謝謝。


推薦閱讀:

TAPD和敏捷研發
敏捷開發思想及Scrum實踐
如何使用魚骨精益敏捷項目
架構師--技術選型
如何使用Leangoo進行簡單的BUG管理

TAG:敏捷開發 | Scrum | 產品經理 |