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

15 评论 10741 浏览 55 收藏 8 分钟
🔗 B端产品需要更多地依赖销售团队和渠道合作来推广产品,而C端产品需要更多地利用网络营销和口碑传播来推广产品..

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

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

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

需求文档的作用

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. 好的,感谢指点

      来自广东 回复
专题
15516人已学习12篇文章
运费是电商的基础功能模块之一,承担着商品运费计算的作用。本专题的文章分享了如何设计运费规则。
专题
90488人已学习30篇文章
想要脱围而出,你必须升级你的技能和思维。
专题
13518人已学习13篇文章
本专题的文章分享了关于教育+AI的思考。
专题
11500人已学习12篇文章
任何理论都有它的局限性和前提条件,没有一种方法论是永远有效的。品牌方法论一直处在变化阶段,它随着时代发展的变化而变化。本专题的文章分享了品牌方法论。
专题
34751人已学习13篇文章
为了给用户提供更好的体验,你需要一套合理的推送策略。
专题
14097人已学习14篇文章
流量难获取,获取之后转化为付费用户更是困难。本专题的文章分享了如何提升付费转化率。