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

這是 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 , 紹民

關於「嗨，我是紹民」

• 每天晚上 11 點，一篇學習日記與你分享
• 也想分享你的觀點嗎？歡迎留言跟我交流討論吧！
• 個人臉書：https://www.facebook.com/smluspace