从0设计App(8):围绕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?

 

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

本文作者@朱鲁斌  。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部