如何找到正確的需求?

01-14

我的角色是設計師，我認為是Sweet Point。

因為需求有很多，那麼解決需求的思路也有很多，那麼Sweet Point是最找到（或驗證）需求的最佳的方式。比如：擠公交的體驗不好。那麼解決方式有很多，痛點很明顯，就是不想擠，那麼解決的Point也很多。有一個「嗒嗒巴士」的產品就解決的很好，它找到了Sweet Point，一但循環起來，就會有很多人用。

那你會說如何找到正確的Point，OK，我更認為是一個 eXperience thinking 的，或是整體性思考的方向。並不是單點，單一的一個角度能夠解決掉。舉一個之前的例子：如何從河一邊到另外一邊，有人會說修橋、建船、造飛機，那我們要思考為什麼從河一邊到另外一邊，假如只是做信息的交換，我們根本不用修橋，我們利用互聯網或建一個互聯網就可以了。那麼進一步思考，建這些的可行性的問題，這裡就不是設計師一個人的事了，這需要通盤考慮，各種情況，才會有一個正確的Sweet Point，才能進一步去解決問題。

當然你可能說這些以你的資源做不到，那麼，再把自己放在行業的角度和老闆的角度思考這些問題，或許能夠又往前解決了一步。

看到這個命題挺有意思的，隨便答一下，有空了我想寫個長文來記錄下。

不謝邀。

多聽聽用戶的聲音，多關注行業，看看同行怎麼做。

在此基礎上頭腦風暴，確定產品方向。

快速做出mvp版，小步快跑，快速迭代，快速試錯，及時調整產品方向。

自己去體驗，自己去使用

補充一點：可量化的「正確」標準，也就是數據說話。

最近發了條朋友圈「不是讓系統去適應用戶習慣，而是讓用戶使用系統」受到客戶冷嘲熱諷「挨踢思維」，然後部門部長也幫腔，估計我在這公司所謂「事業」也到了盡頭，雖然我知道他們理解錯了意思，但也懶得辯解

我朋友圈意思只是「客戶不知道自己真正需求」的另外個表達而已，這也是我做需求第一原則「不盲目遵從客戶」

開發出身，入職一年不到突然就要「被培養」，然後走上需求，設計，開發，測試，運維的一條龍不歸路，然後我就講講我怎麼做需求，需要註明的是，我沒有任何專業知識

為何不要完全聽取客戶需求

一開始我跟著一個領導跑，我做demo，夾起尾巴聽他們討論需求，然後兩個月後

「不對！這和我要的不一樣！」然後全部推倒重做，領導也懶得討論開始在客戶面前夾起尾巴做人，一個月後，所有需求被顛覆，為了趕工期，客戶的「過年前」要求，不斷加人設計開發

事後一個副部長總是說「原來說好只做A，怎麼我出去幾個月，ABCDE都要做了。。」

對於我自己公司來說，這項目從「精英開發」變成「全面開發」，用人成本翻了幾倍，更不用說其中機會成本了，而且「照搬客戶需求」的領導，和開發組長，關係越來越差，甚至後期打起來了。。。

對於客戶來說，很多都是拍腦門想出來的，比如有某處，一個月反覆修改了四五次，別問我為何，我是菜鳥聽領導的，我再舉幾個實際遇到但不能說太細的例子

我離開一年後重回項目，客戶問我，某個功能有沒有，而那個功能是一開始需求就註明一開始就做了的。。。

我遇到的客戶往往追求的是120%功能，100%完美，70%的價格，而這在開發上，因為成本，工期等原因，總是幾乎難以達到的

再說現在，幫客戶做app，需要管理後台，去探討需求，他們只知道他們要哪些功能，完全不知道怎麼做，數據源在哪裡，有哪些風險情況，更多是對UI的吹毛求疵，對文檔的詳盡要求，順帶一提，我現在對他們連話都不想說了，有種說不通的絕望感「如果真的探討他們需求，做個完善的，工期也不允許」

那麼如何確定需求？

我個人對「需求」的理解是，對業務流程的大方面理解，如果和我說「這個按鈕擺在哪」那是UI設計，不是需求

那麼我做需求實際上就是對客戶的需求進行再加工

第一要去除是設計部分的內容，很多是畫面長啥樣，這部分應該不會太多，還包含部分形容詞

第二是整理出技術方面內容，與開發討論後和客戶協商，這個不少，使用框架限制「使用某種語言之類」，性能指標「這個有時候客戶會很扯，比如不加數據量要求檢索時間在很短時間內」，協商好和客戶反饋溝通，確認

第三，是業務邏輯的合理性，你不能讓程序流程陷入死循環，還有「可能」「好像」這種一定要確定個標準，要麼明確「隨機」的「概率」，要麼去除，去除模稜兩可的表述

第四，要明確業務具有技術可行性，如果你不懂開發知識，那麼就可能需要你和開發人員溝通了，另外作為開發，我友情提醒，不要用「別人這麼做為何你們不能這麼做」強壓人的口氣，不是所有功能都能很好融入框架，平和點，好好探討，你也能有所收穫

確定了以上四點，你就可以交給開發估算工作量，如果你想做的更好，提醒開發別急著開工，估算時多加點工作量，然後做第五點和第六點

第五，沒有人是考慮周全的，客戶需求也是一樣，比如有個新用戶，他需要密碼登錄，他不能修改密碼是不太合適的，如果可以修改密碼那麼忘記密碼怎麼辦，是讓他通過某些私人信息重置，還是後台安排人員手動重置。。。總之這一步是沒完沒了的，需要把握一下度，別讓系統過於臃腫，還有客戶可能漏掉的是逆向的流程，這要點技巧，因為你提到「逆向流程」客戶肯定會說「需要」，你需要自己根據自己業務知識和工期以及開發的意見評估逆向流程的必要性和可行性，別用80%時間做20%的事，除非實在太閑

第六點，給需求功能排難易度和優先順序，主要預防項目無法如期完成時，你可以保證80%功能都是好的，告訴客戶有這麼個排序的好處我就不說了

看上去很多，實際上習慣了以後，面對客戶的吧啦吧啦，都可以精鍊起來，然後自然而然的就知道哪些情況客戶沒考慮到，如果了解項目開發框架，也可以知道哪些難以實現，哪些難度高，「我自己就是如果遇到難的，我就說回去問問技術可行性」然後回去告訴客戶「不可行」的理由，總感覺這些話不是自己口頭說更好點，實際上挺快的，經驗積累，然後，我會把其他人腦力也用起來，來防止自己快速的思考沒有考慮周全，或是不合時宜

文檔需要時間反而好長。。。

總結下

思維原則

1. 客戶並不知道自己需要什麼

2. 別讓任何人80%時間做20%的事

3. 沒有人的想法與思考是完美的

做法

1. 精鍊原需求

2. 剔除不合理需求

3. 各個層面分析業務技術可行性

4. 想客戶不會想

5. 排級分類

始終保持溝通，與客戶，與開發

最後，祝挖坑愉快

如果有一個軟體能幫助找到客戶需求的工具，你覺得有需求嗎？

換位思考，

需求背後，如果有對應的情感，那很大機率表示這個需求是剛需。

正確的需求並不存在，問題在於拍板決定需求的人是否正確

頭腦風暴，調研，總結，再調研