聊聊什么是敏捷又不被技术嫌弃的需求文档

先问几个问题，大家觉得写文档是一件必要的事吗？你喜欢写文档吗？？你写的文档程序猿和测试会看吗？？

假如你自己能独立设计和开发一个产品，你甚至根本就不需要写文档。文档的存在很大程度是因为团队协作需要进行信息传递。但负责传递信息的文档会存在几个问题，

1. 信息传递会有损失。

2. 存在写文档的成本。

3. 存在阅读理解成本。

而在一个变化万千的互联网行业里，大家应该知道有一种绝望叫做，当你还在写文档的时候，别人已经在收集用户反馈了。

关于信息传递在知乎我找到一个图表，大概表达的是“沟通成效和沟通渠道的关系”，

我们可以发现右上角面对面交流的效率是最高的，左下角用纸来交流效率最低。

当今的世界是敏捷开发的天下。传统开发过程中，人们通过交付文档来获得价值。但这样做的结果仅仅是撰写了产品的附加件而已，对于产品本身的交付没有太大的帮助。在经典的敏捷软件开发宣言中，

我们会发现很有名的一句话，

工作的软件高于详尽的文档， 你写再多的文档也不如用一个哪怕简陋却可运行的软件来阐述明白你的问题。

当然文档也有它存在的必要，比如说它的“记录”功能，若干个月后，项目换了负责人，他就可以通过这份文档了解项目的来龙去脉，从而更好的传承设计思路。文档也有益于解决纷争，当传递过程中信息流失太多，事后追究过错，看一看文档就能找到问题所在。

因此在互联网行业，无论是大企业还是创业公司，文档有其存在的必要，但这个文档应该是一份轻量且高质量的文档。那么一份敏捷有效的文档应该遵循怎样的原则呢？？

最最基本的有两条：

1. 敏捷性

2. 可读性

什么叫敏捷的文档，我的理解就是“ 精简易迭代 ”。

所谓精简，就是指你的文档只讲重点，什么标题目录复杂的专业术语统统都先抛掉，只写当前任务的核心要点。 有些需求文档会先讲行业和业务背景，还会有名词解释的类别，专门有一块来解释后文难懂的专业术语，

而对于一份敏捷的文档来说，这些细节应该在MRD或者BRD里说明，不应该在PRD里废话。如果程序猿需要了解业务背景知识，当面讲给他听。

所谓易迭代，就是这份文档要有一个易于迭代的形式。

一是编写人员不应该花费过多的时间去注意排版和规范，思考的重心在需求内容。

二是要有迭代记录的区域，需求变更频繁，变动的原因、时间、提出人、处理情况还是有必要记录下来的。

当然大家可以将这部分统一进PRD的文章开头，也可以另外用专门的软件或文档来管理。

关于“敏捷性”还有一个要点要提一提，就是编写文档的时机。我们要知道，不是先写文档，才做产品。合理的顺序应该是先有产品，需要的时候才写文档，当然这一点比较难把握，实际操作中大家需要综合考虑。

接着说可读性，我的理解也是两个要点：

1. 形式易读

2. 考虑阅读对象

关于形式易读，其实它会增加编写人员的写作成本，但还是有一些很基本的技巧和方法可以快速的达到目标。最起码，我们要用上设计四原则的前两个，亲密性和对齐，

再用简单的色块区分开文档的不同要点，就能很大的提高阅读人员的理解速度，同时不会增加太多的编写成本。

接着就到了本文浮夸标题的内容了T.T，也就是写一份考虑阅读对象尤其是程序猿的文档。写文档的人其实最怕写完文档却没人看，所有的努力仿佛都被浪费了，而产品需求文档最主要的阅读人员就是开发工程师和测试工程师。那究竟怎样的文档才是他们喜闻乐见的呢？？

我的想法是写一份符合程序猿思维模式和工作方法的文档。

比如说测试最常见的工作方式是什么，就是撰写测试用例。测试用例如果简化一点，我们可以用写“用户故事”（user story）的方法来写

用用户故事的方法来编写需求文档，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。  

这里我上网搜了一下资料，规划业务需求，可以采用“3W模板”，也就是：

- 谁（Who）

- 是什么（What）

- 为什么（Why）

上面的3W实际上就是描述了相关利益者是谁，他们想要什么，他们为什么有这种需求。下面举一例子进行说明：

- 谁（Who）： 用户

- 是什么（What）： 希望借助一个应用程序在不同服务器间传输文件

- 为什么（Why）： 为了存储项目数据

为了更加接近“用户故事”，我们可以改写为：

- 谁（Who）： 消费者/用户

- 是什么（What）： 想将归档过程数字化

- 为什么（Why）： 为了增强沟通，提高分享效率

敏捷项目中编写用户故事有一个常用模板：作为一名“用户类型”，我想要“需求”，以便于“原因”。

应用到这个例子，就是：作为一名用户，我想要将归档程序数字化，以便于增强沟通、提高分享效率。  

多数情况下，需求内容需要更加充实和详细，这一步要放到后面做，开始不要这样。

用户故事的方法有时会因过于简短、不断重复而受到批评。这里我们必须明白： 需求文档不是散文或诗歌，应该清晰、简明地描述用户需求； 需求文档的重点也在于此，不要管形式多变或内容是否重复这样的问题。

然后作为一个不太懂技术的产品，我了解到开发中最常用的一个软件设计框架叫做MVC框架，

它的运作规则我还在学习，但它给我编写需求文档提供了一个重要的指导意义，就是在开发的思维里，用户的输入行为、后端规则和前端交互是独立出来的，我们在撰写文档时是不是也可以按照这种思维方法来区分内容。对此我设计了一个需求文档的模板，欢迎大家提出参考意见啊，

这个文档还有很多缺陷，欢迎大家提出修改意见和我交流哦。

#专栏作家#

乌木，公众号：wumuwizard，人人都是产品经理专栏作家，简书@乌木。喜欢摇滚和吉他，喜欢骑自行车，喜欢用Sketch，自学编程中，对交互比较敢兴趣。希望做个全面又有梦想的产品人，梦想是做一款自己喜欢用户也喜欢的产品。

转载请保留上述作者信息并附带本文链接