好的需求文档,到底长啥样?

去年入职新公司后,研发团队人员均不在base地,且都是通过外协的形式进行项目开发(问就是初创团队的难),这对导致了产研团队沟通成本很高。另一方面,对于产品工作的最后一公里、产品经理的重要交付物——需求文档的要求也极其的高,因为异地协作沟通成本高的问题,一份好的需求文档可以有效降低重复沟通的时间,以便有更多的时间去摸鱼(bushi)。

那么,就让我来聊一聊需求文档(prd/产品需求规格书)的结构和一些需要注意的点。

一、好的需求文档,到底长啥样?

在说我的结论之前,我们先来看看市面上的文档管理工具所提供的需求文档的模板格式,下图分为飞书、语雀和云效:

好的需求文档,到底长啥样?

以这三家为例,我们来看看对应的需求文档的结构:

  • 飞书:版本信息、变更日志、文档说明(名词解释)、需求背景(产品/数据现状、用户调研、竞品分析)、需求范围、功能详细说明(产品流程图、交互原型图、功能说明)、非功能需求、埋点、项目规划、附录。
  • 语雀:变更记录、背景介绍(业务背景、业务场景)、产品概述(产品定位、服务对象、产品逻辑、信息架构、角色术语)、需求说明(需求列表、需求明细、非功能需求)、人员&排期。
  • 云效:基本信息(项目成员)、需求背景、产品目标、衡量指标、产品需求、功能及界面设计、问题、暂不支持、附录。

是不是很相似?

互联网随着这些年的发展,需求文档也慢慢的标准化,只需在对应的模板稍许改造就能得出符合自己团队的模板。在前司中,因在线文档管理工具使用的是语雀,其中不乏有同事直接使用语雀的需求文档模板。

而我的需求文档,随着工作这几年的迭代和与不同团队的适配,自认为还是比较好的模板(叉腰),让我们来看下文档结构,如下图:

好的需求文档,到底长啥样?

其中我认为版本记录、需求说明、名词解释、需求列表、详细需求说明和问题为需求文档的必要性内容,而暂不支持、性能需求、数据需求及其他均为选择性内容。

1. 版本记录

版本记录是需求文档非常重要的一部分,因为很多需求都是会产生变更的,特别是在一些比较大的需求上…这就导致了版本记录的必要性,这样在用户(研发/测试/自己…)阅读文档时就能大体上知道这个需求的迭代情况。

版本记录包含日期、版本号、修订人和修订描述,其中需格外注意的是修订描述。在修订描述中需求描述修订原因和具体内容,当然修订原因也可单独拆分出一个字段进行管理,原因需说明该版本的‘增删改’情况。具体内容则需说明修改的‘场景 结果’,例如后台管理端新增用户时剔除手机号的必填校验,则可将具体内容描述为用户在管理端「用户管理」中新增/修改用户时,提交时去除手机号的必填校验。

言简意赅的内容描述,可以降低理解成本。

2. 需求说明

需求说明包含需求来源、需求背景和需求目标。

需求来源主要记录需求的所属项目、需求提出人和主要的负责人(需求负责人/研发负责人/测试负责人…)。在一个公司中有多个项目在开发属于正常现象,因此需记录需求的所属项目;需求提出人则可以是老板、对应的业务同事或者是自己,若后续需求提出人出现离岗交接时,也可跟进对应的提出人;主要负责人则按照公司规模进行实际填写,我前司人员较多,还会涉及到系统支持、排版等相关人员。

需求背景主要描述需求产生的背景,即为什么要做这个需求。需求背景的书写切不可流于形式,深入的理解需求背景可以更好的理解当前公司的战略方向,因为每一个需求都是公司战略执行层的具体表现。

需求目标则是描述需求实现的目标,即要做什么。需求目标可大可小,小至功能目标,大至业务目标,需把握好需求目标的尺度。

3. 名词解释

名词解释主要解释该需求的专业名词,让用户更好的理解需求。例如在票据行业中的背书、贴现、前手等专有名词,是有必要在对应的需求中进行阐述说明的。

4. 需求列表

需求列表(feature list)记录了需求的具体需求,即怎么做。对于历史项目/需求的更新,需求列表则尤为重要,在需求列表中描述本次需求的变更点,可以让研发/测试更好理解本次的需求内容,起到了‘总’的概览作用。

5. 详细需求说明

详细需求说明需包含UML图、原型图和详细逻辑说明。UML图在正常的需求中起码要包含活动图/时序图 状态机图(UML这么画请看这篇文章),一个逻辑清晰的图可以胜过千言万语;原型图和详细逻辑说明相辅相成,构成了需求文档篇幅最大的部分,是对「怎么做」的更加详细的描述,详细到页面如何跳转、按钮的交互逻辑、字段的展示逻辑等。

6. 问题

问题主要记录需求评审过程中参会人员提出了相关问题,其中若未能当场给出解答的部分,则需对问题和结论进行记录。

7. 暂不支持

暂不支持记录当前需求无法实现的部分。正常情况下,需求评审之前应对需求的可实现方案进行初步沟通,即和研发通通气,这样可以避免评审过程针对不可实现的打断问题。

8. 性能需求

性能需求包含并发量、响应速度等一系列系统性能相关的需求。性能需求相关的内容偏向于技术层面,我在当前基本不写(写了也没啥用)。

9. 数据需求

数据需求包含数据量、存储时间等,这与单独的报表需求不同,因此我也不写。

二、一些tips

说完我当前的需求文档构成之后,我再来补充几点我认为比较重要的tips。

1. 善用目录导航

对于动辄几千字的需求文档,要善用目录导航,这样在阅读时可快速定位需求内容,结构性会更强。

关于管理端来说,我一般目录导航中会根据页面的从上到下的逻辑进行描述,例如按照查询条件、列表和操作进行说明。

2. 文档拆分

如果是一个大需求,涉及到系统的多个模块的变更改造,最好对文档进行拆分,再利用文件夹对其规整,这样在团队人员阅读起来会降低一定门槛,对于后续的任务分配的工作也有一定帮助。

3. 需求颗粒度

需求的颗粒度是一个很难把控的事情。

比如,是否要涉及到表的相关字段。这个非常考验产品经理对于表的理解和系统的熟悉程度,因为很多情况下用户端的字段和数据库的字段并不是一一对应的。于我而言,若是比较陌生的系统,则是按照‘取值路径 截图’的形式进行描述,这样能有效避免二义性。

另外,B端产品很多情况下会涉及到与外部对接,那么对方系统和本司系统避免不了要交互,那么在这种情况下,尽量保证详细到对接文档中的每个字段,这样能最大程度降低沟通成本。

4. 举个例子

很多时候,研发和测试对于需求的描述会感到非常晦涩难懂,这样「举个例子」就不可避免。我一般是会在比较难懂的部分后面增加一个实际例子,就比如:

1 1 = 2

通过一个具体的例子来对需求点进行阐释,可以有效增强需求的可读性。

5. 需求重点的标注

需求文档作为产品经理的输出物,产品经理对于需求可谓是了然于胸,那么在文档中就可以着重标注出需求的重点(例如用红色字体进行突出),以此突出某个重要需求点,要求研发和测试着重关注。

三、总结

需求文档对于我来说主要作用还是传达和记录,让团队成员对于需求达成相同的认知,以及让后人对某个需求有迹可循,不至于系统‘口口相传’。因此,需求文档并不是所谓产品经理一言堂的一个文档,而是团队对需求的共同认知,所以适合团队的就是一份好的需求文档。

如果需要我对好的文档下一份定义,那就是——问题的答案都在文档中。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部