如何写一份优秀的需求文档

2 评论 2932 浏览 62 收藏 10 分钟

产品经理的核心技能之一就是撰写需求文档,问题来了,产品经理怎么写,才能写出一份优秀的需求文档呢?本文作者便分享了自己日常写需求文档的结构,不妨一起来看看。

为什么写这个主题

在我初为产品的时候,也参考过不少需求文档。有的需要将原型转成图片贴在需求文档里,我认为这比较低效,不适合我;有的需要在axure里写所有的逻辑,包括业务流程图、数据流程图等,axure里对于流程图和文字排版并不友好,我参考过一段时间,后来还是觉得太低效,不能专注于文档的输出。最终选择的方式是在依赖语雀去写文档,非常高效。

有的公司里会用钉钉,用钉钉文档其实也可以,但是我感觉体验没那么好,不管是操作还是界面都没有那么舒服。

需求文档作为产品的其中一项核心技能,那么如何能够结构化地写出高水平的需求文档呢?

写了将近5年,我在不断地完善我的需求文档模板,让我不再为怎么写需求文档而烦恼,提升了我的工作效率。

下面分享我日常工作写需求文档的结构,希望能对你有帮助。

核心逻辑是什么

我认为一份需求文档有2个重点,一是核心逻辑,一是原型。

核心逻辑是你要在短暂的需求评审会议上深刻地讲出来的,并且会上的小伙伴听了之后能够清晰知道整个需求的逻辑。

而且我认为需求评审会议一定是先讲核心的逻辑再讲原型。逻辑一定是先行的。直接讲原型,听的小伙伴估计10个9个都会懵逼。我也听过不少同事是直接讲原型的,效果很差,作为一位产品我也听不懂会议。另外,人的精神总是会分散的,我们需要在会议的最前面把最重要的逻辑讲清楚了,原型其实也是围绕核心逻辑展开,能够把握核心,看原型也更好理解了。

原型也是不可或缺的重要一部分。

它是核心逻辑的具象,非常多细节,我们要在原型里尽可能描述清晰需求,不遗漏需求,考虑缜密。这不仅是我们逻辑能力的体现,更能够减少开发过程中的卡点——因考虑不周全而开发不顺畅或者延期等。总的来说,这个意义重大。

如果仅凭大脑在每次写文档时,费尽心思去枚举需要考虑的点,这会很费劲,工作效率低,在文末也总结了写原型文档的技巧希望能够对你有所帮助。

我们先来看看整个需求文档的结构。

从下面开始进入主题。

一、需求背景

在这个位置写我们的需求背景,也就是这个需求产生的业务背景。注意把关键的业务矛盾描述出来。如果需求有很多点,建议把较大的需求点的矛盾点都描述出来。这样的话,技术看起来会很清晰需求为何而做。对技术讲多点业务,这对做需求是作用很大的,技术越是理解,对需求的理解偏差越小。

二、需求分析

1. 现业务流程

描述现在的的业务流程,便于自己梳理需求以及技术后面看也会比较好理解需求。

2. 竞品调研

如果是做一个新产品,往往需要做竞品调研。将你的调研结果放上来,整个方案的说服力增加不少。

3. 总结

通过对现业务流程的分析以及竞品调研,你可以得到一个直指本质的结论——业务到底要什么。这个本质你其实也可以找业务确认一下,这样做之后基本你不会遇到做错需求的情况。

注意:

  1. 现业务流程和竞品调研都不是必须的,但至少得有一个比较好。
  2. 我还看到过不少人需求分析会写需要考虑什么内容,例如:需要考虑中台是否支持这个操作、需要考虑某业务方是否能接受操作多了一个步骤。其实这些都是方案里面需要考虑的点,我认为并不能算在需求分析里面。需求分析更多是求得需求本质。

三、方案概要

在这里写上你的方案概要,这个概要是基于你的可行方案写出来的。在这个时候其实你已经跟业务沟通过了,得到了沟通共识得到的结论。别人看到这个位置的时候已经能够很清晰地看到你想要怎么做,接下来在听你讲的时候脑子里就会带着方案概要听下去。而你也可以很自然地展开下面的方案内容。

四、方案内容

1. 核心逻辑

总的来说,在核心逻辑这个模块,更多是图文结合地将你的核心逻辑表达出来。我常用的图有以下类型的图。

1)业务流程图

有新的业务流程图时可以放在此模块。这个部分不是必须的,按需写。

2)数据流程图

相关数据流程图可以放在这里。当你做多了需求,你不从数据角度去分析一下流程,其实你会觉得有点太表面了,可能会有疏漏。当你把数据流程也梳理清晰了,那么会很踏实。这个部分不是必须的,按需写。

3)功能流程图

主要针对比较细致复杂的功能,通过梳理功能流程图,减少疏漏,也有助于技术理解流程。与业务流程图的区别是,业务流程图主要针对业务方的工作的流转,功能流程图主要是针对功能的逻辑,例如:登录的功能流程图。

4)架构图

在做比较大的系统时需要将产品架构写清楚,有助于你和技术理解系统。这个部分不是必须的,按需写。可能还有其他的图,大家按需添加。

2. 原型

在此附上原型链接。

3. 非功能需求

  • 查询性能要求;
  • 并发要求;
  • 风控要求;
  • 接口开放要求;
  • 稳定要求;
  • 时效要求;
  • 等等。

4. 规划

如果有清晰的规划可以写在这里。可能有助于技术在设计数据库表的时候提前考虑未来的规划。

5. 需求变更记录

将需求的变更记录写在这里。

6. 其他

其他的什么都可以写在这里。例如,评审会议的目标可以写在这里,需求的最后期限可以写在这里,等等。

到这里需求文档就已经结束了。还有不少同学不知道怎么写原型的文档,下面开始讲解此部分。

五、原型撰写方法

1. 核心逻辑

我们通过分析与总结,其实页面主要就是这几部分组成:查询条件、字段、操作、权限。这是我们整个团队的逻辑思考成果,有很大的价值。在看toB老人家(王戴明老师)的书籍《saas产品经理从菜鸟到专家》时,我也看到他讲述原型是怎么写的,基本和我上一个团队想的是一样的。

所以大家真的要相信自己,大家想出来的东西其实是差不多的,那么差别在哪里?我认为是执行,也有执行速度,迭代速度。其实大家脑袋是差不多的,就是你想了之后有没有执行,有没有快速迭代下去。

2. 原型文档逻辑

3. 原型文档案例

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

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

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. Bruce 写的很精准,拳拳到肉。

    来自广东 回复
    1. 感谢,看来Andy也踩不少坑🤭

      来自广东 回复