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

人人都是产品经理 • 5年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

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

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

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

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

需求文档的作用

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

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

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

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

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

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

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

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

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

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

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

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

1）逻辑流程图

2）原型图

3）开发注意事项

4）设计注意事项

5）产品解释

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

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

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

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

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

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

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