正如我們做出來的産品都希望受用戶歡迎，開發和測試是需求文檔的用戶，産品經理也應該重視他們的想法和要求才能寫得令人滿意。

“寫需求文檔”說專業點是把用戶（或運營、客服等）的需求轉化成技術部門的話語，因此了解技術術語是産品經理的基本素質。要做到需求文檔受歡迎，了解術語是不夠的。雖然不可能寫得像開發人員寫設計文檔的一樣專業，但産品經理如果能運用技術人員的思維多做些考慮，就能減少評審過程的反複溝通，那必然能收到大量好評。

技術人員的思維同樣是被工作環境和内容訓練形成的，編程語言、架構設計、測試方法是最主要的因素。其中，開發人員會有這些思維：

• 組件與模塊；
• 流程與聯系；
• 條件與時機；
• 類型與精度。

測試也會有獨特的思維：

• 極端；
• 因果；
• 場景：一系列的組合條件。

另外，用戶體驗思維中的“層次分明、重點突出”，也非常有助于優化需求文檔的視覺效果以提高閱讀效率。

我們以每種思維作為章節來回答本文的問題。

開發思維：組件與模塊

我們寫文章都不是從頭到尾就一段話的，會分段落、章節，這樣能幫助做到條理清晰。代碼的本質也是“文章”，組件和模塊就像是段落和章節，他們會對應一個功能、界面或規則。

為此，需求本身也應有拆分：産品有結構、功能有細分、界面分區塊等。

産品結構圖就像文章的目錄，在做新項目的時候應該附上。它不僅幫助産品經理自己梳理子需求，也讓整個項目組都清晰知道産品的構成，對開發、測試、UI設計師後續的工作都有指導作用。現在多數人會用思維導圖來畫，原因就是它的最大作用是理順思路。

功能細分可以用“評論”功能來舉例，它可分為：

• 前置的登錄注冊等條件；
• 界面上評論區的功能（比如：@他人，回複某樓層，引用回複，表情輸入等）；
• 提交前的限制條件校驗（比如：字數、特殊字符）；
• 提交評論的過程；
• 評論的内容檢驗（比如：涉黃、敏感信息）；
• 評論後的展示（比如：引用回複、互相@）；
• 用戶信息裡的評論信息更新。

如何做需求拆解是沒有固定模式的，跟業務有緊密關系，一般的兩個思路是流程和規則。

下圖是界面分區塊的示例（示例的意思是在原型和文檔上這樣命名，這不是原型圖）

分區塊并進行命名的好處：

• 利于文檔描述，減少說明字數，加速閱讀。
• 利于溝通。大家隻要說一個名字，就知道是說哪個部分，不用對着界面說。如果整個産品每個區域的名字是唯一的，那麼報bug的時候可能連操作路徑和截圖都不需要了。
• 一般來說，開發寫代碼時也會用這些命名的（翻譯成英語），他們會很感激産品經理幫他們想好了名字。

開發思維：流程與聯系

需求是一個整體，拆分後的各部分必然仍有聯系，他們的協作步驟即是流程。産品的交互設計在代碼流程上是大緻對應的，所以如果産品經理能把流程描述詳盡的話，開發的工作差不多等于把這堆“中文”用編程語言翻譯一遍而已。

如果流程足夠複雜，就需要用圖來表達。畫圖是描述複雜事物的基本技巧，不僅僅是需求文檔的寫作要求了，這裡不展開講。

那麼怎麼才算複雜呢？

一般簡單的判斷是：以最長的步驟路徑為基準，如果超過30%的步驟有分支就應該畫流程圖。例如：如果有7個步驟，有3個步驟是“是非選擇”或“循環指向”，那就該畫；隻有2個步驟有分支就不用畫，用文字說明白。延伸地講，如果分支太多，需求本身可能就有問題了，應該從交互設計上去簡化它，不應該給用戶這麼多可選擇的東西而造成困擾。

一個實際的文字描述步驟例子：

1. 進入“我”頁面；
2. 是否已登錄，是則繼續，否則進入“登錄”流程；
3. 點擊“評論”區，進入評論頁；
4. 如果評論數為空，顯示占位圖，否則顯示評論列表；
5. 點擊評論列表中的一條，進入帖子詳情頁，并且頁面自動滾動到那條評論的位置；
6. 用戶點右上角的“關閉”，跳回第4步，否則按“帖子詳情頁”的流程繼續。

在上面的例子裡，我們也看到，流程之間會産生聯系。一個流程中的某些步驟可以關聯到另一個流程，這些流程之間的聯系，在開發設計中會體現為“模塊間的依賴或調用關系”。

