正如我們做出來的產品都希望受用戶歡迎，開發和測試是需求文檔的用戶，產品經理也應該重視他們的想法和要求才能寫得令人滿意。
“寫需求文檔”說專業點是把用戶（或運營、客服等）的需求轉化成技術部門的話語，因此了解技術術語是產品經理的基本素質。要做到需求文檔受歡迎，了解術語是不夠的。雖然不可能寫得像開發人員寫設計文檔的一樣專業，但產品經理如果能運用技術人員的思維多做些考慮，就能減少評審過程的反復溝通，那必然能收到大量好評。
技術人員的思維同樣是被工作環境和內容訓練形成的，編程語言、架構設計、測試方法是最主要的因素。其中，開發人員會有這些思維：
- 組件與模塊；
- 流程與聯系；
- 條件與時機；
- 類型與精度。
測試也會有獨特的思維：
- 極端；
- 因果；
- 場景：一系列的組合條件。
另外，用戶體驗思維中的“層次分明、重點突出”，也非常有助于優化需求文檔的視覺效果以提高閱讀效率。
我們以每種思維作為章節來回答本文的問題。
開發思維：組件與模塊
我們寫文章都不是從頭到尾就一段話的，會分段落、章節，這樣能幫助做到條理清晰。代碼的本質也是“文章”，組件和模塊就像是段落和章節，他們會對應一個功能、界面或規則。
為此，需求本身也應有拆分：產品有結構、功能有細分、界面分區塊等。
產品結構圖就像文章的目錄，在做新項目的時候應該附上。它不僅幫助產品經理自己梳理子需求，也讓整個項目組都清晰知道產品的構成，對開發、測試、UI設計師后續的工作都有指導作用。現在多數人會用思維導圖來畫，原因就是它的最大作用是理順思路。
功能細分可以用“評論”功能來舉例，它可分為：
- 前置的登錄注冊等條件；
- 界面上評論區的功能（比如：@他人，回復某樓層，引用回復，表情輸入等）；
- 提交前的限制條件校驗（比如：字數、特殊字符）；
- 提交評論的過程；
- 評論的內容檢驗（比如：涉黃、敏感信息）；
- 評論后的展示（比如：引用回復、互相@）；
- 用戶信息里的評論信息更新。
如何做需求拆解是沒有固定模式的，跟業務有緊密關系，一般的兩個思路是流程和規則。
下圖是界面分區塊的示例（示例的意思是在原型和文檔上這樣命名，這不是原型圖）
分區塊并進行命名的好處：
- 利于文檔描述，減少說明字數，加速閱讀。
- 利于溝通。大家只要說一個名字，就知道是說哪個部分，不用對著界面說。如果整個產品每個區域的名字是唯一的，那么報bug的時候可能連操作路徑和截圖都不需要了。
- 一般來說，開發寫代碼時也會用這些命名的（翻譯成英語），他們會很感激產品經理幫他們想好了名字。
開發思維：流程與聯系
需求是一個整體，拆分后的各部分必然仍有聯系，他們的協作步驟即是流程。產品的交互設計在代碼流程上是大致對應的，所以如果產品經理能把流程描述詳盡的話，開發的工作差不多等于把這堆“中文”用編程語言翻譯一遍而已。
如果流程足夠復雜，就需要用圖來表達。畫圖是描述復雜事物的基本技巧，不僅僅是需求文檔的寫作要求了，這里不展開講。
那么怎么才算復雜呢？
一般簡單的判斷是：以最長的步驟路徑為基準，如果超過30%的步驟有分支就應該畫流程圖。例如：如果有7個步驟，有3個步驟是“是非選擇”或“循環指向”，那就該畫；只有2個步驟有分支就不用畫，用文字說明白。延伸地講，如果分支太多，需求本身可能就有問題了，應該從交互設計上去簡化它，不應該給用戶這么多可選擇的東西而造成困擾。
一個實際的文字描述步驟例子：
- 進入“我”頁面；
- 是否已登錄，是則繼續，否則進入“登錄”流程；
- 點擊“評論”區，進入評論頁；
- 如果評論數為空，顯示占位圖，否則顯示評論列表；
- 點擊評論列表中的一條，進入帖子詳情頁，并且頁面自動滾動到那條評論的位置；
- 用戶點右上角的“關閉”，跳回第4步，否則按“帖子詳情頁”的流程繼續。
在上面的例子里，我們也看到，流程之間會產生聯系。一個流程中的某些步驟可以關聯到另一個流程，這些流程之間的聯系，在開發設計中會體現為“模塊間的依賴或調用關系”。
作為產品經理無需理解前面雙引號內詞語的技術意義，但有一個很典型的場景能幫助大家認識它的作用：開發解決了一個bug后導致了別的bug。更經典的是，開發抱怨說這是因為產品的新需求沒考慮到對原有功能的影響。
無論最終是否開發的責任，產品經理也應該去梳理各個需求之間的聯系，包括界面、交互、功能的相互影響。最好是文檔中有獨立的章節列出需求間的關聯，這不僅是幫助開發測試做好設計，也是為自己檢查疏漏。
拿一個普遍的需求“登錄”來舉例，產品經理應該列一下所有“不登錄就不能訪問的頁面”。以后改動登錄功能的時候，自己也可以一下子看清所有的影響范圍，這個習慣最能防止“狀態多層次級聯”（如：A影響B，B影響C）的情況下考慮不周。
開發思維：條件與時機
計算機是不會執行沒描述過的操作的，即使是火熱的人工智能，也是要經過訓練才知道什么條件做什么操作。
所以開發需要在代碼中精確描述：
- 流程的入口場景，即這種“可能性”的觸發時機。
- 流程內每個步驟的執行條件。
不同的條件會導致不同的結果，這對用戶使用有重大影響，所以一定把所有的條件和可能性都列出來。一般來說，產品經理最大的疏漏是沒考慮異常情況。
其實無論過程怎樣，最終反映在界面上只有4種結果：
- 加載中；
- 數據正常，正常顯示；
- 無數據，數據為空；
- 出錯，包括超時。
產品經理把這4種結果的界面都定義清楚，就能覆蓋所有中間過程的情況。當然，最好還是能把中間過程的可能性都考慮周全，并針對不同的狀況有更精細化的結果展示。
開發思維：類型與精度
這是編程語言（更確切來說是CPU計算原理）帶來的思維，我們不去深究計算機知識，只需知道對我們的影響：要用數據來描述一個事物以便計算機能理解。
這些數據分兩大類型：數字與文本。
其中數字還有這些考慮：
- 整數還是浮點數，即是否帶有小數部分；
- 浮點數保留多少位小數部分；
- 是否可能是負數；
- 最大絕對值是多少（數字越大，可能會需要更多內存和計算時間。做適當限制有利于提高性能）。
這個思維（或者說限制）會影響所有需要用戶輸入交互的地方，如果原型圖上不能明顯看出以上的信息，產品經理應該有意識地在文檔中補充。
測試思維：極端
極端的情況下容易出bug，這是最基本的測試思路。如果界面上有一個輸入框，以下幾個測試用例肯定會有：
- 輸入非常多的字符，看是否允許、是否合理顯示；
- 輸入不應該允許的數值，比如超出最大最小值，看能否允許、能否繼續下一步；
- 輸入不應該允許的文本類型，比如身份證號欄填入中文，看是否允許、能否繼續下一步。
下面幾種測試手段，都會用到極端的思維：
- 最低配置的設備上能否流暢運行？
- 在設備資源緊張（例如內存不足）的時候，程序還能否正常工作？
- 在最老舊的系統、瀏覽器版本上能否正常運行？
- 非常頻繁地進行操作，程序還能否正常響應？
依據這個思維，產品經理應該把這些東西都定義清楚：
- 可交互界面的輸入類型與范圍；
- 目標運行環境的最低配置；
- 兼容性：系統版本、瀏覽器品牌與版本；
- 需要支撐多少用戶同時在線、多少同時發生的流量；
- 要能應對什么程度的故障。
測試思維：因果
開發思維中“條件與時機”注重的是“前提”，測試還會做反向思考和補充。除了關心“什么條件導致了這個結果”，還要思考“這個條件會導致哪些結果”，這也是開發寫代碼容易疏忽的。
兩個典型的問題是：登錄后可以做什么，界面上有哪些變化？
這種思維在所有崗位都是適用的，也很容易理解，對產品經理的意義就不細說了。
測試人員不僅用它來評審需求，找bug時要考慮是什么操作、事項、需求導致了bug以及這些東西的關聯關系、影響范圍等，從而進一步發現更多問題。
而且作為需求的實現者，技術人員都會有這個問題：為什么要這樣做，做成了會有什么結果？
產品經理是有責任回答這個問題的。其中，“為什么要這樣做”要心里有數，在需求評審時被問到就要能回答。
不能靠想，要有根據：
- 用戶調研；
- 統計數據分析；
- 市場調查；
- 競品分析；
- 成功經驗。
還有“做成了的結果”應該把它以“目標”為第一章標題寫到需求文檔的前面。
目標示例：
- 解決用戶購物流程中的不便；
- 給占比有27%的喜歡xxx用戶增加一種選擇，可以對xxx進行操作；
- 轉化率至少有12%；
- 提升月活躍度10%（或到30%）；
- 提高廣告月收入至300萬。
產品經理做需求時，應該先想好這些目標，需求是圍繞這些目標來制定的。大家理解這個目標后，還能幫助產品經理想出更多更好的方案來達成。
測試思維：場景
“場景”在本文中意為多個條件共同作用的情況。下表表示的是兩個條件（行為、身份）下的結果（權限）。
設想增加一個情況：已綁定微信的會員可以查看“朋友積分榜”，這就需要一個“行為-身份-微信綁定-權限表”。如果有更多條件，就不是一個表格能說明的了。合格的測試人員會把這些條件的所有交叉情況都測一遍，甚至在需求評審后就要做用例設計，把需求文檔沒覆蓋的情況立刻指出來。
場景的本質是條件的排列組合，可以用數學公式計算出有多少可能性。產品經理不應該把這些情況推托給技術人員去想，因為最極端的情況是可能會發現某些場景無解，以致要推翻整個需求。到評審完才發現這些問題就晚了，耽誤了太多人的時間。
當場景過于復雜，除了要說清楚規則外，還應該寫出示例來幫助理解。
用戶體驗思維：層次分明、重點突出
產品經理或設計師做網頁設計時通常會有這些原則：
- 方便從上到下閱讀，頁面不會產生橫向滾動條。
- 描述一個宏觀事物的圖不會跨越兩屏才看完整。
- 層次分明：標題比正文的顏色更深、字號更大、字形更粗。
- 段落內部的重點詞句（一般是超鏈接）要使用更顯眼的顏色，字形可以使用粗體、斜體、下劃線等。
- 無論需求文檔是寫Word還是用Axure導出網頁給技術同事看，以上原則都是適用的：幫助提升閱讀效率。
還有一個問題是表格的運用，表格能讓人一下看到哪里有填東西哪里是空白，但并不方便人仔細閱讀所有的內容。什么時候用表格或列表，這里總結兩個簡單規則：
- 表格除表頭外至少有3行3列，否則用列表。
- 如果表格寫不出精確的表頭來，也就是每行是不同意義的，用列表。
最后就是，寫需求用Word還是Axure或兩者結合，都無所謂，關鍵是要把事項描述清楚并且方便查閱。
思維應用
上述思維的運用，最終是為了提高需求的完善程度，避免需求本身有bug。產品經理要去學習技術知識的話，應該是要總結出更多的思維，而不是真的要會寫代碼。以下按照界面和交互來總結一下技術思維的關注點。
界面組件上的應用：
（1）文本框
- 過長如何顯示：換行、顯示省略號；
- 如果換行和省略號都不要，就要確定文案最大字數；
- 數字保留多少位小數，四舍五入還是去尾或進1；
- 數字的顯示格式，例如：加逗號或加單位；
- 時間的顯示格式，例如：是否顯示分秒，日期間用中文還是橫線連接。
（2）輸入框
- 默認值；
- 占位符；
- 按下回車的行為；
- 自動補全的規則；
- 可輸入類型：純數字、文本（中文、外文、特殊字符），是否密碼；
- 輸入限制：文本長度、小數位數、取值范圍、最大最小值、是否必填。
（3）選擇框
- 默認狀態；
- 單選還是多選。
（3）下拉列表
- 默認值；
- 實際值與顯示值的對應關系：例如界面上顯示100+，實際值是135。
（4）按鈕：點擊后的行為
（5）彈框
- 位置：屏幕中間或中下；
- 顯隱動畫：時長、方式。
（6）表格：排序規則。
（7）開關：默認狀態。
（8）輪播
- 是否自動換頁，間隔時間；
- 是否顯示分頁器（“點點”或頁碼），是否可點擊分頁器來換頁；
- 是否可循環；
- 是否顯示進度條；
- 是否增加每頁邊距，邊距是多少。
（9）圖片
- 縮放規則，例如：固定寬度、高度隨原比例；
- 層級：誰可以遮蓋誰。
交互上的應用：
點擊：反饋形式（例如變色）。
手勢（例如右滑后退）：
- 距離；
- 速度；
- 方向。
界面切換：
- 動效：時長；
- 窗口、屏幕改變大小（橫豎屏切換）的布局規則；
- 已輸入的數據是否保留；
- 關聯關系。例如選中后會立刻改變其它控件的狀態。
本文為@運營喵原創，運營喵專欄作者。
