适合90%团队的简易需求文档(PRD)模版

这是Kevin的第 803 篇原创,

持续日更,做产品经理的创业斜杠青年。

一个ideal到最小化产品的实现落地过程中,我们喜欢叫做MVP版本产品。这个最小化产品实现中,前期的投入和预算总是非常谨慎的。所以起初要么是创业团队,要么是一个大厂下的小项目组。

市面上的小团队比不上大厂的项目组,在产品经理、开发、运营、测试人员资源数量、和职位等级上都不如大厂。

在大厂里,存在小项目是团队成员“兼职”方式加入,比如本身处于在A业务线,但却临时去支援某个项目。

和创业一样,在大厂的小团队里也面临着生死攸关的问题,但获得的风险也低许多。比如项目迟迟没有达到预期指标,项目就会下架直接原地解散,但这创业的小团队来说,这样的损失成本可谓是最低的。

当然了,如果成功了,所获的收益也是比不上创业团队的。

因为这类风险,小团队里每个人工作就有点特别了,基本上会身兼数职。比如产品经理还上要能够搞定商务、市场,下要搞定产品功能需求调研、同时还要扮演测试角色助力产品上线。

小团队在技术架构的选型、和研发流程上都和成熟产品十分不同。比如在架构设计上是选择快速的单应用、微服务、还是选择成本高的分布式服务?

小团队宁可选择单应用实现业务,后期重构,也不会早期做复杂的架构设计和投入。

对于一个产品经理来说,市面上所传播的各种需求文档规范不尽其数,但在工作一定要要按某一个模版来吗?

实际上不是的,同样需求文档也不是越复杂越好。

比如对于一个产品经理,可能一份标准的需求文档是下面这样

登录注册的需求文档

上面这个模版,包含了该页面的测试用例、交互、前置条件、后置条件、字段规范,但实际上这类PRD文档完成时间需要非常长的。对于每一个需求都这样,那产品经理估计有加不完的班了。

但或者至少也有这样的

简单的需求描述

对于小团队,速度、和快速验证是第一使命。产品经理的需求文档是可以更加应该在这小团队里简化的。上面2种文档是极其笨拙的,所需要的范围、撰写成本都高。

软件类互联网产品,小团队往往就是一个产品经理、前端开发、后端开发、UI设计师构成,如果还要再继续精简,那就是一个产品经理、一个后端开发、一个前端开发即可。

团队虽小,但是要做的事情却一个不能差,我们可以罗列出每个人会牵涉到的工作职能。

成员分工

麻雀虽小,五脏齐全。

在团队成员每个人都在多线程的工作状态下,产品经理显然要选择最简易的需求文档撰写方式,既可以减少需求输出时间、还能够达到快速研发的目的。

这种方式有一个前置条件:需要有至少3年以上的工作经验产品经理才能胜任

理由很简单:越是简单的需求文档撰写,就越需要只关注重要的部分;而不是花时间在其他无用的需求上。

简易需求文档撰写模版

我建议小团队(10人以内的研发团队),需求文档用简易方法撰写,注意下面模版不是以文档的结构开始的,而是列举了文档的必要部分

1.前置条件说明

说明了当前操作是需要依靠前置条件的,比如在Pmtalk下的活动报名H5页面,需要用户的账户完成注册,在微信授权登录-手机号绑定-信息填写后才能选择支付。

前置条件是非常重要的,比如IOSapp是否能提供游客身份、以及用户体系分层都是前置条件最常见描述的。

2.字段类型长度

字段类型长度其实需求文档出现的频率最高的,因为每个页面都会有字段。人数、时间、价格、产品名称、文章标题等,都需要一个规范定义。

3.计算规则

计算规则并不是业务逻辑,比如在下面的阿拉丁小程序榜单里涉及到了应用榜单排名。背后就是对应的算法规则

小程序排名

小程序排名计算规则

当然这类计算规则越到后期肯定是希望系统来完成,人工的参与度降低。所以在后面也会有对应的AI算法、数据修正。但在早期产品经理必须说明清楚

4.文案说明

文案并不是等于内容运营,而是指的是对应产品的按钮、页面、其他样式下的文案。尤其是做微信生态下的产品类型,这类文案和转化率、访问量、传播数据直接相关。

比如微信小程序的分享

比如H5的分享提示文案

3.图片尺寸和大小

图片无论是由后台上传还是前端展示,都需要给出对应的尺寸说明,否则就会造成用户阅读变形,体验极差。

当然还有简单粗暴的方法交给系统进行对应固定尺寸的裁剪和处理。

同样对视频、其他类型的文件也要说在需求文档中给出对应的格式、尺寸、大小,方便在系统进行存储、同时提供给用户展示。

这类一般需要有经验的前端开发或UI设计师进行问题处理,否则产品经理自己拍脑袋给出的尺寸很容易不适用。

4.操作交互

交互说明要区分终端设备和产品形态2个纬度。

比如终端设备可以分为PC端、移动端、还有穿戴设备等领域

在产品形态上可以分为客户端、小程序、web、H5形式类型。

上面小程序的hover、loading加载交互,提升了用户体验。

交互说明既要建立在终端设备上、还要建立在产品形态上。

比如在PMTalk里,我们最常在需求文档描述的是按钮的点击、条件判断2类状态样式。

当然了,如果团队里有资深的前端、客户端开发工程师,这类交互的描述即使没有,也能够带来非常细腻的用户体验。

毕竟做的多了,自然就知道好的产品需要什么。

5.需求背景

需求背景是为了同步给对应上下游同事,告诉当前需求的作用。不能简单认为给任务他们就应该做,让团队得参与感、荣誉感也是十分重要的。所以搞清楚需求背景,让大家清楚现在的问题和优先级

为什么做,当前需求解决了什么问题,预计阶段规划

6.版本号&更新时间

更新时间也是需求文档极为重要的一环节,版本号还是同理,表明了当前文档的有效性。在文档中写明需求更新时间,同时如果是线下文档还要标明文档的版本里

7.业务逻辑图

业务逻辑图是为了讲述需求背后的业务逻辑,只有团队成员清楚了业务逻辑,才能着手进行开发。毕竟需求文档里的文档描述,是不能保证100%描述齐全,同时还存在阅读者可能没有仔细看完。有时候还因为文档的排版问题,开发或设计直接遗漏了某部分需求,导致功能缺失。

业务逻辑

业务逻辑既可以让系统开发中保证串起来。

同时团队成员还能明确知道当前需求的定位。业务逻辑图可以用时序图、泳道图、UML图等表示。但要想实现简单需求文档的实现,最快的方法还是用时序图。

8.词汇表

和文案不同,词汇表收集了通用的功能名称、字段命名。比如PMTalk在早期有签约作者、专栏作者,但实际上背后是一个逻辑。所以为了避免~混淆,就统一更改为专栏作者。

好,今天的分享就在这。我的微信是574319420,欢迎添加我的微信进行交流

推荐阅读更多精彩内容