3个方法,写对用户画像产品需求文档(PRD)

栏目: 编程工具 · 发布时间: 6年前

内容简介:非技术型产品经理福音来了,和程序员不再撕逼,10天在线学习,补齐产品经理必备技术知识。

非技术型产品经理福音来了,和 程序员 不再撕逼,10天在线学习,补齐产品经理必备技术知识。 了解一下

释放双眼,带上耳机,听听看~!

00:00

00:00

需求是科技网络产品开发的基础,对需求的描述载体是需求文档。文档质量决定了产品的质量和生存周期,因此任何公司都会想办法提升产品需求文档质量。那么要如何做呢,让我们看看笔者是如何说的:

3个方法,写对用户画像产品需求文档(PRD)

高质量的需求文档具有如下两个特征:

  1. 完整、正确性:每一项需求的功能都描述清楚、准确、无冲突,使后续开发、测试人员获得所有必要信息;
  2. 可行性:每一项需求都必须能在已知能力和约束条件内实现,对于技术上无法实现,或者成本。

上无法负担的需求,则不可行。例如:此前有报道某公司产品经理提出根据手机壳换APP颜色的需求,那么在当时那个场景下产品的需求可行性为较低。

本文先从一个落地用户学生画像的产品需求文档(PRD)展开,接着分析需求文档的产生过程,然后讲述需求文档产生过程中容易产生的问题,最后提出提升需求文档质量的措施。本篇顺道提一下AI产品需求文档注意要点,本篇AI及数据产品需求文档不是重点,希望看AI产品相关的请继续关注LineLian的文章。

一、已落地的学生用户画像的产品需求文档(PRD)

内容较长建议耐心阅读,因为往往有的产品的需求比较硬核,所以产品需求文档的内容也比较长。为了练习产品经理的基本功,需要有足够的耐心,加上笔者LineLian总结的方法方向将需求用PRD逻辑清晰地表达出来。

下面为用户学生画像产品需求文档案例:

1. 对PRD编号

3个方法,写对用户画像产品需求文档(PRD)

2. 程式化的版本修订记录

3个方法,写对用户画像产品需求文档(PRD)

3. 生成目录

3个方法,写对用户画像产品需求文档(PRD)

4. 对项目进行背景综述

(1)背景

用户学生画像v4.0迭代项目主要是对已有画像平台功能结构重新梳理和整合。项目基于用户学生画像v3.2、江南大学用户学生画像项目以及参考浙大用户学生画像相关要求,以通用性为原则,将原有功能梳理重新定义,对用户学生画像、群体对比、个人画像结构都有所调整,同时增加自定报告功能模块。后续的项目都会基于这个版本进行开发。

(2)目标

明确用户学生画像结构,使得产品结构清晰,将原有画像系统分为数据结果呈现和数据应用两大块:

  1. 数据结果呈现:对应群体画像、自定义画像、群体对比以及个人画像重点在已有数据结果呈现;
  2. 数据应用:对应预测预警和自助报告,前者是根据已有数据对行为预测,后者是根据已有数据形成总结报告。

统一原有用户学生画像系统,减少后续项目个性化定制。

(3)阅读对象

本文档阅读对象为项目经理、UI设计师、开发工程师、测试工程师

5. 对产品进行描述

用户学生画像产品是XX科技画像系列产品重要组成部分,是一款服务于高校学生管理与教育引导的大数据产品。围绕学生在校期间的安全、学业、生活、就业等方面的具体问题,通过刻画学生全维度画像,帮助管理者全面认识学生,精准定位异常人群,以大数据+画像技术服务于大学生精细化管理。

6. 产品思维脑图:逻辑清晰地表达概要功能结构

这个模块往往对上级汇报产品内容时用处多。

产品功能结构,如下所示:

3个方法,写对用户画像产品需求文档(PRD)

7. 帮前期的产品Feature lists生成产品功能列表

产品功能表,如下所示:

3个方法,写对用户画像产品需求文档(PRD)

8. 定义产品用户的角色

用户角色:这里“角色”的概念不是根据这些角色查看数据范围或功能权限一致分类的,因为学院、辅导员所对应学生数据范围是不一样的;这里根据学校数据,如果有对应信息课进行对应分组

示例:

