记得刚开始工作那段时间，很多亲朋好友都问我：产品经理到底是干啥的？我总是乐此不疲地解释说：就是根据用户需求画出软件的样子，然后让工程师开发出来。看到这里大家肯定会觉得好笑，但这还真就是我一年以前的对产品经理的认识，没错，在我眼里，产品经理就是画原型的。
回顾自己这一年中走过的路，从产品小白做起，笑过哭过，迷茫过也踩过坑，如今再面对这个问题，我的答案是：从产品需求分析到上线推广，每一个环节产品经理都扮演着很重要的角色。
【关于需求】
1、需求来源
1）业务方：可简单理解为给研发体系提需求的部门，在以业务系统为驱动的互联网公司，除少量孵化创新产品之外，大部分需求来自于业务方。
2）用户反馈：产品上线后，可通过各种渠道收集用户反馈，了解用户真正的痛点。
3）产品经理自己总结：通过自己对产品的使用及竞品分析，总结分析出优化完善需求。
2、需求分析
不管需求来源是什么，当面对一个新需求时，我们首先要弄清楚：
1）需求的价值是什么？（需求频次、真正的痛点在哪里、前景如何）
2）技术难度怎么样？研发资源有时间支持吗？
3、需求评审
版本计划、PRD和原型（后面会单独讲）都完成后，就要进入到必不可少的需求评审环节中，确定实现方案及排期。以下几点需注意：
1）与会人员不可遗漏：服务端/客服端相关研发、测试、必要时也需要设计师参加。
2）免不了会是一场撕逼：要悉心接收大家的意见，但也要有自己的坚持。
3）会议纪要：一定不能忘记发会议纪要，确定项&遗留项，可以让后续大家的工作有据可依。
TimLine红包接入评审会议纪要
【关于版本计划】
包括：需求分类+需求编号（分类标识+时间+序号）+具体描述+关联产品线+优先级+责任人
咚咚M端某版本计划
【关于PRD】
1、版本号，修订记录
2、切忌文字堆砌，力求清晰、简洁
记得我第一个PRD写TimLine的文件撤回功能，当时不懂得要分点、分类，我的导师指出这样写一是没有逻辑性，让人很难读懂；二是文字太多也很浪费大家的时间。后来自己每次写PRD都会反复修改几次，直到至少自己觉得满意为止。例如以下对TimLine搜索逻辑的梳理，分为搜索规则、排序规则、显示规则三大块，每一块再进行具体细节的详细描述，就比较清晰了。
TimLine搜索优化逻辑
3、用户场景全面考虑
1）多终端是否兼容
2）新老版本是否兼容，是否会影响老版本用户的正常使用
3）异常情况如何友好处理
【关于原型】
1、版本号，修订记录
xxx原型修订记录
2、标识说明
缺失的话可能会导致首次阅读你原型的同事不清楚每个标识的含义
xxx原型标识说明
3、注重交互细节
原型并不是画几张图就够了，需要画出整个重要的人机交互流程，用户每一步操作的结果是什么。如果原型里面都忽略了，那研发和设计师后续会漏掉很多细节，并会影响测试同学的测试质量。
xxx项目原型&交互稿
【关于测试】
1、主流程回归
APP发版前一定要做功能的主流程回归， 不像网页端产品，出问题可随时修复，APP一旦发出 去出问题，是无法挽回的。关于这一点我是有血与泪的惨痛教训的，去年负责的一款APP因发版前未做完主流手机系统的回归测试，导致发出去的版本无法正常升级。而恰恰就是没有测试到的系统版本出问题。墨菲定理总是能在某些时刻应验，同志们，千万不能存侥幸心理呀。
2、交互细节
测试同学主要注重于产品功能的测试，而交互细节则应该产品经理去做验证，虽然不能达到设计师做视觉还原那么专业，但是回归基本的交互应该是没有问题的。
【关于上线推广】
1、上线前，有目标地指定某新功能的宣传计划。
2、上线后，发现异常需要引导用户正确使用。
【其他】
1、PPT——重要技能
拒绝简单罗列文字，尽量结构化、可视化，表明各部分间的关联。
TimLine工作汇报
2、阅读——丰富你的内涵，拓宽你的视野
3、学会减压
IT行业工作节奏很快，虽然成都远不及北上广压力大，但要说毫无压力也是不可能的。有的时候挺羡慕设计师的，在一个相对单一的工作环境里，专心做好自己的专业设计就行。不用像产品经理那样，要参与太多的事，需求跟进、开发跟进、测试跟进、项目推动、资源协调，各式各样的压力都可能会出现，所以一定得学会给自己减压。K歌，美食，跑步，音乐，喜欢什么就去做什么，休息够了玩够了，回来又是一条好汉~
网友评论