我静坐了好一段时间，思考这半个月繁忙的时间里，我做了什么事情，在哪些方面有不足之处。在需求分析方面，我在实践当中暴露出一个缺点，想得太全。正因为这样一个不足，我在这上面成长飞快。
为什么想得太全会很容易带来问题？是什么影响一个人可能想得太全？
先回答第一个问题。
以一个简单的功能，合同管理人员录入合同为例。一个合同管理人员在表达自己录入合同时，他可能是这样子说的。我一天的工作当中，当接收到销售的合同后，就会开始录入合同的信息。信息当中有一些必要的字段，比如合同编号，合同名称，产品名称，售卖模块、名称、房型等等
这个时候你可能不会深究这些说到的字段。但真正做原型设计的时候就会开始头疼了。比如房型这个字段，酒店和房型是一对多的关系。那一次当中会有多少房型呢？在录入的时候，你可能会觉得房型有那么5到10个，这个时候在web设计上可能是表格式的分页。然后，你也考量到了，在房型只有2-3个数量很少时的场景。为了兼容两种方式，你这个时候采取的方式可能会使用tab收缩的方式，比如点击某个房型，展开房型里面的具体信息。
OK，这是一种兼容且理想的交互方式，无论是操作的流程的步骤还是交互的效果，都算是折中且“理想的”。
但是，合同管理员某天会突然意识到，我一次只有两个房型，特殊情况也不会超过三个，这样输入真的心累。摔！
这才是真实使用环境和实际场景。最爽的体验是，给出直观简单的方法直接展示、录入。但在实际设计产品的时候就很可能遇上这一种坑。
至于第二个问题。
产品玩得多，体验了很多的优秀产品的交互设计后，产品人员在视野上有所增长，这个时候对于一些问题可能就自然而然的忽略掉。比如商品订购，一个有经验的产品人员下意识的就是想到购物车、订单等等等功能，并且很可能会以这种视野去与用户沟通。但用户其实想表达的是，他一天当中只固定买这家商品、以及按固定批量买。这个时候，这个用户并不需要购物车，他要闪购。这个购物车功能放到如此场景下就是鸡肋。
其次，产品开发多，拥有一定产品经验之后的产品经理，他在思考问题的时候会考虑的很全面，甚至为了尽可能的减少成本，减少可能出现的情况而为产品做加法，所以体验就没那么好了。这个时候就需要树立一个观念，产品是需要迭代的！极致并非全面，而是从当下来考量，是否能为产品当前的收益带来最大化。一个活不下去的产品没有资格谈未来。仔细观察TO C端的产品，你会发现一个个版本当中改来该去，有兴趣的朋友可以去查一下今日头条的历史版本，会琢磨出很多有趣的事情。
当然，产品迭代和成本控制需要把握平衡，这一点就很难了，需要经验。
需求的来源有几种，一种是用户反馈而来，一种是自己亲身感受而来。从用户反馈而来的问题就涉及到如何听的问题。如何听出实际的需求是很需要琢磨的问题。
又犯困了，又挖坑。。如果微信后台收到超过20个“赶紧起床”。。我会尽快补坑:)
PS:允许非商业性转载,转载请注明出处,谢谢.
这里只求真，没有真理。
微信公众号：PM范儿
记录一个不惧撞南墙的野路子产品经理的故事.
期待分享和交流~
