Soking 來信:如何看懂 B2B 產品需求訪談的常見地雷?


哈囉,朋友

你是 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

Soking

千綺創意設計 Co-Founder / 產品設計總監,目前經營軟體領域的體驗設計顧問公司,也從事 UX 教學,喜歡以工作坊形式,引導你體驗 UX 領域的專業知識。 工作聯絡:service@soking.cc

Read more from Soking

哈囉,朋友 如果你在工作上要去執行需求訪談,相信也曾遇過不耐煩的受訪者。 尤其是主管位階的大忙人,特別沒耐心受訪。 或許你會想,可能是自己的職稱不夠高,所以對方才不耐煩。 但換個情況,如果我們是主管,然後總是對於跟位階低的人講話不耐煩。 那這樣要如何領導其他人呢? 所以有沒有一種可能,不是我們位階低,而是對方感覺這次的談話是沒有用的。 就我自己的親身經歷,最常見以下幾種狀況: 同樣事情他已經講了一百遍 沒有人可以了解他在幹嘛,忙得喘不過氣 你想訪談的東西他覺得跟他無關 因此我想與你分享一下,這幾類狀況的訪談應對策略。 ▋狀況一:同樣事情他已經講了一百遍 除非對於一件事情有使命狂熱,講個千遍也不厭倦。 不然任誰同一件事情講十次以上應該都會超級不耐煩吧? 講了十幾遍之後,他覺得自己已經付出了沈重的代價。 然後此時再來一個什麼都不懂的人,這情況簡直糟得不能再糟糕了。 因為有更多的事情得從頭講起。 那該怎麼辦呢? 讓對方意識到你也付出了一些沈重的代價,但沒有找到答案,所以來到了他的面前。 例如對方跟組織內的同事講過許多次了。...

哈囉,朋友 原本預計今天寫給你們的一封信,被我收進了草稿匣,因為變成了奇幻小說,而我不知道該怎麼向你們介紹而不顯得突兀。 如果你有追蹤我的臉書,最近的我,正處於內在衝突的自我整合歷程,因此不斷萌發各種念頭,看起來不太像在說人話,先跟你們抱歉。 我想改成與你分享,最近我們團隊正在籌備的一場直播講座的調查狀況。 這個調查主題是關於「side project」,當你接觸網路軟體產業之後,或多或少應該聽過這件事情。 有些人想透過 side project 來提升自己的能力,有些人想透過 side project 打造屬於自己的解決方案或工具,有些人渴望透過 side project 讓自己更快樂、有成就感。 我自己常常發起屬於自己的 side project,大多數在當下都沒什麼用,但可能在日後突然串了起來,在某個專案中起了絕妙的用途。 因為這樣,我常常被誤認為是有創意的人。 但我其實不是有創意的人,而是嘗試過一百種當時不可行的辦法,並且記錄、分類、保存下來。 因此 side project 對我來說,就是用來失敗的。 那我是怎麼遇見想要的 side project 呢?...

哈囉,朋友 或許你也曾聽別人說:「我對於人很感興趣,所以想從事 UX 相關的工作。」 至少我跟上百位學 UX 的朋友聊天時,這是最常被提到的理由。 對於從事 UX 相關職業的想像通常包含:可以數位遊牧遠端工作、可以研究人們的行為、薪水落在還不錯的區間等等。 不知道你有沒有聽過最近流行的潮名詞:多巴胺職業。 我認識的一位 SEO 專家邱韜誠 Frank,提出了這個有趣的概念。 多巴胺職業相對於傳統職業,更能帶給人們成就感、意義感以及創造性。 因此人們很容易受到多巴胺職業吸引,渴望從中獲得熱情與成就的自我實現。 ▋UX 相關的工作是什麼? 與 UX 相關的職業,目前主要集中於資訊軟體產業裡面的產品經理、UIUX 設計師、UX 研究員等職位。 因為 UX 這個趨勢崛起,來自蘋果電腦。 以用戶體驗為中心,打造符合人性的產品,獲得商業上的巨大成功。 蘋果電腦在賈柏斯的領導之下,重新定義了「產品設計」,成為地球上第一家市值超過一兆美元的科技公司。 用戶體驗設計,就是蘋果電腦的祖傳靈魂配方。 ▋UX 在業界的現實 蘋果電腦帶著 iPhone 征服許多人,Mac...