这是第803篇原创文章。

每日更新，这是一篇由担任产品经理的年轻创业者发表的文章。

实现一个极简产品的过程，也就是我们喜欢说的 MVP 版产品。在实现这个极简产品的过程中，前期的投入和预算总是非常谨慎的。所以一开始要么是一个创业团队，要么是一个大公司旗下的小项目团队。

市面上的小团队无法和大公司的项目团队相比，在产品经理数量、开发、运营、测试人员资源，以及岗位层级等方面都不如大公司。

在大公司里，有一些小项目，团队成员以“兼职”的方式加入。例如，他们原本在业务线 A，但临时去支持某个项目。

和创业一样，小团队在大公司也面临生死存亡的问题，但风险要小得多。比如项目达不到预期指标，就会被当场下架解散，但对于小创业团队来说，损失成本是最低的。

当然，如果成功了，获得的利润也不会比创业团队的利润好。

因为这种风险的存在，小团队里每个人都有专门的工作，基本上要身兼数职，比如一个产品经理，需要能搞定商务和市场，又能做产品功能需求调研，还要充当测试的角色，帮助产品上线。

小团队在技术架构的选择和研发流程上与成熟产品有很大不同，比如在架构设计上，是选择快速的单体应用，还是微服务，还是高成本的分布式服务？

小团队宁愿选择单一的应用来实现业务，后期再进行重构，也不愿意前期做复杂的架构设计和投入。

对于一个产品经理来说，市面上流传着无数的需求文档规范，但在工作中是否一定要遵循一定的模板呢？

其实并不是的，同样，需求文档也不是越复杂越好。

例如，对于产品经理来说，标准需求文档可能如下所示：

登录和注册要求文档

上面的模板里包含了页面的测试用例、交互、前置条件、后置条件、字段规范等，但实际上这种 PRD 文档的制作时间非常长，如果每个需求都是这样的话，产品经理可能就得加班了。

但至少有这样一个

简单需求描述

对于小团队来说，速度和快速验证是第一要务，产品经理的需求文档在这种小团队中可以更加简化，以上两份文档极其笨拙，涉及范围和编写成本较高。

对于软件互联网产品来说，一个小团队往往由一个产品经理、一个前端开发人员、一个后端开发人员、一个UI设计师组成，如果再精简一点，可以是一个产品经理、一个后端开发人员、一个前端开发人员。

虽然团队很小，但什么都不能少。我们可以列出每个人将要参与的工作职能。

会员分工

麻雀虽小，五脏俱全。

当团队每个成员都处于多线程工作状态时，产品经理显然应该选择最简单的方式来编写需求文档，这样不仅可以减少需求输出的时间，还可以达到快速研发的目的。

这种方式有一个前提条件：需要至少有 3 年工作经验的产品经理才能胜任

原因很简单：需求文档越简单，你越需要把精力集中在重要的部分，而不是花时间在其他无用的需求上。

简单需求文档写作模板

我建议小团队（少于 10 人的研发团队）使用简单的方法来编写需求文档。注意，下面的模板不是从文档的结构开始的，而是列出了文档的必要部分。

1. 先决条件

说明当前的操作是需要依赖前提条件的，比如下面这个活动报名H5页面，需要注册用户的账号，经过微信授权登录-手机号绑定-信息填写之后，用户才可以选择支付。

前置条件非常重要，例如能否提供访客身份、用户系统层级等，都是最常见的前置条件描述。

2. 字段类型长度

字段类型长度其实是需求文档中出现频率最高的，因为每个页面都有字段，人数、时间、价格、商品名称、文章标题等都需要一个标准的定义。

3. 计算规则

计算规则不是业务逻辑，比如下图的阿拉丁小程序列表，涉及到应用列表的排序，背后都是对应的算法规则。

小程序排行

小程序排名计算规则

当然，越到后期的计算规则，越是期待系统能够完成，人工参与的程度就越低，因此后续也会有相应的AI算法和数据修正，不过产品经理一定要在前期讲清楚。

4. 文案说明

文案不等于内容运营，而是指对应产品的按钮、页面等样式的文案。尤其对于微信生态下的产品，这类文案与转化率、访问量、传播数据有直接关系。