自我介绍一下,gege现在是大三,想成为一名PM。

原文发布于:人人都是产品经理

图片 1

之前有在58赶集集团的「转转」实习过,依然属于小白,目前在练习一些PM的基本技能。

流程图是流经一个系统的信息流、观点流、或部件流的图形代表。它既可以是生产线上的工艺流程,也可以是完成一项任务必需的管理过程。流程图有时也称作输入-输出图,该图直观地描述一个工作过程中的具体步骤(百度解释部分节选)。

文档能力是产品经理必备的基本能力,产品经理通过文档的方式把需求传递给项目的相关人员,使相关人员更好的理解需求。所以文档的好坏直接影响到团队成员对需求的理解程度。

自己在学习的过程中的所思所得想找个地方记录,因此开始码字,争取之后每周都写几篇文章,例如产品分析等等。

个人理解,一个好的互联网产品(移动端/PC端)流程图就是用户完成某一项任务的具体行为步骤,例如:登录、注册、购买商品等等,这执行这项任务时,每一个行为的集合,从流程的开始到结束的封闭系统。中间不能出现断层、及走不通的情况。

所以刚入行的产品新人都会优先学习产品需求文档(下面会用PRD代替)的撰写和原型的绘制,自己当时也是一样。当时看了很多产品需求文档的案例,各种类型、格式的产品文档都研究过。然后在主流的几个文档格式中选择Axure原型来撰写PRD,因为Axure做的原型需求文档,与读者之间有互动,体验更加良好而不至于那么单调。

PM工作中最最基础的应该就是流程图以及原型图的产出了,而诸多功能的流程中,登录与注册的应该算是最简单的了,下面就是gege做的流程图:

为什么要画流程图(意义)

产品需求文档初成型

刚开始时,在网上的一些模板并结合实际项目来撰写PRD的,并且PRD和原型图是完全分开的,也就是说第一次撰写的PRD只包含一些基本的和公共的信息,比如文档的修订历史、产品说明、版本介绍以及核心的流程图。其他的细节信息则是通过在原型图上进行简要的标注。

图片 2

后来经历过几次的项目开发和迭代之后,发现PRD与原型图分开管理的方式制作起来十分繁琐,并且一些小版本的更新很经常会直接在原型图上做更新而忘了更新PRD。而且开发人员、设计师基本上只看原型图,不看PRD,遇到需求问题就直接问PM,这样就失去了产品需求文档的意义了。

后来就决定把原型图与PRD进行统一,上面分散管理的问题也得到解决。并更换为更流行的侧边导航栏、更好的视觉设计,使读者的阅读体验更好。此时的产品需求文档已经慢慢开始成型。

图片 3

这个版本可以说是PRD的Beta版,虽然是Beta版本,但是基本功能能满足我们的需求,所以当时以这个版本的PRD持续了一段时间。

登陆注册流程

在设计一个互联网产品时,流程图可以帮助我们查漏补缺,避免功能流程、逻辑上出现遗漏,确保流程的完整性(往往这也是产品被喷的一个重要因素)。

文档的迭代优化

以Beta版的PRD持续一段时间后,经历了一些项目的沉淀,在项目的使用过程中,发现几个有趣的现象:

  • 开发人员基本上只关注功能的实现,焦点在交互原型图上
  • 设计师基本上只关注页面和效果,焦点在原型图上
  • 测试人员则是侧重于功能细节与各种情况的处理方案

可以理解,如果把PRD作为一个产品来看,上面的涉及的人员都是PRD的核心用户,只不过3种角色的工作性质不一样,所以需求不同而已。显而易见,Beta版的PRD只是把产品相关信息和原型图进行简单的结合是满足不了上面的需求的,所以开发过程中就出现了几个严重的问题:

  • 对原型图、功能的描述不够周全,开发经常找PM确认需求上的点
  • 原型图上没有添加页面跳转信息,导致设计师设计起来有些吃力
  • 没有把核心功能的流程图的流程粒度细化到每个操作,增加PRD读者的理解成本
  • 一些分支流程、特殊情况没有在文档中说明清楚,导致测试人员经常找PM确认流程细节问题,严重降低PM工作效率以及增加了团队的沟通成本。

没错,自己挖的坑,跪着也要填回去。明确知道问题所在后,就需要针对性解决。在此之前,需要针对目标用户进行“用户调研”,确认一下开发人员、设计师和测试人员这些“核心用户”的意见和看法。收集了他们的意见之后,去「起点学院」购买了一些课程学习了具体的文档规范,然后阅读一些与PRD相关的文章,进行分析总结,然后迭代出新版的产品需求文档。

图片 4

新版本PRD在实践中运用之后,之前出现的问题得到了很好的解决,最明显的是团队成员找PM确认需求的次数大大降低了,并且开发效率也得到了提高。当然,PM也减少了在沟通上成本。

下面我会通过以下7个方面来对新版PRD进行详细说明。(文章末尾附有PRD模板Axure文件的下载地址。)

  • 文档命名
  • 文档结构
  • 产品概述
  • 全局说明
  • 流程图
  • 功能需求
  • 非功能需求

