产品新人,如何将产品需求文档撰写更深入?
产品需求文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档,如果你已经能可以撰写需求文档,那么你现在需要看看本文,在会撰写的基础上能够将产品需求文档撰写的更深入。
一、简述
撰写结构与开发思维,是在产品需求文档基础上,需进一步提升的核心基本功。而这个基本功,决定着能否输出高度模块化的产品需求文档。
但是,许多的新入行的产品新人,对产品需求文档认识,局限在:“套个模板、添加个前置、后置条件、流程图”等认知,便能输出一份严谨的产品需求文档。事实上,这些都只是些浮于表层的事物!对于模板“是否拥有前置条件、后置条件”这些模块结构,对于产生优质的产品需求文档,其实并不是核心的决定因素。
纠结于产品模板,会导致新人误入形式,远离本质。这种场景下,很难将产品需求文档撰写严谨,最终必然导致内容空泛。我们对产品需求文档最终达到的效果,进行TAG概括:
- 推理严谨
- 逻辑合理
- 描述细致
- 场景清晰
在进阶版篇章中,我们从产品需求文档模板的框架中跳出来,在高一层的维度中,从“方法论”的角度展示。
根据案例:产品需求文档A与产品需求文档B,基于撰写结构与开发思维,如何实现“严谨、合理、细致、清晰”效果,进行案例分析。
二、撰写结构
撰写结构,就是基于被撰写的产品功能模块,有规划的进行内容组织。且将组织的内容清晰的描述出来,而内容组织并不局限在使用某个产品需求文档的模板中,只需要拥有个人“方法”,将产品功能描绘清晰即可。但,它须坚持一些原则:
- 符合浏览对象浏览信息流的习惯,被组织的内容权重主次清晰,并起到引导作用。
- 内容组织紧凑,功能模块内容结构划分清晰,区分明显。
- 结构化的撰写方式,以结构化的形式展示数据流、业务流、页面布局逻辑。
- 严谨的是与否判断。
产品需求文档A
产品需求文档A,在描绘需求时,采用的是“功能名称-需求说明(内容描述)-原型图”形式作为撰写结构,进行文档撰写,描述不够深入导致整体较为空洞,体现在:
- 页面布局:缺乏1、2级层级关系,用户浏览信息时,缺乏主次。需要查看参与者个人进行信息区分,队内容层级筛选。
- 整体排序:排序不符合查看参与浏览信息方式,不能起到引导用户有节奏地进行产品功能内容传递。
- 模块结构:内容结构单一,在“需求说明”上,无法系统化地进行产品功能细节描写,页面的数据流、逻辑关系无法清晰的表达。
- 撰写结构:文档描述口语化严重,缺乏结构化语言,思维零碎,无法引导查看参与者思维进行文档价值传递。
基于上述原因,产品需求文档A,对于产品功能涉及的“字段、操作逻辑、数据流、排序规则….等,都无清晰的表达出来。
产品需求文档B
采用竖并列式的结构进行文档撰写,整体显的紧凑,内容丰富,主要体现在:
完整的文档模块
产品需求文档B,文档模块,围绕产品功能的数据流与逻辑关系展开搭建,框架模块较为清晰。从产品功能名称介入,从“用例图、前置条件、后置条件、功能概述”的角度,将产品功能大的框架明确。
产品框架的基础上,进行产品功能模块细化,绘制出:“字段列表、表单、操作、交互、算法模型….”,而描述的模块与结构化的思维,将产品功能主次区分开,将细节进一步深入描述。如进行产品功能规划:“从主业务流切入,将核心流程打通。”后台:逻辑业务流,前台:选购支付流(流程不通,转化率必然很低)。
规范的内容排序
严谨的功能模块,结合内容主次排序,如何符合参与角色浏览文档的习惯,便显的非常重要。产品需求文档A,在文档排序上,使用:“功能名称-功能说明-原型图”,这种描述逻辑是:
查看参与者,需要先看需求说明,才进入查看原型图,这种查看文档的交互方式,是有问题。
对 于文档传递信息而言,第一步是进行整体的产品功能概念的价值灌输,从原型图了解大体的逻辑与数据,让参与对象可以在功能上对整体模块进行了解。在这个基础 上,才进入细节描述,这个过程中才结合原型图,逐渐将功能细节撰写排序。这样利于后续交接方与提出方、研发方,在查看文档时,最短的时间熟悉产品功能的大 体逻辑。
而产品需求文档B,在内容排序上,采用“功能名称-原型图-整体业务框-功能说明”,这种描述的逻辑是:
了解功能,了解答题的功能内容-了解整体业务框架-进入细节了解,这种查看文档的交互方式,符合上述方法论,并且从浅往深引导查看参与者由浅至深的深入了解文档整体内容。
严谨的细节撰写
在整体框架的基础上,撰写的更深入。一方面,需要对行业业务知识进行积累;另一方面,对于所把握的产品功能的使用业务场景理解透彻。
在 产品需求文档A中,每个字段、操作逻辑、判断条件、业务场景无严谨的说明,所描绘的内容仅局限于不清晰的页面布局与不清晰的提取数据记录。而产品需求文档 B,采用格式化的形式进行文档撰写,在格式化的框架下,细致页面布局的字段与涉及业务场景、判断条件都能很好的进行描述。
而细节描述,尽量精确至每个字段。若所设计的字段与当前业务字段符合,请备注为当前功能不变,开发成熟的模块仅需要插进去。
但 业务场景,必须想清晰,如:在某款特卖产品中,新增”浏览记录”功能点,常规用户进行历史浏览记录查看时,超过90%的浏览的记录时“无法进行购买超 过”,这是影响用户体验,印象流量转化率。若后续在“本场景”下新增个性化推荐功能点,也显的有些不搭调,这个场景逻辑是:我看个人历史记录-没有了-推 荐其它商品,那我干嘛还看我的历史浏览记录?若针对于活动热度这种特殊场景,但是浏览记录又是一个常规功能。而事实上,这是非常典型的没将功能点各个业务 场景清晰的梳理清楚:
- 特卖商品拥有档期属性,若干天就需要对商品进行下架。
- 大量的用户非每天都会在本产品进行新商品浏览。(若是电商PM查看本文档,请查看贵平台后台的BI分析报表,查询一下日用户活跃度(DAU)的环比下降幅度,与用户平均查看商品数)
可理解的描述结构
产品需求文档A整体是缺乏结构的,而产品需求文档B是在结构化的框架下进行撰写。而描述结构围绕着产品功能或字段,围绕着“我是谁,我从那么来,我要那里去”,整体便非常清晰。
撰 写结构,是产品需求文档非常核心的组成部份,在模块化、排序、细节、结构等层面上。一方面,从整体上解决产品需求文档A存在PRD撰写的问题。另一方面, 将发散的思维收窄,聚焦至解决一个产品功能的业务问题上,包括字段数、业务逻辑、涉及的变量算法… ….清晰的描绘出来。
让PM把握产品功能整体,完整的的对价值实现上与下进行传递,并满足本章节提出的“撰写结构原则”条件。
三、开发思维
开发思维,是一种线性思维;在逻辑的世界里,只有“是与否”。是,则开始。否,则结束或进入下一个开始。
它们就像完美的整体,将产品从顶层战略至功能细节,体验在产品每个使用场景中(用户使用体验)(具体的用户体验,我们将从后续的篇章进行描述,这里不进行详细描写)。
正如在《倒爷教你写产品需求文档(基础篇)》中,计算机表达的是数据流与逻辑操作,那么开发思维,便是通过“是与否”,将产品细节,从数据流、操作逻辑关系的角度。描述出来;主要体现在两个方面:
数据流
在 协助层与基础层之间,通过“数据控制”与“数据传送”两个动作,实现数据的仓储与传送。那么,前台主要是进行取值(数据提取),后台主要是数据发布与管 理;而PM,需对所负责业务,对系统拥有哪些数据,与数据是如何控制拥有足够的把握。只要后台拥有产品功能模块数据,在不影响前台性能的前提下,在时间条 件充足下,基本上可以实现。
随着平台业务的增长,平台需从开始由于“低门槛”让参与度提高的策略,摆脱前期策略导致的信息数据匮乏。后期需逐渐逐渐通过运营的手段,将前后台的业务数据补齐,支撑后期进行数据结构化分析,实现数据智能精准化运营。而数据流,必然少不了。
逻辑关系
机器的行为,是通过程序语言来实现。你需要输入某个指令,它才会去执行某个任务。在处理多个任务的时候,便需要对多个指令进行判断执行。而在前后台业务时, 需要PM对每个业务状态场景有深入的认识,才能基于判断逻辑与触发条件足够的把控,将所负责的业务场景打通;(在这点上,若不是只做操作功能点的PM,可 以用户产品功能架构,将个人所负责产品功能,从数据发布、管理、提取、仓促、分析,进行产品功能框架搭建)
总而言之数据流与逻辑关系相互结合,能让PM在撰写产品需求文档时,让用户使用场景与计算机逻辑紧密结合,设计出符合用户体验的产品,结合业务场景进行功能取舍,设计出符合平台战略或用户体验的产品功能点,提高了对应的转化率与实现业务(GMV)增长。
四、综述
撰写结构与开发思维,是撰写产品需求文档非常核心的组成部分。是在模板或者样式的基础上,输出优质严谨的文档内容。在业务层面,与开发与业务方更严谨的进行良性沟通。而这些正是进阶版的核心所在,这个基础上,你可以根据实际的产品功能请看,进行PRD撰写与设计!
同时,将PM从发散思维的产物收窄至逻辑思维的产物,大大提高了PM入门门槛,提高了专业度。
五、附语
对于产品需求文档是否需要某类样式与格式?具体的样式与格式,可根据团队、项目实际流程与平台业务性质进行撰写结构进行设计,毕竟商业社会是以团队的形式进行作战。
但, 作为个人,是否需要进行训练。倒爷001无法给你明确的答案,因为那是你自己的事。但是,从PRD角度,撰写完整的框架,能对你个人的产品框架思维得到训 练。并且,文档是否高要求,其实也是你的事,至于开发看不看那是开发的事。出了问题,背锅的也是你的事。总不能让测试背吧?
大道至简,简难而繁易。处理一个功能点的框架思维与处理一个产品的框架思维是一样的。经过严谨的训练,能让框架思维得到提升,而初始框架搭建是否靠谱,也决定了产品后续的迭代生长。
六、抛个话题
如果上帝无法预测与控制宇宙的每个细节,在我们所能理解的所认知思维中,对我们存在认知进行设计,并存有大量以下的现象,如:
- 50%的人类是畸形人
- 50% 的天气是自然灾害
- 女性的占比率<=1%
那么,你认为Ta是一位伟大的创造者?
相关阅读:
作者:倒爷,微信:ftl_keen。
本文由 @倒爷 原创发布于人人都是产品经理。未经许可,禁止转载。
感谢作者大大的分享,读到这篇文章的您,
如果想具备系统产品知识技能,
有一套体系化的个人项目作品,
想工作和求职,都更加的顺畅!
那体系化的学习训练就很有必要,
点这里,先看看公开课: http://996.pm/7GVQ4
大神 能讲点具体的栗子么,好迷糊,感觉好抽象 😈
看不大懂,我还是太小白了
读不下去了感觉像英文用翻译软件翻译成的中文。。。
还有错别字。。。
有的语句有点不通顺啊。。
图片清晰度好差啊,是手机看的缘故吗
😛
内容挺好的,就是案例过于理论,不那么易懂
😯 😯 😯 😯
只有我看不清楚B文档图片的内容吗? ➡ ➡ ➡ ➡ ➡ ➡ ➡ ➡
😆 😆 😆 😆
😳 😆
➡ ❗
终极篇,倒爷001会以注册登录功能,直接进行文档撰写
谢谢分享!
亲,文档的图片真真是小,完全看不清,能不能把不方便展示的信息删除后,给妹子发一份?还在行外面的小菜鸟求~ 330326703@qq.com
😯 加我wechat
妹子,求一份插图,可以给我发一份吗?1360312976@qq.com,谢谢了。我加了楼主微信,暂没收到回复。。。