精华内容
下载资源
问答
  • 需求文档 | 产品需求文档(PRD)

    千次阅读 多人点赞 2018-08-07 16:52:56
    首先,与大家先分享一句话:把需求文档当成一个“互联网产品”去管理,理解它的用户,关注它的体验,不停迭代,使其价值最大化。(引用) 既然把它视为一个互联网产品,那我们需要思考PRD的用户是谁,他们通过PRD...

    一份优秀的PRD能够帮助你获取资源,有效推进项目,获得团队成员的信任。

    一、PRD的用户是谁?

    首先,与大家先分享一句话:把需求文档当成一个“互联网产品”去管理,理解它的用户,关注它的体验,不停迭代,使其价值最大化。(引用)

    既然把它视为一个互联网产品,那我们需要思考PRD的用户是谁,他们通过PRD要了解什么内容?

    根据用户以及他们的诉求,我把PRD分成几个阶段:

    image

    1)MRD阶段

    这个时候,主要需要说服我们的老板、或者团队内部评审,也会有需求方,让大家认同你的方案,知道你要做什么怎么做。

    所以这个时候类似于MRD,把整个方案路线说清楚就可以,做一个较粗线条的DEMO图。

    切勿做细化的设计稿,更不要写详细的功能说明,因为这时候被拍的可能性很大。

    2)PRD V1.0

    如果通过了第一步评审,这时可以做细化的内容,做一个相对细化的DEMO图,这一步面向开发、交互,开发进行技术上的评估。

    交互是下一步真正要做事儿的人,会关注一些页面的细节,所以这个时候可以做详细的DEMO图,并在DEMO图右侧配以一些说明,方便交互及UI进行工作。

    不要写详细的界面操作说明,不过可以在进行界面设计期间,先写一些业务逻辑相关的内容。

    3)PRD V2.0

    这个就是全版了,这么细化的内容,只有真正做这块功能的开发同学才会细看,写细写全没得说了。

    了解了不同用户的诉求,那我们就具体说下PRD编写的内容吧。

    二、围绕用户体验要素的PRD编写

    为什么要说围绕用户体验要素来编写PRD,因为产品的设计是围绕着这个经典的框架来的,那写PRD的任务当然是要把这个内容向大家表述清楚。

    用户体验要素

    下面就具体说下PRD如何围绕这个内容编写。

    第一部分:需求概述(战略层)

    其实不仅仅是做产品,任何事情,第一步肯定是要想清楚要做什么,为什么要做,也就是把战略层描述清楚,PRD的第一部分就是要把这块内容说清楚,回答出下面的问题。

    1)用户要获得什么?—— 用户痛点、需求

    建议这块内容,说清楚整体的问题痛点,同时也要举具体case,列举数字,如用户的使用频次,现在的花费等等。

    2)用户是谁?—— 用户细分、用户数量、画像

    用户是谁,并不是如“商家用户”这种粗线条的描述,要说清楚对于当前的功能,是哪类用户在什么场景下的需求,用户的量级是怎样的,有一个相对具体的画像。

    3)用户能通过这个得到什么? —— 用户收益

    这里面补充个内容,俞军老师曾说过,用户净收益=新体验-旧体验-替换成本,替换成本可能是获取成本、认知成本、资金等等, 虽然这些内容并不是真正可衡量的,但在做一款新产品评估其价值时,可以从这几个角度进行思考。

    4)我们能得到什么?—— 对企业能带来什么收益

    这点很重要,做任何产品,给用户赋能,给用户带来价值,其主要目的还是企业自身能够盈利,这点想清楚才能说服老板提供资源呀。

    image

    第二部分:产品规划(范围层)

    最抽象的战略层说清楚了,下一步就要大体说下为了实现上面列举的各种想法目标,要一步一步怎么做了,也就是说清范围层的内容。

    1)功能&信息结构图

    范围层,就是要说清楚,为了实现战略做什么事情,什么功能,提供什么内容。这块一般会通过脑图或者框架图来展现,说清楚我们需要哪些数据,做哪些功能,各个功能与功能之间的关系。

    要注意,这部分需要在长远角度,解决这个问题地整条路线进行思考。举个例子吧,比如要做个评论功能,让用户对产品更了解,并带来更多销量。那第一步先增加评论功能,之后可以对评论进行分析,为用户推荐高质量的产品,发现问题产品保证平台产品质量等等。类似这样,出一个整体的规划蓝图。

    2)路线规划

    蓝图出来了,还是要落地的。所以这一步要把刚才地蓝图,切成一块一块,每一步要做什么,多长时间,这个阶段解决怎么的问题,为后面提供什么铺垫。有些内容,也可以出一个简易的DEMO图,能描述清楚即可。

    image

    第三部分:功能概述(结构层、框架层、表现层)

    这一部分是对当前这一期要做的内容的详细描述了。这部分面向的主要用户是UI、交互、开发、测试同学,具体到做事情上,就是把大家的认知拉齐。

    1)产品流程图

    通过图的方式,可以快速、方便地告知PRD的每个用户这个功能的思路流程。这里最开始放的是比较粗线条的流程图,比如买家购买商品,加入购物车->付款->商家发货->确认收货。而一些细节,比如买家超时未付款,或者卖家修改价钱等等,可以到具体写到这个功能点地时候再出一个细化的流程图。

    2)DEMO,原型制作

    3)UI稿

    4)产品功能点

    image

    补充:

    产品流程图——UML(统一建模语言)

    Unified Modeling Language (UML)又称统一建模语言,为软件开发的所有阶段提供模型化和可视化支持,简而言之,就是用图的方式把事情描述清楚。

    下面我以员工提交权限审批这件事为例,对应地类(或者说是对象)有员工、老板、还是审批单,给大家主要介绍4个图。

    1)活动图

    我们也经常叫流程图,就是要描述清楚各个角色之间的工作流程。

    矩形框内描述当前活动,菱形块列出分叉路线。如果有多个角色,如下面的例子,则将每个角色出一个泳道,对应哪个角色的活动即放到哪个泳道下。

    image

    2)序列图

    这个图是各个对象之间的一个描述,与活动图略有相似,可以看下面的例子,我们在日常工作中,选取其中某一个把事情说清楚就OK了。

    这里每个对象会有一个生命线,我把系统本身单出来,做了一条生命线,员工、老板在进行某些操作后,需要系统这面进行保存或者修改状态,那右侧即对应与数据库的交互,后端同学根据这个,大体就了解自己在什么时候要做什么事情了。

    image

    3)状态图

    状态图的样式,虽说和活动图样式差不多,但其实内容差别还挺大的,状态图是对一个对象的不同状态切换进行描述。比如权限审批这个事情,审批单有“审批中”、“未批准”、“批准”这3种状态,通过这个图可以很清晰地了解各个状态的转换方式。

    image

    4)类图

    描述类的内部结构和类之间的关系,这个用得不多,可以简单了解下。

    还是这个功能,我们有员工、审批单、老板这3个类,他们有些属性,对于员工和老板还有一些操作,可以通过这个类图来表述出来。其中有个±号,+号是public,即其他类可见,-号是private,其他类不可见。比如员工的姓名,其他类无法获知,但可以通过一些对象操作获得。这个就有些偏开发的内容了,不是特殊需要开发同学知道信息,可以不对这块进行标注。

    image

    产品功能细化说明

    这块就是要把功能说得足够细,但也是有一些技巧。

    1)更新说明

    首先,我一般会在功能最上方,列出更新的清单,一般记录有:调整时间、调整功能块、详细说明。

    2)全局说明

    每期功能可能会有多个页面多个功能块,但有一些想通的地方,比如对于数据产品,数字的展现形式,保留2位小数,增加三分位符号等;对于移动端产品,一些操作方式等。这个适用于各个块,不用分别在每个中单独说明,而且后续做其他功能都是可以复用的,可以先列出来说清楚。

    3)具体每个块的功能说明

    • 前置条件:有些功能可能会有这个内容,在什么情况触发这个功能,比如在用户购买什么商品后提供某个功能;
    • 主体功能说明
    • 流程描述:主流程、分支流程,这个就可以使用上面介绍的UML图,把主线条描述清楚;
    • 界面描述:操作、文案,文案建议其他颜色标注出来,防止和描述弄混;
    • 业务规则:这个是在界面看不到的,比如限制条件、表格的排序规则、需要记录的数据、还有一些数字的计算公式等等;
    • 异常描述:这个不能忽略,尤其是C端产品,考虑需要更为全面,因为很可能就是一个小异常,就导致用户使用不爽而流失,比如上传文件没有考虑超出大小怎么办,用户上传后一直没反应,就会认为这个产品不好用,转而使用其他产品,所以,异常地考虑很重要。列几个常见的异常:如未输入、输入错误、无数据,无网络,长时间未操作,异常退出等等。

    最后说下写这块内容的原则

    • 完整:足够细,考虑足够周全;
    • 无歧义:RD同学是拿着这个文档真真切切写代码,所以说得内容,要能够落到代码上,比如用户一段时间未操作则提示。等待多长时间,要写清楚;
    • 有条理:这文档是有人看的,所以序号、符号都适当的用上,让你的文档容易阅读;
    • 及时更新:功能、DEMO的调整,都需要落到PRD上。

    第四部分:数据需求

    需要哪些维度、哪些指标,指标的来源库表字段、计算口径是什么,这些都要清晰地记录下来。

    除此之后,有个内容可能经常会被忽略,就是数据的整理。以某宝的搜索结果页为例,一般会展示图片、标题、价格、销量、卖家名称、包邮会标记出来,这些RD通过UI稿可能会查看到,但有一些比如鼠标移入显示信息,点击操作、是否购买过,都在商品展示时体现出来。

    这些内容,我们可不能指望RD同学从UI稿中一点点发现。所以列出这样的表格,把你认为需要的类及其属性列清楚,有点类似我们上面类图中对象属性要描述的内容,目的是让开发同学对照这个来进行库表设计,不要遗漏某些点。

    image

    第五部分:数据埋点

    包括按钮的埋点&内容的埋点,可以通过截图+表格说明的方式,截图标明需要埋点哪些控件,表格说明对应控件的什么信息,如操作PV、UV、输入内容等。

    第六部分:效果评估方案及上线安排

    对于C端产品,这块内容会更加重要,一般会有个灰度发布过程,因此需要说清楚灰度发布的方式,放量安排、节奏,需要关注的指标,这个指标如何进行评估,达到什么样程度可以全部上线。

    第七部分:人员排期

    OK,大功告成了。

    三、PRD的承载

    PRD的存放:

    • 在axure中完成,在DEMO的右侧进行说明,但这个不好的是:在进行更新后,还要发送给大家,各个版本的存放加上axure本身下载解压就比较麻烦,所以并不是最佳方案。
    • wiki来完成,只要一个链接,更新后只要告知大家同步下信息就好,就是在写功能时候,需要把DEMO对应图贴上去,RD能够比较方便知道是对哪块内容的描述。

    对于上述内容,我一般分成2个wiki页记录,一个记录需求概述和产品规划部分内容;一个记录产品功能及之后的内容,这个是当前这期的事情。一个总分的结构。

    以上是我个人写PRD的一些经验总结,希望对大家有帮助。

    展开全文
  • 产品需求文档(PRD)

    千次阅读 2019-09-17 16:47:00
    产品需求文档是将商业需求文档(BRD)和市场需求文档(MRD)用更加专业的语言进行描述。 一、什么是产品需求文档 该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然,这个定义针对...

    俗语有云:人人都是产品经理,身为开发人员,要开发一款卓越的产品,还必须得从产品经理的角度去思考、设计以及看待遇到的各类问题。

    产品需求文档是将商业需求文档(BRD)和市场需求文档(MRD)用更加专业的语言进行描述。

    一、什么是产品需求文档 

    该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然,这个定义针对的是一个全新的产品。广义上来讲,产品需求的描述,应该包含有产品的战略和战术,战略是指:产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等。

    PRD的主要使用对象有:开发、测试、项目经理、交互设计师运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑;测试可以根据PRD建用例;项目经理可以根据PRD拆分工作包,并分配开发人员;交互设计师可以通过PRD来设计交互细节。PRD是项目启动之前,必须要通过评审确定的最重要文档。

     二、产品需求文档的要素

    1、文档的命名和编号 

    文档的编号和命名很关键,每个产品都是经过若干个迭代才完成的,而每个迭代所完成的产品功能或者升级的需求都可能是不一样的,因此需要定义清楚该文件属于产品的哪个迭代,修改了几个版本。文件命名的方法一般是通过版本号定义,比如简单的方法是,XX产品V1.0PRD_V2,前面的V1.0是产品迭代的编号,后面的V2 PRD的版本号。稍微详细点可以定义成,XX产品XXXX需求PRD_V2,即对本次迭代的需求任务做命名,这样更便于阅读和记忆。

    2、文档的版本历史 

    包括,编号、文档版本、章节、修改原因、日期、修改人。编号只是为了记录修改的顺序,文档版本显示的当前修改的内容属于文档的第几个版本(或第几次修改,一次修改一般为一个版本),章节是具体到修改内容属于的功能模块,以便阅读人及时找到修改后的内容,修改原因说明为什么要修改该需求,让阅读者直观的了解原因。日期是指需求文档修改的时间,修改人是指需求内容的修改者。

    3、目录 

    不需要自己新建,文档完成后直接更新模版中的目录即可。目录是用来了解文档结构的。

    4、引言

    这部分的内容有:产品概述及目标、产品roadmap、预期读者、成功的定义标准和判断、参考资料、名词说明。

    1. 产品概述:解释说明该产品研发的背景以及核心功能。

    2. 产品roadmap:为产品规划的蓝图,每个关键阶段完成的核心任务。产品研发是个不断迭代的过程,需要经过若干个版本的迭代,,对一个功能点做了N个迭代后最终又回归到了第一个迭代是很常见。产品经理需要做好心理准备。产品roadmap并不需要全部规划好所有的阶段目标,但是对产品未来发展趋势的一种预估,要达到目标,需要更多的更新和迭代。清晰的呈现产品的roadmap可以帮助产品经理把握产品的全貌,更好的控制研发过程。

    3. 预期读者:文档的使用对象

    4. 成功的定义和判断标准:旨在说明产品的目标

    5. 参考资料:PRD的参考资料

    6. 名词说明:名称、说明。名称就是对文档中会出现的比较新的名称,说明则是对这些名称进行解释。

    5、需求概述 

    需求概述通常包括需求概览、用户类与特征、运行环境、设计和实现上的限制、项目计划、产品风险等等。

    1. 需求概览:分两部分,一是业务流程图,对产品整个业务流程的发生过程做图形化的展示,是对产品整体功能流程的阐释。二是需求清单,对本次要开发的需求任务做分类,给出简明扼要的需求描述并标注优先级。

    2. 用户类与特征:产品的最终用户,确定产品的最终使用者,并对使用者的角色和操作行为做出说明。

    3. 运行环境:该产品上线后的使用环境,比如支持的浏览器及其版本,操作系统、数据库的要求等等,测试人员在看到环境要求后会在测试时重点测试,而最终上线产品时需要把最佳的运营环境告知给用户。设计和实现上的限制:比如控件的开发环境、接口的调用方式等等。

    4. 项目计划:对于prd中要开发的内容,给出关键里程碑,比如需求评审通过的时间、开发的完成时间、上线时间等等。

    5. 产品风险:描述产品可能存在的风险,比如性能瓶颈,没有解决的问题,用户不当使用的风险等等。

     6、功能需求

    功能需求一般是由功能详情和主流程说明两大部分。功能详情是所有的产品功能的描述和规划。功能详情包括以下内容:

    1. 简要说明:介绍此功能的用途,包括其来源或背景,能够解决哪些问题。

    2. 场景描述,产品在哪种情况下会被用户使用,就是用户场景模拟。这也是产品经理讲“好”故事的必备条件。

    3. 业务规则:每上产品在开发时都有相应的业务规则,将这些规则清晰的描述出来,让开发、测试人员能够直观的明白该规则,且没有产生歧义。业务规则必需是完整的、准确的、易懂的。业务规则的描述上如果涉及到页面交互或者页面的修改,建议给出页面的草图或者页面截图在图上说明要修改的内容。另外也建议对页面的输入框、下拉框的内容格式、长度、控件之间的关联性做出说明,什么时候可见,不可见,灰掉或点亮的条件在文档中都给出说明。方便阅读者理解业务规则。

    4. 界面原型:如前所述,涉及到页面交互的部分,产品经理需要设计页面原型。原型设计通常需要产品经理和UI设计师一起来完成。建议的做法是,产品经理可设计一个页面框架,将该页面要呈现的字段及其特征以及页面要使用的场景向交互设计师解释清楚。之后交互和视觉设计师完成产品的原型设计。

    5. 使用者说明:对产品使用者做出说明,可融入简要说明中。

    6. 前置条件:该需求实现依赖的前提条件。比如,上传照片时,需要存有图像文件。

    7. 后置条件:操作后引发的后续处理。

    8. 主流程:把主流放在最后是有道理的,结合上面所说的,做出主流程说明,对每个功能流程走向分点说明(这是非常重要的)。

    看过很多的PRD,文档中对既没有前提条件,也没有后置条件,只对主流程做了说明,但是在描述主流程时却没有描写主流程中每个功能流程的各种走向,只有一个主走向,让人感觉prd成了操作手册。事实上,对分支的介绍是非常重要的,开发和测试中提出的各类问题均与对分支的定义不明有关。一个合格的PRD不仅要描述主流程,同时对分支流程所出现的各类问题都要做详细阐述并给出解决办法。PRD的特征一定是明确的、全面的阐述需求及各类异常情况的处理而不是等到开发和测试阶段发现问题后再给以答案(虽然PRD不可能百分之百的覆盖所有的可能,但是最大化的思考所有的业务问题是编制PRD时必须遵守的原则)。另外,在描写功能需求时给出的办法中不能出现“可能”、“或者”等词,一定是明确的,准确的描述。如果有别的方案,建议写入“可选方案”,在产品构建的早期可选方案可以为功能实现提供更多的选择,当方案确定后可在文档中注明本次使用了哪种方案。

    推荐一个方法:“用例”,在面向对象的软件设计模型中,用例是一个被阐述的内容,用例是对功能使用场景的解释。用例很条理的介绍了每个功能的前置、后置条件,主流程介绍,帮助开发、测试等角色快速的了解产品功能。

    7、效益成本分析

    通过这一点上能看出产品经理必须是个全才,不仅要具备行业知识,还需要有财务知识。一个产品的成本衡量一般包括三个方面:效益预测、产品技术成本和其他成本支出。

    效益预测是指所提供的功能在未来能产生的效益,可通过对比以往的产品或者竞争对手的产品来做预估,效益预测的指标,如每个功能点的潜在用户数、使用频率,吸引到的新的用户特征及数量。产品技术成本是指研发设计以及上线后的运营需要的资源需求,包括人力,软硬件(带宽、服务器、机房)支出。当有项目经理时可以由项目经理来协调这部分需求,如果没有项目经理,产品经理得挑头了,召集开发经理去找运维等部门落实此事。其他的成本还包括支持成本,比如上线后的运营资源投入、市场推广投入以及客服服务投入等。

    此处建议产品经理们都去学习一门课《非财务人员的财务管理》体验下财务的过程管理,如果能亲历沙盘训练,记录财务明细账目,核算资产负债、现金流量、利润率的计算,对成本和利益的核算非常有帮助,而且财务上要求的一丝不苟、精益求精也是每个产品经理需要长期坚持和遵守的。

    8、整合需求

     产品整合能力是产品经理很重要的一个能力,业务合作通常是不可避免的,将隶属于两个不同来源的业务功能做整合也是常见需求,比如系统登陆使用公司的域用户登陆,或者付款使用财付通、支付宝付款,解决好整合需求也是体现产品经理核心竞争力的一大重要表现。

    9、BETA测试需求

    很多产品在正式上线前都有BETA版本或者内测版本,或者叫灰度版本,目的是在测试产品的一些核心功能或者性能。这部分内容不是必须的,但如果需要,需要给出在此阶段要实现的目标或测试、衡量标准。

    10、非功能性需求

    一般情况下非功能性需求包括以下几个部分:产品营销需求、运营需求、财务需求、法务需求、使用帮助、问题反馈等。这些信息构成了产品上线的完整内容,也很好的体现了产品经理的综合素质。

    11、运营计划

    产品上线后如何运营,目标受众是什么,建议的推广策略、问题反馈途径、风险监控、亮点宣传等等,以及与运营人员的协作方式。作为产品的设计人员不是开发完产品就能画句号的,让产品用起来、用得好,有口碑更为重要,所以非常建议运营计划的制定上有产品设计人员的参与。

    再次,说下需求变更,需求不是一成不变的,在产品研发过程中需求变更是正常的,产品团队成员需正确的看待需求变更,并要控制好变更。这里的建议是在做需求分析时,尽可能把每个问题都考虑透彻,提前做好需求变更的预估及应对方案,必要的情况下和团队成员提前沟通存在变更的内容。

    在与团队沟通变更时,需要以一种开放的心态,从团队成员的角度、产品未来的发展趋势、市场格局的变化正确的提出变更需求,始终保持产品方向的正确和团队成员目标的一致。

    三、产品需求文档的相关内容

    1、文档意义

    该文档在产品项目中是一个“承上启下”的作用,“向上”是对MRD内容的继承和发展,“向下”是要把MRD中的内容技术化,向研发部门说明产品的功能和性能指标。

    1、文档撰写

    在该文档中,基点依然是MRD中的内容,只是把重心放在了“产品需求”上,而产品需求本身是在MRD中有所体现的,区别就是在于,PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明。

    这部分是PD写得最多的内容,也就是传统意义上的需求分析,我们这里主要指UC(use case)文档。主要内容有,功能使用的具体描述(每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程,等几大块),Visio做的功能点业务流程,界面的说明,demo等。Demo方面,可能用dreamweaver、ps甚至画图板简单画一下,有时候也会有UI/UE支持,出高保真的demo,开发将来可以直接用的那种。

    2、文档核心

    该文档中,侧重的是对产品产品功能和性能(即“产品需求”)的说明,相对于MRD中的同样内容,要更加详细,并进行量化。在一些国外的公司,是允许把MRD和PRD合并成一个文档的,通常叫做“Marketing & Product Requirements Document”。

    四、产品需求文档的写作方法

    1、写前准备

    在写PRD文档之前,我们需要先罗列出产品功能的信息内容,这一步是将想法逐渐清晰的第一步,也是帮助我们接下来规划功能的辅助信息,同时也可以辅助服务端技术人员创建数据库。因为这是第一步,所以我们不需要罗列的很详细,在之后的步骤里,我们会逐步改进和完善信息内容。

    例如一篇文章的信息内容主要有:文章标题、文章正文、文章作者、发布时间、所属分类。初始的功能需求只有这些信息内容,但是在之后的功能规划中逐渐更加细致的考虑时,可能会增加或者删减,因此第一步我们不用刻意的追求信息的全面。

    罗列信息内容的方式有很多种,文本形式、思维导图形式等等都可以,最主要的是能够清晰易懂,我最常用的方法就是思维导图,因此我称这一步为信息结构图。

    2、梳理需求

    当我们对产品的信息结构了解后,我们就需要规整脑海中的产品需求,让想法更加结构化,因此这一步是梳理产品的需求。我们首先要罗列出产品的频道及页面(产品结构图),其次再基于产品结构图梳理出频道及页面中的功能,并延伸构建出用户的操作流程(用户流程图)。

    以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解,类似鸟瞰式的一目了然,也方便调整完善。

    3、原型设计

    当我们逐渐清晰了产品的需求后,并梳理了产品的各个频道及页面,那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。

    首先我建议通过手绘的形式快速在草纸上绘制出产品的原型,推演和讨论方案的可行性,当有一定的进展之后,我们再通过软件工具进行更深入的设计。移动产品可以考虑灰模原型,网站产品可以考虑交互原型,对于这两种原型方式,无论是移动产品还是网站产品都可以使用,具体取得于你的个人习惯和团队要求。

    对于产品经理来说,原型设计是为了帮助我们细致的考虑方案,并论证方案的可行性,同时也是为了避免产品宣讲时,抽象的语言描述导致听众理解困难和理解偏差。

    4、撰写文档

    当我们通过以上三个大的步骤之后,我们就已经非常清晰产品的需求了,一般情况下,通过原型加描述的方式就已经完成了PRD文档的目的(很多产品经理直接使用Axure制作PRD)。

    当然也会有一些个人或团队的要求不一样,对PRD文档有特定的规范标准,这类情况可能是需要存档归类。无论什么样的规范标准,PRD文档的目的都是相近的,因此功能描述的方式也是相似的,所以在这里我分享了三种撰写PRD文档的方式。

    5、用例文档

    《产品需求文档(PRD)的写作方法》的补充文章,主要讲解PRD文档中的重要辅助文档“用例文档”。

    注:该方法为互联网产品经理唐杰所作

    摘自:https://baike.baidu.com/item/%E4%BA%A7%E5%93%81%E9%9C%80%E6%B1%82%E6%96%87%E6%A1%A3/22740526?fromtitle=PRD&fromid=11013752&fr=aladdin

    展开全文
  • 我为了”敏捷开发“,没写需求文档,直接把excel扔给了开发。结果就导致一系列后遗症。 首先是开发在写sql的过程频繁确认需求。xxx字段是什么意思?转化率是如何算的? 我又得去找需求方确认需求,开发继续写sql。...

    今天业务部门向我提了个需求,想要在BI上实现一份日报表,并提供了一份日报表的excel文档样例。

    我为了”敏捷开发“,没写需求文档,直接把excel扔给了开发。结果就导致一系列后遗症。

    首先是开发在写sql的过程频繁确认需求。xxx字段是什么意思?转化率是如何算的?

    我又得去找需求方确认需求,开发继续写sql。最后终于出来了报表。需求方一对,错漏百出。各个值都与需求方自己计算的值有差异。

     

    最后一核对需求,是需求方的下单用户数是不统计已退单用户的,而研发写的sql是算进去。需求方的用户转化率是下单uv/访问小程序uv,研发是下单数/总单数。

    所以数据产品需要严格的文档,而且需要产品经理自测和配备专门的测试人员。

    以下是我们公司通用的报表需求文档

    该文档采用的是指标和维度分离的做法,采用这种做法有利于研发的理解和技术实现。同时表明输出的方式是用接口、数仓报表或是excel,数据输出周期可以按天、按周、实时,按天时应注明t+n。

    关于指标、维度、原生指标、派生指标等概念,可参考https://blog.csdn.net/weixin_41337483/article/details/99409090

    ————————————————

    更多产品经理成长日记,时间管理心得,读书笔记分享,外文博客翻译,请关注我的公众号「原住民的自修室」

     

    展开全文
  • 通用产品需求文档模板

    万次阅读 2017-06-10 17:25:08
    很多朋友说,产品需求文档怎么写?很多公司的产品需求文档要求各不相同,但也是大同小异,其实就是说清楚: 基于什么样的背景,我们要做什么事情, 满足什么用户哪一个需求? 需求分解出来,产品的逻辑如何? ...
    很多朋友说,产品需求文档怎么写?很多公司的产品需求文档要求各不相同,但也是大同小异,其实就是说清楚:
    

    基于什么样的背景,我们要做什么事情,

    满足什么用户哪一个需求?

    需求分解出来,产品的逻辑如何?

    交互图如何?

    设计图如何?

    哪些功能点?

    哪些细节?

    实现进度如何?

    产品健康运转的闭环如何形成?

    文档,就怕写复杂了,连开发都看不明白的文档,必然不是一份好文档。

    抽象了一份文档出来,供大家参考,根据各自公司的具体情况进行修订完善吧。

    1. 文档历史

    修订日期

    修订内容

    修订版本

    修订人

    创建:立项成功后创建需求文档

    V1.0

    开发排期后修订项目进度;

    V1.1

    修订交互/视觉设计稿后需要修订文档

    V1.2

    修订有需求变动的时候需要修订文档,

    同时周知文档关系人,将修订的内容明确标识

    V1.3

    2.目录

    1. 文档历史

    2. 目录

    3. 项目说明

    3.1 项目背景

    3.2 项目目标

    3.3 项目概述

    3.4 项目排期

    4. 项目策划

    4.1 产品逻辑图

    4.2 功能与特性简述列表

    4.3 交互/视觉设计

    4.3 需求详细描述

    5. 数据需求

    5.1 数据建设:考核评价指标

    5.2 指标定义与计算逻辑

    5.3 数据报表

    6. 客服文档

    7. 运营方案

    3. 项目说明

    3.1 项目背景

    项目需求不是产品经理拍脑袋想出来的,一定有个出处,例如,

    l 用户需求驱动,解决哪一种用户什么样的问题?

    l 市场竞争驱动,有了什么新的变化?

    l 技术驱动,有什么技术创新可以应用在产品上,让解决问题的效率更高?速度更快?

    案例:目前繁琐的注册流程导致用户注册成功率仅为20%,本项目主要是优化注册流程,提升注册成功率。

    3.2 项目目标

    由背景推导出的目标,符合SMART原则,简明扼要,一般通过数据衡量,目标通常是贯穿整个需求的线索,整个需求都应该是围绕目标在进行的,包括优先级的排列,也是综合考虑需求点能实现目标的程度、效率、紧迫性、成本控制等各方面因素。

    目标举例,2013年8月10日完成注册流程优化,提升注册成功率10个百分点,从原有的20%提升到30%。

    3.3 项目概述

    将涉及到的页面做个列表,可以帮助评估设计、开发需求所耗费的时间

    文档位置

    页面名称

    页面数量

    所需工作

    4.3.1

    注册起始页面

    3

    页面设计+页面制作

    4.3.2

    注册成功页面

    页面设计+页面制作

    4.3.3

    注册失败页面

    页面设计+页面制作

    3.4 项目排期

    项目进度时间表,也是一个不断推动、修订的过程,协调各方资源,尽量给出靠谱的时间进度,并推动按期完成需求。一般用表格形式,包括字段:项目名称、项目内容、负责人、开始日期、完成日期。

    4. 项目策划

    4.1 产品逻辑图

    按照逻辑线索理出逻辑图,便于阅读者组织对该项目的理解思路,涉及流程的必须给出流程图,一般用VISO绘制。

    4.2 功能与特性简述列表

    产品需求的核心部分,详细的功能列表对需求评审、开发时间评估、测试用例撰写具有重要价值,列表可以尽量详细,一个功能/特性点都可以单独一项,基本可以和测试用例对应,同时,需要给出优先级和测试重点。

    1.功能列表:简洁概要的描述要实现的功能点, 就是让用户做什么,可以按照用户场景和产品流程进行描述,第一步、第二步、第三步……成功、失败。

    2.具体描述:给出在某场景下,用户的具体操作实现过程。例如用户身份变化对应的不同产品表现形态、用户每一步操作需要对应的产品功能、产品的数值变化,数值极端情况。尽可能的考虑全面,细化,具体,可操作,可读性强。

    3.优先级:最高级,本期必须实现。中级优先,二期需求,视第一期产品表现后决定做哪些优化。低优先级,本期可以不实现或延后实现。

    4. 测试重点:从测试的角度,给出具体描述的各个场景下的一些需要关注的主要测试点。一些细节可以在需求详细描述中说明,可以写上详见第几点详细描述,这里只需要给出一些方向即可。

    4.3 交互/视觉设计

    这个部分,一般会有多个修订稿,注意文档的保存与更新。修订文档的时候应该补充好交互/视觉设计稿,便于其他阅览者清晰还原需求所在的产品场景,文档描述所见和开发出的产品所得相统一。

    4.3 需求详细描述

    每个产品功能、特性的详细描述,可以和前文的项目概述一一对应,也是对功能与特性概述的详细说明,一般

    例如一个注册功能详细描述:

    (1) 功能或特性名称:用户注册流程

    (2) 需求描述:一句话描述,简化原有注册流程;

    (3) 使用者:什么样的用户会使用这个功能;

    (4) 前置需求:这个需求的前置需求如何?基于前面的需求,进行功能的进一步开发,说明前一个需求对该需求的影响或者创造的条件;

    (5) 后置需求:该需求完成后,会对哪些需求产生影响;例如用户注册后成功后的用户教育引导需求、注册填写信息对构建用户关系链的影响;

    (6) 主流程描述与业务规则:用户的主要操作流程,及其每个步骤的规则说明。例如,对展示的内容进行描述,如果有可操作部分,需要单独列出:操作前后的状态,操作后的反馈,链接到具体位置等;如果涉及数值等级,对不同数值等级,不同的状态,不同的操作反馈

    举个例子:对注册流程的规则描述:

    A. 注册页面打开,鼠标焦点定位在注明名输入框;支持TAB键进行输入框切换;

    B. 每个输入框的状态:输入前、输入过程、输入结束;

    C. 输入类型:字符、数值;字母、汉字、数字、符号;非法字符;

    D. 敏感词问题;输入长度;是否必填;是否联想;是否记忆;是否有默认值?如何对齐?过长后如何显示?

    E. 输入后多久给出判断?

    F. 一个IP每天可以注册多少个帐号?

    G. 是否可以采用OPENID的形式注册?

    H. 是否需要邮箱、手机进行注册成功验证?

    I. 一个手机或者邮箱是否是唯一绑定关系?

    J. 注册成功后,跳转到用户引导页面;

    K. 注册失败,引导重新注册;

    (7) 产品性能要求:能达到一定的性能指标,比如速度快、软件稳定性、并发使用上限

    (8)其他补充说明(视具体情况选择是否需要)

    A. 安全需求:能够抵挡黑客攻击,保证用户的数据不会丢失,防止黑客刷等级,暴力注册等;

    B. 兼容性需求:如浏览器兼容性、系统版本兼容性;

    C. 财务需求:如一定预算,需要提前找财务审批,产品收入与财务的对接

    D. 法律需求:需要法务部门协助的需求,如何同审核、用户协议、版权

    5. 数据需求

    5.1 数据建设:考核评价指标

    [考核评价指标是评估产品目标的重要标准,在项目策划的前期就必须制订]

    l 访问量

    l 转化率

    l 留存率

    l 用户活跃天

    l 产品收入

    l 任务、活动完成量、质量

    5.2 指标定义与计算逻辑

    数据指标的含义是什么,开发上报哪些数据字段,可以通过公式计算出这些指标;

    5.3 数据报表

    用Excel画出需要查看的报表;如果需要统计图的,说明需要什么类别的图形,柱状图、折线图、饼图等等。

    6. 客服文档

    让客服了解产品,周知客服本产品有可能遇到的用户问题,给出常见问题解答。

    7. 运营方案

    需求完成后的功能点说明或描述,用户周知推广。

    产品不只是上线,后期的运营需要提前考虑。在产品策划阶段或许很难有一个详细的运营方案,但至少有产品成长运转的运营保障,例如从产品生命周期考虑运营方案,在启动期、成长期、成熟期等各个阶段的运营对策;在启动期,第一批种子用户从哪里来?如何保证产品的灰度放量到健康成长的正循环养成?需要提供哪些运营资源的支持?

    一般的运营,都会考虑:拉新、留存、活跃、回流等运营策略。有的只是一个小功能优化,这里可以省略。

    展开全文
  • 本来标题想写成:《震惊!她居然靠这个让程序猿GG高潮》。后来一想算了吧,我又不是UC震惊部的,还是务实一些,少玩儿标题党。 每一个产品经理都写过无数的PRD...1、需求方:当需求方提出需求并与产品经理讨论后,产品
  • 本文继“后端产品经理笔记:数据传输和写入”之后,梳理了需求文档的语法,有兴趣的朋友可以一起交流,欢迎指正。 一、需求文档概述 (1)一些移动端产品不写文档,直接在原型上备注,但遇到逻辑复杂的时候还是要...
  • 初识app之产品需求分析文档设计

    万次阅读 2017-03-17 17:58:00
    1.作为一名开发人员来说,做需求分析是一次巨大的挑战,下面...3.经过看了许多资料之后感觉有那么点意思了,这里我个人感觉比较实用的:(1)如何高效的制作一款app产品需求文档 http://www.chanpin100.com/article/397
  • 产品需求文档到底该怎么写?

    万次阅读 2016-05-14 10:14:24
    博主作为一名产品小白,也被产品需求文档折腾的死去活来,网上也难找一个完美的模板。那么,作为产品需求文档,到底该怎么写,才能让设计让开发都能清晰的了解呢? 产品需求文档,主要目的是说明需要开发的产品功能...
  • 如何写好一份产品需求文档

    万次阅读 多人点赞 2017-01-24 15:52:03
    如何写好一份产品需求文档 PRD写得好看还不如需求把握得准确,PRD写得好看还不如体验设计得顺畅。 工欲善其事必先利其器。 产品需求文档(以下都简称PRD)对于大多数产品新人来说都并不陌生,它是产品工作中...
  • 拼多多产品需求文档

    千次阅读 2019-10-14 13:08:59
    1、产品概述 1.1 产品介绍 拼多多是一款国内主流的电商购物类软件,用户通过发起和家人、朋友、邻居等的拼单,以更低的价格,拼团购买商品。以鲜艳热烈的红色为图标主色调,以“多实惠、多乐趣”为口号,拼多多在给...
  • 【文章摘要】首先声明一下,笔者虽然写过几个网站的代码,那也是5年前的事情了,并非技术出身,很多表达方式上也没有技术语言,有不妥的地方还请海涵。怎么完整高效的制作一款...如何完整高效地制作一款APP产品需求文档
  • 前三篇文章我们逐步梳理了产品的信息结构、框架结构、界面结构(原型),这一步我们就要根据之前完成的工作,开始正式撰写产品需求文档了(PRD文档)。 通过之前的准备工作,我们更加清楚了产品的需求,并细致的考虑...
  • 本文主要目的在沉淀产品经理日常工作中撰写产品需求文档的通用方法。 一、产品需求文档是什么 在日常的工作中,产品经理需要针对特定需求,提出对应的解决方案,不断优化迭代。 产品需求文档就是将产品经理经过...
  • 当我们初次接触产品需求文档时,首先会从网络上寻找产品需求文档模板,希望从中了解和学习具体的写作要求,但实际上,现在网络上绝大部分的PRD文档都是与实际工作不相符的,或者说是复杂的。前几天一位从事产品类...
  • 优秀的产品经理应该对需求文档基本是驾轻就熟信手拈来。 但是对于程序猿如果想尝试些需求文档就非常痛苦,不知道该怎么写。 对于新手产品经理,如何总结模板,每次都恰如其分的套用也很关键。 结合多个优秀的需求...
  • 产品需求文档(PRD)札记

    万次阅读 2018-04-17 08:58:54
    1、理解并掌握PRD文档-写作思路-写作方法-写作格式2、什么是PRD文档– PRD文档向上是对MRD内容的继承与发展,向下则是要把MRD文档里面的各种理论要求技术化,向研发部门与设计部门说明产品的的功能和性能要求。...
  • 当我们初次接触产品需求文档时,首先会从网络上寻找产品需求文档模板,希望从中了解和学习具体的写作要求,但实际上,现在网络上绝大部分的PRD文档都是与实际工作不相符的,或者说是复杂的。 前几天一位从事产品...
  • 前面的几个步骤是为了帮助我们梳理需求、验证可行性和明确细节,到了这一步的时候我们已经非常清晰的了解产品需求,此时撰写产品需求文档可以大大减少和避免了撰写文档时容易忽略的细节黑洞。 产品需求文档是将产品...
  • 需求文档 一、为什么软件开发项目中,需要需求文档这么个东西? 在稍微大一点的开发团队中,产品经理...在产品上线前的测试环节,测试人员也同样会拿产品需求文档来验收产品质量。当团队进入新人时,文档也可以
  • 记得自己在学习PRD文档撰写的时候,总希望能找到一份比较全面详细又易懂的模板。如果你也曾有相同的困恼或者尚未遇到满意的答案,或许本文可以提供不错的参考...不同公司、不同团队或产品对PRD文档的要求不同,不同...
  • 产品需求文档(PRD)对每个产品经理来说都不陌生,它是产品项目由"概念化"阶段进入到"图纸化"的转折和体现,作用是"对市场需求文档(MRD)中的内容进行指标化和技术化",PRD质量的...
  • 需求文档

    千次阅读 多人点赞 2019-03-29 18:10:18
    2018年03月05日 22:11:21 zhangbijun1230 阅读数:40947 产品设计是一个由抽象的概念到具体形象化的处理过程...
  • 产品需求分析文档

    千次阅读 2016-08-26 11:31:31
    互联网产品设计常用文档... BRD 商业需求文档——BRD(Business Requirements Document) 商业需求文档重点放在定义产品的商业需求,要说明产品能够解决的、客户碰到的一个或多个商业问题,然后提出建议解决方案——通
  • PRD(Product Requirement Document,产品需求文档), 这对于任何一个产品经理来说都不会陌生的一个文档, 一个PRD是衡量一个产品经理整体思维的标准, 一个PRD可以看出一个产品经理在某个领域的专业性, ...
  • AI产品经理数据模型设计文档(简版)

    千次阅读 2019-04-03 08:32:42
    有一些产品童鞋不惜花很大的力量想要看看数据模型设计文档长什么样子,下面就列举一个数据模型文档的例子,本文尽量奔着通用型产品经理能看懂来写。 据笔者实践经历来看,目前数据、算法、AI等是...
  • 产品需求文档产品人员非常核心的基本功!是协调研发、测试、UED、业务非常重要的重要工具。但是,往往很多新入行的PM与互联网领域的PM,产出的文档往往不尽人意,主要体现在: 缺乏逻辑,语言啰嗦不精练; ...
  • 产品需求文档(PRD)到底怎么写?

    千次阅读 2015-09-28 09:12:15
    产品需求文档(PRD)到底怎么写? 做产品经常会写PRD,但是如果没有一套完整的写作思路和框架,写出的PRD质量就不会太好,导致遗漏重要信息,在项目过程中被开发、前端、测试吐槽。趁这个周末有空,来梳理下一下写...
  • 第二:我在自学PRD文档的编写过程中,总是遇到PRD文档里的对应产品总是找不到或是下架的情况,很难找到比较全面以及详细的参考模板,故一气之下撸了一篇,写好分享之。 关于这篇文章: 1.PRD本来就没有固定的...
  • 第二:我在自学PRD文档的编写过程中,总是遇到PRD文档里的对应产品总是找不到或是下架的情况,很难找到比较全面以及详细的参考模板,故一气之下撸了一篇,写好分享之。 关于这篇文章: 1.PRD本来就没有固定的...
  • 当我们初次接触产品需求文档时,首先会从网络上寻找产品需求文档模板,希望从中了解和学习具体的写作要求,但实际上,现在网络上绝大部分的PRD文档都是与实际工作不相符的,或者说是复杂的。 前几天一位从事产品...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 465,814
精华内容 186,325
关键字:

数据产品需求文档