产品经理职责

一,拿到一个项目大体的策划书之后:
1,需求调研(时长、用户);
(1),所在行业、市场的分析,当前发展情况及未来发展趋势;同类产品的发展情况;
(2),使用场景分析;需求层次的分析,表面分析,深入分析;
(3),竞品分析,分析竞品功能的出发点及主页业务,从而分析自身的一些需求,切记不要照抄;
(4),需求分级,根据产品不同周期区分什么是核心需求,什么是重要需求,什么是次要需求,然后根据需求的重要性,调整对此需求的开发投入。

二,调研结束知道大体的需求后:
2,产品策划,核心需求,架构分析,功能,交互、设计等,同时需要对竞品的产品需求、产品功能、用户定位、商业模式、运营思路、营销盈利等方面进行分析;具体如下:
前台(App或H5):
(1),MVP(最简化可实行产品)原则和可用性测试就不用去做;
(2),设计原型,不要一开始就画需求。首先进行需求分析,分析明确了逻辑、流程、功能点再着手制作原型;
(3),项目需求文档(PRD)的书写,严格区分并且记录每次需要发布的版本;
首先,明确需求后,用Xmind画出项目架构,然后通过架构中的某个模块或者业务,进行拆分话出流程图。
对于某一个复杂或者具体的业务模块,用Xmind画出流程图,并且进行记录,在优化或升级的时候在其基础上进行重新保存,记录版本;
PRD文档中包含:原型的展示,数据元素,用例描述,复杂一些的模块还需包括流程图;
[1],PRD文档可和设计原型并行完成,先在PRD文档中书写大纲,然后再具体的模块中进行设计原型并且完善PRD文档;
[2],可以直接贴本功能的原型图;
[3],本功能原型图中所有展示的数据列表及解释;
[4],本功能中部分操作用例的操作方式及交互方式;
[5],描述每个功能的互动设计和使用案例,用最简洁易懂的语言或者图形。
(4),每次升级或者优化的版本进行记录,以便后期能够直观的看出每个版本具体做了那些升级,最好做成excel以供检索;
(对每一个版本的需求进行分组,组下边有此版本的各个功能的增加、修改、优化条目,方便查找且留有历史记录)
(5),版本的冗余度不要太高,不要将某个版本的功能做的太过复杂,要进行发布迭代,先实现核心的需求,然后迭代次要需要。
(6),最重要 – 总结能力,各个功能和版本进行总结。

设计:
1,规范一些产品主题色值;字体大小,字体颜色,遮罩,透明度,圆角,一些常用文本的行数;
2,规范标准图标的大小。例如:iOS,Android的icon、封面展示图,wechat、新浪等第三方分享的封面展示图;
3,不要让设计人员因为美观而去修改产品的交互性和产品最初的理念;
4,设计人员的设计工作从外到内进行设计,设计出来一个页面就发布一个页面,禁忌全部设计完再发布,勿拖延开发人员时间。

后台(开发):
[1],规范一些需要保存的数据字段用以数据分析;例如:
IP、坐标、设备型号、设备ID、版本号、设备类型、token等公共信息。
[2],规范一些接口中不得出现的字段及一些数据格式;
例如id,nil等不出现的字段或者值;
接口整体形式:
{ code , msg , data, attach}
[3],后台系统的一些流程图,主要以功能图为主,从管理员登陆到base页展示,菜单栏操作等;
[4],后台系统的一些实体关系图,例如用户权限的一些操作图,不仅用于记录,而且直观的让后台开发人员直观的看到权限等,对数据库的设计有所帮助;
[5],后台原型图;
[6],后台系统的PRD(原型,元素,用例);
[7],后台不要一股脑的返回所有的字段给前台,需要什么返回什么,缺什么加什么;
[8],最重要 – 总结能力,各个功能和版本进行总结。

