workshop，也就是我們常說的需求訪問會。在workshop中，業務雙方會對產品需求進行初步溝通與評估，筆者結合自己的經驗，和我們一起聊聊B端產品的需求訪問是怎么樣的。

一、什么是workshop

各位B端產品/需求分析的同學一定對workshop這個名詞不陌生，它的中文名是需求訪談會。個人對C端產品不熟，本文也僅就B端產品的訪談聊一聊個人經驗。本文適合0~3歲的產品同學。

一般而言，workshop指的是就某一議題的面對面需求溝通會議，用于溝通業務現狀、痛點，并初步評估需求的可行性及方案，及傳達初步方案。

一般成員包括：

• 業務
• 產品經理
• 架構師/資深開發

一場好的workshop應該至少做到以下幾點：

• 業務關鍵流程及關鍵需求點達成決策；
• 評估需求可行性，對于簡單需求可形成各方滿意的初步方案；
• 識別并剔除不合理需求（例如：需求無邏輯或實際可能發生的業務支撐、投產比太低、造成項目風險的需求）；
• 形成清晰的會議紀要/需求文檔。

痛點

Workshop的特點是信息密集，背景了解較少，因此造成溝通較難。以下列舉我在過去幾年中常見的痛點：

• 業務需求溝通不到位：如遺漏、錯誤；未挖掘真實需求導致需求易變更；
• 方案可實施性差導致需求重談；
• 需求管控失?。喝缗茴}導致需求無法充分表達、無限發散、接受不合理需求等。

以下將根據經驗方法，按照workshop的各個環節展開闡述如何避免痛點、達成目標。

二、事前準備

1. 了解背景

會前需盡可能了解以下信息：

（1）溝通的主題

若溝通主題是他人發起的，則需要了解主題的業務知識，最好是該公司/部門目前的業務。若無法獲知，則應了解行業或龍頭的業務模式和解決方案，可在后續溝通中獲得優勢。

還需了解本次溝通的目的是為了解決什么問題，例如解決現有系統功能不好用的問題，則應盡量了解當前的系統操作。有條件的可以去測試環境等操作一下。

（2）對方的部門架構

Workshop費時費力，我們應了解對方部門的架構，確保溝通對象能決策溝通主題，或至少能負責大部分問題。對于中途加入的溝通對象，應了解或詢問其崗位。比如：這位也是你們做運營的同事嗎？和你一樣負責系統對接嗎？

以上問題也適用于溝通過程中出現的新主題、新加入訪談的成員。

前一陣某知名咨詢公司來我司訪談，他們主訪談顧問都不問一下我司甲方參會的是誰，于是在一屋子業務中，選擇問一個新人程序員業務流程，結果后面結論推翻重新談。

（3）溝通對象的能力

我們需要找到一個熟悉業務/系統的人進行溝通。若已知該對象的能力不行，則可以在初期嘗試換人或找到其他外援同事。換不了是大多數，但是如果外援都找不到那就會累死自己和項目。

外援可以是你同行其他公司的朋友（他們的意見只能作為參考），也可以是業務部門的其他負責相似模塊的同事。

（4）我方領導的要求

我方領導掌握著資源，不搞清楚他們要什么、能接受什么，可能要命。大需求workshop之前，需要著重弄清楚領導對需求的定位（什么時候愿意投入多大資源），至少受到領導的授權。

2. 安排人員

一個流程完善的公司，一場需求評審會要產品、業務、運營、UI、開發、測試、架構師等角色參與。同樣，在workshop階段，也有其人員安排：

• 1~2名產品（依據溝通會內容復雜度、長度而定，可用錄音筆挽救）
• 資深開發/架構師一枚
• 可決策的業務

確定人員后，對于內部team（其他產品和開發）還需做以下事情，用于培養默契：

• 互相傳遞了解的業務背景
• 預估會議溝通難度、難點
• 明確主旨和互相配合點

特別強調一下要帶開發，因為哪怕真的很簡單的功能，你的開發可能會告訴你不能做，所以需要一個技術伙伴實時幫你評估，幫你懟其他開發，還能從技術角度幫你懟需求。

3. 安排場次

在workshop之前，需逐步了解信息以合理安排后續訪談計劃：

