一種互聯網產品迭代中的需求管理模型

黃永光 哈爾濱音樂學院

1 互聯網產品迭代方法

目前互聯網公司中，幾乎所有的產品都是采用迭代的方式進行的，包括以下幾個部分：最開始的市場調研，需求提煉，需求分析，產品設計原型，研發產品，測試上線，投入市場，需求反饋。每一次的產品迭代都重復以上過程。在產品迭代周期中，產品迭代周期會根據需求大小和意義劃分成不同的粒度。比如重要里程碑的版本，時間為3個月到半年左右，甚至更長。在大版本迭代中會劃分為若干小版本。小版本上線也是采用螺旋式的迭代方式。一般在互聯網公司中，兩周是一個基本的迭代周期，有些創業公司甚至是一周一個新的版本迭代。

互聯網都奉行著唯快不破的產品理念，項目的整體進展也是通過項目迭代的方式進行的。這是一種典型的原型模式。因為市場上大眾的需求是在不斷變化的，并且人類的本質需求也在隨著時代的變化，而有著不同的表現形式。所以產品迭代是最好的一種表現方法，既快速逼近真實需求，又滿足需求的快速變化。

2 基于需求池的整體需求管理

推進整個項目進展最核心的驅動力就是需求管理，通過對需求的管理，來確定迭代的目標和內容。需求的來源有很多方面，比如市場分析、用戶反饋、用戶訪談、競品功能、國外相關產品動態、自己的需求抽象、已知bug、公司內部來源等等。一個項目隨著時間變化，需求是越來越多的，需求池管理實際上是對眾多需求的管理，需求的狀態分為未上線，進入不同階段迭代周期，已上線等。需求通常還根據象限劃分為重要性和緊急性兩個層面。從定性和定量兩個角度來進行衡量。

每次開始產品迭代的起始點來源就是需求池，每次產品結束的驗收也是基于產品需求池。需求池是衡量整個產品工作的一個重要依據。它一般由軟件產品是代替實現。

3 自頂而下的層次化需求細化方法

迭代周期，根據粒度不同會劃分為不同的階段。一般采用自頂向下的方式將總體需求細化。根據不同的目標，首先劃分大的目標，類似于里程碑的功能，比如1.0版本。2.0版本。這種版本一般都是一種比較大塊的功能需求或者重要功能訴求，一般只是描述功能，或者大的方向和目標，并沒有具體的實現細節。一般這種周期都是以季度為單位，一個季度或者半年為一個周期。

大的目標之下，還要進行需求粒度的劃分。通常會從不同角度做不同的需求分解。最小粒度為交由研發的PRD文檔，每一個功能都有細致的輸入輸出，以及性能要求。

舉個例子，大需求為網站實現全文搜索功能。按照自頂向下的層次化分解方法，我們將全文搜索功能分解若干中間目標：實現基本搜索功能、搜索排序、高級搜索條件等。針對每一個中間目標，再進行下一步的細致化功能，比如高級搜索條件，每一個具體的搜索條件，界面擺放位置，性能指標等等。

4 最小迭代粒度的需求優先級判別方法

需求管理最核心的功能就是需求優先級的判斷，上一節我們提到需求的層次劃分方法，大需求的判斷優先級，往往運用PEST等分析方法，再結合整個公司戰略目標來進行判斷優先級。而最小迭代粒度的需求管理，是由產品經理具體負責，將功能細化，再結合研發的情況和用戶的反饋等綜合做出優先級的判斷。

傳統的需求優先級的判別方法，大多都是有兩維度四象限的方法，重要性和緊急性。在與研發溝通最小粒度的迭代需求管理中，往往都是由產品經理來確定，基本使用的都是定性分析，很少運用定量分析。這樣的方式比較依賴于產品經理的經驗，有可能會造成產品需求偏離或者升級安排不當。因為第一產品迭代很大程度上取決于產品經理的水平，第二與研發溝通的時候，研發對于定性的東西，有時并非特別信服和認可，這就可能會造成溝通障礙，使整個項目的推進不順利。

本文提出了一種適用于小團隊的需求優先級判斷方法。首先我們利用需求池，將未實現的需求列出來，然后再通過自頂而下的層次化方法將需求細化。細化到可為研發使用的需求列表。然后再對需求進行多維度需求打分。(1) 需求的實現難度和周期，難度越小，周期越短，也就表明需求將越快實現，用戶可以盡快的享受到新的功能，從而得分越高。（2）需求收益，這個和傳統的需求重要度比較類似，需求收益越大，表明越功能重要，得分越高。（3）需求緊急度，越緊急得分越高。往往遺留bug是最緊急的，同時也有對于大量用戶共同反饋的問題也是比較緊急的。（4）市場和競品情況，如果市場已經有類似產品功能，競品也有類似類似功能，那么得分較高。通過對各個維度的權重賦值，對每一個功能進行打分。根據打分的的大小，來進行優先級的劃分。

5 總結

本文探討了需求的優先級模型，通過一些定性打分的方法。盡可能的減少產品經理的主觀想法，以期更好的對產品進行迭代管理。誠然這樣打分方式并不是一成不變的，各個行業和各個公司都有一定的特殊性，但這種結合研發情況的需求優先級的定性方法確實是值得一定的探討的。