作為産品經理無需理解前面雙引号内詞語的技術意義，但有一個很典型的場景能幫助大家認識它的作用：開發解決了一個bug後導緻了别的bug。更經典的是，開發抱怨說這是因為産品的新需求沒考慮到對原有功能的影響。

無論最終是否開發的責任，産品經理也應該去梳理各個需求之間的聯系，包括界面、交互、功能的相互影響。最好是文檔中有獨立的章節列出需求間的關聯，這不僅是幫助開發測試做好設計，也是為自己檢查疏漏。

拿一個普遍的需求“登錄”來舉例，産品經理應該列一下所有“不登錄就不能訪問的頁面”。以後改動登錄功能的時候，自己也可以一下子看清所有的影響範圍，這個習慣最能防止“狀态多層次級聯”（如：A影響B，B影響C）的情況下考慮不周。

開發思維：條件與時機

計算機是不會執行沒描述過的操作的，即使是火熱的人工智能，也是要經過訓練才知道什麼條件做什麼操作。

所以開發需要在代碼中精确描述：

1. 流程的入口場景，即這種“可能性”的觸發時機。
2. 流程内每個步驟的執行條件。

不同的條件會導緻不同的結果，這對用戶使用有重大影響，所以一定把所有的條件和可能性都列出來。一般來說，産品經理最大的疏漏是沒考慮異常情況。

其實無論過程怎樣，最終反映在界面上隻有4種結果：

1. 加載中；
2. 數據正常，正常顯示；
3. 無數據，數據為空；
4. 出錯，包括超時。

産品經理把這4種結果的界面都定義清楚，就能覆蓋所有中間過程的情況。當然，最好還是能把中間過程的可能性都考慮周全，并針對不同的狀況有更精細化的結果展示。

開發思維：類型與精度

這是編程語言（更确切來說是CPU計算原理）帶來的思維，我們不去深究計算機知識，隻需知道對我們的影響：要用數據來描述一個事物以便計算機能理解。

這些數據分兩大類型：數字與文本。

其中數字還有這些考慮：

• 整數還是浮點數，即是否帶有小數部分；
• 浮點數保留多少位小數部分；
• 是否可能是負數；
• 最大絕對值是多少（數字越大，可能會需要更多内存和計算時間。做适當限制有利于提高性能）。

這個思維（或者說限制）會影響所有需要用戶輸入交互的地方，如果原型圖上不能明顯看出以上的信息，産品經理應該有意識地在文檔中補充。

測試思維：極端

極端的情況下容易出bug，這是最基本的測試思路。如果界面上有一個輸入框，以下幾個測試用例肯定會有：

• 輸入非常多的字符，看是否允許、是否合理顯示；
• 輸入不應該允許的數值，比如超出最大最小值，看能否允許、能否繼續下一步；
• 輸入不應該允許的文本類型，比如身份證号欄填入中文，看是否允許、能否繼續下一步。

下面幾種測試手段，都會用到極端的思維：

• 最低配置的設備上能否流暢運行？
• 在設備資源緊張（例如内存不足）的時候，程序還能否正常工作？
• 在最老舊的系統、浏覽器版本上能否正常運行？
• 非常頻繁地進行操作，程序還能否正常響應？

依據這個思維，産品經理應該把這些東西都定義清楚：

• 可交互界面的輸入類型與範圍；
• 目标運行環境的最低配置；
• 兼容性：系統版本、浏覽器品牌與版本；
• 需要支撐多少用戶同時在線、多少同時發生的流量；
• 要能應對什麼程度的故障。

測試思維：因果

開發思維中“條件與時機”注重的是“前提”，測試還會做反向思考和補充。除了關心“什麼條件導緻了這個結果”，還要思考“這個條件會導緻哪些結果”，這也是開發寫代碼容易疏忽的。

兩個典型的問題是：登錄後可以做什麼，界面上有哪些變化？

這種思維在所有崗位都是适用的，也很容易理解，對産品經理的意義就不細說了。

測試人員不僅用它來評審需求，找bug時要考慮是什麼操作、事項、需求導緻了bug以及這些東西的關聯關系、影響範圍等，從而進一步發現更多問題。

而且作為需求的實現者，技術人員都會有這個問題：為什麼要這樣做，做成了會有什麼結果？

産品經理是有責任回答這個問題的。其中，“為什麼要這樣做”要心裡有數，在需求評審時被問到就要能回答。

不能靠想，要有根據：

• 用戶調研；
• 統計數據分析；
• 市場調查；
• 競品分析；
• 成功經驗。

還有“做成了的結果”應該把它以“目标”為第一章标題寫到需求文檔的前面。

