產品經理的需求（含PRD）能夠被精準不麻煩的復現，說明產品經理描述此需求比較清晰。

產品經理一般是通過先自我吃透需求，然後再對需求進行聚類、遞歸和因果表達出來。

如下圖：

作為產品經理（萬金油角色）也需要去梳理了解產品角色邏輯，方便更好的溝通交流，其實產品邏輯可以分為四大類：基礎產品邏輯、業務邏輯、系統邏輯和思維邏輯。一般通過四個方面如下：

業務邏輯篇

基礎產品邏輯篇

系統邏輯篇

思維邏輯篇

具體理解如下：

業務邏輯：需要業務夥伴解釋清楚：這個業務想為哪些用戶提供什麼樣的解決方案，目的是什麼？——業務評審會

產品邏輯：需要產品經理在這個場景中能滿足業務的哪些需求，通過原型交互方式、不同頁面的跳轉規則、角色判斷等來對項目組其他同事梳理清楚。——產品評審會

視覺邏輯：需要依託於產品經理做這樣的原型背景下，UI應該用怎樣的視覺來讓對應用戶沉浸在該場景中。——設計評審會

交互邏輯：UE協同產品經理表達怎樣的交互讓用戶感覺更加的友好，增強用戶的操作感——交互評審會（和產品評審會一起）

開發邏輯：有些邏輯可能用技術語言描述更清楚一點，以及對技術有特殊的要求。前後端介面、數據對接等。——介面評審會

至此描述一個需求功能點需要產品經理站在被傳達著的場景，思考被傳達者所了解的需求數據，如果他知道的不多，那麼產品經理幫忙補上。

這是一個比較大的問題，但可以簡單地回答幾個核心要點。

在回答之前，我覺得這個問題問的多少有些模糊，不夠清晰，比如：

  • 這個需求是否是關於軟體的需求？
  • 產品經理和誰清晰地描述？

不同的對象，描述的方法也會不太一樣。對業務有業務的描述方法，對技術有技術的描述方法。所以，在描述需求功能點的時候，一個最基本的規則就是：

用對方能夠聽懂而且可以深入理解、無歧義的方式來描述需求。

接下來我們假設這個問題是在問關於軟體的需求，我們來看一下某一個需求功能點的描述方式：

  1. 如果需求功能點比較小、比較簡單而且獨立，可以用User Story的方式來描述需求，如果情況剛好相反，那就用Use Case。
  2. 交互可以用低保真原型，如果一定要『清晰』，那就得用高保真了。
  3. 用文字的方式說清楚業務規則，可以舉例說明，這一步如果做的比較到位，測試用例也就快出來了。

通常來講，能做到以上3步，單一的需求功能點就已經很清楚了，如果還不夠，可以繼續：

  • 對於技術團隊，如果遇到了複雜的業務邏輯，文字描述容易引起歧義的話，偽代碼是消除歧義的必殺技。
  • 為了消除各方可能出現的歧義，需要說清楚項目的目標、需求的由來、相關的背景、制約的因素、未來的規劃、相關需求之間的關係等等。
  • 需求功能點不僅涉及到功能，通常還涉及到其他類型的需求，例如：性能、質量、管理、維護......，在必要的情況下，需要弄清楚，不要遺漏。

如果你做到了上面這些，可以說，單一的需求功能點已經清晰無歧義了，當然，還有一些方法可以在需求過程中保證需求功能點的清晰度，在這裡就不再展開了。

希望回答了你的問題。

先整理個名詞表，務必統一所有名詞及解釋。如果受眾無法接受英文縮寫，請務實一些，用樸實的中文 ------ 你信手拈來的 CP （內容方），你的程序員可能百度了一下，曲解成「情侶」。

複雜的功能點，說之前，自己先畫一遍；公開場合，自己先預演一遍。

能畫清楚的，不用加旁白，剩下的時間交給別人看、琢磨、提問題。

畫不清楚的，補文字，讓別人看的同時自己做解說。

如果是可視化產品，利用好原型工具，時間准許的前提下，事無巨細，盡量 100% 還原。

如果是非可視化的，學習使用各類流程圖。

不要試圖描述如何實現，不論是技術工作、美術工作、或者跑腿工作，只聊想要的結果。

