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