此为历史版本和 IPFS 入口查阅区,回到作品页
呂紹民 darrenlu.eth
IPFS 指纹 这是什么

作品指纹

【產品需求不清楚?都是語意曖昧惹的禍!】

呂紹民 darrenlu.eth
·
·

這是 PM 系列計畫的第一篇, 近期主要會以書籍心得、整理為主
再加上一點自己的菜鳥實務經驗,歡迎各位可以一起參與這份讀書計畫!

「從需求到設計 - 如何設計出客戶想要的產品」

做好需求分析,是新產品專案成功的關鍵

大約有 90 % 的產品開發案是失敗的,其中 30% 沒有開發出任何產品
其他的雖然有產品問世,但人們不喜歡,或從來不使用 ; 即便使用了,也是毛病一大堆。
- 取自封底


「需求」產生的語意曖昧

設計出一個使一小群人免於大自然災害的辦法

給自己 15 秒,想出一個答案,再繼續閱讀下去

.

.

.

如果仔細思考,會發現上面的需求實在太籠統、不清楚了
比如說,我可能可以提出三種可能的建築形式:

  1. 蓋一座地下碉堡,可以抵禦各種天災
  2. 蓋一個國際太空站,可以遠離地球上的各種災害
  3. 蓋一個就地取材的雪屋,可以抵抗強大的暴風雪

這些例子,似乎都有符合上面的需求,但提案內容卻大為不同
還有太多因素應該被考慮進去,舉例來說:

  • 建材是否有限制?多少成本內要完成?需要可以存在多久?
  • 一小群人是多小? 10 個人? 100個人 ? 1000 個人?
  • 大自然災害是什麼? 暴風雪算嗎? 宇宙射線算嗎?

敘述的問題並沒有提到這個建築的各種細節,例如形狀、大小、年限
也沒有提到內部需要什麼功能、建築的實際環境在哪裡?

這個需求敘述也沒有提到「這群人」是誰?可能是家庭、工作團隊?
社會及文化的因素很容易在提案中,因為自己的背景導致遺忘、忽略這方面的考量

更重要的是:需求描述中,根本沒有說到「保護人群的辦法」應該是建築物
但如果下意識的進入思考框架中,將很難跳出這個框架,導致理解需求時的偏誤



「語意曖昧」產生的原因

上面提到「因為自身背景,容易陷入某個思考框架中」,這邊做個小小測驗:

現在,請仔細「觀察」這張圖片(先別往下滑):

準備好了嗎?測驗來摟!

.

.

.

.

.

.

請問剛剛圖片中的藍色星星,總共有幾個角?

如果你觀察的夠仔細,應該可以很快速地回答出答案
但在書本中,總共100 多個測試人員中,卻提出了 18種 答案

根據經驗&研究造成這種結果的原因,通常可以有四種情形:

  1. 觀察錯誤|這世上不會有人和兩個人認知的內容完全相同
  2. 記憶錯誤|人們無法完整的保存所觀察到的內容
  3. 解讀錯誤|不同背景,對於一句話的描述、定義有所不同

以剛剛上面的題目來說,可能它剛剛在關注的是:「圖上有幾個黑點」「哪幾個角上有黑點」
又或著說,猜想著出這道題有什麼陷阱,沒有仔細地專注在圖上
又或著說,單純記憶不好,直接根據印象進行了猜測
又或著說,從不同角度來說「角」有多種意思,有可能是「無限多個角」

-

不是有四種情形?怎麼只提到了三種:
第四種就是基於上述的三個問題,合併起來的「語意曖昧、混合錯誤」

現在請各位發揮你的最佳記憶力,回想一下剛剛的問題:

.

.

.

這邊有兩個問題詢問大家:

請精確的、一字不漏的,寫下剛剛問題的描述
你認為觀看這篇文章的其他人,可能會怎麼描述剛剛的問題?

我們可以很容易的預想到,幾乎不會有兩個人寫出一樣的描述
基於上述的各種錯誤,時間過去、理解差異、背景不同,會給出不同的描述與解讀

因此,在規劃需求時,我們要找出所有「語意曖昧」的原因、思考問題「不同的解讀」方法
要求所有規劃人員「回憶並描述自身認為的需求」,以力求消除語意曖昧!




直接詢問法的侷限

