想转“产品”也不是一天两天的事情了，但是我一直对“产品经理”这个名词在内心没有确切的定义。最近，看看苏杰的《人人都是产品经理》，
以及和公司从事“产品”的同事的交流。自己内心对产品已经有个大致的定义。“产品”：“为解决问题而存在的一种有形或者无形的一种载体”，
无形可以说是一种服务，比如说：你使用的电话套餐。有形，你可以拿到一个具体的实物。比如说我今天买了一个笔记本。“产品经理”第一次
起源于保洁内部的故事，想必大家都知道的。“产品经理”，“把每个产品看作是自己的孩子。产品经理就是那个计划让孩子到出生，发展，到死
亡的这个过程的管理者。
1.孕育到出生：需求采集的过程
现在我写的这些东西都是在纸上谈兵，我至今还未曾做过和需求采集相关的工作。但是学习到做事情的方法还是比较重要的。
需求的奋斗史，从需求被发现到决定实现的一个过程。
采集需求有几种方式：
1.1用户访谈;
对着用户采用约谈的方式，这种方式较为快捷，可以及时沟通。但是这个方法的缺点：用户“说”和“做”不一致；样本少，以偏概全的问题；
用户过于强势，把你们往沟里带；你们过于强势，把用户往沟里带；
1.2调查问卷
而调查问卷通常封闭式问题比较多，适合大用户量的信息收集，但不够深入，一般只能获得某些明确问题的答案，调查问卷不是考试卷，
不适合安排问答题。无论是网上还是线下，作答时间最好不要超过10分钟，否则很多人看一眼就被吓跑了。但是这个方法还是有问题：
第一，样本的偏差，即样本与想了解的目标用户群体出现偏差。第二，样本过少的问题。第三，问卷内容的细节问题。
1.3可用性测试
可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题，通常只能做少数几个用户的测试，看他们怎么做，
属于典型的定性研究。这样也有问题：第一，可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性
问题，通常只能做少数几个用户的测试，看他们怎么做，属于典型的定性研究。第二，总觉得可用性测试很专业，所以干脆不做。
第三，明确是测试产品，而不是测试用户。第四，测试过程中，组织者该做的和不该做的。
我个人是比较喜欢做可用性测试，很多时候开评审会议的时候，需要开发人员在短时间之内做出决策（尤其是那些不喜欢看PRD文档的人），
demo更能快速高效的传递你的意思。而且，现在AXURE Rp工具也极为方便。
1.4数据分析
虽然绝大多数情况下的经验证明，只要在用户的选择上没犯什么低级错误，他们是“具有代表性的”，或者说接受这种假设是一种性
比很高的廉价解决方案。不过，我们还有数据分析，一种定量的研究方法，数据来说话，看看用户到底是怎么做的，不论是考察目标用
户全体、还是采样，都完全可控，所谓“According to the data”是最难被驳倒的。
总结：需求采集可谓是重中之重，记得以前在上软件工程课中，需求到最后成品简直没有半点关系。所以，必须把握好需求这关。
对于自己身边，批发站的产品，从需求这面着手，我采用约谈方式。对于小公司不适合采取成本过高的需求采集方式。对于内部员工约谈，应该是最合适的方式。但是有的项目需求存在不确定的问题，作为产品，一定要给最后的产品开发留上需求改变的空间。