>>>

1.一個高質量需求的經典要素

何謂高質量的需求？一是需求本身有價值，二是需求被清楚明晰的表達沒有疏漏。所以，需求從「一個想法」蛻變為「高質量的需求文件」需要經歷評估和細化的過程。

1.1評估需求：確定目標和優先順序

評估是確定需求價值的過程。每個產品都有著生命週期，把握好迭代的節奏能讓產品迅速佔領市場、收益最大化。那麼，就要確定需求的目標，即達到效果的量化標準。一坨需求的目標拿來比較排序，就是優先順序。

如何確定需求的目標和優先順序呢？「假如你是QQ的產品經理」這篇文章中有很好的分析，如下：

使用者需求重要性的判斷標準：使用者基數、使用次數和類別重要性。類別重要性分成基本型、期望型和興奮型需求三類。

對於基本型需求，比如產品的效能、安全、瀏覽器相容等方面，一旦出現問題，使用者不能訪問使用產品，應立即利用一切可利用的資源儘快解決。
對於期望型需求和興奮型需求，可以通過分析運營資料，使用公式計算：使用者需求重要性=功能使用使用者百分比(使用者使用率)*功能使用次數百分比(功能 或內容使用率)*類別重要性百分比(期望型需求、興奮型需求)。

目標有了公式來計算量化標準，自然也就便於比較優先順序。當然，產品經理對於百分比的預估可能是不準確的，這就要求了每個需求要配合相應的統計項需求，用來觀察驗證與目標是否一致。隨著經驗累計，預估會越來越準確，直到成為直覺。

對產品節奏的把握是關鍵甚至致命的，在同一個時間點，米聊選擇做塗鴉資訊，微信選擇做檢視附近的人，產品的使用者規模就此拉開距離。

1.2 細化需求：SMART原則的運用

SMART原則自從被「杜拉拉昇職記」使用後廣為人知，即明確性（Specific）、可衡量（Measurable）、可實現（Attainable）、相關性(Relevant)、時限性（Time-bound）。筆者發現，其實不只是用在目標管理上，SMART原則用於需求管理和細化也非常貼切。

• S：明確性

首先，需求要無歧義，這就需要儘可能少的出現形容詞，比如“可能、大部分”等；出現的名詞如不確定對方能夠理解，需給出名詞解釋，比如“準確率、召回率”。

其次，需求要完整。可以從使用者操作流程出發，考慮到不同的使用者角色和使用者環境，操作時的每一個分支和異常。

在此僅以手機端為例

從使用者角色上：使用的App版本不同、首次啟動/非首次啟動、使用者許可權（免費/付費、普通使用者/管理員等）；

從使用者環境上：無網路環境/網路環境異常中斷/網路環境良好、不同機型、不同系統、橫屏/豎屏使用、手機/平板；

從操作分支上：前置條件、後置條件（我的理解是當前介面上每一個按鈕/手勢的下一步反應）；

從操作異常上：操作的邊界情況（比如：在評論框中惡意輸入呼叫資料庫的程式碼）。

• M：可衡量

可衡量意味著需求需要有量化標準，使其可以被測試和證實。

僅以註冊頁面為例

“當用戶輸入使用者名稱和密碼後，註冊成功；當輸入出現錯誤時，彈出錯誤提示”

這並不是一個可衡量的需求，因為沒有定義什麼是正確什麼是錯誤，無從驗證。

應為：

“當郵箱格式為[email protected]，密碼至少為6個字元，密碼和確認密碼一致這三個條件均滿足時，註冊成功；否則分別出現’郵箱格式錯誤’,'密碼應至少為6個字元’,'密碼和確認密碼不一致’的錯誤提示”

另外，需求目標也需要可衡量，也就是上文提到的“每個需求要配合相應的統計項需求來檢驗上線效果”。

• A：可實現

可實現除了考慮需求的可行性，還需考慮到成本控制，包括時間、人力、資源等等。

有這樣一種說法，“理論上來說所有明確的需求都可以實現，只是需要時間。”

