从0设计App（8）：围绕3个目的撰写靠谱PRD（系列完）

至此，我们完成了app的定位、系统架构、产品结构、重要的2大流程图（业务、页面流程图）以及所有页面的原型稿、交互稿、视觉设计稿。最后将他们组合在一起，是否就得到PRD了呢？不完全是，本文将围绕PRD的3大目的来拆解如何写PRD。

本系列是笔者拆解从0到1设计「职得App」，这个作品帮助我拿了好几个offer，因此特别展开分享给大家。之前的文章，可以在笔者的个人中心阅读，欢迎订阅～

一、市场分析篇： 市场分析（上） ； 市场分析（下）

二、竞品分析篇： 竞品分析

三、用户调研篇： 用户调研（上） ； 用户调研（下）

四、需求管理篇： 需求管理

五、架构流程篇： 产品定位（上） ； 系统架构/产品结构（中） ； 业务、页面流程图（下）

六、原型设计篇： 原型&交互设计

七、UI设计篇： 视觉概念设计

八、PRD文档篇：（本文最终篇）

在此声明：本系列的产品内容原创且非商用，如有雷同，你抄我的！

一、前言

在之前的文章中，我们做过背景分析（市场调研、用户调研、竞品调研）、需求管理、产品定位（功能目标）、流程图、原型图、交互稿、UI稿。

如果你还没看过之前的文章，建议先行阅读，以免产生知识的诅咒，读不懂下文。

实际上，在做这些事的过程，就相当于在写PRD。PRD的全称是：Product Requirement Document， 核心是围绕「需求」来写的一份文档罢了 。鉴于我们是从0设计App，相对来说就是N个需求的集合，甚至还涉及到了需求排期和产品演进蓝图，因此我们职得的PRD会非常大。

二、Why：为什么要PRD？

我们反过来想，如果没有一份PRD会怎么样？

• 沟通全靠想象力；
• 跟不同部门的同事用不同文档沟通；
• 开发完了没有“凭据”；
• idea太好，记不住了……

如果没有一份完备的PRD，就会导致需求无法落地成软件。如同借钱不打借条，没门。如果不写PRD，相当于程序员天天不敲代码。

三、PRD是什么？

不用多说，PRD重要性不言而喻。

实际上，在各公司里，对PRD都有各自的规范，其实你可以理解为 各公司规定的一份「解决需求」说明书 ，PRD也好，需求稿也罢只是一个名头而已。不要被名词所拘束。

在不同公司里，要灵活运营，达到以下3个目的即可：

1. 清晰地传递需求——>评审、沟通用；
2. 详细地拆解需求——>设计、开发用；
3. 认真地验证需求——>验收、测试用。

很肯定地说，不用拘泥于需要什么模块、也不用拘泥于用什么工具开发，朝着这3个目标去写就可以了。

一份优质有效的PRD关键点是什么？

1. 把背景、共识交代清楚了。好的prd是放置1年，新入职的产品同学也能看得懂。
2. 逻辑明确，没有废话。好的prd是字数不多，逻辑清晰、全是有用的信息。
3. 简约清晰，该有的都有。好的prd是顾及到本次需求涉及的同事，如服务端开发、测试工程师。

只要你能够做到这3点，大概就是一份好的prd了。从来没有人定义好的prd是字多。

四、怎么写PRD？

问：PRD用什么写？

答：Word、Axure、共享协作软件都可以。

主要看公司统一用什么，你就跟着用就对了。个人比较喜欢用共享协作软件，因为prd的一个目的是沟通用，而在沟通中一定会出现其他人的不同意见，或者其他人才有的知识，可以让别人直接更改，很高效。我在公司里用过。

当然，我也推荐用Axure，小需求小改动或者是多个需求集合的时候，可以使用，比较适用于小团队，我在公司里也用过，各有优劣。

问：PRD怎么写？包含什么模块？

答：不要固化思维，正如上文，重点在于围绕「需求」的三个目的。

按照上文一份PRD的3个目的即可，结合「职得app」来拆解每一个模块。

目的1：清晰地传递需求

关键词：清晰、传递。

为了清晰地向其他同事（如开发、设计师、测试、运营、市场等）、上级领导、boss、未来新入职的产品讲清楚需求。

必须说清楚的有：

• prd版本迭代： 因为一份prd并不是一个人来写的，比如常见的UI稿就来自UI设计师，因此prd是一步一步写出来的，特别需要在prd开头写明白；
• 交代背景： 场景、遇到的困难、为什么要做这个需求；
• 定义词汇： 对于陌生词、专有词、跨领域词用文字在prd开头定义清楚；
• 交代目的： 想解决什么问题、想提高什么数据到多少；
• 描述解决方案： 根据背景/现状、以及目的去描述可能的解决方案；
• 附属链接： 贴上与本需求相关的其他内容。

回到我们「职得App」中，我们一一拆解来看。

