从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个目的即可:
- 清晰地传递需求——>评审、沟通用;
- 详细地拆解需求——>设计、开发用;
- 认真地验证需求——>验收、测试用。
很肯定地说,不用拘泥于需要什么模块、也不用拘泥于用什么工具开发,朝着这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」系列的最后一篇内容,感谢大家的关注和支持~
相关阅读:
产品人深思(7):互联网群面的1个通关原则:horsekeeper
产品人深思(5):产品经理如何写有用的简历?
产品人深思(3):大学生如何拿到产品offer?
作者:朱鲁斌,公众号:字字朱心。每周深度思考一个问题,不稳定的世界里找到一份笃定。
本文作者@朱鲁斌 。
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!