功能不是需求，功能是實現需求的方法。

需求就是「我想要什麼什麼」?

我想要訂飯店，這就是需求了？

需求＝產品特性或功能？

很多公司的需求等於一張功能列表，這張功能列表通常出自 PM 手中。

也許是 PM 看了公司 UX 部門提出的使用者研究報告後寫的一張功能列表。

但使用者研究報告能夠影響這份「列表」多少呢？全憑 PM 的個人想像。

運氣好的話，開發人員會拿到一套連貫的產品規格，但不能保證照著規格開發出來的產品就是是使用者喜歡的產品。

產品需求＝實現方式？

「這邊要放個下拉選單，選單裡有…」有人在說這句話的時候，他在心裡已經有個「預期中的假定解決方案」了。

為什麼畫面要這樣擺？因為不這麼做很奇怪/大家都這樣做？

使用者為什麼需要這個？不知道。

開發者拿到這種「預先假定好的解決方案」也很難進行開發，不知道使用者是誰、使用者在什麼情境下使用。

使用者會怎麼有什麼樣的行為？如何操作我們的產品？使用產品的動機？有想要完成什麼任務或目標嗎？

通通不知道。

也許你覺得知道這些又不會對產品造成多大影響….舉個例子：「一群遊客吃中餐，要讓他們吃飽」。

同樣都是「吃飽」，在登山途中的遊客和遊覽車上的遊客，他們怎麼面對「吃飽」這件事？

他們對於「飽」的標準一樣嗎？登山客需要更大量的體力，他們比較在意食物現點現做新鮮、還是快速補充熱量？遊覽車上的遊客需要多少食物才會覺得飽？

他們為什麼要吃飽？吃飽之後接著做什麼事？繼續爬山，還是上車前往下個景點？體力消耗相同嗎？

通通不知道的情況下，即使目標都是「吃飽」，但不同需求、不同行為，對吃飽有不同標準，開發者怎麼配合使用者進行開發？

猜！矇！通靈！

（員工：反正公司傳統就是這樣，一聲口令一聲動作，產品不討喜不賺錢干我屁事，別拖欠薪水就好。）

怎麼定義需求？

所以產品開發非常看重「需求」，使用者研究就是為了讓產品不要朝「錯誤的方向努力」。

使用者為什麼要用我們的產品？他有想達到的目標或待完成的任務需要我們的產品幫忙。

所以我們的產品能提供哪些訊息和能力來完成使用者的目標？

設計產品行為之前，必需先定義產品是什麼、要做什麼。不然就變成「不知道來家裡吃飯的人有幾位、不知道是老人年輕人還是小孩，你就要開始備料做菜了」。

誰知道怎麼開始動手啊？連要煮幾道菜都沒有頭緒啊！

在和 PM 溝通的過程中，最常遇到的問題之一就是「需求和功能混為一談」，自以為釐清了需求，解釋半天，其實都在講「我為什麼要叫你做這個功能」。

功能不是需求，比如「會員註冊」不是需求。

「我想要會員註冊」，也不是需求，不是加上「我想要」3個字就等於需求啊！

為什麼想要會員註冊？

「我們平台需要區別每個會員的不同，才能記錄單一會員在我們平台做了什麼事，包含個人資料、購買清單等，方便追蹤會員喜好和習慣。」

這才是需求！

需求不是術語，有點像是「用一句話描述使用者＋情境＋動機」。

「我想要路徑導航」不是需求，「我想要有人告訴我路怎麼走」或是「我想知道去台北車站有哪些交通方式」才是需求。

你覺得 VS 我覺得

大家都知道「往錯誤的方向努力是件浪費力氣的事」，也都知道自己想的和對方想的往往有落差，抱怨「豬隊友太多」。

那為什麼敢不把話說清楚，敢靠「默契」做事？

不好好向專案成員說明目標，不一條條把現在遇到的問題列出來，甚至在還沒達成一致意見就直接敲定解決方案？

而且也沒有清晰、明確、客觀的方式評估設計是否適當，那你的工作要做到什麼程度算完成？判斷完成的標準是什麼？

同事：「我覺得我做完了。」
你：「我覺得你啥都沒做，亂搞一通。」

為什麼要用「明確、簡單易懂、可驗收」的方式把需求寫清楚，就是為了確認工作是否適當的完成，避免你認為的工作和我認為的工作不是同一件事。

同樣都是吃飽，「你覺得」一盤雞肉沙拉就能吃飽，但「我覺得」要喀兩個排骨便當才算吃飽，這時候怎麼確定滿足需求，有好好的完成工作？

由薪水比較高的那個人、還是音量比較大的那個人來決定？