• <menu id="gokgi"></menu>
    <nav id="gokgi"><nav id="gokgi"></nav></nav> <menu id="gokgi"><tt id="gokgi"></tt></menu>
    您的位置:首頁 >聚焦 >

    全球播報:5個案例:難以描述的需求,PRD越抹越黑?

    2023-01-07 12:39:14    來源:程序員客棧
    本文作者從自身工作實踐出發,梳理總結了PRD撰寫上需要注意的幾個問題,與大家分享。
    01 原以為恰到好處的描述,或許不是最佳表達方式

    怎么在PRD中表達“區間不能相互交叉”呢?

    案例:

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


    【資料圖】

    如何描述呢?舉例說明:

    描述一:同一規則的任意兩條數據,其重量區間不能有交叉;

    描述二:同一規則的任意兩條數據,假設重量區間分別為a-b、c-d,那么若出現a

    描述三:同一規則的各條數據,每一條數據的起點或終點,都不能介于其余各行的起點和終點之間。

    分析:

    描述一:同一規則的任意兩條數據,其重量區間不能有交叉;

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

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

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

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

    描述二:同一規則的任意兩條數據,假設重量區間分別為a-b、c-d,那么若出現a

    比描述一更加具體化,抽象概括,給出了定義。

    但是實際上遇到的情況是,開發自己把自己搞糊涂了,最后開發看著描述三,才把代碼寫清楚。

    描述三:同一規則的各條數據,每一條數據的起點或終點,都不能介于其余各行的起點和終點之間。

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

    02 蛛絲馬跡的疏忽,測試是否會放過?案例:

    電子合同的一個環節是簽章。點擊簽章按鈕,新窗口打開第三方外部鏈接,在第三方提供的外鏈上完成簽章操作?;氐巾撁?,狀態變為‘已簽章’。

    分析:

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

    但是忽視一個小問題:新窗口操作完成后,舊窗口不會知道狀態的變化,也就是缺少一個刷新狀態的功能。

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

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

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

    對此細節,若測試較真的,就需要補上。

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

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

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

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

    案例:

    已知模塊:

    商品管理后臺、活動配置后臺、C端商城常規區、C端商城促銷區

    已知邏輯:

    商品管理后臺的商品上架之后,進入C端商城常規區銷售;該狀態下的商品,才可以配置活動;配置之后,出現在C端商城促銷區;

    需求:

    個別用戶希望指定的商品在促銷區的時候,不要顯示在常規區。怎么解決?

    方案:

    希望在商品后臺,對商品增加一個字段:‘是否參與活動時不顯示在常規區’。

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

    分析:

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

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

    從用戶場景來說,因為促銷活動,所以才引發了藥屏蔽常規區,因此創建活動的地方設置該字段,從心理距離上最近。從操作上,配置促銷活動的同時,就在頁面上勾選是否僅顯示活動,也比較方便;反過來:如果做在商品后臺,那么每次用戶設置,都要從一個場景切換回到一個(較為低頻的)基礎商品庫中配置,顯然比較有距離感;此外,活動是可以擴展的。因此該設置是商品+活動維度的。放在活動配置的位置直接就是一對一。而放在商品的位置就要不斷增加活動類型的值,形成一對多的配置對,顯然不方便。結論顯而易見,將該功能放在活動配置后臺。04 把權威給到設計師是臨時的,產品把關是永恒的有時候,產品經理不負責頁面的設計。就會讓設計師設計了頁面,配合產品的PRD,交給開發。如下圖這樣,將翻頁放在這個位置,看起來貌似挺挺緊湊。毫無違和。但實際上用起來一定不舒服。因為用戶習慣是拉到最下方的時候,準備翻看下一頁,這時候發現需要爬樓到上方找按鈕。就算是將下一頁固定吸頂,也需要移動注意力的位置。05文字描述不出來,只能用流程+圖+文字下面這個需求,背景是用支付平臺的結算規則計算應結算的金額,最終于平臺的擬結算金額對賬。但是支付平臺多,賬號多,對比雙方的起始數據表多,還要做數據多層清洗計算。其中最難的就是數據計算,PRD需要定義數據的取值。數據規則是第三方支付平臺制定的,所以基本難以以常識去理解,只能去認識。這也意味著PRD的主要職責是講清楚規則。但是規則太復雜,怎么辦?先定模型:就以從哪里出發,經過什么規則,得到數據。但是發現還是很難以文字描述,因為參數的判斷來回反復交叉在多表之間。還有很多分支要素要判斷。最終以這樣的方式呈現:其中的圖示是這樣的,因為這個規則太難寫,就畫了個取值的流程圖。-完-

    掃碼關注我們

    微信號:jjyypm

    “超時”機制總共有哪些?“加載超時”只排第三盤點PRD中遺漏的三類非正面需求App產品原型背后要交代的細節或要理解的原則(二)我的新書<后端產品經理寶典>——捭闔在前,布局在后

    關鍵詞: 產品經理 任意一種 自動刷新

    相關閱讀

    和老少妇做真爽
  • <menu id="gokgi"></menu>
    <nav id="gokgi"><nav id="gokgi"></nav></nav> <menu id="gokgi"><tt id="gokgi"></tt></menu>