从几个细节问题出发，如何写好产品需求文档？

这篇文章暂时不讨论什么是需求文档，也不强调需求文档的重要性等等，就简单地从各种细节问题出发如何写好一份需求文档。

一份好的需求文档的标准是什么？不同项目不同规模的团队有不一样的评判标准，个人觉得能清晰准确把握需求各项要素，写完之后各相关部门同事能清楚明白，那就是一份好的需求文档了。想要做到清晰和准确却不是一件简单的事，作为缺乏经验的产品新人，我觉得可以从一些细节问题上开始做好。

有人会觉得需求文档根本不需要那么严谨细腻，这样会浪费很多时间。写产品需求文档本就是一个锻炼自己逻辑思维和推敲求证的过程，严谨细腻的态度可以让我们更全面的考虑问题，从而写出一份好的需求文档，减少团队成员的理解障碍。现在就把我平时写需求文档遇到的一些细节问题拿出来给大家分享一下，希望大家都能避免这些不必要的错误。

排版规范

我们会写各种文档，如图能做到每一份文档都有统一的排版，将更方便各部门同事阅读。格式的标准包括文档页眉、各类型文字的字体型号、大小、颜色；表格规范；流程图统一规范等等。

文档的命名

如果能做到高度概括，精准定义，可以帮助团队成员快速准确把握文档的内容，避免跑偏。需求文档的命名可以从文档的意义，作用，性质方面考虑。

名词的定义

第一次出现在文档中的特殊名词一定要精准描述，不可有缺失。产品肯定明白自己写的内容是什么，但并不代表团队里面的人都能理解。每个人对事物的理解都不一样，如果不做好名词的定义解释，很容易产生歧义，从而产生分歧。用普通的电商网站举个例子，如果在需求文档只是简单描述说“后台实现XX功能”，那就麻烦大了。这个“后台”可以指的是买家个人中心、卖家后台系统甚至整个网站的后台管理系统等等，如果不正确命名并解释清楚，开发看起来会很痛苦。

尽量不用大段大段文字描述需求，不是每个开发都有耐心开得下去。

尽量用表格或者流程图进行描述，比如说要说清楚不同角色间不同的功能权限，用表格列出来可以清楚明白地表达和比照；另外一种就是流程图了，正所谓一图胜千言。建议大家都可以学习和使用UML的一些相关知识，比如用例图、类图、序列图、活动图、状态图等，它们可以清楚详细的描绘出任何一种事物和各种逻辑关系。从开发的角度看，他们是很喜欢这种表达方式的，如果你能正确熟练的使用的话。

牵扯到专业术语要弄清楚再写

比如说某些登录输入框需要用到正则表达式，如果自己没弄懂什么是正则表达式，最好别写在需求文档上。需求文档不是开发文档，我们不一定要用开发的语言去描述，只要把功能逻辑讲清楚即可。

不要留空白

很多时候我们在写文档的过程总会有些内容未确定，但是请养成好习惯，不要留空白的地方，未确定的地方写“待定”或者“TBD”，并交代清楚和谁待定，这将有利于你接下来的工作对接。

善于举例

写需求文档的目的就是跟团队相关成员讲清楚需求，在描述需求的时候多举例子可以帮助阅读人员更好的了解需求。我们可以像讲故事一样去描述需求，但是千万别跑偏了。

图文一致

需求文档我们会用到交互原型图，原型的截图和文字说明必须保持一致，而且截图必须与实现情况相符。

写这篇文章的主要目的是想引起大家对文档细节的重视，从细节中发现问题，并找到相应技巧和方法去把需求文档写好。上面只是列出了几条细节问题，如果大家在写文档过程中发现更多细节问题和文档技巧欢迎交流学习。

 

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