写了一年的需求文档,我想告诉你……

15 评论 10677 浏览 55 收藏 8 分钟

本文作者写了大概一年的需求文档,对需求文档也有了不同于一开始的认识,也积累了一些经验,在此分享给大家。

到目前为止,大概写了一年的需求文档。

整个过程从零开始,通过自己的探索(反复练习与参考资料),也算能产出一份比较满意的需求文档,接下来需求文档的作用说起。

需求文档的作用

1. 帮助产品经理梳理功能逻辑,构建产品的框架

很多人会认为需求文档是给开发同学与设计同学看的,目的是让他们更好地理解需求。但经过一年的实践,越发觉得产品同学才是需求文档最大的受益者。

写需求文档过程,也是构思产品的过程。需求文档中包含『产品结构图』与『逻辑流程图』,产品结构图展示的是产品的具体模块与功能,而逻辑流程图则说明了功能的具体步骤。将他们写清楚后,产品的骨架也搭建了起来。

另外,在画产品原型、补充产品逻辑的过程中,能够帮助产品同学理清产品的细节,确保产品在最初的设计上尽可能的完善与流畅,最大限度避免了后续出错的可能。

2. 辅助产品同学阐述产品需求

在进行需求评审的时候,需求文档是辅助产品同学阐述产品需求的重要支撑,类似于演讲的PPT。很多时候单靠口头描述,很难说清产品的具体细节与逻辑,如果结合着产品原型图,则会事半功倍。

十分建议将产品逻辑背后的『理由/产品解释』写到需求文档中,例如弹窗的『确定』与『取消』按钮,突出『确定』按钮的原因是想让用户完成期待的操作;添加『功能结果页』的原因是为了增加广告的展示频次等。

这样做有两个好处:一是能让产品同学在设计功能的过程中,不断的自我质疑,减少功能逻辑潜在的缺陷;二是能让别人更好理解需求本身,增加沟通的流畅性。

3. 减少沟通成本

需求文档对于设计与开发的同学来说,更像是一份参考文档或者需求词典。在他们困惑的时候,能够通过翻阅需求文档,解决疑惑点,从而省去了询问的过程。这就要求产品同学在编写需求文档的时候,要尽可能细致。

一份需求文档,除了原型图外,还应该写清楚『开发注意事项』与『设计注意事项』。开发注意事项包含页面间的跳转逻辑,每个组件的操作响应,操作之间的避让逻辑等;而设计的注意事项应该包含页面组件的表现优先级,组件的不同状态等。

另外,如果牵扯到广告变现,还要将广告的请求时机,展示时机说清楚。

在产品实现正式开始之前,产品同学一定要对开发同学与设计同学说清楚原型图中的每个要点,确保他们对于需求的理解和自己达成一致。这样在推进产品落地的过程中,才能充分发挥需求文档参考作用。

4. 产品存档

处于维护期的老产品,如果没有相关的文档,对于刚接手的人,简直是一个灾难。因为一款产品从发布到成熟,期间经历过各种坑,缺少对应的文档的解释,很多功能逻辑都无法理解,可能需要重新趟一次浑水,才能将老产品彻底的掌握。这个过程本身是痛苦的,成本也是巨大的。

但是,如果有比较完备的参考文档,接手过程就会顺利很多。另外,在遇到产品问题的时候,也能够通过翻阅备份文档,快速定位问题,极大提高了工作效率。

5. 需求文档构成元素介绍

1)逻辑流程图

  1. 将产品目标拆解实现步骤,将相关的步骤聚合为产品模块,每个模块之间低耦合,高聚类;
  2. 模块内使用流程图将具体的逻辑串联起来,每个模块内的逻辑流程基本上都可以从头到尾执行完毕,少有交错的情况;
  3. 如果有重复出现的逻辑流程,要使用子流程进行概括,并且在主流程中使用子流程进行替换;

2)原型图

  1. 画清楚页面的组件布局以及文案信息;
  2. 各个组件的展示优先级,通过组件的大小、颜色的深浅表现出来;
  3. 页面/组件的不同状态展示(选中状态);
  4. 页面之间的跳转逻辑(使用跳转);
  5. 每个组件的操作响应(使用简单的流程线);
  6. 广告的展示位置。

3)开发注意事项

  1. 控件的操作响应;
  2. 页面间的跳转逻辑;
  3. 状态更改的时机与条件;
  4. 广告的请求、展示逻辑。

4)设计注意事项

  1. 组件的优先级说明;
  2. 组件自身在各种场景下的变化。

5)产品解释

  1. 说清楚页面/组件要实现的产品目的

小结

虽然写出一份完整的需求文档,看起来要花很长的时间。但实际纯粹输出文档的时间并不多,大概一到两天的时间。真正耗费时间的是产品框架的搭建与逻辑的梳理,而这一块对于任何产品都是必不可少的。

需求文档如果做得比较完善,节省出的沟通成本是巨大的。在实践的过程中,一份完整的需求文档,加上充足的前期沟通,大致能节省后期70%的沟通成本。省下来的沟通成本所带来的是成倍的效率,因为沟通前后的精力转移成本是非常巨大的。

当然,需求文档的详略主要取决于团队成员对于项目的理解。

如果项目本身就很小,每个人对于项目都有着较深的理解,需求文档只需要简单的概述需求本身;对于比较大型的、复杂的产品,需求文档则越完善越好。

#专栏作家#

MING,个人公众号:MING的大航海,知乎专栏:产品见知录,人人都是产品经理专栏作家。一只专注于个人成长的产品汪,沉迷『方法论』,只分享值得收藏的『硬干货』!

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

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 原型和逻辑不应该交互设计做吗?

    回复
    1. 看公司,小公司基本上都是产品一人搞定,大公司的话会分工会比较清楚,但是无论如何,一个合格的(初级)产品经理都需要对原型有熟练的掌握(以上为个人观点)

      来自北京 回复
  2. 需求文档跟原型放在一起写感觉会好很多 对应功能旁边就是文档说明

    来自四川 回复
  3. 有一个示例模板吗

    来自广东 回复
    1. 才看到回复,请阅读我之后写的文章,也可以关注公众号『MING的大航海』

      来自北京 回复
  4. 开发不细看PRD,就喜欢问。这问题怎么解决?

    回复
    1. 需求文档写完之后,要带着『开发』与『设计』认真的过一遍,把里面的细节都讲清楚,如果开发的后续的过程中提问,如果是之前漏掉的细节,那你需要认真跟他说,并把漏掉的不全到需求文档中,如果他问的问题之前说过,那直接让他看文档(过程要注意沟通技巧)

      来自北京 回复
    2. 如果你觉得你的prd写的很完整 阅读性也比较高 ,那他下次问你你可以委婉的告诉他prd里面写了 请他看!

      回复
  5. 对的。文档还是要写,叫不叫“PRD”不重要,管用就好,有利于工作提升就好。别为了写文档而写文档就好。

    回复
    1. 握爪

      回复
  6. 感谢作者的分享,顺带问一下作者平时写需求文档是用word,axure还是用其它工具

    来自广东 回复
    1. 原型与说明用Axure,流程图用processon

      回复
    2. 好的,感谢指点

      来自广东 回复