• 根據業務知識和項目/需求背景，找準對接人。
• 通過最初溝通了解需求框架和主要關聯方，然后安排后續的workshop：
• 首先需組織一場項目/需求背景介紹會議，務必請對接人協助邀請各個關聯方參與。會后需收集關聯方的態度和意見，明確后續對接人，并及時反饋各方領導。
• 后續根據需求細節安排主題相關的會議即可，但是每場會議都要事前明確溝通主題，時間和會議室盡早預定。
• 最后，需求內容定稿階段，組織一次各方參與的會議評審，此次會議不強求各方參與、但需知會各方。

關于會議時間的選擇，時長最好在2小時內，并且安排在上班半小時后、下班半小時前。如需其他人加班支持，最好事先面對面溝通請求幫助。

三、事中溝通

在溝通前，我們已經做了大量鋪墊，這會大大提升我們的自信。訪談主要目的不是交朋友，而是對外理解需求，明確需求、挖掘需求、引導需求；對內傳達需求，確保隊友理解主框架，減少會后再次溝通工作量。

1. 抓議題

當會議較為順利、人員溝通能力較好時，會議容易出現發散的情況。無關話題發散超過0~2分鐘就必須打斷。

另一種常見情況是，內容相關但是層次不對，例如在溝通框架的會議上過多地討論細節，也需要打斷。

對于會議主持者，要知道什么話題會易于帶來發散和細節討論，并在自身避免。

能判斷什么話題需要打斷，討論的東西能否幫助解決問題，無關的及時打斷。其次方式要合適，例如：你的點很有用，我記下來了，后面細節討論的時候再說，我們現在先看XX問題。

2. 打破僵局

與上面一種情況相反的是，會議陷入僵局。你需要分析僵局的原因，例如：

• 參會人不知主題/其他人員，則需介紹背景。
• 被技術/業務性問題卡住，則可以抓大放小，能不糾結的就先過；對于較大問題可詢問誰懂這一塊，能否現在邀請參會。
• 被制度流程性、決策性問題卡住，大多數情況則需了解問題找哪位領導拍板，并給出可能結果的對應方案，重大問題不要擅作決定。例如：回去你和你們李總溝通一下，如果要做，我們就XXX；如果不做，我們也向領導反饋為什么不做。
• 對方故意不配合，若感受到這一點，則需說明來意，放低身段，可以說是雙方領導安排，可以表明合作的好處，但不要自恃專業、表達高人一等情緒。
• 對方描述不清楚問題，這種情況需要你用清晰的邏輯幫忙梳理流程、問題。

對于暫時無解的阻斷性問題，可以在安排后續action后，再中止會議，讓出時間解決問題。

再舉一個反例，前段時間有位tier2的10+年資深顧問來我司訪談，張口就說我們做了十多年的業務根本不對。我們解釋了之后，她竟然反饋說這一套流程市面上80%公司都自動化了（這個數據不知道從哪里聽來的，完全不負責的態度?。瑢е挛覀儤I務狂翻白眼然后敷衍了事，最后她的訪談拿到的只是她腦海中的那一套已有的業務信息。

3. 及時反饋確認

溝通需求最忌諱的就是似是而非，最怕的就是以為自己懂了其實并沒有。以下做法可以減少錯誤：

• 理解的情況下，要用自己的語言簡短概括，這樣能確保理解正確并同時完成需求明確。
• 對于似是而非的問題，要多問幾個來源，確保自己理解了，確保訪談對象提供的信息可靠，而不是接受錯誤的結論。
• 對于自己不懂的且在主線上的問題，不要羞于提問，不要竊竊私語，反而要及時直接提問。若花了一段時間仍不理解而且隊友理解了，那可以考慮先過掉。
• 對于關鍵性節點，還需多問隊友是否也理解了，否則后半程隊友可能就是一尊菩薩。

往往是模糊的地方，藏著潛在需求。一般明確的、好解決的問題早就解決了。幾個經典的問題是：

• 你們現在系統是怎么做的？
• 你們現在遇到的問題是什么？（要點是拆分問題、連續追問）例如自動化率不高，那么你們全流程是哪些步驟？哪些步驟已經自動化、哪些沒有？已有的步驟是否已全部自動化？如何實現的？沒有自動化的步驟問題是什么？是太復雜還是投產比太低？
• 你們曾經為了解決問題做過什么？（這個問題可以幫你踩坑）

