綜述

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

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

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

1. 元件與模組。
2. 流程與聯絡。
3. 條件與時機。
4. 型別與精度。

測試也會有獨特的思維：

1. 極端。
2. 因果。
3. 場景：一系列的組合條件。

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

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

開發思維：元件與模組

我們寫文章都不是從頭到尾就一段話的，會分段落、章節，這樣能幫助做到條理清晰。程式碼的本質也是“文章”，元件和模組就像是段落和章節，他們會對應一個功能、介面或規則。為此，需求本身也應有拆分：產品有結構，功能有細分，介面分割槽塊等。

產品結構圖就像文章的目錄，在做新專案的時候應該附上。它不僅幫助產品經理自己梳理子需求，也讓整個專案組都清晰知道產品的構成，對開發、測試、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匯出網頁給技術同事看，以上原則都是適用的：幫助提升閱讀效率。

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

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

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

思維應用

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

介面元件上的應用：

• 文字框
  • 過長如何顯示：換行、顯示省略號
  • 如果換行和省略號都不要，就要確定文案最大字數
  • 數字保留多少位小數，四捨五入還是去尾或進1
  • 數字的顯示格式，例如加逗號或加單位
  • 時間的顯示格式，例如是否顯示分秒，日期間用中文還是橫線連線
• 輸入框
  • 預設值
  • 佔位符
  • 按下回車的行為
  • 自動補全的規則
  • 可輸入型別：純數字、文字（中文、外文、特殊字元），是否密碼
  • 輸入限制：文字長度、小數位數、取值範圍、最大最小值、是否必填
• 選擇框
  • 預設狀態
  • 單選還是多選
• 下拉列表
  • 預設值
  • 實際值與顯示值的對應關係：例如介面上顯示100+，實際值是135
• 按鈕：點選後的行為
• 彈框
  • 位置：螢幕中間或中下
  • 顯隱動畫：時長、方式
• 表格
  • 排序規則
• 開關
  • 預設狀態
• 輪播
  • 是否自動換頁，間隔時間
  • 是否顯示分頁器（“點點”或頁碼），是否可點選分頁器來換頁
  • 是否可迴圈
  • 是否顯示進度條
  • 是否增加每頁邊距，邊距是多少
• 圖片
  • 縮放規則，例如固定寬度、高度隨原比例
• 層級：誰可以遮蓋誰

互動上的應用：

• 點選：反饋形式（例如變色）
• 手勢（例如右滑後退）
  • 距離
  • 速度
  • 方向
• 介面切換
  • 動效：時長
  • 視窗、螢幕改變大小（橫豎屏切換）的佈局規則
  • 已輸入的資料是否保留
• 關聯關係。例如選中後會立刻改變其它控制元件的狀態