我靜坐了好一段時間，思考這半個月繁忙的時間里，我做了什么事情，在哪些方面有不足之處。在需求分析方面，我在實踐當中暴露出一個缺點，想得太全。正因為這樣一個不足，我在這上面成長飛快。
為什么想得太全會很容易帶來問題？是什么影響一個人可能想得太全？
先回答第一個問題。
以一個簡單的功能，合同管理人員錄入合同為例。一個合同管理人員在表達自己錄入合同時，他可能是這樣子說的。我一天的工作當中，當接收到銷售的合同后，就會開始錄入合同的信息。信息當中有一些必要的字段，比如合同編號，合同名稱，產品名稱，售賣模塊、名稱、房型等等
這個時候你可能不會深究這些說到的字段。但真正做原型設計的時候就會開始頭疼了。比如房型這個字段，酒店和房型是一對多的關系。那一次當中會有多少房型呢？在錄入的時候，你可能會覺得房型有那么5到10個，這個時候在web設計上可能是表格式的分頁。然后，你也考量到了，在房型只有2-3個數量很少時的場景。為了兼容兩種方式，你這個時候采取的方式可能會使用tab收縮的方式，比如點擊某個房型，展開房型里面的具體信息。
OK，這是一種兼容且理想的交互方式，無論是操作的流程的步驟還是交互的效果，都算是折中且“理想的”。
但是，合同管理員某天會突然意識到，我一次只有兩個房型，特殊情況也不會超過三個，這樣輸入真的心累。摔！
這才是真實使用環境和實際場景。最爽的體驗是，給出直觀簡單的方法直接展示、錄入。但在實際設計產品的時候就很可能遇上這一種坑。
至于第二個問題。
產品玩得多，體驗了很多的優秀產品的交互設計后，產品人員在視野上有所增長，這個時候對于一些問題可能就自然而然的忽略掉。比如商品訂購，一個有經驗的產品人員下意識的就是想到購物車、訂單等等等功能，并且很可能會以這種視野去與用戶溝通。但用戶其實想表達的是，他一天當中只固定買這家商品、以及按固定批量買。這個時候，這個用戶并不需要購物車，他要閃購。這個購物車功能放到如此場景下就是雞肋。
其次，產品開發多，擁有一定產品經驗之后的產品經理，他在思考問題的時候會考慮的很全面，甚至為了盡可能的減少成本，減少可能出現的情況而為產品做加法，所以體驗就沒那么好了。這個時候就需要樹立一個觀念，產品是需要迭代的！極致并非全面，而是從當下來考量，是否能為產品當前的收益帶來最大化。一個活不下去的產品沒有資格談未來。仔細觀察TO C端的產品，你會發現一個個版本當中改來該去，有興趣的朋友可以去查一下今日頭條的歷史版本，會琢磨出很多有趣的事情。
當然，產品迭代和成本控制需要把握平衡，這一點就很難了，需要經驗。

需求的來源有幾種，一種是用戶反饋而來，一種是自己親身感受而來。從用戶反饋而來的問題就涉及到如何聽的問題。如何聽出實際的需求是很需要琢磨的問題。
又犯困了，又挖坑。。如果微信后臺收到超過20個“趕緊起床”。。我會盡快補坑:)

PS:允許非商業性轉載,轉載請注明出處,謝謝.

這里只求真，沒有真理。
微信公眾號：PM范兒
記錄一個不懼撞南墻的野路子產品經理的故事.
期待分享和交流~