最後，不論對方是否真的明白了，都要不厭其煩的從頭核對一遍。

補一個小故事：

15年前，要給公司開發一個網頁。

之前合作過的策劃（當時公司沒有產品經理這個概念，我們稱為策劃），通常是交給我一張A4紙，上面1、2、3、4的羅列功能，用心一點的會像寫論文一樣，每一點下面再羅列（1）、（2）、（3）小點，然後補充大量文字。

這次這個策劃有點特別，一個新入職的同事。他交給我一堆A4紙，大概60多頁，每頁紙上面都手繪了整張網頁的所有細節，然後在互動的元件邊上用類似 「word 批註」的方式繪聲繪色的描述為什麼有這個互動、要如何互動、互動後的結果、能解決的問題。

當時覺得他這個搞法很新穎，而且特別效率，頓時對他有了極大的好感。當然，直到今天我們也是非常好的朋友+合作夥伴。

他的這一套，之後有了更專業的說法和工具，比如原型設計（Axure），敏捷開發中的 user story 。

遇到腦子清楚的人，確實是工作中最值得慶祝的事兒。

以人為本，從用戶出發，找到用戶的需求點，根據這個需求點設計和開發產品，進而可以清晰的找到產品的需求功能點！

首先，先界定好你的產品要解決目標用戶的需求是什麼？這裡需要描述：

  • 你的目標用戶是什麼樣的？
  • 他們在什麼場景（時間、地點）產生了什麼樣的動機（問題、目標），因而產生了什麼需要？
  • 在這個過程中，你期望解決什麼問題，幫助用戶達成目標

其次，你為解決這個問題，提供什麼樣的解決方案？這裡需要描述：

  • 為什麼是這個解決方案？你的思考排序維度都是什麼？（投入產出比，試錯成本低還是商業價值等等）
  • 都有哪些功能集合來支持這個解決方案
  • 最核心而重要的功能是哪些？有哪些是非必要的功能（錦上添花，可捨棄的）？

最後，展開重要核心的功能詳細描述：

  • 用戶如何使用這個功能，也就是用戶流程
  • 關鍵的業務辭彙描述，讓協同者理解你傳遞的專業或業務辭彙，降低後續溝通成本
  • 明確描述驗收和走查的標準，讓開發和測試聚焦關鍵範圍

也可以參考如下需求文檔的樣例：

這是我們工作多年對需求描述的最好的實踐理解，希望能回答題主的問題，幫到你

說不清楚就畫出來，軟體用的不順手，就直接在紙上畫，如果畫都畫不出來，那麼就說明自己的思路還不清晰，繼續整理思路。如果能畫出來，那麼基本上也就可以清晰的表達清楚了

這個問題很抽象，而產品經理在實際工作中需要把抽象問題具體化，具體辦法就是明確問題的用戶場景目的。

所以我們首先要明確這個問題的三個重要要素，也就是，產品經理給誰講需求，背景是什麼，描述需求的最終目的是什麼？以下舉幾個例子:

  • 產品經理日常做技術評審，給開發講需求，希望開發理解需求並啟動排期上線計劃
  • 產品經理要做晉陞述職，需要給領導描述自己做過的需求，從而獲得認可和晉陞
  • 產品經理要與業務方同步需求方案（tob場景），確認該解決方案能夠解決問題，保證需求上線後符合業務方預期效果。

基於背景目的才能明確問題，才能明確解法。我們來簡單看下其中某個場景的解法:與業務方描述需求。

業務方關注的一定不是技術實現方式，而是這個需求能解決我什麼問題，我要怎麼用，效果是什麼。

  1. 解決什麼問題

開頭的描述往往就是介紹需求提出背景，誰遇到了什麼問題，影響有多大，相關涉及方都有誰。這樣雙方才能在同個目標去理解這個需求，這一步基本上也是其他場景介紹需求時必備項。

2. 要怎麼用

接著要闡述為了解決這個問題，設計相應的功能方案具體是什麼樣的。

基於這個功能，運營上線前需要做什麼操作？日常又要怎麼去使用，

3. 效果是什麼

最後一步也是最關鍵的，這個需求上線後可以帶來多少效益。這個效益如何體現，可以通過哪些數據指標進行觀察。

推薦閱讀：
相关文章