需求文档：没有标准、只有沟通

同样我能够想象到出，当我们经历多了之后，简简单单说一个方案之后，这个方案真的可能是最优方案，毕竟天才和蠢材说出相关的解决方案，前者是经历过很多失败的方案之后说的，后者可能是运气好，正好说中罢了。叫他说出其中缘由，那就漏底了。

第三：成功的定义

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

这里的成功有两个意思：成功的研发出来；这个功能推出后取得的效果。

成功的研发出来这个很好理解，就是还原度，百分之一百的还原出功能。只有保证这个功能能够百分之一百的还原，我们才能通过市场、通过用户去验证这个功能或说这个方案是否成功。不然对于团队和我们来说就是，资源浪费。

我们要将成功进行定义，只有这样才能得到有效的反馈。不然我们无法确认得到的结果，到底是成没成功。

第四：场景

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

第五：功能描述

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

我们需要让其他人了解业务的流程，让每一个人清晰的知道，我们的业务环节。就像我们说的，如果你们团队很强大，几乎人人都是业务方面的小能手，那么你觉得还需要相关图吗？

反之，我们为了能够清晰的表述业务，不一定要去画精美的图来表示，只要能够理解，写个1234都可以。

我们需要让其他人了解当前产品的架构，不管是信息还是功能，这样能够尽可能的复用，减少开发成本。不然研发不清楚，瓜兮兮的跑去写代码，结果要写完了发现，这尼玛其他模块有，可以直接调用或者是改一下就能用。

现在写出来了还不能用（开发：代码耦合度高）只能去改原来的，那么确实是很尴尬。

所以可以告知用户，这个功能在原产品上是存在的或是已经实现过了，因为代码真的不像我们说的，这个功能很简单，随便加一个字段就行。

最后

其实小李那些草图里面的内容确实是包含所有需求文档有的东西，只是相对于所谓的需求文档，没成体系罢了。也不是说那个测试的问题，我只是觉得太过去追求所谓的需求文档，反而不知道需求文档的真实目的。

虽然标准的文档在一定程度上能够在这些内容表述清楚，通过原型具现出来。但是切记，这些还是需要根据当前公司文化来，按需输出。一味追求所谓标准的需求文档，不去思考为什么这样写，写这些的意义是什么。反而落了下层。

补充一点的就是，大部分研发都不喜欢开会，特别是那种你在这三四十页的需求文档，一开就开几个小时那种。先不说他们记不记得住，这个开会的成本是真的高。

所以我推荐产品在开会前计算下每次开会的成本是多少（计算方法是，每一个参会人的小时工资之和），开会不要随意的开，每一次开会都是耐心的挑战、资源的挑战。

作者：wcof，在努力做产品不做产品经理的人；微信公众号：wcof（ID：wcofPM）

本文素材来自互联网

（编辑：厦门网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!