針對B端產品 如何順利開展workshop?

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

編者按：本文來自人人都是產品經理，作者咩咩，36氪經授權轉載。

一、什麼是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%公司都自動化了（這個數據不知道從哪裡聽來的，完全不負責的態度啊），導致我們業務狂翻白眼然後敷衍了事，最後她的訪談拿到的只是她腦海中的那一套已有的業務信息。

3. 及時反饋確認

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

理解的情況下，要用自己的語言簡短概括，這樣能確保理解正確並同時完成需求明確。

對於似是而非的問題，要多問幾個來源，確保自己理解了，確保訪談對象提供的信息可靠，而不是接受錯誤的結論。

對於自己不懂的且在主線上的問題，不要羞於提問，不要竊竊私語，反而要及時直接提問。若花了一段時間仍不理解而且隊友理解了，那可以考慮先過掉。

對於關鍵性節點，還需多問隊友是否也理解了，否則後半程隊友可能就是一尊菩薩。

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

你們現在系統是怎麼做的？

你們現在遇到的問題是什麼？（要點是拆分問題、連續追問）例如自動化率不高，那麼你們全流程是哪些步驟？哪些步驟已經自動化、哪些沒有？已有的步驟是否已全部自動化？如何實現的？沒有自動化的步驟問題是什麼？是太複雜還是投產比太低？

你們曾經為了解決問題做過什麼？（這個問題可以幫你踩坑）

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

4. 配合引導

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

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

知道該需求的實際業務重要性

對於所談需求的主要方案已心中有數

知道各個主要方案的人力耗費

知道你引導的方案不能解決什麼問題，這些問題是否致命

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

講機會成本：要做這個方案，你們需要投入多少IT人力，導致你們其他的XXX需求無法支持。

講質量：若按你的方案做，重要性不高、解決不了你目前的問題，反而帶來IT工作量，在固定時間內工作量變大，質量會下降，包括其餘你重視的功能ABC。

講後續業務自身影響：你們業務後續也需要花費多少人力支持。

講複雜度：讓開發小夥伴現講後臺實現方案的問題，喝口水讓他們回答開發的問題吧。

設置統籌題：涉及其他業務風險，請統籌財務、法務、信息安全等等。

講流程管控：能做，但是項目會帶來上線風險，需告知項目組及雙方領導核實後做；超出SOW範圍無法做主，請上升PMO。

講行業經驗：龍頭都是怎麼做的

拋漏洞：迅速找到對方方案的漏洞（而我的方案沒有的漏洞），讓對方給出解決方案。

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

5. 傳遞情緒與價值

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

作為被訪談方，業務輸出了業務知識，你在接收之餘應該回饋一些價值，以保持你來我往的平衡感（哪怕實際價值不對等）。在會議空餘或閒聊時間中，可以與業務專家討論一些別的事情。這需要在溝通中觀察他人對什麼感興趣。總要能找到自己的一些輸出點。

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

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

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

四、事後跟進

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

一般會議紀要都有模板，記錄會議時間、地點、人物、主題；

內容方面記錄業務需求溝通結論，對於重要非結論性溝通也要記錄。會議紀要不是簡單的內容闡述，要拿出寫初稿需求的架勢來對待。

會議紀要最核心的是待辦事項，初步方案，及責任人，解決時間。

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

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

最後

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

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

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

（責任編輯：王榮智 ）