6,产品跟进和推动(项目管理);
8,测试:熟悉项目功能、流程、交互、盈利模式等,需要全方位进行测试。
9,上线后的数据分析,从数据里发现优化点,从数据获得新的需求等进行迭代;通过数据分析,分析产品功能效果,找到产品迭代的重点,对症下药。
10,优化,改进,营销;

1,业务逻辑图;2,流程图;3,产品结构图;
业务逻辑图等同于流程图。


1,统领心,大局观;
2,逻辑性;
3,沟通能力,表达能力。

1,思考能力;
2,总结能力;
3,学习能力;

1,产品需求;
2,产品功能;
3,用户定位;
4,商业模式;
5,运营思路;
6,营销盈利。

一些规范:
1,文件命名: 公司名+产品名+PRD+v1.0 ,例如: 公司名-产品名-PRD-v1.0;
2, 修订控制页 : 编号、文档版本、修订章节、修订原因(背景)、修订日期、修改人 ;

项目背景:人员组成、产品目标描述等
修改记录:每次的修改点和原因
信息架构:整体架构
核心流程:主要用户使用流程 交互分支1/2/3…:中高保真原型(功能和元素布局等)、详尽交互说明(空状态、错误提示、网络相关等等)
场景关联:应用外部的关联场景,硬件相关(低电使用、物理键操作等等),软件相关(通知打断、应用调用等等)
应用一致性梳理:弹框、toast、文案、设置列表、操作手势等等聚类梳理,主要是自我核查。(如有时间,会协助视觉同事把所有图标聚类梳理)
当然,文档撰写前有很多前期工作,例如用户研究、需求分析、沟通/评审/修改/确认、可用性测试等等。文档交付之后,还需要沟通/修改/补充/确认、开发核对、辅助测试等等。

一般而言,PRD文档是写给UI、研发、测试看的,那些市场分析、数据分析、产品需求、产品背景介绍等等前期准备工作还是通过MRD或者PPT来完成,针对PRD文档,针对的对象很简单,就是指导UI设计和开发团队研发和测试,既然如此,那么框架很简单:
1.目录(这个不用说)
2.修改记录(为了追踪整个产品形成的过程)
3.设计风格、要求(主要针对界面设计)
4.功能说明(便于了解产品架构)
5.操作说明(这里要重点说明,一定要详细写明,不同操作状态下的显示、提示、转场是什么样的,都要详细说明,不然留下的后果就是开发人员按照自己的程序语言来表达,导致啼笑皆非的事都有,后面你要优化个没完没了,还不如刚开始提交PRD文档时就面面俱到。

一些概念:
1、uv(unique visitor),指访问某个站点或点击某条新闻的不同IP地址的人数。
在同一天内,uv只记录第一次进入网站的具有独立IP的访问者,在同一天内再次访问该网站则不计数。独立IP访问者提供了一定时间内不同观众数量的统计指标,而没有反应出网站的全面活动。

2、PV(page view),即页面浏览量;用户每1次对网站中的每个网页访问均被记录1次。用户对同一页面的多次访问,访问量累计。
PV(page view),即页面浏览量;用户每1次对网站中的每个网页访问均被记录1次。用户对同一页面的多次访问,访问量累计。

3、转化率;用户从某个指定的区域进入目标页面的次数;例如banner图点击进入某个商品详情后,记录一次banner的转化率;

给老板看的东西一般为:
市场分析、数据分析、产品需求、产品背景介绍等等前期准备工作还是通过MRD或者PPT来完成,然后通过演示给管理层进行评审。

功能性需求:登陆,注册,聊天等功能性的需求;
非功能性需求:产品客观意义上的一些需求,功能以外的一些需求,例如系统性能、可靠性、可维护性、可扩展性、兼容性、营销需求、运营需求、财务需求等。

1,是否需要国际化;
2,是否需要兼容暗黑模式;
3,是否需要删除缓存;

Leave a Reply

Your email address will not be published. Required fields are marked *