 |
VOOZH | about |
|
VOOZH | about |
對於敏捷開發，講它的價值、方法的內容已經夠多。而對於需求、設計、測試這三個環節，如何適配並融入敏捷開發的流程，卻著墨寥寥。本文主要從產品設計及需求表達兩個方面，介紹如何在敏捷開發的背景下，保證產品設計不挖坑，並為開發人員提供的高效支撐。文中所述適用於中小規模的團隊，產品形態以web端非成熟期產品為最匹配。
1.遠粗近細，規劃先行在整個敏捷流程開始之前，應該先檢視如下幾項：
（1）BRD & roadmap
此時產品團隊已經確定了所有大方向，以及達到這些方向的路徑。
（2）外部環境中的關鍵時間節點
此時應該對接下來兩次疊代以內的外部環境（如行業周期、市場壓力、節假日等運營引爆點）有較為明確的把握，確保版本方向不會受迫產生較大的變動。
（3）需求池
此時可能已經積累有來自各方的需求，以及產品規劃中預計要新增的模塊。而每次疊代，需求來源都出自這個表格中。
根據以上，首先通過關鍵時間節點來修正產品roadmap，細化roadmap中距離當前最近的一段時間，顆粒度最細須達到完成一次敏捷開發的所需要的時間。關於最終細化出來的產品路線，產品經理的腦中一定要有非常清晰的節奏，明確每一步的整體目標。完成後，應該明確下一步疊代的兩個內容，一是新增哪個模塊/欄目，二是優化哪些功能、頁面。
對於新增的模塊，我們要讓它單獨進入敏捷開發流程，必須保證它是相對獨立的，不會受到另一個未開發模塊的牽制。如果不是，那麼這些模塊應該在同一次疊代中，以最基本（基本到只剩關鍵流程）的形態同時上線。
2.先加後減，解構產品確保新增模塊的獨立性後，就到了產品設計的環節了。對於產品設計經驗不是非常豐富的PM來說，此時，一定確保設計環節的完整，需求分析、用戶任務和流程設計、產品結構決不能被「敏捷」掉。直接動手做流程和原型，無論時間多緊都不應該，反而會因為挖坑，導致在以後浪費更多的時間去反覆填坑。
我在做敏捷設計的時候，傾向於經由完整的設計流程，產出相對完整的產品設計，然後根據敏捷周期，來對產品進行精簡。這樣不會因為後期豐富該功能時，由於思考不全面和先前沒有一個明確的理想解決方案，而推翻重做或者有較大改動；也保證了產品功能拆分後，各個子單元在不同版本疊代完全時的產品一致性。
我們需要對完整稿進行拆分和優先級排序，找出主要流程、關鍵信息，先保證主線跑通，再考慮提升用戶體驗的輔助性功能，以及提升用戶停留時長或提高轉化率的信息豐富手段。
由於這個完整稿，本身就是用來試錯的，那麼，我們在細化需求的時候，可以先細化主線需求到能夠交付開發執行的程度，而對於可能有變動甚至整體捨棄的其他分支，暫時到特性層面就可以了。
基於完整稿，我們可以提出幾種拆分方案，在需求評審時，與開發團隊討論確定最終的目標方案。對於該方案，我們需要在方案內的特性中，再次排出優先級。目的是，讓開發先做高優先級特性，如果遇到不可預估的困難，可以馬上決策並削減優先級低的特性，保證主流程的完成，儘量弱化工程延期的不利後果。
3.簡短明了，文盡其用關於產品設計後的需求表達，我一直以來的原則就是不參考模板，靈活使用。在敏捷開發中，我們通常不可能去寫全面囉嗦的PRD，移動端更甚。我的做法是，使用excel做產品backlog，省去所有對開發無意義的描述說明文字，從feature list直接獲得。審視自己寫下的每一個列首項，是不是對開發有用，省去所有無用項。
如果團隊中沒有專職測試，甚至可以將測試功能融合進backlog中，僅需增加測試結果與狀態兩列，而只要需求想的透徹，特性說明完全可以做基本的功能測試用例。
同時，該表格也可以融入項目管理的功能。狀態列中，單元格為下拉菜單，分別有待開發、待測試、完成三個狀態。
backlog表頭示例
適合每個團隊的文檔形式各不相同，有的開發喜歡原型結合文檔進行開發，有的喜歡看原型做，文檔備查，這些都需要PM提前溝通，了解PRD的用戶需求，砍掉無效的工作，製作出適合自己團隊的文檔形式，並自己保證花在文檔上的時間，都是有效的。
作者：塵中之光（簡書作者）
本文由 @塵中之光 授權發布於人人都是產品經理，未經作者許可，禁止轉載。