其中包括忘记密码、社交账号登录、短信验证码登录等一些功能。

在实际工作过程中,很多PM因为时间上的原因往往将这个工作给忽略了,最后导致在需求评审会上总时不时的被技术发现这样那样的问题,逻辑走不通,流程有问题等等情况(长此以往你在他们心目中的专业性将大打折扣…认真思考下,为什么技术看不上你了吧)。动手写文档或画原型之前,梳理下流程是很有必要的一项工作,真的花不了太多时间(熟能生巧,第一次都会感觉痛苦…o(╯□╰)o老司机都是这么过来的)。

文档命名

产品需求文档的命名,只要能告诉别人这个文档的必要信息就可以了,比如对产品需求文档而言,需要让别人知道这个文档是什么产品的产品需求文档,处于什么阶段,比如PRD_产品名称_V1.0.0。不过为了更好的进行统一管理,这里使用采用了下面的方式来对文件名进行命名。
文档命名规则:【PRD】+ 产品名称 + 产品版本号
例如:【PRD】微信 V6.6.1

接下来gege用Axure绘制了登录及注册流程中的的原型图,下面是其中的两张:

举我一个工作过程中实际发生的例子:

文档结构

PRD的内部结构,如下图所示。

图片 5

主要包含产品概述、全局说明、流程图、功能需求与非功能需求这5大模块,每个模块下方有对应的子模块,下面进行详细的介绍。

登录及注册原型图

背景:登录功能,支持第三方登录。个人资料有修改密码的功能。

产品概述

产品概述模块是用于展示产品介绍、开发规划以及文档修订历史等基本内容。主要有4个部分:

  • 修订历史
  • 开发周期
  • 产品版本说明
  • 产品介绍

首先来看看修订历史。

修订历史
修订历史是展示PRD的修改记录,里面记录着产品经理对PRD的修订的方式以及修订的内容。一般会放在文档的第一页,方便团队成员第一时间了解到需求是否有改动。而修订历史一般会采用表格的形式展示,包含文档的版本号、修订日期、修订方式、修订人以及修订内容。

图片 6

开发周期
开发周期包含两个模块,分别是开发周期以及开发计划。

图片 7

从上图可以看出,在开发周期表格中,显示项目的计划开发时间,不同的平台开发难度不同,所以这里也会加以区分。在下方的则是开发计划,在敏捷开发中,都会以一个时间区间作为迭代的里程碑,小步快跑,一步步完成迭代上线。比如说一个移动App,开发的第一阶段首先要进行框架的搭建、启动页、登录注册等基本功能的开发,然后再按照计划、优先级开发后续的功能。

产品版本说明

图片 8

版本说明只是展示产品对应版本所包含的核心功能。需要注意的是,这个版本是以上线版本为基准,与上面开发周期所说的版本需要区分开来。

产品介绍
显示产品的相关介绍,常见的字段有产品名称、logo、slogen、产品简介、产品定位、目标人群、使用场景以及产品目标等。有个别产品可能还需要显示其他对应的信息,具体以实际情况为准。

图片 9

之前在58实习时曾用Axure画过活动的banner,这次还是第一次来绘制界面。

点击第三方登录按钮,登录成功后,进入应用。这是一个很简单的需求,其实也没什么好梳理的流程,可是在个人资料页面有修改密码这一功能,如果一个新用户通过第三方登录的话,那这时的用户是没有密码的,那这个修改密码是不是就是有问题的,是否应该有些判断,看这个用户是否是设置过密码的,如果是则应该是设置密码的功能。

全局说明

全局说明则是对产品中公共部分的控件、文案、网路请求状态显示等进行统一的说明。全局说明这部分会因产品不同而变动较大,所以也需要根据实际情况而定。

图片 10

图片 11

在开始做之前呢,觉得登录的流程图以及原型图都很简单,但在实际操作中就会经常在一些问题上动脑筋。比如说,忘记密码放在左边还是右边、注册的流程是不是在一个界面完成,以及在流程中我加的一个小需求:密码错误5次后自动跳转到忘记密码页,并且自动填入用户在登录时填写的手机号或邮箱地址。

所以很多时候,PM再设计产品的时候,功能上的缺失,逻辑上的错误往往就是功能、业务流程上没有考虑周到,尤其是经验不太丰富的PM,所以流程图是很重要的应该予以重视,哪怕仅仅是纸面上的草图。

流程图

流程图在这个PRD中是比较重要的模块,其中的逻辑性较强,最能反应出产品经理的逻辑思维能力与流程图的绘制能力。

在文档中,流程图中包含信息结果图、功能结果图、业务流程图以及任务流程图(也是功能流程图)。

图片 12

其中信息结构图和功能结构图可以使用Xmind、MindManager、百度脑图等工具进行绘制;而业务流程图、任务流程图则可以使用Visio、OmniGraffle、ProcessOn等工具进行绘制,然后导入到PRD。如果业务涉及到多端、多用户角色的产品,可以使用泳道图。流程图的具体的绘制大家可以参考woshipm社区下的实例解析业务流程图与产品流程图