現在,我們已經了解到「消除語意曖昧」是必要的
而在一般規劃產品的過程中,最常被使用的是所謂的「直接詢問法」

簡單來說,就是直接詢問使用者各種問題,來嘗試釐清需求

我們來看一個例子,客戶給了一個需求:請設計一種交通工具
身為設計者,我們會去開始詢問更多問題,以了解更多關於這個需求的細節!

首先這是一個交通工具,那請問:
1. 何時需要完成這個產品? 十八個月內
2. 這個交通工具需要載運的內容是什麼? 載人
3. 一次預定要載多少人? 一個人
4. 這個交通工具的動力為何? 只能由「被載運者」自己提供動力,也就是「乘客驅動」
5. 這個交通工具要在哪種情境上行駛? 在堅硬、平坦的表面上行駛
6. 載運的距離大概多長? 通常超過 3 公里
7. 這個交通工具預計時速至少多少? 時速至少要 6公里/hr
8. 這個工具是否有成本限制? 這項交通工具,包含製造與維護的成本,應低於3000台幣
如果你是設計者,你會設計出怎樣的交通工具?

仔細思考過後,我們可能會提出一種像是腳踏車、或是直排輪類型的交通工具
但其實「輪子」這件事沒有被討論過,但如果在「堅硬、平坦的表面上行駛」似乎就是必須的?

總之,我們在認真思考、評估了一番之後,設計出了一輛小巧、便宜的「折疊三輪車」
它符合了上面八個問題的所有條件,多麼完美的提案設計!

興高采烈的拿去給了客戶,認為應該會取得不錯的回饋與成果
結果對方詢問:「這設計不錯,但請問這個要如何拿去救援山難使用?」

尷尬,客戶需要的其實是一個「山難救援設備」,我們的方案跟客戶的要求剛好差 90度
我們設計出了一款輕便、乘客驅動、便宜、能夠過堅硬平坦道路的「水平運輸工具」
但是客戶的要求,其實是可以下降至堅硬、平坦道路的「垂直運輸工具」

這個例子看起來荒謬嗎?

其實一點都不,每個人的認知、表達內容比我們所能評估到的,複雜太多太多


實際案例QQ

前陣子在做「學位證書數位證書」的案子,
就是大家在求學階段一定要拿到的那張紙,團隊們正在討論什麼是「數位證書」

根據我們調查的結果,數位證書應該要有以下幾個基本需求:

  1. 防偽|避免紙本容易偽造的問題(網路上可以輕易的買到各大專院校的證書)
  2. 方便保存、攜帶|實體的物品隨著時間,容易消失、腐蝕
  3. 資料足夠安全、可信任|數位證書應該要建立在足夠安全的系統上、資安要做足

因此,一開始設計的提案方向是:

基於紙本證書新增可驗證的區塊鏈 QRCode,並有APP可以儲存,有網站能夠驗證

看起來是不是很可行?而且在第一次會議中,包含團隊、長官都一致認同這個方向
結果剛進入實作後,某次討論中某長官給了以下的回饋,他以為:

  1. 數位證書就應該直接提供「紙本證書的PDF」版本比較好,不用QRCode
  2. 不需要 APP 儲存,學生不會有意願為了持有數位證書下載 APP 的
  3. 區塊鏈目前風險太高不穩定,資料的儲存先放在中心化資料庫就好

尷尬,完全偏移當初方案的設計(幸好實作內容還不算多),修正再來一次

最後根據不同需求與建議(實際上與政治上的),改了好幾個需求版本,才得以開發

-

如果比對「真實案例」與「書中建議」來說,我們犯了幾個錯:

  1. 沒有釐清「實際客戶」到底是誰,搞錯需求方向
  2. 「與會者」對於數位證書的「認知背景」不同,想像十分不一致
  3. 會議記錄太過「語意曖昧」,導致未出席的長官並沒有即時修正方案


「語意曖昧」導致的問題,會導致成本的大幅消耗,且無法完成實際需求

至於怎麼樣盡量減少語意曖昧、更有效的確認需求呢?
將會在下週四會介紹書中的「第二章 - 起步的方式」,談到包含「會議技巧、開放式問題」等

如果喜歡這系列,歡迎留言與我分享你的想法或是觀點~

2020 / 02 / 27 , 紹民


關於「嗨,我是紹民」


CC BY-NC-ND 2.0 授权