關于具體挖掘需求的方法，站上有很多，就不多說啦。

4. 配合引導

用開發的話說，需求都是能做的，只是人力的問題。而我們要引導用戶去省時省力的方向，還要引導客戶放棄次要矛盾。

對于需引導的點，在了解需求的基礎上，還需要有以下能力，這樣才能談引導：

• 知道該需求的實際業務重要性
• 對于所談需求的主要方案已心中有數
• 知道各個主要方案的人力耗費
• 知道你引導的方案不能解決什么問題，這些問題是否致命

對于不重要或不合理的業務需求方案，提出問題以引導。正向引導在于闡述方案的優點，反向引導則在于指出業務的不成熟想法。以反向提問為例：

• 講機會成本：要做這個方案，你們需要投入多少IT人力，導致你們其他的XXX需求無法支持。
• 講質量：若按你的方案做，重要性不高、解決不了你目前的問題，反而帶來IT工作量，在固定時間內工作量變大，質量會下降，包括其余你重視的功能ABC。
• 講后續業務自身影響：你們業務后續也需要花費多少人力支持。
• 講復雜度：讓開發小伙伴現講后臺實現方案的問題，喝口水讓他們回答開發的問題吧。
• 設置統籌題：涉及其他業務風險，請統籌財務、法務、信息安全等等。
• 講流程管控：能做，但是項目會帶來上線風險，需告知項目組及雙方領導核實后做；超出SOW范圍無法做主，請上升PMO。
• 講行業經驗：龍頭都是怎么做的
• 拋漏洞：迅速找到對方方案的漏洞（而我的方案沒有的漏洞），讓對方給出解決方案。

正向引導可以從以上角度講自己方案的優點。不過遇上大包大攬的老板，那就只能多做啦。

5. 傳遞情緒與價值

你要能及時感知他人的情緒，并制定對應的溝通策略。具體的內容后續有時間再寫。只有情緒穩定、互相有一定信任感，才可能互相有效溝通。

作為被訪談方，業務輸出了業務知識，你在接收之余應該回饋一些價值，以保持你來我往的平衡感（哪怕實際價值不對等）。在會議空余或閑聊時間中，可以與業務專家討論一些別的事情。這需要在溝通中觀察他人對什么感興趣?？傄苷业阶约旱囊恍┹敵鳇c。

例如，教業務基本的IT項目管理知識是我最喜歡做的一件事，他們懂了項目管理基礎之后，才能知道怎么配合你才能把項目打上線。

八一八各個部門公司間的行情都是可以的，這樣可以了解對方部門的近況、趨勢。

交流交流職業，比如之前我在乙方的實習生就給客戶講現在大學生都怎么找實習，實習行情怎么樣，客戶聽了之后覺得自己的實習招聘貼應該改一改。

四、事后跟進

事后產出比較好理解，要及時發出會議紀要：

• 一般會議紀要都有模板，記錄會議時間、地點、人物、主題；
• 內容方面記錄業務需求溝通結論，對于重要非結論性溝通也要記錄。會議紀要不是簡單的內容闡述，要拿出寫初稿需求的架勢來對待。
• 會議紀要最核心的是待辦事項，初步方案，及責任人，解決時間。

對于待追蹤事項，需要持續跟進，在截止日前就要開始追進度，而不是以會議紀要發出為終點。

對于一些其他對結論有影響的較重大事項，應及時知會各方。

最后

記得剛畢業入行時，小朋友連訪談會都是不太能參加的，只能拿著前線senior的會議紀要畫圖，對直面業務客戶有一定的恐懼感。實際上訪談是一系列綜合因素混合的結果，表面上是主持需求訪談會議，實際上要求你對人對事對業務都要有一定的了解，才能順利開展。

除了上文的一些內容，過硬的業務系統知識、過關的溝通表達、與客戶關系維護能力、篩選靠譜的搭檔隊友等等都是成功訪談的其他條件，這都不是一朝一夕的事情，要早早準備喲。

第一次寫文，寫的比較淺顯，主要是一些主持會議的思路框架，沒有太多抽象的東西。歡迎大家交流~

本文由 @咩咩?原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議