哈囉，朋友

你是 B2B 產品開發團隊的一員嗎？

相對於面向一般消費者市場的軟體產品，其實更大比例的軟體產品設計工作，發生在企業端的需求上。

在過去我接觸到的案例中，B2B 產品的需求訪談往往不是什麼輕鬆的經驗，因此我想透過這篇文章與你分享有什麼常見的地雷？以及面對這些地雷的拆彈原則是什麼？

常見的地雷有：

• 直接指示你具體的規格，但邏輯矛盾
• 要求你先進入執行，但講不出交付標準
• 跨部門流程，每個人的說法各自解讀

​

▋直接指示你具體的規格，但邏輯矛盾 ▋

我還是產品經理的時期，曾經遇過一個同事跑來找我談需求。

他說：「你們有空嗎？下週能不能在 OO 頁面上加個圖表？」

我問：「你是因為什麼狀況，所以需要圖表功能呢？」

他回：「行銷希望企業用戶寫完問卷之後，可以看到一些回饋。」

我又問：「為什麼會希望企業用戶可以在那個時候看到回饋呢？」

他回：「現在問卷的填寫狀況不好啊！想說放一些回饋比較吸引人。」

我：「欸？可是圖表放在問卷填寫之後的頁面，用戶在填寫前還是看不到啊？為什麼這樣可以解決填寫狀況不好的問題？」

同事：「不行嗎！？」

​

如果我不在乎對方要什麼，只要許願就照單全收，那麼光是處理這類矛盾的需求就飽了。

​

更糟糕的是，通常這類討論需求的情境中，往往要你在第一時間就壓上時程，在你還不確定問題的樣貌之前，就問你什麼時候可以開發完成。

​

但我們七趕八趕的加班完成這些工作，有用嗎？

如果這個需求沒有解決問題，問題還是會回到我們手上，一而再的修改。

​

所以第一個 B2B 需求訪談的拆彈原則是：先釐清真正的問題與影響範圍，才評估解決方案

​

▋要求你先進入執行，但講不出交付標準 ▋

另外一個情況是，要求你先規劃一個流程，可能是競品有這類功能，也可能是客戶內部的某個需求單位曾經許願過。

但要求你設計這個流程的人，他卻無法回答最重要的關鍵問題：交付標準。

​

誰要使用？不知道。

他會怎麼使用？你先想。

​

會發生這樣的情況，往往是因為來到你面前的這位需求方，他只是一個代理人，他並不真正掌握問題發生的情境。

​

在這邊我們要掌握一個基礎原則，那就是 B2B 產品的用戶目的到底是什麼？

​

如果說大部分產品的終極目的是：「幫助使用者成為更好的人。」

那麼在 B2B 產品的情境中，最基本的就是：「幫助使用者完成他的工作。」

​

這個時候，我們可以使用 STAR 原則，來進行行為職能的訪談，來找出具體的使用情境，如此才能定義如何幫助使用者達成目標。

​

使用 STAR 原則來調查行為職能，通常會以這四類問題切入：

「有哪些情況會跟這個需求產生關係？」（情境 Situation）

「什麼樣職位的人會需要參與？他們的職責目標是什麼？」

（任務 Task） 「他們會採取什麼行動？為什麼選擇這樣的作法？」

（行動 Action） 「預計會發生哪幾種結果？什麼因素會產生影響？」（成果 Result）

​

▋跨部門流程，每個人的說法各自解讀 ▋

即使運用了 STAR 原則來調查行為職能，還是會遇到一個艱困的問題：跨部門。

​

有時候，你遇到不同職能的人與你討論同一個工作流程時，感覺像在討論完全不一樣的議題似的。

​

你可能覺得是在討論需求，另外一個角色他卻稱呼這叫提案，還有人認為這就是開會。

​

我們會遇到此狀況的第一個原因是「本位主義」，每個人都是從自己的觀點出發來看待問題，採用自己熟悉的觀點才能夠降低認知負荷。

​

第二個原因是知識的詛咒，同一群人在同樣的領域久了，習慣用自己內部的溝通語言，而忘記小圈圈之外的人聽不懂他們對話內容中許多隱含的資訊。

​

身為圈外人的我們，可以如何處理呢？

「任務步驟分析」會是你梳理跨部門流程的好幫手。

​

任務步驟分析關注三件事情：

• 可獨立：每個任務步驟由單一角色執行
• 可交付：每個任務步驟都產生具體可驗證結果
• 可置換：對任務步驟進行抽象化，可使用不同解決方案達成同樣目的

​

例如一個請假的流程，可能涉及到請假人、代理人、審核主管以及人事 HR。

我們要先知道的並不是具體假別的計算規則與欄位有哪些。

​

我們要釐清的是，整件事情有哪幾種觸發的起點？

從起點抵達終點所需要的交付條件是什麼？

可共用的任務步驟有哪些概念？

如何提供客觀證據來驗證某一任務步驟已經完成？

某一任務步驟有哪些不同形式的提交資料方法？

上一任務步驟交付的結果，下一任務步驟的單位會如何運用？

​

先整理出每一個關鍵任務步驟客觀的可驗證結果，才去釐清這些結果是用什麼規則、哪些欄位組合出來的。

​

最怕的就是被一句話唬弄過去：「輸入不同的條件會得到不同的結果。」

客觀來說，這是一段沒有意義的廢話，因為我們無法從中提取出可驗證範圍的規則。

​

你會發現，有時候同一個流程，A 企業是幾個部門合作完成，但在 B 企業卻是同一個部門內自己在處理，到了 C 企業卻通通是同一個人搞定的。

​

識別任務步驟的切分點，能夠讓你找出適當的顆粒度，用來設計產品的流程。

而不是根據 A 企業的部門分工，拿去要求 B、C 企業按照別人的營運邏輯來分配人力。

​

▋總結一下

我們在 B2B 產品的需求訪談中，有三類常見的地雷，我們的拆彈原則有：

• 遇到直接許願的需求方，先釐清真正的問題與影響範圍，才評估解決方案。
• B2B 產品的用戶目的，就是能夠順利完成工作，可以透過 STAR 原則，了解情境、任務職責、具體行動、關鍵成果。
• 遇到橫跨多個部門的流程時，運用任務步驟分析，找出適當的切分點。

​

以上是我在進行企業內應用的需求訪談時，也經常採用的需求訪談方法，分享給你。

希望能對你的工作帶來一些幫助，也歡迎你與我分享你想解決的問題。

​

by Soking