編輯導語：產品經理在日常工作中，經常要做需求講解，而需求講解的質量對需求的範圍，團隊的效率、認可度等方面有很大的影響。那麼，如何做好一場需求講解呢？本文作者提出了幾點建議，一起來看一下吧。
產品、需求在日常工作中，少不了做需求講解，像我們團隊可能兩周就要組織一波評審。有時涉及到交付團隊的需求支持，售前團隊的產品演示，相關講解會更頻繁。
在近兩年持續的講解過程中，發現了主講人一些共性的問題，並通過幾個月的嘗試讓組內的小夥伴逐漸掌握了基本講解能力，今天歸納出來供大家參考，各位有什麼其他好方法也歡迎留言交流。
需求講解的質量不僅影響理解效果、評審效果，更可能對需求的範圍，團隊的效率、認可度等方面產生深遠影響，其重要性不言而喻。
01 先拋幾個最常見問題
- 上來直接講功能
- 不管聽眾是誰，講解內容基本不會變化
- 主講人的得失心太重，反而影響了語言表達的準確性
- 沒有提前演練（準備講一小時，實際上40分鐘就講完了。漏講、節奏亂、不通暢、斷片了）
- 沒有真正理解吸收，過程不自信，問題解答不好
其他的問題大家可以自由補充。
那麼我們可以從哪些方面來著手解決這些問題呢？
02 區分人群（見人說人話，見神說神話）
一定要根據聽眾的不同，差異化整理自己的話術，包括講解的細緻程度。
可能文檔都是一樣的，但是給項目經理講、給開發人員講、給測試人員講、給需求組同事講、給領導講，側重點一定是不一樣的。
組內的同事要細講，現狀、業務規則、交互規則、關聯功能、處理邏輯，在時間充裕的前提下，能多講點就多講點。
如果是項目經理或者測試人員，還可以把自己這樣設計的原因、思路說出來，讓大家都能與你共情。同時關聯功能、關鍵功能記得講解的時候時不時「敲敲黑板」提醒大家注意。
給領導講更多的是講解原因、思路、目標、效果，並將所涉的難點或需要領導重點關注的問題說出來。
如果給客戶講，又是一種方式。
看講解的背景：是售前階段，還是需求初期，還是需求評審，亦或是上線培訓。
看聽眾的身份：甲方的領導、業務方、測試方、技術方、還是最終使用的用戶。
這裡簡單區分一下，不展開介紹：
- 售前階段：更重要的是講解價值、定位、目標客群及各角色的使用場景
- 需求初期：重點是先讓聽眾和我們的方案思路達成一致，同時關聯實施路徑，不用講太細節的內容
- 需求評審：注重整體方案邏輯及關聯方如何配合，細節的內容要挑重點功能進行細緻講解
- 培訓階段：更注重如何使用、常見問題如何應對等方面
總之一句話「看人下菜碟」，切莫一套話術講到地老天荒。
03 從宏觀到微觀（由淺入深，抽絲剝繭）
講解正式開始的時候，無論是0-1的新需求，還是優化疊代需求，都要先介紹一下背景、用戶角色、整體場景、使用流程，讓大家對本次講解有個基礎的認知同頻。然後再開始按場景優先級進行功能介紹、規則介紹。
就像拆一個快遞盒一樣。先看收件人和發件人是誰，然後打開箱子看到禮物的外包裝，整體的長寬高，顏色形狀。然後打開外包裝，發現裡面有三個小盒子。再逐一開箱「品鑑」。
04 場景代入（變枯燥為生動）
人的大腦更容易接收「故事」而非「概念」。所以講了一段「概念」後，一定要穿插一個「故事」，最好是真實的例子。如果是大家身邊的例子，效果就更好了。
在這裡我也拿一個大家能快速理解的場景「舉個栗子」：比如很多公司的OA，或者人事財務類管理平台會有「線上算薪」功能，也就是把每個月財務給大家計算工資的過程通過此功能線上計算（釘釘、HRSaaS等多類產品均有此模塊）。針對這個模塊，下面三種風格的講解思路高下立判。
薪酬計算這個模塊分為了以下幾個大功能：
- 應發工資計算
- 社保計算
- 個稅計算
- 實發工資計算
- 社保方案維護
- 算薪方案維護
- 員工薪酬檔案管理
下面我們來具體看每個功能是怎麼實現的。
如果想完成線上的薪酬計算，我們需要先維護好各個員工的薪酬檔案，也就是每個人的基本工資、補助之類的信息；然後制定每個人的算薪公式，五險一金繳納方案。
這些前期準備完成之後，每次線上算薪時，先通過每個人的算薪公式和工資項，計算我們的應發工資；然後通過應發工資和五險一金方案計算我們的社保扣除金額；然後計算我們的個稅，最後相減得出我們的實發工資。
我們公司每個月給大家算工資的時候，財務或者人事都要先根據咱們的考勤、績效、請假、加班等信息，按照公司的算薪公式計算出大家的應發工資，或者叫稅前工資。
然後根據咱們五險一金的繳納比例、基數來計算我們這個月各項社保、公積金的扣除金額；然後再給大家算這個月應該扣除多少錢的個人所得稅；最後通過應發工資再減去要扣除的社保、個稅，得出我們的實發工資。
在這個過程中，衍伸出來了我們今天要講解的幾個核心功能：
而在正式計算之前，公司要先知道我們每個人的固定收入是多少，工資組成是怎樣的，五險一金繳納比例和基數是怎樣的。所以系統需要通過「員工薪酬檔案」、「算薪方案」、「社保方案」幾個功能來配置生成這些信息，從而完整的完成我們算薪過程。
下面我們來具體看這些功能的描述和規則。
這三種表達方式在實際講解中都是存在的，而且以前兩種尤其是第一種居多。而且我們會發現一個神奇的現象：字多的比字少的聽起來更容易理解。
因為我們需要在具體的需求講解之前，先讓聽眾對所涉及的功能有一個清晰的認知。通過現實生活中的場景代入，衍伸類比出系統中的抽象功能，大家才能真正明白這些功能是要解決什麼問題。在聽的時候才能具象地引出高質量的疑問。所以這個過程一定要精心的準備且多費一些口舌才行（當然廢話不算）。
即便這樣，我們也會經常發現講完之後，對方的提問明顯是沒聽明白……當然也可能是他個人的問題。對於講解人來說，一次講解能夠保證大多數人能思維同頻，認知一致就已經很厲害了。
同時場景代入不僅僅是開頭，後面涉及到具體需求講解時，對於一些相對複雜、或者認為聽眾容易產生歧義的功能，依然可以通過這種方式來提升效果。
代入場景的過程也需要講解人提前準備、反覆斟酌。一定要避免用錯場景的情況發生，否則得不償失。
05 多練（勤能補拙）
去年有一位新同事，按照團隊的培訓計劃進行產品學習，並在一周後進行產品講解。第一次講解的效果非常差，雖然他準備了兩大篇稿子，但真正脫稿講的時候只講了15分鐘就因為屢次卡殼放棄了。
之後我又給了他一天時間準備。我發現那一天他一直在會議室里演練，在黑板上反覆畫圖。自然而然第二次講解能夠通過考核。
所以即便我們準備好了提綱、稿子，乃至PPT的備註。真正在正式講解的時候，如果沒有多次演練，那效果一定不會好。
06 能脫稿最好（對內容全然吸收後的輸出最有魅力）
很多需求人員前期對自己所涉業務有了初步認知後，經過多次練習便能夠順利的完成一次講解。但是在答疑過程還是會發現很多問題不知道怎麼解答。
能夠做好一場準備充分的講解只是完成了第一步【熟練】，真正第二步的【掌握】則是需要長時間的積累、思考，以及全面的答疑才能最終爛熟於心，隨用隨取。
自己的思考也很容易陷入思維怪圈，無法全面的發現問題。所以要多和團隊內部各個崗位的同事交流。看看他們對這個需求的認知、理解、疑問。從而在這個過程中完善自己的想法。
同時在上一段提到的反覆練習過程中也可以同步思考，講到哪裡，聽眾可能會提什麼樣的問題，我要如何應答。尤其是自己在設計過程中的疑問是如何解決的，其他人也很有可能有相似的問題。
而且不同的聽眾關注點不同，問的問題也不盡相同，我們要儘可能多角度思考，以備不時之需。
真正的大佬們一定是經歷過幾十甚至上百次不同場景、不同人群、不同業務的講解、吸收、思考之後才形成隨機應變的能力。
正所謂「見多識廣」。
07 多復盤（在復盤中快速進步）
每次講解完成之後都要整理大家的提問清單，事後再考慮一下如何更好地回答，以後肯定用得上。
講解的過程，尤其是前幾次的講解，有條件的話，能錄音最好全程錄音，事後再聽幾次，在復盤中讓自己對本業務的認知更豐滿，發現自己現場無法察覺的問題以及可提升的小細節。
其中小細節一定不能忽視，它遲早會成為你前進路上的絆腳石。如不合適的口頭禪，不合適的停頓，重點內容的抑揚頓挫及語氣重音，都是在後續需要注意的。
08 其他小技巧（能掌握一個賺一個）
- 直接：語言要簡單明確，不要有過多的無效解釋，無效修飾。
- 互動：階段性與聽眾有些小互動，或提問，或眼神交流，以便讓大家更專注。
- 動作：講解過程中的手勢、表情等，能夠讓聽眾從外在更接受你的內容。
- 自信：即便你現在說的不一定對，但是你自信的表達出來，對方大概率也不會追問，後續思考過程中發現了問題，那就再私下解決。
- 問題複述：如果有些問題你是第一次聽，可以先向提問者複述一遍問題，以確認對問題的理解是否有偏差。同時這個過程也能給你增加幾秒「寶貴的」考慮時間。有時候還可以通過對方的提問發現他的理解可能存在誤區，這時候就可以順勢進行糾偏。
- 把握時間：無論是一場正式的會議，還是一次短暫的討論，或者是一個臨時的「電梯演講」，對時間的把握是非常重要的一環。心裡始終裝著一塊表，隨時提醒自己並調整講解節奏。
09 寫在最後
其實，做好需求講解，不僅僅是需求人員、產品人員的必備技能，對於項目經理、運營等需要經常與不同類人群有工作交集的崗位，如果能掌握更清晰簡潔的講解方式，在工作中都會得心應手。即便是一名開發人員，能夠把自己所涉業務很好的講出來，也能在眾多同事中脫穎而出。
同時文中提到的一些方法，不僅限於需求講解，在其他交流場合也是互通的（如員工培訓、測試用例評審、運營方案介紹等）。
篇幅所限，更多的場景和內容，大家可以結合自己的業務靈活擴展。
言而總之：溝通是一門藝術，願我們都能成為一名優秀的「藝術家」！
公眾號：不想延期了本文由 @不想延期了 原創發布於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基於CC0協議。