我真服了!竟然还有产品经理写不好PRD

0 评论 675 浏览 14 收藏 7 分钟

在产品开发过程中,产品需求文档(PRD)扮演着至关重要的角色。然而,即便是经验丰富的产品经理也可能在PRD的撰写逻辑上存在误区。本文旨在深入探讨PRD撰写的核心要点,提供系统化的方法论,以确保文档的逻辑性和全面性。

最近模拟面试了几个产品同学,发现一个问题,虽然有些人已经有几年经验,但是在问到写PRD的思路时,却答得不通顺,逻辑很乱。

也不是他们不会写PRD,而是写的思路是乱的、错的,没有成体系的方法。

这还让我挺惊讶的,产品经理这个岗位,都进入下行周期了,产品的基础技能,网上已经有非常多成熟的资料,他们竟然连最最基础又核心的PRD,都没有吃透,属实有点不应该。

现在大部分公司,要求产品经理既要有高度,又要能落地,上至产品规划,下产品需求,都要干,写好PRD,对于产品经理来说,非常重要。

写PRD最重要的是什么?

我发现很多产品经理写PRD,都是从模板开始。在网上找到一个觉得很完善的模板,然后就套着模板写,模板包含什么,就写什么。

还有一些是对着原型写,大部分写的是交互说明,其实只是PRD里面的一部分而已。

01 写PRD最重要的是什么?

是逻辑啊!

PRD是分层次的,需要从不同的维度去写。

新项目和迭代的项目,侧重点又有一些不一样。

02 新项目PRD怎么写?

从0到1的新项目,最重要的是梳理清楚业务流程、系统架构和功能结构。

业务流程是整个项目设计的起点,梳理不同角色完成业务目标的过程。

业务流程可以推导出系统架构。

系统架构是把满足业务的所有系统遍历出来,再按照一定结构进行组织的过程。

每个系统又包含不同的功能,把所有功能梳理出来,可以指导后续具体的产品设计。

对于一个新项目来说,PRD的结构大致是这样的:

1、项目背景。描述当前遇到的问题,或市场机会。要达到什么目标,以及大致的方案是什么样的

2、整体说明。业务流程、系统架构、功能结构、全局通用说明(名词解释,全局交互等)

3、功能需求。按照系统→功能模块→功能点的方式,进行拆分,一个功能点就是一个设计模块

4、非功能需求。包括安全性,并发,数据统计等

03 迭代项目的PRD怎么写?

迭代项目,要么是新增功能点,要么是对已有功能点的优化。

迭代的项目,最重要的是弄清楚单个功能点的需求是怎么写的。

写PRD,很大一部分时间都是在写具体的功能,所以写好单个功能的需求非常重要。

对于单个功能点来说,主要包括以下部分:

功能描述:这个功能满足哪些用户需求,解决用户什么问题。

业务流程:用户和系统是怎么交互的,主要流程是什么,分支流程是什么,异常流程是什么。

业务规则:系统在执行逻辑判断的时候,依据的规则是什么。

界面交互:注意,写PRD一定是前面的步骤梳理清楚以后,才是写界面交互,界面交互的细节非常多,也是经常容易遗漏写不全的模块。一个功能里通常包含多个页面,写界面交互的时候,第一个是要梳理清楚各个页面之间的跳转关系,第二是要梳理单个页面里的交互。一个页面,通常包含这些部分:

– 页面描述:进入页面的默认内容,进入下一个页面后再返回,页面怎么处理。不同状态下页面的区别,进入页面的权限等。

– 字段描述:输入型表单规则,有哪些输入型,录入方式是什么,是否必填,有哪些规则。输出型的展示规则:展示哪些字段,展示的逻辑是什么。

– 交互描述:点击后跳转到哪里,界面元素有哪些变化,有哪些控件,不通状态的展示,操作权限等。

– 异常情况:网络异常、接口异常、加载超时,该怎么处理

– 埋点/日志:哪些事件要做埋点,数据怎么存

交互写多了以后,你应该能够形成一份自己的交互走查清单,以确保需求完整,类似下图的自查清单:

迭代里优化功能的需求,大概是需求的某个模块进行调整,可能是业务流程,可能是业务规则,也可能是具体的交互。

这类需求主要是要说清楚,现在用户的使用场景是什么样的,为什么要改,修改前是怎样的,修改后是怎样的。

04 写在最后

以上,提供一个写PRD的思路,对于新项目来说,重点是说清楚项目背景和整体的设计,然后再以功能为单元进行具体的设计。

对于迭代类的PRD,重点是描述每个功能的所有元素,如果是修改的话,弄清楚用户的使用场景,为什么要改,改成什么样。

实际上,PRD的具体形式,不必过于看中,可以用axure+批注,也可以用word文档,重点是逻辑,重点是思路。

本文由人人都是产品经理作者【刀哥】,微信公众号:【刀哥说】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!