比描述一更加具體化，抽象概括，給出了定義。
但是實際上遇到的情況是，開發自己把自己搞糊涂了，最后開發看著描述三，才把代碼寫清楚。
描述三：同一規則的各條數據，每一條數據的起點或終點，都不能介于其余各行的起點和終點之間。
比起描述二，描述三的本質是一樣的，但是你會發現，換了一個簡單的描述方式，避免了一個先入為主的限制，給開發一些留白，又能不遺漏地去想自己的代碼。
02 蛛絲馬跡的疏忽，測試是否會放過？案例：電子合同的一個環節是簽章。點擊簽章按鈕，新窗口打開第三方外部鏈接，在第三方提供的外鏈上完成簽章操作?；氐巾撁?，狀態變為‘已簽章’。
分析：以上的描述似乎沒有問題，說清楚操作步驟，也要求頁面狀態變更。
但是忽視一個小問題：新窗口操作完成后，舊窗口不會知道狀態的變化，也就是缺少一個刷新狀態的功能。
這時候若用戶關閉外鏈接窗口，回到舊窗口頁面，是沒有變化的。因為一直在外鏈上操作，沒有在舊頁面實現任何觸發因素。
只有通過用戶手動點擊刷新舊頁面，或者自動刷新之后，才會反應過來。
因此，如果需求中不交代這個背景，開發不一定問，但測試可能就會問，這種情況算不算bug，因為文檔要求是狀態變更，而沒說手動過系統刷新該頁面之后產生狀態變更。
對此細節，若測試較真的，就需要補上。
比如明確不做自動刷新或刷新按鈕，手動加載頁面才刷新。
也可以說在外鏈完成的時候，提示的文案中寫清楚需刷新原頁面。
03 A/B方案的對決，是論據而非感覺這個字段加在哪個模塊呢？
案例：已知模塊：
商品管理后臺、活動配置后臺、C端商城常規區、C端商城促銷區
已知邏輯：
商品管理后臺的商品上架之后，進入C端商城常規區銷售；該狀態下的商品，才可以配置活動；配置之后，出現在C端商城促銷區；
需求：
個別用戶希望指定的商品在促銷區的時候，不要顯示在常規區。怎么解決？
方案：希望在商品后臺，對商品增加一個字段：‘是否參與活動時不顯示在常規區’。
這樣上架的之后，一旦遇到有活動，則讀取商品配置的該字段的值，決定是否隱藏常規區的展示。
分析：本質上C端只需要一個標示——是否只展示在促銷區。
那么對C端從哪里獲取都是一樣的。于是問題在于，放在商品這里合適嗎？或者還可以放在其他哪些地方？
從用戶場景來說，因為促銷活動，所以才引發了藥屏蔽常規區，因此創建活動的地方設置該字段，從心理距離上最近。從操作上，配置促銷活動的同時，就在頁面上勾選是否僅顯示活動，也比較方便；反過來：如果做在商品后臺，那么每次用戶設置，都要從一個場景切換回到一個（較為低頻的）基礎商品庫中配置，顯然比較有距離感；此外，活動是可以擴展的。因此該設置是商品+活動維度的。放在活動配置的位置直接就是一對一。而放在商品的位置就要不斷增加活動類型的值，形成一對多的配置對，顯然不方便。結論顯而易見，將該功能放在活動配置后臺。04 把權威給到設計師是臨時的，產品把關是永恒的有時候，產品經理不負責頁面的設計。就會讓設計師設計了頁面，配合產品的PRD，交給開發。如下圖這樣，將翻頁放在這個位置，看起來貌似挺挺緊湊。毫無違和。但實際上用起來一定不舒服。因為用戶習慣是拉到最下方的時候，準備翻看下一頁，這時候發現需要爬樓到上方找按鈕。就算是將下一頁固定吸頂，也需要移動注意力的位置。05文字描述不出來，只能用流程+圖+文字下面這個需求，背景是用支付平臺的結算規則計算應結算的金額，最終于平臺的擬結算金額對賬。但是支付平臺多，賬號多，對比雙方的起始數據表多，還要做數據多層清洗計算。其中最難的就是數據計算，PRD需要定義數據的取值。數據規則是第三方支付平臺制定的，所以基本難以以常識去理解，只能去認識。這也意味著PRD的主要職責是講清楚規則。但是規則太復雜，怎么辦？先定模型：就以從哪里出發，經過什么規則，得到數據。但是發現還是很難以文字描述，因為參數的判斷來回反復交叉在多表之間。還有很多分支要素要判斷。最終以這樣的方式呈現：其中的圖示是這樣的，因為這個規則太難寫，就畫了個取值的流程圖。-完-掃碼關注我們
微信號:jjyypm
“超時”機制總共有哪些？“加載超時”只排第三盤點PRD中遺漏的三類非正面需求App產品原型背后要交代的細節或要理解的原則（二）我的新書<后端產品經理寶典>——捭闔在前，布局在后
[責任編輯：h001]
(資料圖片)