第一篇文章,一个新开始,产品前辈若路过,恳请指点一二

(说到底就是为了少出问题,不被喷o(╯□╰)o)

功能需求

功能需求模块是整个PRD中最重要的部分,这个模块是将需求转换为功能的详细说明。在这个模块中可以对产品功能有个全面的了解。先看看功能需求下的三个子模块:

图片 13

功能列表
该页面展示的是整个产品的所有功能,一般采用列表的形式展示,通常包含字段有模块、功能名称、功能描述以及优先级。在这里额外添加了一项阶段安排,通过颜色的刺激程度来区分功能的开发阶段。

图片 14

产品线路图
产品线路图与上述所说的功能结构图十分类似,只不过功能结构图是以功能为单位,而线路图则是以页面为单位。产品线路图展示了产品的所有页面以及对应连接关系。我们可以通过点击线路图中的矩形节点,跳转到对应的功能详情。

图片 15

功能详情
这个是我们的开发人员、设计师、测试人员使用最多的一个模块,没有之一。该模块展示的是功能页面的详细信息,主要有功能页面的描述、流程说明以及异常情况处理。

图片 16

以启动页为例说明一下。主要包含4个部分,分别是原型图、页面简介、界面描述和用户用例。其中界面描述是对原型图中的元素进行详细的解释。用户用例则是对用户的使用流程以及备选流程、异常流程情况的说明,不过并不是每个页面都会有用户用例这个部分,一些简单的展示界面、没有用户行为的页面,就可以不做用户用例。

通过功能详情的一些细节描述和用户用例的思考,可以大大减少产品经理对功能思考的遗漏点。

怎么画流程图

非功能需求

不同产品有不同的非功能性需求,一般有以下几类非功能性需求。

  • 性能需求
  • 统计需求
  • 营销需求
  • 法务需求
  • 质量需求
  • 安全需求
  • 运营需求
  • 财务需求

上面的列举的非功能需求就不一一说明了,每个产品都不一样,需要根据具体产品、具体情况而定。

同样是拿注册登录这个流程举例:下面这张图是我用Axure画的(OmniGraffle,ProcessOn这些工具也都不错,文末会附有Axure
8中文版,OmniGraffle
6的破解版下载链接,有需要的自取),不要太纠结于工具,找一个顺手的即可。

总结

其实PRD的撰写与迭代,可以看做是一个产品的设计与迭代的过程。所以我们在PRD迭代更新的过程中,要明确团队的实际需求,找出痛点、分析问题、得出解决方案、然后实施并验证方案的正确性。以上产品需求文档是经过两次迭代之后,然后结合团队的流程总结出来的,虽然并不完美,但是很好的满足当前团队的需求,基本上符合当前敏捷开发团队的使用,后续也会不断改进优化。不过每个团队也会因情况不同而需求不一样,所以也仅供参考。文章末尾是文档抽离出来的模板,附有对应下载地址。

不过需要明确一点的是,PRD只是一个帮助PM传递想法和需求的工具,一个辅助手段,并不是目的,所以核心还是在需求上。或许到了团队的后期,团队成员能力都很强、都很默契,基本上可以通过口头沟通完成信息传递时,那么产品需求文档也就不那么重要了。(嗯,这很理想…)

产品需求文档模板_Axure文件地址
密码:mhns

可以直接保存图片到本地,还是挺清楚的。

上面这幅图是登录、注册,找回密码的流程,因功能及业务需求的不同仅供参考。当你认真仔细的梳理过后,就会在最大程度上避免一些流程上的问题发生。

提高效率的小技巧

当然,这一过程中其实也是有些小技巧可以快速的提高我们的工作效率,例如:获取验证码这一功能,基本上是大同小异的,一次做好我们可以反复去使用。

在上面那一张,完整的登录注册流程图里,你就可以把获取验证码这一流程,单独提取出来,涉及到这个流程的时候,只需要一个超链接,链接到获取验证码这一个流程就可以了(具体操作看原型Axure,密码登录时获取验证码,文末会有链接),同样的方式,在电商类产品里从浏览商品到最后下单,付款结账这一任务流程,把其中常用的付款流程单独提取出来,这样一个大的流程就是由许多小流程(一个流程一个小模块)组成,每个小流程(常用的,每个App流程基本改动不太大的)可反复使用,提高工作效率,这就有点像面向对象的封装思想

以上就是我个人在平时的实践中总结的一些工作方法,可能并不一定很好,但又怕什么呢,这不就是一个不断成长与进化的过程么,就像一个优秀的产品也是在不断打磨的过程中逐渐完善起来的,所以我们的工作方法也是,需要不断的探索,力求找到最好方法。最后,如有什么建议与想法欢迎能和大家沟通交流,彼此成长。特别喜欢一句话:

累死你的不是你的工作,而是工作方式。

【本文由“Mr_Xia账号”发布,2017年07月26日】

相关文章