这次写这个其实也算是有感而发，起因是一个产品朋友小李向我吐槽，他在一个创业团队，公司正在从探索期向成长期度过。原来的测试工作都是小李和研发相互协同的，也就是他们各自客串下测试。后面公司慢慢向成长期过度，员工从10个演变成了50多号人，其他城市也有分公司，加起来快100号人，研发人员也就从2人变成了近10人。因为业务发展迅速，要全力负责业务线上的事情，就招了个测试。之后便是他们找我吐槽的原因。

小李给我说，测试来的第一周，给了他第一个任务，就是熟悉业务，了解公司当前的运营模式，以及基本功能。随后便带着他去见了每一个部门相关对接人，甚至带到兄弟部门去认识下部门的领导。希望后面有问题可以直接有效的沟通，不然后面公司在扩展下，这种机会就很少了。随后也带到了研发那里，一一介绍，给研发表示，这是新来的测试，以后大家就是工作上的一家人我，画外音就是让研发不要刁难测试。

就这样过了2周，小李觉得半个月时间基本的业务和一些功能应该熟悉了，那么就开始对相关功能就行上手测试吧。这个时候小李他们的公司也在疯狂的扩展，并且还是获得了融资，这使得小李的工作更忙了。但是小李还是和她约好时间，进行相关功能的对接。对接的时候，小李拿着草图给测试，进行了相关的讲解。想让他根据草图和上面的文字先进行简单的测试。但是测试老说，没有文档测试不了。

小李说当时他很困惑，虽然当初很多功能都是ide，直接在会议室假设出来，但是之后去探索验证之后，很多都完善到草图上了。他就直接给他说那些草图就是就可以直接完成测试。后面测试就直接怼了小李，说你这是草图，根本就不是需求文档。小李就直接说，原来公司处于探索业务，变换的很快，都是根据草图来进行研发的，这个草图上都有，为什么不能作为测试依据？

那时，两人争得不可开交，争到最后，测试就说她来自己写一份，说小李根本不是产品。小李说到这里我也是吃惊了，毕竟都说出这样的话了。连忙问小李草图上有哪些东西，小李表示上面很多是手绘的原型和注释，以及后续方向，并且上面也简单的写了公司的业务方向以及后期如何做这些内容。还因为怕看不懂，专门还整理了，整理之后还给研发他们看，他们都说没问题，他也不知道问题出在哪里。

后面我也想了想这个问题，真的是没有需求文档而引起的吗？写个需求文档他的标准是什么？

需求文档的作用

工作中，对于产品写需求文档还有个很常见的事情就是，我们花了大量的时间，将产品所有细节都推敲的完毕，都仔仔细细的写在了需求文档上面，甚至写完后还反复和研发、业务部门核对了，确保没有问题之后，交付给了相关干系人。结果他们因为工作安排，时间紧凑要么就没看，要么就简单的看了几眼就放在了一边。这个无疑是打击我们。

但是这个好处是十分的明显：

1、后期研发中出现了什么问题，这个锅产品肯定不背。为什么？研发自己不看文档，文档里面写的清清楚楚，这个地方要这样处理，是你们自己不根据文档来研发。

2、如果出现了人员的离职或者是新增，那他可以通过需求文档快速的了解项目。减少他的熟悉时间。

换个角度，不写需求文档。那就是我们可以从作出决定，快速的推进至研发阶段。等于开完会就直接开工，而不需要将所有细节都写的清清楚楚。有种说法，人无完人，事无巨细。但是这个对研发团队要求很高，首先团队必须具备作出决定的能力，其次大家要有相同的行为准则和职业素养，这个就体现在相关代码规范、设计规范、原型规范上。因为如果配合出现了失误，包括功能和功能之间的不协调，ui配色和尺寸的不统一。那么就直接凉了。

写需求文档的作用是什么

需求文档的作用主要就是为了保证目标一致性，让研发或是其他配合人员能够清晰的了解我们在做什么，了解当下我们需要解决的问题、面对的场景是什么，对于成功的定义是什么。

总结起来就是只要写出的东西，弄够帮助团队成员，作出正确的结果的东西，那就是需求文档，需求文档没有标准，只有沟通。

我不希望约束的说，需求文档这样写才对，你那样写不对。我认为需求文档对于个人来说，想这么写就这么想，想那样写就那样写。但是对于工作，还是根据公司要求来，毕竟吃饭嘛。

但是，不管是写需求文档还是说需求文档，我还是认为包含下面这些信息，对于团队，还是个人都还是有很大的好处。

