需求文檔需要描述清楚，做好細節(jié)處的處理，這樣才能讓測試和開發(fā)看懂，減少反復扯皮。本文作者從自身工作實踐出發(fā)，梳理總結了后端產品需求文章撰寫上需要注意的幾個問題，與大家分享。

01 原以為恰到好處的描述，或許不是最佳表達方式

怎么在PRD中表達“區(qū)間不能相互交叉”呢？

案例：

在一個Excel導入功能的需求中，要導入的內容是不同重量區(qū)間對應的費用計算規(guī)則。因此需求文檔中，要體現不允許重量區(qū)間交叉。

如何描述呢？舉例說明：

描述一：同一規(guī)則的任意兩條數據，其重量區(qū)間不能有交叉；

??描述二：同一規(guī)則的任意兩條數據，假設重量區(qū)間分別為a-b、c-d，那么若出現a<e<b、a<f<b、e<b<f、e<a<f中的任意一種情況，則視為這兩個重量區(qū)間交叉。

描述三：同一規(guī)則的各條數據，每一條數據的起點或終點，都不能介于其余各行的起點和終點之間。

分析：

描述一：同一規(guī)則的任意兩條數據，其重量區(qū)間不能有交叉；

看起來比較需求化，但實際上存在一個問題，就是沒有定義什么樣才算是交叉。

因此，是需求描述的不清楚。

如果產品經理認為交叉是個白癡問題無需定義（實際確實如此），但是開發(fā)的代碼如果寫錯，就會出現對標不一致。

換句話說，產品理解這句話，開發(fā)也理解這句話的意思，測試也理解，但是沒有確保大家的理解是一致的。

描述二：同一規(guī)則的任意兩條數據，假設重量區(qū)間分別為a-b、c-d，那么若出現a<e<b、a<f<b、e<b<f、e<a<f中的任意一種情況，則視為這兩個重量區(qū)間交叉。

比描述一更加具體化，抽象概括，給出了定義。但是實際上遇到的情況是，開發(fā)自己把自己搞糊涂了，最后開發(fā)看著描述三，才把代碼寫清楚。

描述三：同一規(guī)則的各條數據，每一條數據的起點或終點，都不能介于其余各行的起點和終點之間。

比起描述二，描述三的本質是一樣的，但是你會發(fā)現，換了一個簡單的描述方式，避免了一個先入為主的限制，給開發(fā)一些留白，又能不遺漏地去想自己的代碼。

02 蛛絲馬跡的疏忽，測試是否會放過？

案例：

電子合同的一個環(huán)節(jié)是簽章。點擊簽章按鈕，新窗口打開第三方外部鏈接，在第三方提供的外鏈上完成簽章操作?；氐巾撁?，狀態(tài)變?yōu)椤押炚隆?/p>

分析：

以上的描述似乎沒有問題，說清楚操作步驟，也要求頁面狀態(tài)變更。

但是忽視一個小問題：新窗口操作完成后，舊窗口不會知道狀態(tài)的變化，也就是缺少一個刷新狀態(tài)的功能。

這時候若用戶關閉外鏈接窗口，回到舊窗口頁面，是沒有變化的。因為一直在外鏈上操作，沒有在舊頁面實現任何觸發(fā)因素。

只有通過用戶手動點擊刷新舊頁面，或者自動刷新之后，才會反應過來。

因此，如果需求中不交代這個背景，開發(fā)不一定問，但測試可能就會問，這種情況算不算bug，因為文檔要求是狀態(tài)變更，而沒說手動過系統(tǒng)刷新該頁面之后產生狀態(tài)變更。

對此細節(jié)，若測試較真的，就需要補上。

比如明確不做自動刷新或刷新按鈕，手動加載頁面才刷新。

也可以說在外鏈完成的時候，提示的文案中寫清楚需刷新原頁面。

03 A/B方案的對決，是論據而非感覺

這個字段加在哪個模塊呢？

案例：

已知模塊：

商品管理后臺、活動配置后臺、C端商城常規(guī)區(qū)、C端商城促銷區(qū)

已知邏輯：

商品管理后臺的商品上架之后，進入C端商城常規(guī)區(qū)銷售；該狀態(tài)下的商品，才可以配置活動；配置之后，出現在C端商城促銷區(qū)；

需求：

個別用戶希望指定的商品在促銷區(qū)的時候，不要顯示在常規(guī)區(qū)。怎么解決？

方案：

希望在商品后臺，對商品增加一個字段：‘是否參與活動時不顯示在常規(guī)區(qū)’。

這樣上架的之后，一旦遇到有活動，則讀取商品配置的該字段的值，決定是否隱藏常規(guī)區(qū)的展示。

分析：

本質上C端只需要一個標示——是否只展示在促銷區(qū)。

那么對C端從哪里獲取都是一樣的。于是問題在于，放在商品這里合適嗎？或者還可以放在其他哪些地方？

• 從用戶場景來說，因為促銷活動，所以才引發(fā)了藥屏蔽常規(guī)區(qū)，因此創(chuàng)建活動的地方設置該字段，從心理距離上最近。
• 從操作上，配置促銷活動的同時，就在頁面上勾選是否僅顯示活動，也比較方便；

反過來：

• 如果做在商品后臺，那么每次用戶設置，都要從一個場景切換回到一個（較為低頻的）基礎商品庫中配置，顯然比較有距離感；
• 此外，活動是可以擴展的。因此該設置是商品+活動維度的。放在活動配置的位置直接就是一對一。而放在商品的位置就要不斷增加活動類型的值，形成一對多的配置對，顯然不方便。

結論顯而易見，將該功能放在活動配置后臺。

04 把權威給到設計師是臨時的，產品把關是永恒的

有時候，產品經理不負責頁面的設計。就會讓設計師設計了頁面，配合產品的PRD，交給開發(fā)。

如下圖這樣，將翻頁放在這個位置，看起來貌似挺挺緊湊。毫無違和。

但實際上用起來一定不舒服。

因為用戶習慣是拉到最下方的時候，準備翻看下一頁，這時候發(fā)現需要爬樓到上方找按鈕。就算是將下一頁固定吸頂，也需要移動注意力的位置。

#專欄作家#

唧唧歪歪PM，公眾號：唧唧歪歪PM（ID：jjyypm），人人都是產品經理專欄作家。書籍《后端產品經理寶典》作者，藥學碩士轉行互聯(lián)網產品多年；熟悉跨境電商業(yè)務，醫(yī)藥領域；擅長大型后臺體系，社交App。

本文原創(chuàng)發(fā)布于人人都是產品經理，未經作者許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議