15158846557 在线咨询 在线咨询
15158846557 在线咨询
所在位置: 首页 > 营销资讯 > 网站运营 > 如何写一份让开发工程师【泪流满面】的PRD产品需求文档?

如何写一份让开发工程师【泪流满面】的PRD产品需求文档?

时间:2023-11-30 04:24:01 | 来源:网站运营

时间:2023-11-30 04:24:01 来源:网站运营

如何写一份让开发工程师【泪流满面】的PRD产品需求文档?:我们都知道一份完整的PRD,面向阅读人群有:设计师、市场、运营、测试、研发、领导…那在实际工作中,真的会有这么多角色来看你的PRD吗?

其实,因为互联网快速迭代的原因(我曾经负责的产品每周发版),一方面阅读落到做这件事的研发头上,一方面PM也没有充裕的时间去思考和完善PRD中那些为了某些非核心阅读人员看的内容。

所以,我这里说的主要是:如何写一份看上去清晰,研发容易理解的PRD。

那么研发在看一份PRD的时候到底关注什么?经过这几年我与不同岗位、不同层级的研发同学深入沟通和交流,总结为以下几点:

1、为什么做这个?
团队中少数研发会很关心这个问题,他们不愿意盲目去写代码。
2、业务关系是什么样的?
这个功能涉及到的整体业务流程和系统架构是什么。
3、页面长什么样子?
页面很大部分决定前端的工作量,大部分后台同学也习惯于通过前端页面去评估。
4、数据从哪里来?
从后台来?从其它事业部来?还是从合作的第三方API拿?亦或是人工上传?
当然,研发同学肯定关注的问题不只以上4点,但一开始这4点说清楚了,基本上这个文档就很容易读下去了。

曾经一位研发总监给我一个建议: PRD先画一个整体流程图,不要一上来就说具体功能,不然很容易就产生“这个功能好复杂好难”的潜在心理暗示。 我深表赞同!

那么接下来,就实际说一下,满足以上条件的PRD到底怎么落地去写。

一、需求背景

解释一下为什么做这个需求?我们遇到的问题或现状是什么样的,我们做这个需求是为了解决什么具体问题的。 尽量用大白话描述,不用太书面化。

这么几年工作下来,大概感觉是研发团队中其实不到50%的人在意这个需求背景,一大部分研发还是习惯于直接看功能描述,看怎么做,偏向于单纯的写代码。

二、产品目标

1、功能目标

描述一下这个需求具体要实现什么功能,这里的描述类似于一句话给别人介绍你这个产品。

2、数据目标

现在这个时代下,不关注数据的产品迭代行为都是耍流氓。你可以不完全依靠数据去做决策,但是必须知道你做的产品,核心衡量数据指标是什么吧?即所谓的OMTM(one metric that matters)。

建议这个指标不要超过3个,聚焦在核心路径上 ,甚至最好是只有1个。

三、系统架构&流程

这部分我认为主要是用来向研发同学传递以下2点内容:

1、功能的逻辑流程

基本等同于从用户使用角度的用例流程。

2、各个端之间的交互

前端、后台、算法等是怎么交互的。像机器人产品就更复杂了,大范围划分要涉及到客户端、机器人前端、机器人后端、服务器、语义平台、云平台等等。而某些机器人端功能更是要讲核心板和算法板也划分开。

建议是用泳道图的形式来表现这部分内容。

四、页面 & 功能结构

说白了就是功能的概览图,但是很多时候我们会面临:这个概览图是按照页面纬度还是功能纬度去划分。

我的建议是,根据这个需求的实际表现情况, 如果涉及到超过5个以上大大小小的页面了,那么建议从页面纬度来划分功能概览 ;如果是主页面就涉及到2、3个,那么从功能以及功能分支维度划分可能更好一点。

五、最小化功能描述

这部分你就要开始详细的描述一个功能点了。我一般会从以下几方面来描述一个功能点。

1、 功能简介 : 一句话说明这个功能要完成什么操作;
2、 原型图 : 如果有设计稿就直接放设计稿截图部分;
3、 入口: 主要入口在哪里?同时要多想一下用户还可能从哪些地方进来,比如APP可能有PUSH消息直达;
4、 前继条件: 进入此功能需要满足什么条件吗?有什么必须带入的参数吗?等等此类说明;
5、 页面或功能包含元素: 事无巨细的列出这个页面或功能由哪些元素构成;
6、 每个元素的属性和作用: 纯文本元素还是文字链?是否可被点击;
7、 整个页面和功能的交互规则: 点击某个元素会触发什么操作等描述;
8、 数据内容从哪里来: 从后台调取还是前端写死?前端写死的话此处要附上文案。
对一个功能如果以上8点描述清楚了,我相信基本就可交付开发了。

当然,在这几年实际迭代中,我发现 在PRD交付后,项目后期或者测试期间,最容易被问到的问题就是:没数据了怎么办?数据太多了怎么显示?

此类问题,每次写都嫌弃麻烦,但是不写的话测试同学可是会给你提BUG的,况且还会影响产品功能和项目进度。 建议勤快点,此类问题提取出来作为公共规则,在公司内部建立公用文档,每次需要的时候直接超链在PRD中即可。

以上希望对一些同学有帮助,如有其它写作PRD的实战经验,欢迎交流。

以上内容转载自公众号PM无漏法,作者是小七,希望能够给你带来收获。

接下来我们来讨论一下:

如何撰写产品文档?

产品经理该如何高效轻松地撰写产品文档?摹客近期重磅推出的产品文档在线撰写功能,为产品经理带来了全新的产品文档写作解决方案。

摹客是一个产品协作设计平台。从产品、设计、到开发,研发流程的每一个环节都可以汇聚到一个平台,形成一个完整闭环。摹客将产品文档在线撰写无缝接入其柔性工作流,打造了一款自带协作基因的产品文档写作神器,不仅可以帮助产品经理高效写作产品文档,还能让产品经理充分深入到产品开发流程中来,极大地降低沟通成本,提升团队效率。

在线写作模式

产品文档没有标准化的模板,因此,产品文档写作的自由度和流畅度很大程度上决定了文档的效率。对此,摹客提供了全新的写作模式:

此外,产品经理还可以直接上传已编写好的产品文档,摹客会自动解析目录,并生成文档树,方便查阅。

和设计稿完美结合

产品经理在写作产品文档时可插入设计稿,团队成员在设计稿上进行评论时也可以引用产品文档进行说明,可以精确至引用文档的某一部分,创建引用点,并标记该内容为高亮状态,方便查阅。这样,文档、原型图、设计稿就能无缝衔接,相互引用,无论是需求评审,还是开发时查阅,统统都能搞定。

多人在线协作、审阅

文档编写完成后,通过链接分享给团队成员,成员可对文档进行实时审阅,通过打点评论来标记内容,无需频繁开会。

我们有准备一份教程,欢迎去看看哦:添加产品文档

偷偷告诉你,摹客的产品经理们也一直在使用摹客管理产品文档,几位PM都觉得写作效率明显提升了,和设计师、开发工程师的交流也更加顺畅了。

助力产品高效研发!点击下方链接开始使用:



关键词:产品,需求,工程师

74
73
25
news

版权所有© 亿企邦 1997-2025 保留一切法律许可权利。

为了最佳展示效果,本站不支持IE9及以下版本的浏览器,建议您使用谷歌Chrome浏览器。 点击下载Chrome浏览器
关闭