1、问题和方案。

2、证明问题和方案

3、成功的定义

4、场景

5、功能描述

第一：问题和方案

人与人之间有着明显的差异性和共同性，更别说不同职位了。前端、后端、测试、UI、产品、运营等职位，对于相同的事物和问题都会有着自己的见解和解决方案，并且因为职业壁垒原因，常会鸡同鸭讲，这是最常见的。

（工作中例子太多了，产品要增加个功能，直接给研发说，结果研发说没必要。这就是很典型的研发不知道说在什么样子的背景下，遇见的这个问题。）

我们首先要明确这个新增加的功能要解决了什么问题。其中包括了简要的背景，这个背景可以说一句话，例如，支付成功人数很低。也可以说相关的用户调研、市场反馈、数据趋势等，用于证实这个功能或产品是我们团队要做的。

第二：证明问题和方案

我们需要证实两个东西，一个是问题，一个是方案。要给其他人说明这个问题是真实存在的，而不是我想当然的。因为职业问题，很多研发或者是其他的部门的人都会认为（不绝对哈，但确实有这样现象），产品是技术部门的“门面”，“吹拉弹唱”样样都会。让人误以为产品经理是个只会“吹牛”的“交际花”。但确实行业内，包括当初我自己出现过随随便便写个我认为的问题，而没去证实他，之后草草丢给研发。

方案，也是同样的问题，不去穷举，不去关注相关竞品的解决方案，也就推进到研发阶段。我想这也大家都会经历的一个过程。同样我能够想象到出，当我们经历多了之后，简简单单说一个方案之后，这个方案真的可能是最优方案，毕竟天才和蠢材说出相关的解决方案，前者是经历过很多失败的方案之后说的，后者可能是运气好，正好说中罢了。叫他说出其中缘由，那就漏底了。

第三：成功的定义

我们要清晰的告诉其他人，这个功能对于成功的定义是什么。

这里的成功有两个意思，一、成功的研发出来。二、这个功能推出后取得的效果。

成功的研发出来这个很好理解，就是还原度，百分之一百的还原出功能。只有保证这个功能能够百分之一百的还原，我们才能通过市场、通过用户去验证这个功能或说这个方案是否成功。不然对于团队和我们来说就是，资源浪费。我们要将成功进行定义，只有这样才能得到有效的反馈。不然我们无法确认得到的结果，到底是成没成功。

第四：场景

场景说产品工作中最重要的东西，自始至终贯穿整个产品的一生。我这里不在过多阐述，文末我会发个我使用的场景还原方式。

第五：功能描述

功能描述包含的了很多东西，如：业务、流程、反馈、架构等，如果是文档的还会包括原型、状态、迭代记录等问题。

我们需要让其他人了解业务的流程，让每一个人清晰的知道，我们的业务环节。就像我们说的，如果你们团队很强大，几乎人人都是业务方面的小能手，那么你觉得还需要相关图吗？反之，我们为了能够清晰的表述业务，不一定要去画精美的图来表示，只要能够理解，写个1234都可以。

我们需要让其他人了解当前产品的架构，不管是信息还是功能，这样能够尽可能的复用，减少开发成本。不然研发不清楚，瓜兮兮的跑去写代码，结果要写完了发现，这尼玛其他模块有，可以直接调用或者是改一下就能用。现在写出来了还不能用（开发：代码耦合度高）只能去改原来的，那么确实是很尴尬。所以可以告知用户，这个功能在原产品上是存在的或是已经实现过了，因为代码真的不像我们说的，这个功能很简单，随便加一个字段就行。

最后

其实小李那些草图里面的内容确实是包含所有需求文档有的东西，只是相对于所谓的需求文档，没成体系罢了。也不是说那个测试的问题，我只是觉得太过去追求所谓的需求文档，反而不知道需求文档的真实目的。虽然标准的文档在一定程度上能够在这些内容表述清楚，通过原型具现出来。但是切记，这些还是需要根据当前公司文化来，按需输出。一味追求所谓标准的需求文档，不去思考为什么这样写，写这些的意义是什么。反而落了下层。

补充一点的就是，大部分研发都不喜欢开会，特别是那种你在这三四十页的需求文档，一开就开几个小时那种。先不说他们记不记得住，这个开会的成本是真的高。所以我推荐产品在开会前计算下每次开会的成本是多少（计算方法是，每一个参会人的小时工资之和），开会不要随意的开，每一次开会都是耐心的挑战、资源的挑战。

‍

‍