3个方法,写对用户画像产品需求文档(PRD)

9. 产品功能需求说明正正文部分

  • 找到合适的产品需求文档框架模板,根据适应原则做裁剪处理;保证文档整体结构的完整性;
  • 逻辑一致和完备;任何功能都要能够清晰地描述思维逻辑过程和采用的方法,同时要注意临界值和异常值的处理;可以使用正向逻辑检查或使用反向测试逻辑走查;
  • 描述内容在正确的前提下尽量简洁明了,能用界面截图或图例的不用文字,重点内容鲜明标注;补充解释或者举例。

文档分类:文档的目标用户不同,用途不同,文档的内容和风格差异就会比较大。从0-1的产品需求文档和迭代升级的产品需求文档侧重点和关注的内容不同,目标用户有差异的文档内容不同;不同身份撰写者提交的文档重点不同。

功能需求说明,这部分主要的查看对象是Coding和test及产品经理自己验证产品时所用。由于原PRD过长,笔者LineLian仅截取一部分,如果实在有需要可以跟笔者LineLian联系或者联系起点。但是从笔者所列的部分仔细阅读的同学,一定能够看出一份用户画像和数据型产品需求文档需要讲清楚模块优先级、功能名称、用户对象,特别是需求描述需要讲清楚功能的交互逻辑、业务对应的需求规则、操作的流程、字段、图表说明、算法模型建议和保密需求等等。

具体如下所示:

基础模块:

3个方法,写对用户画像产品需求文档(PRD)

3个方法,写对用户画像产品需求文档(PRD)

3个方法,写对用户画像产品需求文档(PRD)

群体画像:

3个方法,写对用户画像产品需求文档(PRD)

3个方法,写对用户画像产品需求文档(PRD)

二、分析需求文档的产生过程

产品开发一般需要经历五个阶段:

需求分析阶段、设计阶段、编码阶段、测试阶段、验收交付阶段,后续还有运营维护阶段。而需求分析阶段产生的需求文档,是后续几个阶段的依据和必备条件。

上述需求文档是为第4版迭代重新进行需求分析的文档。

需求文档是需求分析阶段的工作产品,是需求开发和分析的结果,是用户和开发人员之间交流的桥梁,也是设计和编码的基础,又是测试和验收的依据。需求文档需精确地阐述一个软件必须提供的功能、性能、设计和实现的限制条件,并尽可能完整地描述软件预期的外部行为和用户可视化行为,还需包括设计、构造、测试或工程管理的细节。

一般需经历如下几个过程:

1. 产品需求开发过程

需求开发的主要目的是全面发掘用户的需求,尽量避免后期的需求变动,一般采用现场调研、调查问卷、样机、样例等方式,此时的需求都是从用户的角度提出,尽量保证全面,不要求详细、具体。

例如:上文PRD中,我们当时采用到学校现场调研了解每一个角色对当下系统的使用情况,倾听客户和用户的需求。然后确定软件开发任务书。

2. 产品需求分析过程

产品需求分析就是解答产品做什么的问题。本过程是需求文档形成的主要过程,是在前述任务书确定了开发任务的基础上,对用户的需求进行去粗取精、去伪存真、正确理解,然后把它用软件工程开发语言(形式功能规约,即需求规格说明书)表达出来的过程。这个过程中需要明确每个功能的具体要求,例如:如何操作、如何展示结果、界面的样式、要求、通信协议、接口、处理的数据、功能间的交互关系等等。

例如:上述PRD中充分挖掘学校对学生心理健康数据尤为关注,那么产品需求分析就要结合心理学和实际学生心理数据相结合来设计产品。最后一般是以软件需求规格说明书的形式呈现全部分析结果。

3. 需求评审过程

主要是从用户的角度和产品设计的角度,由用户、软件设计人员共同对需求规格说明和初步的用户手册进行评审,以确保产品需求的完整、准确、清晰、具体,并使用户和产品设计人员对需求规格说明和初步的用户手册的理解达成一致。

因此,任务书和需求规格说明形成后,均需进行需求评审,评审文档中的每一条需求是否符合用户要求、是否有遗漏、是否模糊、前后是否一致、是否无歧义等,使开发方和用户方的理解达成一致,并固定用户需求。

