其实在我刚入行做产品时和大多数新人一样，遇到最大的一个问题就是「怎么写需求说明文档？」，而现在做了一年多之后回过头来看，这个问题的答案仍然是「需要」，但我所理解的「需求说明文档」和传统意义上的可能不太一样。
先来说说我们团队现在的配置：
- 1个 CEO 兼产品 Leader
- 1个 PM（我）
- 1个 UI 设计师
- 2个后端开发
- 2个 iOS 开发
- 1个 Android 开发
- X 个运营
除了运营之外我们就只是一个不足10人的产品研发团队，体量太小，如果是用标准的 PRD 来进行需求沟通，那太慢了，而且维护成本太高，大部分时候 PRD 并没有起到沟通的作用，在产品的起步阶段我写了上万字的 PRD 结果却没有一个工程师认真的看，在这种情况下 PRD 反倒成了累赘。
PRD 的核心作用无非就是以下几点：
- 方便产品经理自己梳理流程和细节
- 方便其他人理解需求并按照文档内容实现功能
而在大公司可能还有其他作用：
- 保证各部门沟通有理有据，避免撕逼
- 约束产品经理的随意变卦
- 甚至是 KPI 的指标之一
总的来说 PRD 的作用是减少团队沟通成本，但值得注意的是，PRD 只是需求沟通的一种形式，而不是目标，产品经理的目标应该是提供满足需求的功能和推动功能的实现，其实大部分产品经理没必要写需求文档去表述功能，尤其是在人数较少的创业团队，只要能让所有人理解需求功能点，具体是怎样一种表现形式又有什么关系呢。
简单说一下目前我们团队开发的基本流程：
- PM 根据需求出手稿和 Leader 过一遍
- UI 设计师根据手稿出视觉稿的同时 PM 写后端功能逻辑
- 和工程师们根据视觉稿沟通前端交互和后端功能逻辑
- 工程师评估开发周期，Leader 根据周期长短适当增删功能后即可正式开始开发
可能我们团队有些特殊，我和 UI 设计师异常默契，有时候甚至连手稿都不需要他就能完全把我想要的交互画出来，大大减少了画原型的时间；而前端工程师经验丰富，交互基本都是通过口头沟通对方即可理解，即使有什么遗漏的扭头喊一声我就马上跪倒在其面前进行讲解；测试用例近期也在进行迭代，不再使用传统的格式「功能点、用例说明、用例编号、前置条件、测试步骤、预期结果、测试结果、失败原因」，而是用思维导图一句话表达即可，所以总的来说我需要产出的文档就只有「后端功能逻辑」和「测试用例」，对于需要快速开发上线的小团队来说，面对面沟通显然好过文档（关于这点当初我和 Leader 产生了分歧甚至因此大吵过一架）。
但需要注意的是这种模式并不适用于所有团队，规范有规范的好处，随着团队的人数扩张，产品页面数量越来越多，业务逻辑越来越复杂时，一份相对规范的文档能够帮助你理清思路，只靠单纯地沟通，会显得吃力且容易遗漏。
所以关于是否一定要写 PRD 这一问题的答案并无绝对，需根据团队实际情况以及产品经理的习惯，找出最适合你们的沟通方式即可，至于是用 Word 还是 PowerPoint 甚至是 Excel 都可以，而我则更喜欢用 Markdown 编辑器，毕竟能有效地传达需求给对应的人员并确保对需求的理解一致才是根本目的，没必要拘泥于形式。
