从需求分析到原型制作，到需求文档，产品经理会掉进哪些坑？

　　从最开始的对于产品经理这个职位不屑一顾，认为不接触代码、不做设计，工作主要建立在沟通打杂这件事上，工作室会比较轻松，但后来真正实现入门，在相继接触多年的产品工作后，发现以前的认知完全错误，一个需求分析或者写需求文档就足够让我深入学习很久。
　　在此，多年走过的坑，以及熟知不再犯，给大家一些参考意见。
　　需求分析
　　做需求分析的时候，不要总是用“我认为“”我感觉“这一类的语句来解释为什么需要做这个需求，这类解释是苍白无力的，有时间去做个用户访谈，可以参考腾讯的101001000法则（每个月10个用户调查，关注100个用户博客，收集反馈1000个用户体验），只有全局了解用户需求，才能做出为人所用的产品。
　　在会议上进行需求分析的时候，随着头脑风暴的崛起，需求随之增多，满满几十条跃然纸上，这都是正常的，这时候作为产品经理，千万不要宣布会议结束，直接确定需求，这是非常愚蠢的做法。
　　我向来坚持一个观点：只会加需求的人不是产品经理，会减需求的人才称得上是产品经理。
　　我经历过一个产品经过数次需求评审会议，在我进行需求优先级排序后，后期临时增加需求，然后无限制卖命加班，最后做出的产品是个四不像，各种功能都有，没有主次之分，很乱。
　　一般来说，对于需求分析，个人认为比较正确的做法是：在需求分析会议上加了很多需求，进行记录下来，然后回到产品的定位上面，从这上面进行思考，不要出现你做一个和旅游APP，加个社交功能，各种关注私信，这就是画蛇添足了。
　　根据产品定位进行思考，将最主要的功能进行甄选出来，并且和参会人员进行谨慎地确认，包括老板的意见，询问项目经理是否可以实现等等问题，然后将主要的需求进行确定，会议后进行整理，发邮件给反馈进行确认。
　　将最主要的功能甄选出来进行开发，可以提高开发周期的效率，快速上线产品，用户使用可以快速试错，通过用户反馈做出更好的产品体验。
　　需求确定后，在之后的设计以及开发过程中，不要出现一个想法，临时加需求，这样影响产品最初的一些规划以及开发排期，以我个人经验来说，后期乱加需求往往意义不大。
　　原型制作
　　需求确定后，产品经理一般着手于原型制作了，现在大部分的产品经理需要懂交互，所以你必须懂，还需要专业。
　　1、根据信息架构进行原型制作，根据具体的产品，我还是建议用比较简单的原型图来进行表现。
　　原型图不可能一次性通过，需要进行评审以及各种更改，制作高保真原型图涉及到那些跳转链接，费时费力，那么都需要改，你需要花费很多时间，给出清晰的备注就好，提高效率。
　　各种颜色以及按钮形状出现在原型图上，会极大地干扰之后UI设计师的设计思路，会对思维产生干扰，专业的人做专业的事。
　　2、在制作原型图的过程中，建议先画出清晰的业务流程图，有个清晰的思路进行参考制作原型图，每一个功能都需要画出相应详细的流程图出来，为了确认流程走得通，这是必不可少的。
　　经常有产品经理在确定需求后，一股脑地直接画原型图，最后做完给开发，发现最简单的登录注册流程都走不通，那真的是贻笑大方。
　　切记每个功能画出相应的流程图。
　　3、在画原型图的过程中，对于功能描述尽量使用确定肯定的词语，不要使用含糊不确定的词语。
　　功能描述能分点列出就分点列出，简单直接，不要使用大段文字，便于设计开发理解。
　　举个例子，这是对于留言界面的反例：用户可以在留言界面进行留言，留言可删除，点击屏幕可以刷新。
　　程序员看到了就要崩溃，是否登录才能留言，留言的字数限制，初始显示多少条，留言可删除是管理员删除还是用户，刷新是下拉刷新还是其他方式？
　　比较规范的做法：
　　留言初始显示六条，查看更多留言点击下方有关页数按钮。
　　游客不能进行留言，注册登录用户才可进行留言。
　　留言字数限制在五十字以内。
　　用户留言，本人可以进行删除，其他用户无删除权限。
　　以上只是一个简单的例子，功能描述足够清晰，才能提高设计开发的效率，减少沟通成本。
　　4、一个小细节，玩过很多产品，部分产品还在犯，
　　是”登录“，不是”登陆“，
　　是”登录“，不是”登陆“，
　　是”登录“，不是”登陆“，
　　重要的事情说三遍。
　　需求文档
　　需求文档是产品经理的日常工作，可能我们对于这份工作并没有做好，重在细节。
　　需求文档的命名要确定一个规范，以后照此进行，便于文档整理。
　　需求文档中，最开始需要给出产品定义，说明产品是一个给什么用户，基于什么场景，使用这个产品干什么。
　　关于需求文档中的术语和定义，都需要对专有名词给出具体的解释。
　　需求文章中最基本的信息架构图以及产品用例图，都要放上去，便于阅读者了解产品的整体思路轮廓，更加了解需求文档。
　　产品的版本规划中，确定的都填上去，不确定的就写待沟通。
　　有关具体的功能，先给出功能定义，再给出详细的流程图，前置条件、功能规则、后置流程使用清晰确定的词语进行表示，不要使用产品经理本身并不是特别了解的程序表达方式如：正则表达式等词语形容规则，这样的描写对错不确定，程序员看到这种内容也比较排斥，专业的人做专业的事，信任他们才对。
　　产品经理对于填写用户资料、评论、留言等内容的字段说明给出具体的规则，这是产品经理必备的素质，比如微博发状态140字，QQ个性签名50字等主流社交一般的规则，进行了解参考结合具体的产品给出合理的字段说明规则。
　　其他
　　1、最后一个在产品设计的过程中，不要刻意追求创新，去打破现有的一些产品交互逻辑。
　　比如修改密码，绑定邮箱等内容一直都放在菜单设置里面，这么多年的产品培养了用户这个习惯就不要随意打破，打破的效果只会适得其反。
　　2、每次和设计开发去沟通的时候，先想好要说的问题，为什么这么做，找到相应的数据以及产品样例进行支撑，来解释你的做法从而说服他们，不要因为程序认真发表他的意见拒绝你的需求，你就立马撕逼，这是最没有意义的一种行为。
　　事实上，我遇到过的程序员都是讲理的，前提是你要有足够的理由说服他。
　　最后
　　从小听过了很多大道理，却依旧过不好这一生。
　　这句话个人还是比较赞同，所以我比较喜欢掉坑，在产品设计的过程中，只有掉过坑后才能让自身印象深刻，在实际地遇到困难直到解决之后，才能对产品设计有更多的体会，能力得到提升。
　　另外一个非常重要的就是总结，在你做完一个产品上线、一个产品迭代，在阅读完一本产品书籍后，不要经历了就经历了，看过了就看过了，对于这个过程中掉过的坑以及内容的总结，用mindjet等软件进行记录，十分有必要，让你快速吸收经验知识，能力也会得到很快的提升。
　　这是《用户体验要素》中的第一章节，一个章节进行总结浓缩为一页，一本书的精髓内容无非几页而已，这种做法的优点。
　　提升你对于内容的筛选总结能力
　　加深对于产品设计过程或是书籍的理解
　　便于在产品设计思考遇到困境时，进行快速地翻看查阅，可以寻找一些灵感。