例如:笔者LineLian在日常产品相关工作中,会安排一些时间,来帮年轻的产品经理过需求和评审需求文档的质量。

三、需求文档产生过程中容易产生的问题

上述需求文档产生的三个过程,理论上可以保证需求文档的质量,实际实施时会有较多的原因导致控制失效,甚至会导致需求与用户的要求不一致,造成这种情况的主要原因有:

1. 市场环境变化导致场景变化

例如:针对学校学生为主的用户开发大数据人工智能软件,某一天市场突然要求校园不能以软件开发为目标让学生使用校外面的产品,那么这个政策下来后,许多原来的需求就不得不停止甚至终止。

2. 需求不是来自直接用户

例如:上述文档中征集需求时只收集了订购方校方的意见,未能面对真正的使用用户学生,导致订购方的需求不能代表最终用户的需求等。

3. 产品需求分析人员技能不足

这一点也是考察产品经理是否为高阶段资深产品经理与否的一个客观标准,分析需求时未能真正了解到用户的具体要求。

例如:用户要求数据保密功能,需求人员对保密缺乏相关知识,使得只设计了密码登陆的功能,未能提出更多的需求分析问题,以征集到用户的不同角色权限不同、数据保密、密码长度、强度等要求全面的保密需求。

四、提升需求文档的措施

1. 需求开发过程是否合理

  • 是否制定了需求开发计划,计划的合理性经过评审;
  • 需求开发的执行人是否有相应的技能;
  • 选择的调查对象是否能代表最终用户的意见;
  • 是否采用了规定的方法、流程、模板、表格等;
  • 是否未经调查直接编制需求文档。

2. 需求分析过程是否合理

  • 是否制定了需求分析计划,计划的合理性经过评审;
  • 需求分析人员是否具备相应技能;
  • 是否采用了规定的或者合适的需求分析方法;
  • 是否采用了规定的模板、表格;
  • 是否针对软件的行业特性制定了相应的分析措施。

五、总结一下用户画像类PRD的写法

PRD产品需求文档主要有MRD、竞对分析、原型、开发任务书、软件规格说明书等形式,均包含在PRD(产品需求文档内)。

一款产品不是所有的文档均需要撰写,例如文中所述的学生用户画像产品主要撰写产品功能的具体定义。所以,我们撰写产品需求文档不一定把上述文档撰写一遍,在强调敏捷开发的环境下,可以用原型配合产品经理的口头表达也是常见的开发方法。

随着人工智能产品需求的增多,产品经理还会面临新的需求。例如:配合算法工程师设计模型调教算法,这一点需要产品经理持续地学习。

这里先顺道提一下AI产品需求文档的几个要点,日后笔者将会写AI产品需求文档:

  • 目标用户包含算法工程师的文档:需要清晰地交代需求背景、现有的数据支持情况、预期的结果及功能设计采用的AI技术和设计的逻辑;
  • 采用第三方的AI技术支持的产品:需要完整地描述产品的整体实现过程、期间调用第三方技术的方式、第三方技术的支持范围和实现逻辑,以协助自己团队技术人员顺利对接,确保设计的功能能够实现;并明确边界和异常情况的处理方式;
  • AI产品都离不开底层数据的支持,对数据的采集、计算和处理需要特别注意;
  • AI产品的界面及交互与互联网产品有明显的差异:界面少,算法更强;交互方式科技感更强,更简洁。

以上是为正确撰写用户画像产品需求文档的内容。

#专栏作家#

连诗路,公众号:LineLian。人人都是产品经理专栏作家,《产品进化论:AI+时代产品经理的思维方法》一书作者,前阿里产品专家,希望与创业者多多交流。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

3个方法,写对用户画像产品需求文档(PRD)


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Web Analytics 2.0

Web Analytics 2.0

Avinash Kaushik / Sybex / 2009-10-26 / USD 39.99

The bestselling book Web Analytics: An Hour A Day was the first book in the analytics space to move beyond clickstream analysis. Web Analytics 2.0 will significantly evolve the approaches from the fir......一起来看看 《Web Analytics 2.0》 这本书的介绍吧!

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器

HEX CMYK 转换工具
HEX CMYK 转换工具

HEX CMYK 互转工具

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具