至此，我们完成了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个目的即可：
- 清晰地传递需求——>评审、沟通用；
- 详细地拆解需求——>设计、开发用；
- 认真地验证需求——>验收、测试用。
很肯定地说，不用拘泥于需要什么模块、也不用拘泥于用什么工具开发，朝着这3个目标去写就可以了。
一份优质有效的PRD关键点是什么？
- 把背景、共识交代清楚了。好的prd是放置1年，新入职的产品同学也能看得懂。
- 逻辑明确，没有废话。好的prd是字数不多，逻辑清晰、全是有用的信息。
- 简约清晰，该有的都有。好的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：认真地验证需求
关键词：认真、验证
互联网人喜欢说「闭环思维」，这一步就是闭环。
当一个需求被开发完之后，还没有结束。可以说才完成了一半，最重要的是检验是否达成了目标，怎么检验，如果达成改怎么办，如果没达成又该怎么办？
例如：
- 在开始中时，临时调整需求；
- 在测试环节出现了问题，需要代码回滚；
- 一个简单的需求上线后出现了bug，需要fix；
- 上线后数据效果不佳，远不如预期；
- ……
这些情况都可以算在验证需求环节出了问题。即目标和现实情况出现不匹配。
如何实现「闭环」，去验证需求？实际上并不局限于prd，一般有如下几点要注意：
- 质量保障：多方验收与测试。
- 数据分析：无论是否有a/b实验，有数据变化的话都要进行事后分析。
- 目标完成度：记录下未完成/超额完成的原因是什么？
- 下期规划：是否要做下期需求来弥补/持续优化。
- 邮件通知：尽可能发邮件通知到本次需求的所有参与方。
关于这一目的，由于「职得App」无法真正上线，不能够形成真正的闭环。因此就不展开举例。以上5点是我个人在实际工作中总结出来的，同样地，并非针对每个需求都要如此，需要是情况而定。
所谓产品经理要靠谱，如果能够对需求形成「闭环思维」，就是真正的事事有着落。这，特别需要在实际公司、业务中磨练，培养出这种思维意识。
总之，PRD只是一种承载形式，它完成它的3个目的即可，核心关键还是在于内容是否想明白，如流程是否解决用户需求、交互是否合理，这才是产品经理的本质工作。
五、感谢和总结
这是「从0设计App」系列的最后一篇内容，感谢大家的关注和支持～
作者：朱鲁斌，公众号：字字朱心。每周深度思考一个问题，不稳定的世界里找到一份笃定。
产品教练
若有收获，就点个赞吧
0 人点赞
