總有一些小需求，根本寫不出PRD——姜太公公

你是否遇到過寫不出PRD的小需求呢？也就是我們經常說的“一句話需求”。

加個按鈕，改個顏色，加個跳轉，刪除個邏輯……blabala～ 這種情況下，你說寫PRD吧？寫10個字兒寫完了。不寫PRD吧？和開發童鞋直接溝通，，開發完成后發現和預期相差八百里。那么，你是怎么處理“一句話需求”的呢？你在處理過程中和開發溝通的愉快嗎？

舉一個實際例子：

產品：在這個頁面增加一個「回到頂部的按鈕」。這個需求的場景是用戶在列表頁一直滑滑滑，突然想回到頁面頂部，這個按鈕可以幫手用戶快捷回到頂部

技術：好的

一天之后……

產品：這個「回到頂部按鈕」為啥出現在首屏？我還沒有滑呢為啥它就出現了？這時候不需要回到頂部啊？技術：你說過嗎？

所以你看，“一句話需求”真是說時一時爽，上線之后都是填不完的坑。

那么問題來了，為啥給開發講“一句話需求”開發總是做的跑遍了？明明是一個很簡單的需求啊！

其實，“一句話需求”沒有錯，錯的是你踩了“場景”和“實現效果”兩個大坑。要高效的溝通“一句話需求”，可以嘗試的遵守如下兩個原則：

原則一：“一句話需求”不要談場景，要講“當前狀態”！

原則二：“一句話需求”不要談實現效果，要講“用例”！

原則一：“一句話需求”不要談場景，要講“當前狀態”！

什么是場景？簡單來說，就是什么人在什么時間什么地點做了什么事情產生什么結果（who+when+where+what+how）

產品經理必需會談「場景」。就像一個情場老手必需時刻把“我愛你”掛在嘴邊一樣。有了它，你幾乎戰無不敗。直到某一天你遇到一個開發，你手捧粘著露水的玫瑰，深情滿滿的說“我愛你”，開發扣著腳說“啥？”，想想也是夠掃興的了。

那正確的姿勢是什么？描述當前狀態。

如下圖，故事原作者是「老李說」，圖片截取自UI中國

回到上文加「回到頂部按鈕」的例子，產品說的“這個需求的場景是用戶在列表頁一直滑滑滑”就是這個需求的場景……

這樣的描述，開發會有如下疑惑：

列表頁：哪個列表頁？搜索結果頁，促銷列表頁？是只加單個列表還是全局添加？列表頁狀態：在初使狀態是否添加「回到頂部按鈕」？在空狀態時是否添加「回到頂部按鈕」

正確的描述應該是：

在“搜索結果頁”，用戶處于瀏覽態（沒有任何「可點擊浮層」覆蓋在“搜索結果頁”上），而且當前曝光商品處于屏幕的非首屏，此時需出現一個「回到頂部按鈕」。備注：只要滿足上面的條件，無論上滑手勢或者下滑手勢都可吊起「回到頂部按鈕」展現

正確的描述“當前狀態”，應該盡可能用結構化的語言。結構化的目的是為了讓“一句話需求”的表達更加接近于開發思維，從而減少和開發的信息理解分歧錯誤稱。下面是幾種常見的“當前狀態”的描述，可以進行參照：

當前的物理狀態是什么？斷網狀態，網絡欠好狀態，網絡通暢狀態……當前的用戶狀態是什么？瀏覽狀態，確認狀態，輸入狀態，等待狀態，初始狀態……當前的頁面狀態是什么？無結果狀態，處于第幾屏，是否為疊加層……原則二：“一句話需求”不要談實現效果，要講“用例”！

“一句話需求”講實現效果可以嗎？可以是可以，但是問題是，實現效果是一種感性的描述，而開發是理性的動物。這就是我們的代溝。當你說出實現效果時，你的邏輯是：「首先腦海中有畫面，然后話語描述實現效果」

可是開發通過你的一句話可以準確的倒推回和你腦袋里面的畫面嗎？

回到上文加「回到頂部按鈕」的例子，產品說的“用戶突然想回到頁面頂部，這個按鈕可以幫手用戶快捷回到頂部”是這個需求的實現效果……

那怎樣的描述可以更加精準的幫手開發理解呢？講用例。用例是用戶完成目標的方法和步驟。告訴開發用戶的任務，前置條件，用戶做了怎樣一個操作。

正確的描述應該是：

前置條件：用戶點擊手勢或者長按后的松開手勢預期結果：頁面回到頂部，「回到頂部按鈕」消失總結

為啥把“一句話需求”單獨拎出來，一方面是有的需求小的根本無法寫出PRD，另一方面本著敏捷開發的原理，處理好“一句話需求”可以幫手我們團隊提升效率。那么PRD怎么寫呢？下回分解吧。

PS： 你被哪些“一句話需求”坑過嗎？歡迎大家留言踴躍留言

作者：姜太公公 ?(微信號公眾號：grandpa_jiang) ?產品老流氓，終身學習者。致力于研究產品方法論，解決小白PM的疑難雜癥。

標簽：九江 林芝 烏魯木齊 鹽城 東營