尤其移動端採用敏捷開發的話，搞一個需要做半年的需求就給跪了。

資源上來說，類似個性化推薦、雲端產品需要把每個使用者的資料在伺服器存一份，小公司可能會燒不起伺服器。

• R：相關性

需求和產品定位保持一致，策略和已存在的產品保持邏輯一致，形式和風格與已存在的產品保持形式和文案風格的一致。

需求之間的邏輯、定義和文案風格一致。

• T：時限性

T原則一般用於工程師細化需求，而非產品經理。在計劃會之後，每個需求會被拆分並有相應排期。

2.反例：低質量的需求

假設老闆給Google now產品經理提了這樣一個需求：讓多個城市的天氣顯示在同一張card上。

首先，評估需求。根據現有資料計算得出

使用者需求重要性=功能使用使用者百分比(5%)*功能使用次數百分比(10%)*類別重要性百分比(20%)＝0.001

優先順序低。不過既然是老闆提的需求，還是先細化一下需求吧，運用SMART原則。

每張card有相應的佈局和排版，如果要多個城市的天氣顯示在一張card就需要拉長card或者重新排版。多個城市的閾值需定為多少？當多個城市＝2，3，4…時是否要每種單獨定製模板和佈局？同時如何保證主要資訊全部顯示？

產品經理突然發現，這樣一個反人類的需求不僅開發量增大而且收益微小。

這時，普通產品經理在心裡暗罵老闆SB，二逼產品經理向同事傾訴老闆是個SB，炫酷產品經理反過來想，老闆為什麼會這麼想呢？啊，他一定是想更便捷的檢視同類型的card。於是，他推出了一種炫酷的設計——Google now中同類型card為疊放樣式。

（本故事純屬杜撰，如有雷同，呵呵）

3.實踐：親手製造高質量需求

這裡用一個小例子來一步步製造高質量需求。筆者的母親希望筆者在晚上十點前仍未回家時發簡訊報平安，但筆者經常忘記，受到ifttt啟發萌生這樣一個想法，當我十點前仍沒到家時，自動發簡訊給媽媽報平安。

3.1 需求評估

使用者需求重要性=功能使用使用者數量(2.7億*18%＊5%)*功能使用次數百分比(30%)*類別重要性百分比(50%)＝364500

有此需求的使用者特徵大致是：未婚、與父母同住、上學或工作，故年齡分佈大致在21-26歲。

中國目前有2.7億智慧機使用者［3］，智慧機使用者中20-29歲人群佔比36%［4］，如果均分則21-26佔比18%，預測其中有此需求的使用者佔比5%；功能使用次數為一週兩次，重要性為50%，得出使用者需求重要性的數量為364500.當然這個估計可能偏大了，重點還是想說細分需求的步驟嗯。

3.2 明確概念

當某時未到某地時，自動發簡訊給某人。

未到某地的定義：距離某地大於等於1000米的直線距離。

3.3 主線流程

先完成主線的執行邏輯，注意每一個步驟的可衡量

3.4 繼續完善分支和異常情況

考慮每一個步驟的其他操作和錯誤情況

至此，便完成了需求的主要邏輯。

可以通過觀察反推成熟產品（比如iOS上的備忘錄）的需求邏輯來訓練簡化流程且不遺漏的能力，也可以多閱讀同行的優秀文件，比如白鴉老師的「微信自定義機器人的最初需求樣本」。

4.總結：從好需求到好產品

好需求是好產品的必要非充分條件，一份清晰、無疏漏、不輕易變更的需求文件能讓團隊其他成員專注於開發。當然，僅僅寫的清楚也是不夠的，還要說的明白，在溝通中達成一致。

引用：
［1］高質量的科學謠言是如何出爐的,Ruki
［2］假如你是QQ的產品經理,Krrishyan
［3］2012網際網路趨勢報告，Mary Meeker,2012.12
［4］中國移動網際網路發展狀況調查報告，中國網際網路絡資訊中心，2012.03
［5］微信自定義機器人的最初需求樣本，白鴉

轉載於:https://my.oschina.net/skyzwg/blog/184134