目标示例：

• 解決用戶購物流程中的不便；
• 給占比有27%的喜歡xxx用戶增加一種選擇，可以對xxx進行操作；
• 轉化率至少有12%；
• 提升月活躍度10%（或到30%）；
• 提高廣告月收入至300萬。

産品經理做需求時，應該先想好這些目标，需求是圍繞這些目标來制定的。大家理解這個目标後，還能幫助産品經理想出更多更好的方案來達成。

測試思維：場景

“場景”在本文中意為多個條件共同作用的情況。下表表示的是兩個條件（行為、身份）下的結果（權限）。

設想增加一個情況：已綁定微信的會員可以查看“朋友積分榜”，這就需要一個“行為-身份-微信綁定-權限表”。如果有更多條件，就不是一個表格能說明的了。合格的測試人員會把這些條件的所有交叉情況都測一遍，甚至在需求評審後就要做用例設計，把需求文檔沒覆蓋的情況立刻指出來。

場景的本質是條件的排列組合，可以用數學公式計算出有多少可能性。産品經理不應該把這些情況推托給技術人員去想，因為最極端的情況是可能會發現某些場景無解，以緻要推翻整個需求。到評審完才發現這些問題就晚了，耽誤了太多人的時間。

當場景過于複雜，除了要說清楚規則外，還應該寫出示例來幫助理解。

用戶體驗思維：層次分明、重點突出

産品經理或設計師做網頁設計時通常會有這些原則：

• 方便從上到下閱讀，頁面不會産生橫向滾動條。
• 描述一個宏觀事物的圖不會跨越兩屏才看完整。
• 層次分明：标題比正文的顔色更深、字号更大、字形更粗。
• 段落内部的重點詞句（一般是超鍊接）要使用更顯眼的顔色，字形可以使用粗體、斜體、下劃線等。
• 無論需求文檔是寫Word還是用Axure導出網頁給技術同事看，以上原則都是适用的：幫助提升閱讀效率。

還有一個問題是表格的運用，表格能讓人一下看到哪裡有填東西哪裡是空白，但并不方便人仔細閱讀所有的内容。什麼時候用表格或列表，這裡總結兩個簡單規則：

1. 表格除表頭外至少有3行3列，否則用列表。
2. 如果表格寫不出精确的表頭來，也就是每行是不同意義的，用列表。

最後就是，寫需求用Word還是Axure或兩者結合，都無所謂，關鍵是要把事項描述清楚并且方便查閱。

思維應用

上述思維的運用，最終是為了提高需求的完善程度，避免需求本身有bug。産品經理要去學習技術知識的話，應該是要總結出更多的思維，而不是真的要會寫代碼。以下按照界面和交互來總結一下技術思維的關注點。

界面組件上的應用：

（1）文本框

• 過長如何顯示：換行、顯示省略号；
• 如果換行和省略号都不要，就要确定文案最大字數；
• 數字保留多少位小數，四舍五入還是去尾或進1；
• 數字的顯示格式，例如：加逗号或加單位；
• 時間的顯示格式，例如：是否顯示分秒，日期間用中文還是橫線連接。

（2）輸入框

• 默認值；
• 占位符；
• 按下回車的行為；
• 自動補全的規則；
• 可輸入類型：純數字、文本（中文、外文、特殊字符），是否密碼；
• 輸入限制：文本長度、小數位數、取值範圍、最大最小值、是否必填。

（3）選擇框

• 默認狀态；
• 單選還是多選。

（3）下拉列表

• 默認值；
• 實際值與顯示值的對應關系：例如界面上顯示100 ，實際值是135。

（4）按鈕：點擊後的行為

（5）彈框

• 位置：屏幕中間或中下；
• 顯隐動畫：時長、方式。

（6）表格：排序規則。

（7）開關：默認狀态。

（8）輪播

• 是否自動換頁，間隔時間；
• 是否顯示分頁器（“點點”或頁碼），是否可點擊分頁器來換頁；
• 是否可循環；
• 是否顯示進度條；
• 是否增加每頁邊距，邊距是多少。

（9）圖片

• 縮放規則，例如：固定寬度、高度随原比例；
• 層級：誰可以遮蓋誰。

交互上的應用：

點擊：反饋形式（例如變色）。

手勢（例如右滑後退）：

• 距離；
• 速度；
• 方向。

界面切換：

• 動效：時長；
• 窗口、屏幕改變大小（橫豎屏切換）的布局規則；
• 已輸入的數據是否保留；
• 關聯關系。例如選中後會立刻改變其它控件的狀态。

本文由 @hursing 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部