PRD产品迭代需求文档,特别复杂的需求怎么写得清晰易懂?

文摘   2024-05-17 11:11   广东  

在最小可行性产品(MVP)上线后,产品很少再有大版本/颠覆性的更新,都是按天、按周、按月去快速迭代改进。

产品经理每个迭代都在重复从需求获取、调研、需求分析、竞品分析、需求实现方案设计、画原型、流程图、需求评审、需求跟进、验收、上线。
在需求评审前,产品经理工作主要产出就是产品迭代PRD文档,其它时间都是沟通、跟进。
可以看出PRD文档对产品经理的重要性。
我们有时候会听到让产品经理反感的话,研发会吐槽说这就是“一句话的需求、需求没写清楚、需求看不懂”,在某些情况下产品经理也很容易出现这样的问题,所以需求文档的规范就很重要。
规范的产品需求文档至少包含两个重点: 清晰的需求内容描述和规范标准的产品需求模板。
而且需求文档还容易出现下面2个问题:
1、如果需求文档很长,很容易导致研发看起来特费劲,易读性和阅读体验很差,看完后没太看懂,还要不断问问题。
2、很容易出现遗漏,不管是逻辑还是场景,常常评审后才发现,甚至是开发完测试验收发现的问题
一个需求文档可以影响整个团队的协作和沟通效率,作为一个有思想有责任心的产品经理,我们必须要求自己产出一个高质量的需求文档。
一个流程复杂功能点多页面元素多的需求描述要怎么写?
在我写过的需求文档中,B端的需求相对复杂,特别是单据类的,有业务流程、单据状态多、要审批、功能按钮操作也多、页面表单元素多、页面同时包含表单和列表。
复杂事情结构化、清晰化的关键点:
  • 修订记录
既然是需求迭代模式,那么版本的管理非常重要,必须要记录每一次需求变动改了哪些,什么时候改的,并需要关联每一次需求单。
这是用confluence+jia的需求迭代文档中版本的记录。
每一次需求的细节改动都要插入超链接锚点,点击直接跳到变动的位置,不然研发要在文档中找到这个需求变动点也不容易。
定位后的需求变动记录:
  • 需求范围

需求范围很重要,一个复杂的需求文档能否让用户看着清晰易读,就必须要把需求范围按目录结构的模式梳理出来,需求要细到每个功能按钮操作,让用户对需求有一个总览的感觉,如下图。
需求范围每个标题最好是可以配置锚点,方便多次阅读后快速定位。
  • 流程图

流程图的作用就是能快速描述清楚需求的整个业务逻辑,通过业务逻辑才能把涉及到的功能合理的串联起来。

  • 单据状态说明

单据状态如果超过3个,就要单独列一个标题说明清楚每个状态的意思,每个状态是如何变化的,包括正向和逆向,以及状态变化有什么其他条件等。
要清晰描述也可以额外附一个状态变化流程图,下图为采购计划状态说明:

  • 方案设计(原型和描述
这里是整个文档最复杂的地方,涉及到很多原型图和描述,各种交互跳转、页面和操作。
注意点:
1、每个功能页面、功能点都要用多级标题来写清楚,如果功能点太多了,要在这里把功能和功能点用目录模式单独再提出来一份,每个功能点都要插入锚点。
下图为跨境ERP的采购单功能点:
2、每张原型图下都要紧接着描述,可以把页面划分几个区域,比如列表页面可以分为:顶部导航、查询区、操作按钮、列表。
简单示例:
  • 数据埋点
一般C端产品较为关注,特别是互联网产品,要通过采集的埋点做数据分析,比如上线后的页面访问pv/uv、转化率、页面停留时长、页面元素的点击情况、页面数据的收集等。
PRD产品迭代需求文档结构
这个文档目录结构也是我自己用的最多的一个需求文档结构,再加上多方对比做过一些调优,也删除了很多鸡肋结构,是目前最新最好用的一个版本。
产品需求文档是公司的重要资产,人经常变动,知识和信息要通过文档沉淀下来,很多公司表面重视这一点,实际管理的非常差。
高质量的产品需求文档是团队高效沟通协同的桥梁,也是提高整体效率的重要通道。
只要产品经理不偷懒,再加上一个约定的模板,就可以提高PRD的文档质量,最后需求文档内审时严格一点,多指出细节问题和驳回修改,会让产品经理产出的文档质量更高、效率更高。

------ END ------

推荐阅读
做产品规划时要如何做竞品分析?
深度解析产品思维,产品经理最重要的思维
产品经理成长体系 I阶段
产品经理方法论 62讲
产品经理思维框架24讲
关注公众号
在公众号主页发消息:1
加好友,备注加群,进微信交流群,一起分享和成长!
发消息:3、4、5
免费下载PPT原型+Axure元件库》
免费下载整套产品文档》(竞品分析、产品规划...)
免费下载《产品经理成长计划表》源文件

    产品经理方法论
    让每个PM的学习和成长之路都是最高效的。
     最新文章