內容索引

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

1.1 評估需求：確定目標和優(yōu)先級

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

2.反例：低質量的需求

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

3.1舉例：自動告訴媽媽，我快到家了

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

=========================

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

何謂高質量的需求？一是需求本身有價值，二是需求被清楚明晰的表達沒有疏漏。所以，需求從“一個想法”蛻變?yōu)?ldquo;高質量的需求文檔”需要經歷評估和細化的過程。

1.1評估需求：確定目標和優(yōu)先級

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

如何確定需求的目標和優(yōu)先級呢？“假如你是QQ的產品經理”這篇文章中有很好的分析，如下：

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

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

對產品節(jié)奏的把握是關鍵甚至致命的，在同一個時間點，米聊選擇做涂鴉信息，微信選擇做查看附近的人，產品的用戶規(guī)模就此拉開距離。

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

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

S：明確性

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

其次，需求要完整。可以從用戶操作流程出發(fā)，考慮到不同的用戶角色和用戶環(huán)境，操作時的每一個分支和異常。

在此僅以手機端為例

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

從用戶環(huán)境上：無網絡環(huán)境/網絡環(huán)境異常中斷/網絡環(huán)境良好、不同機型、不同系統(tǒng)、橫屏/豎屏使用、手機/平板;

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

從操作異常上：操作的邊界情況（比如：在評論框中惡意輸入調用數據庫的代碼）。

M：可衡量

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

僅以注冊頁面為例

“當用戶輸入用戶名和密碼后，注冊成功;當輸入出現錯誤時，彈出錯誤提示”

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

應為：

“當郵箱格式為example@example.com，密碼至少為6個字符，密碼和確認密碼一致這三個條件均滿足時，注冊成功;否則分別出現’郵箱格式錯誤’，’密碼應至少為6個字符’，’密碼和確認密碼不一致’的錯誤提示”

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

A：可實現

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

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

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

資源上來說，類似個性化推薦、云端產品需要把每個用戶的數據在服務器存一份，小公司可能會燒不起服務器。

R：相關性

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

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

T：時限性

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

2.反例：低質量的需求

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

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

用戶需求重要性=功能使用用戶百分比（5%）*功能使用次數百分比（10%）*類別重要性百分比（20%）=0.001

優(yōu)先級低。不過既然是老板提的需求，還是先細化一下需求吧，運用SMART原則。

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

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

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

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

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

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

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 明確概念

當某時未到某地時，自動發(fā)短信給某人。

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

3.3 主線流程

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

3.4 繼續(xù)完善分支和異常情況

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

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

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

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

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

標簽： 交互設計原則 如何寫好需求文檔 方舟子 

版權申明：本站文章部分自網絡，如有侵權，請聯系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯系。