PRD版本迭代： 做成表格，每次记录迭代顺便记录即可。包括时间节点、负责人、内容、进度。

需求的背景： 对于从0设计的APP来说，无疑是 市场分析 、 用户调研 、 竞品分析 。关于调研内容我在本系列头几篇文章已经详细分析过，还没阅读的小伙伴可以认真看一下。

定义词汇： 因为涉及的业务比较简单也没有什么专有名词，跳过这个模块。

交代目的： 做一款App解决市场上发现的未被满足的需求。

大致解决方案： 之前在 产品定位 有提及，包含产品定位和v1.0.0版本功能需求Feature List、系统框架、以及产品演进蓝图，就不一一赘述了。

名称：职得App

定位： 大牛培伴式互联网职场技能学习平台；

slogan： 陪练十遍，技能自现；

目标用户： 非一线互联网职场新人；

用户痛点： 在中小型公司得不到业界大牛指点岗位技能的机会。

附属链接：无

目的2：详细地拆解需求

关 键词：详细，拆解

需求最终还是要给到设计师、程序员、测试工程师来进行设计和开发。因此在prd里必须包含了本次需求所涉及的实现路径。

视情况而定，不同需求拆解的程度不同。

• 比常规少： 有的需求不涉及前端的页面，就不涉及UE/UI设计，有的需求开发自测，不需要测试工程师来进行质量把控。
• 比常规多： 有的需求涉及跨部门协作，需要运营、市场的人后期参与，或有的需求涉及数据分析师、公司中台的协助。

简而言之， 几方参与就写几方内容，一般包括但不限于：

• 给开发看： 业务流程图、页面流程图、原型交互稿、UI稿、数据库调整规范、埋点修改规范、版本迭代、接口规范
• 给UE看： 需求目标、解决方案、线框稿
• 给UI看： 需求目标、解决方案、原型交互稿、
• 给测试看： 需求解决方案、业务流程图、页面流程图、原型交互稿、测试用例、埋点修改规范
• 给运营看： 运营推广计划、a/b实验方案、产品培训方案
• 给数据分析师看： 需求目标、解决方案、a/b实验方案

再次强调It depends，情况而定的思想。需求目标会影响到在prd中需要拆解出哪些内容。

回到我们「职得App」中，因为是从0设计App，因此几乎会覆盖到所有人。但由于是模拟项目，并非真实上线投入到市场中，无法验证，所以不包含运营计划和ab实验方案。

因此「职得App」PRD中包含业务流程图、页面流程图、原型交互稿、UI稿。而这些在之前的文章中一一详细分析过了。

在实际工作中，还应当包含： 埋点规范文档（给开发和测试看）、测试用例（和测试协商）、运营推广计划（和运营协商）、ab实验方案（和数据分析师协商）、产品培训方案（和运营/商务协商）

目的3：认真地验证需求

关键词：认真、验证

互联网人喜欢说「闭环思维」，这一步就是闭环。

当一个需求被开发完之后，还没有结束。可以说才完成了一半，最重要的是检验是否达成了目标，怎么检验，如果达成改怎么办，如果没达成又该怎么办？

例如：

1. 在开始中时，临时调整需求；
2. 在测试环节出现了问题，需要代码回滚；
3. 一个简单的需求上线后出现了bug，需要fix；
4. 上线后数据效果不佳，远不如预期；
5. ……

这些情况都可以算在验证需求环节出了问题。即目标和现实情况出现不匹配。

如何实现「闭环」，去验证需求？实际上并不局限于prd，一般有如下几点要注意：

• 质量保障：多方验收与测试。
• 数据分析：无论是否有a/b实验，有数据变化的话都要进行事后分析。
• 目标完成度：记录下未完成/超额完成的原因是什么？
• 下期规划：是否要做下期需求来弥补/持续优化。
• 邮件通知：尽可能发邮件通知到本次需求的所有参与方。

关于这一目的，由于「职得App」无法真正上线，不能够形成真正的闭环。因此就不展开举例。以上5点是我个人在实际工作中总结出来的，同样地，并非针对每个需求都要如此，需要是情况而定。

所谓产品经理要靠谱，如果能够对需求形成「闭环思维」，就是真正的事事有着落。这，特别需要在实际公司、业务中磨练，培养出这种思维意识。

总之，PRD只是一种承载形式，它完成它的3个目的即可，核心关键还是在于内容是否想明白，如流程是否解决用户需求、交互是否合理，这才是产品经理的本质工作。

五、感谢和总结

这是「从0设计App」系列的最后一篇内容，感谢大家的关注和支持～

相关阅读：

产品人深思（7）：互联网群面的1个通关原则：horsekeeper

产品人深思（5）：产品经理如何写有用的简历？

产品人深思（3）：大学生如何拿到产品offer？

 

作者：朱鲁斌，公众号：字字朱心。每周深度思考一个问题，不稳定的世界里找到一份笃定。

本文由@朱鲁斌  原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash， 基于CC0协议。