我們做開發的經常遇到一個問題：設計出來機制不是需求方想要的,按照他的思路去修改功能,結果做出來發現有損失了，就是解決他要的問題，其他附帶問題就來了，那個不是他想要的。
其實我借鑑《顧客想得與說的不一樣》中的。我理解到，技術需求與顧客需求分析也是一樣的道理，所以我借鑑過來。
總結為：我們不要陷入需求方的思維去，不要陷入需求方口頭上說的去。而要問對方要解決什麼問題(因為我解決他那個問題的技術方案很多種)
可以看《顧客想得與說的不一樣》裡面提到一個例子：
你問使用者想要什麼樣的把手，顧客答：我想要把手粗的！
結果工廠造把手加粗的。結果還是沒人買。
實際上，深入問對方：想解決什麼問題？
顧客答：我只是想避免把手拿到手裡，滑落掉，所以我覺得粗點的能夠避免滑落！
所以核心出來了：是要避免從手裡被滑落
要避免把手從手裡被滑落掉！解決辦法有很多種啊。可以不加粗把手，不把手上面做一些增加摩擦的。
外行肯定以為那樣子好。實際上就損失了，比如你把手加粗了後，會出現其他問題了。產品因增加此部分而帶來的新的問題，可能不是使用者能夠去接受的。產品白做了。
這其實就是所謂做產品市場定位的時候，經常聽顧客說我想要什麼，我期待產品是什麼樣子的，然後你按照他的思路去做了後，推向市場，反響很差，那批原來調查的顧客不見得購買你的。就是太相信顧客口頭說的，這也是就是像書的標題說的那樣子：顧客心裡想的其實與口裡說的不一定一致。不要陷入他們的思維去了。
你只關注的是：使用者要解決什麼問題。然後公司開發的產品要解決這個問題即可。
這種分析顧客需求(把功能需求方當程式設計師的顧客)的方法，我後來用過幾次。
比如，需求方只是想實現手機號碼就可以登入。只要解決這個問題而已，我們如果具體去問對方：是不是把手機號作為使用者名稱呢？因為對方是不懂技術實現的人員，他答：是的，這樣子我就可以實現手機登入了。手機號就是使用者名稱。
結果技術人員陷入他的思維了，使用者表中，以手機號作為使用者名稱，要知道，人的手機號是會換的，如果順應對方的思維，以手機號作為使用者名稱，一旦使用者的手機號換了，就麻煩了(手機號可能涉及到接收手機驗證碼)，他就需要重新註冊一個新手機號的使用者嗎？
或者即便技術人員提前告訴需求方：如果你使用者名稱作為手機號會出現這種問題。對方也會覺得，ok。沒問題。其實因為他不是技術人員，所以不知道技術實現細節，他只會想著滿足當前需求就ok。至於到時候要使用郵箱登入等等，這種是你們技術人員去考慮的。
其實，如果我們具體問對方要解決什麼問題，他會回答：我想解決手機號可以登入問題！
這樣子技術實現方案其實很多種。我可以使用者名稱仍然是"mynamkk"這種字元形式，一旦註冊就是唯一性，跟使用者的手機號和郵箱等都只是繫結關係。這樣不去管使用者修改郵箱和手機號了。比如支付寶可以繫結郵箱，打款的時候直接填寫對方郵箱，就是對應到支付寶去了。