你可以这样写需求文档 第01期：正文前要

作者简介

Jarvan，前百丽、环球易购、顺丰产品经理，现某互联网公司内部系统负责人，从 0 到 1 搭建团队、系统，目前管理团队近 20 人，从事跨境电商、零售行业产品经理多年，拥有丰富的后台产品经验。

各位好，从今天开始，我们来聊一下产品经理的一些内容，因为笔者专注 B 端产品，所以基本上都是 B 端的产品内容。第一个我们来讨论下产品经理最基本的需求文档，应该如何去写，大家有什么好的见解欢迎留言。

言归正传！

我们说产品经理对外输出有三个内容，需求文档、原型图、流程图，其中需求文档承载了整个设计目标、过程及最终结果，所以是笔者认为产品经理最重要的输出点。

首先，我们需要明确几个问题：

一．需求文档的目的是什么？

产品经理作为一个产品的设计者，需要将自己的设计思路用最通俗易懂的文字来描述出来，形成一份文档，给到相关人员，什么叫通俗易懂，简而言之，我们随便从外面招进来一个开发或者测试，在不了解我们的系统业务逻辑的情况下，可以按照产品的需求文档来进行正常的代码开发和测试，这就是通俗易懂，同样也是笔者对于团队的要求。

二．需求文档的面向对象有哪些？

最直接的自然是我们的开发和测试，除此之外，这个文档还会作为整个系统的设计沉淀，为后续的新人提供最直接的参考资料，所以基于这个点，一定要细，事无巨细。

所以，笔者认为一份高质量的需求文档应该有以下几点：

一．背景、目的

笔者对于团队成员很强调的一个点，在所有的需求文档里，一定要描述清楚背景和目的，需要让开发和测试做事情之前清楚我们为什么这么做，这么做的价值是什么。

产品经理作为整个环节直接对外人员，他会有很清楚的业务熟知度，但是我们的开发和测试不会，很多时候需求上线了还不知道做了干嘛用的，很不利于整个项目进展，所以一定要提前同步好信息。

二．方案概述

对于一份内容极多的需求文档，功能复杂性不是三言两语讲得清楚，所以在需求文档评审时，一定要有一个概要，需要将你设计的基本方案同步给大家，同时，当你处理复杂的需求时，方案概述也是需要你跟需求方在需求开发之前确认的一个环节，确保动工前两边的信息是一致的。

三．要素定义

要素指的是一些专业的术语解释，对于很多业务性的专业词汇而言，很多人并不清楚它的实际含义，比如供应链里有一个词叫“库存水位”，我们如果来做一个“库存水位”的需求，连这个词都不知道干嘛的，像是这种就需要提前将术语解释放在前面，便于大家更好的理解，“库存水位”有兴趣的大家可以百度下看看。

四．权限要求

笔者习惯放在前面，有一些放后面也没什么，这个菜单需要哪些按钮做权限控制、哪些数据维度做权限控制、需要开给哪些角色，都需要描述清楚，一是便于开发和测试处理，二是需求上线后也便于产品开权限。

五．测试要求

这个是笔者对于团队最近要求的内容，很多对接 Amazon 或者其他平台的，如果有大批量的数据对接，或者其他类似内容，对于测试的难度会加大，资源上是个很难操控的点，所以需要产品在最初就明确好，对于这类需求，测试到哪些点就可以结束，不要花费太多的时间在这上面，“点到为止”。

今天先聊到这里，下一讲会来细聊“字段取值如何写”，重点！

写在最后：

笔者见过很多产品经理的“一句话需求”，也见过很多特别特别细的文档，两者对比真的差距明显。笔者一直认为“专业的人做专业的事”，既然你身为一个产品经理，对你的客户负责，对你的团队负责，需要将你该做的内容做好，当然了，如果团队比较成熟，开发和测试对内容也是知根知底，在不影响质量的情况下，为了节省时间，可以弱化一些需求文档的内容。

用最简单的设计、最明确的流程、最通俗的文字来实现用户最复杂的需求，这是笔者的坚守，也是笔者的追求，希望这篇文章可以给大家一些帮助，感恩。