2010就这样过去了，好说歹说我也算是当了5个月左右的pm-产品经理。这么说，2011年我是不是不能以新人为借口来为自己那些错误做掩饰呢？
以前还没参与工作时，很天真地认为，产品经理就是那个用嘴巴勾勒着产品模样的人，虽然实际上和这个理解也差不远。但产品经理远远不是只勾勒模样，产品的长相只是冰山一角。
到了后来，其实我明白了自己的很多缺点，或者说是做得不好的地方，有时候顾起来了就暗示自己，有时候那股劲太强了，就没能压制住。
归纳一下那些做得不好的地方：
1.为了芝麻丢西瓜
我个人感觉，规划需求的时候，一定要把核心抓好。我，有时候很容易被一些貌似重要但却边缘的功能分散了注意力。这个我可以举个例子，也好好得鄙视一下自己吧。
在BD实习的后半段时间，我独立做了一个文库的一个专区。在我还没来深圳之前，我一直很骄傲自己完成了这么一个任务。再后来，有一天，我回去看看这个诞自我手的孩子的时候，我发现了自己做的产品真TM挫。
当时为了做一个绝对公平的排行榜，把一些原本应该有的体验和功能给舍弃了。现在我看来，排名的重要性比使用专区的重要性其实要低，所以不应该为了一个排名规则而把很基础的功能给去掉。首先要确保的是使用起来的功能能够流畅，再通过一些方案尽量去解决存在的问题，先打骨架再塑肌肤。
又想起来了那个问题：为什么商场不把买菜的区域放在商场的进口处？
因为会弄湿弄脏地板，或者说没人愿意拿着菜去买生活用品？这都是原因，但其都是芝麻，边缘性的东东
商场是为了赚钱而开的，并不是所有去商场的人都买菜，或者说应该是非大部分人会买菜，并且商场并不是菜市场，商场也不想让自己变成菜市场。但若买菜区能给商城带来压倒性的利润和客户时，我相信商场应该会愿意变成菜市场的。
或者这个缺点又可归咎到我的另一个缺点之上，有大一统的偏好。希望所有人都有好结局，就如希望所有东西都存在一样。
这个缺点需要不断实践+自我学习和养成良好的思维方式来克服。
2.没有设身处地
没有尽量周全地思考用户操作的过程，在设计产品时，会出现两种情况：
A：分析需求不够准确。因为没有很好的理解操作过程的各种需求，所以很容易就理所当然地认为这样是对的，或者用一种一致对待的方式去解决不同的问题，这样就会出现逻辑不合理。
B：交互设计得不流畅。主要表现为忽略了某个用户场景，然后出现规划产品时，某一些需求被遗忘了。用户场景其实可以分成两种，一种是常态的，一种是暂态的。通常被遗忘的都是暂态的。主要是出错没给提示，或提示没有说明解决方案。在功能需求被满足以后，怎么样才能做出好的交互，需要理解用户的操作过程，需要估计用户的心理感受，需要理解用户的操作习惯。
这个缺点有时候也可以叫做：先入为主。
正常的思考方式，思考顺序应该是：问题是什么=》为什么发生=》怎么解决问题
但是如果有了先入为主这个缺点，就会变成：这样解决问题=》解决方案解决了xx问题，这样就很容易造成思维上走进死胡同，认定这样做有这样的好处而不是想着怎么去解决核心的问题。
3.缺乏体验，缺乏判断
缺乏体验主要是产品体验不够多，这个缺点对于交互设计会带来了比较多的困扰。多体验，才能多收获。
缺乏判断力，对一些需求和一些交互上的决策缺乏自己的判断力。这个归咎于对需求理解不够深入，如果能够很好地掌握到需求，那就可以很容易地判断和取舍，和第一点有点关系。
4.需求文档混乱
这个缺点曾经让我感觉到挫败感极强。（连阅读需求都不能理解，还做什么产品）
需求文档是为了让开发能够较好地理解产品的开发需求。在需求无误的情况下，要确保文档能够被流畅地阅读和理解。
我个人还是认为应该先总体理解，再细节描述，这样文档的阅读性会比较好。因为我觉得这个就是个学习过程，先告诉我我学的东西大概是啥，有啥用，我才会知道以后学的每个公式其实都是为了解决某个问题。
以前写文档会比较没有组织，或者说缺乏较好的范例来教我怎么组织可以更好地被理解。
目前发现，出口入口&checklist是好东西。表格用来描述产品功能的一些特性也是不错的。
发现缺点其实就说明自己也从里头学到了些东西，好事好事。
自我remind
1.核心需求是什么，解决的主要问题是什么
2.精细地检查整套流程
3.多用优先级处理问题
4.多训练和注意自己的表达方式，口头&书面
5.多看书，多体验，多学习，最重要的是多思考！
以前不理解“简单可依赖”这句话，而且还一度自以为是地鄙视，看来我真的是无知地不行啊。
现在我觉得简单可依赖不是说得那么简单，这是一种最完美的状态。当然即使整天说这句话的BD也有绝大部分产品并非达到了简单可依赖。
简单可依赖是要用最简单的方式实现最绝顶的用户体验，没有多少公司做到。
