寫完第一篇，覺得定義需求很重要，應該拿更多例子來講，
乾脆再開一篇～
為什麼定義需求重要呢？
不瞞大家說，昨晚在開車回台中的路上差點跟我老婆吵起來
她覺得把現有的解決方案改善沒有什麼不好啊！
為什麼你們這群人老在那邊自命清高，覺得把需求確定好最重要？
這是有原因的，
因為一旦定義好你的需求後，譬如昨天的例子「如何讓父母立刻知道小孩發燒」
不該急著想「一個」解決方案，而應該是「一堆」解決方案，
也就是所謂腦力激盪（brainstorming）
大家可能會提案如：
- 請保母5分鐘量一次體溫
- 在寶寶耳朵塞個固定式耳溫計，然後五分鐘偵測一次
- 電腦即時分析寶寶監視器影像，一分鐘如果動超過50下代表躁動
一旦電腦認定為躁動就發送通知請保母量體溫、並通知父母
- 做個可以貼額頭或身體的貼片，即時量測體溫，
如果異常就通知保母及父母
...........（以下略）
看起來這些解決方案都有好處壞處，但是再更深入一點：
1. 「寶寶」是指幾歲？0-6個月、6-12個月、一歲到兩歲？
要知道這0-6歲還不會翻身，可是一歲以上可能會到處亂跑；
所以影像偵測系統在這種狀況可能不適用；
耳朵塞固定式耳溫計......除非做得超級小不影響耳道
請保母5分鐘量體溫.......人家應該馬上辭職 XD
2. 該產品還有說，可以用來偵測排卵日的溫度變化
這讓我更困惑了，因為這種體溫變化只有0.5度C
所以這種體溫偵測的敏感度要小數點以下兩位
但若是偵測發燒，只要超過37度C逼逼叫就合格
偵測器太敏感反而是浪費跟干擾
如果我是工程師，應該會很困惑吧？！
3. 還有，「即時偵測發燒」真的是需求嗎？需求量多大？
如果是我自己小孩，發燒了活動力正常，我頂多讓他多喝水
除非嚴重影響睡眠品質，我才會考慮給藥緩解症狀
因此我認為即時偵測發燒只適用於神經質的父母親
有沒有覺得越弄越複雜？
如果我是發明人應該開始胃酸逆流了......
講白一點，太急著進入brainstorming或解決方案
或者先想解決方案再去找其他適用情況
沒有觀察需求、確定需求、市場分析、利害人分析、專利分析
往往會落得花時間做個沒用、或已有更好針對問題的解決方案
對於新創公司根本是致命傷。
雖然你可以說，iphone出來前誰知道手機可以這麼智慧？
福特那個年代的人只想要匹跑更快的馬、誰知道汽車是啥鬼？
強者幫顧客創造需求啊！
然而成功絕非一蹴可幾，
福特不是第一個做出汽車的人，
他是第一個成功量產並降低成本，讓大家買得起汽車的人；
如果Steve Jobs沒有觀察使用者習慣、喜好，
人為大眾有「想要便捷取用網路資源」的需求
他會那麼天才想到做iPone嗎？
而且，其實失敗的例子遠多於成功的啊，
對資源有限，只夠讓你燒錢半年一年的新創公司而言，
密集有效安打，遠比揮大棒全壘打有效。
如果我們重新回到觀察需求的部分，
0-6個月的寶寶，比起發燒、我更在乎窒息高度相關的嬰兒猝死症
6-12個月的寶寶、1-2歲.....各個年齡層的重點需求都不同
如果你是工程師，要不要去找幾個小兒科醫師討論？
要不要去小兒科病房聽聽父母親的抱怨？
要不要去聽聽護士的抱怨？
要不要去聽聽急診科醫師的抱怨？
簡單來說，沒有在定義需求這關做足工夫，
急著抓到一個解決方案再四處尋求適用情況
就像毒果樹啊！
所以工程師不能只想到自己的技術解，
也不能只聽一兩個醫師或父母的意見
關於需求觀察（Needs observation），
容我用個design thinking的影片當引子：
我並不是在批評被我當例子的團隊，
如果他們還沒有成品，只是在need observation的階段蒐集需求
那我覺得他們在做正確的事，
這個團隊應該可以繼續看下去；
就像影片裡的例子，團隊沒在一開始就賣工程師覺得讚的點子
而是先去蒐集使用者意見，了解他們特性，
開發出prototype確認可行後，才開始動作
這樣才是增加成功率的方法。
明天我拿我們團隊自己的例子來講講大家或許比較身歷其境
（光定義需求可以混這麼多篇啊 XD）
延伸閱讀：
定義需求(identifying needs) (1)：Biodesign，史丹佛大學的醫療器材創新課
Biodesign - 史丹佛大學的醫療器材創新課：引言