从0设计App（8）：围绕3个目的撰写靠谱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？

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

本文素材来自互联网

（编辑：威海站长网）

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