三大文档 FSD一般包含在PRD
1.BRD一般是去向决策层汇报 2.产品介绍的各项是可选的 不是必备的
产品线路图就是roodmap。团队一般是偏技术的团队。
BRD案例。
痛点。定性的描述。不会非常细致。
当前的手段。
价值。
竞品。
计划与目标。
BRD的亮点。协调资源。
产品的功能结构。
本篇文章以电子纸市场为例,解构BRD文档写作标准,供大家参考学习。案例涉及BRD流程、电子纸行业市场、中台概念、以及智慧办公等领域内容。
一、BRD文档的目的
电子墨水屏具有像纸一样超薄、超低功耗、如同纸质书阅读体验缓解视觉疲劳、强光下可视等优良特性,与主流液晶显示屏对比有着差异化市场应用,已被广泛应用于电子书阅读器、电子货架标签、消费电子、金融业产品等领域。
电子纸最早发展于20世纪70年代初期,电子纸技术历经研究开发、样品与少量生产、正式生产等阶段,在2008年得以大量生产,电子纸的发展史更是技术的迭代史。
在电子纸行业中能够量产电子墨水膜的企业有两家:
一家是中国台湾的元太科技工业股份有限公司,该公司控股的E Ink 公司拥有微胶囊型电泳式技术,此外,元太科技控股的达意科技股份有限公司拥有微杯型电泳式技术。
另一家是中国大陆的广州奥翼电子科技股份有限公司,而元太科技在电子纸市场占据垄断市场地位,市场占有率在90%左右。
2015 年,全球电子墨水屏的应用产品产值就已达到 17.4 亿美元,这几年一直保持着快速增长。
2020年,全球电子墨水屏的应用产品产值 60 亿美元左右。
商业市场周期:
资料来源:观研天下数据中心
2025年全球电子纸市场规模将超600亿美金,为实现全色域的显示效果,电子纸供应商E ink发布了彩色电子纸技术,近几年将实现大规模量产。
2021 – 2025年全球电子纸显示终端市场规模预测:
数据来源:洛图科技(RUNTO),单位:亿美元
基于彩色电子纸技术的应用,电子纸的传统产品电子阅读器将面临再一次的需求激增,特别是在美国、中国、欧洲等主要经济体,在线浏览、数字阅读的习惯正在普及,将成为电子纸的主要市场。
同时,受益于全球5G、大数据、物联网的部署,未来五年,全球电子纸显示终端市场复合增长率50.6%。
伴随着物联网的发展,电子纸从厘米到米尺寸级别,广泛应用在多样化的各场景和领域中。
资料来源:E Ink
应用级智能硬件在国内兴起5年多时间,无纸化、低功耗、不发光、防炫目等亮点需求已深入人心。
特定场景(会议、医院、共享空间、酒店等)存在巨大的市场需求,作为一个新兴的蓝海市场,将成为垂直市场的爆发点。
国内细分市场潜在的客户:
1)会议场景桌牌
批量导入内容,快速完成一个桌牌的更新,并可随时修改。
解决痛点:
场景:工位牌/会议桌牌/会议室门牌/会议信息显示牌,应用于智慧办公领域:
2)共享中心、图书馆
智能桌牌、显示预约留座信息。
解决痛点:
空间使用的管理实现无缝对接,极大减少了管理员的基础工作量。
3)医院、养老院
床位牌、门牌。
解决痛点:
与医院的各类系统无缝对接,没有闪光/刺眼等现象,实现账单显示以及保健知识、医药推荐等内容。
场景:床位牌/病房门牌,应用于智慧医疗场景:
4)企业、酒店电子门牌
解决痛点:
安装简便,无需布线,低功耗,电池续航时间2年+,无缝对接酒店系统,信息同步。
场景:门牌
5)广告屏(公交车、地铁):拉手广告屏
解决痛点:
公交系统20小时/每天运营,解决人力更换广告纸时间来不及问题。遇到重大节日、重大事件,临时更换信息内容,传播公益等。公交系统一般是弱网络、无外接电源。
场景:公交站牌,应用于智慧公交/智慧零售领域
智慧城市建设是行业信息化升级,利用云计算、大数技术、人工智能提升城市服务能力,主要面向交通、医药、环境、文化、旅游、水利等行业,为促进民生建设。
互联网+政务服务主要是面向广大民众开设的网上服务办理平台、官方网站(包括web网站、微信公众号、APP)、信息查询平台、数据开放平台。
上海已经开始布局:
上海久事集团说,近年来加快了安装新型墨水屏的力度,目前已安装新型墨水屏2736个,其中站亭1092屏,站杆1644根。今年内将完成站杆522根、站亭416个,实现公交到站预报设施全覆盖目标。
6)标签、胸牌、介绍牌:会展中心、博物馆等标签展示
解决痛点:
无需电源接入,屏幕没有闪光、刺眼等情况,颜色根据展示内容更换配合营销、活动等,临时更换展示信息内容。
场景:信息显示牌、电子胸牌
单一的产品形态难以在市场获得持续的成功,企业必须要搭建一套系统能力来应对市场的不确定性。我们要不只挣扎于眼下的生死,需要做更长远的规划和建设。
企业中台是把一些驱动业务的中长期模块,在全公司范围内共享给做业务突击的部门。不仅能更好地支持创新,又避免了资源重复建设。
结合在电子纸领域的独特优势,提供一套结合电子纸产品的中台系统,打造智慧办公领域的中台能力。
中台最早是从阿里在2015年提出的“大中台,小前台”战略中延伸出来的概念。
灵感来源于一家芬兰的小公司Supercell:一家仅有300名员工,却接连推出爆款游戏,是全球最会赚钱的明星游戏公司。这家看似很小的公司,设置了一个强大的技术平台,来支持众多的小团队进行游戏研发。这样一来,他们就可以专心创新,不用担心基础却又至关重要的技术支撑问题。恰恰是这家小公司,开创了中台的“玩法”,并将其运用到了极致。
中台是为前台而生的平台,它存在的唯一目的就是更好地服务前台规模化创新,进而更好的服务用户,使企业真正做到自身能力与用户需求的持续对接。
“小前台+大中台”的运营模式,就是美军的特种部队(小前台)+航母舰群(大中台)的组织结构方式,以促进管理更加扁平化。
十几人甚至几人组成的特种部队在战场一线,可以根据实际情况迅速决策,并引导精准打击。而精准打击的导弹往往是从航母群上发射而出,后方会提供强大的侦查火力后勤支援。如果中台没有办法承接前线的需求,前线就会不认可它的服务价值。
中台通常可以分为三个层面:业务层面,数据层面和技术底层。
业务中台:
业务服务将业务的公共需求组合成服务,比如电商公司:客户、商品、物流、支付就是公共需要;
比如汽车制造商:用户、车辆、订单、交付都是公共需求。将这些公共业务组合成统一的业务服务,供各个业务单元使用。
数据中台:
数据时代,业务中越来越依赖于数据,包含:数据的收集,数据处理,数据算法和分析,报表,以及数据的治理。
技术中台:
基础服务通常是底层的服务,面向技术。这些底层技术包括:安全认证、权限管理、流程引擎、门户、消息、通知等。这些组件通常与业务关联度不大,属于每个应用都需要使用的功能。
中台,是企业/行业的组织架构重构后的服务平台,如何构建智慧办公行业的中台?
传统的办公行业的供需模式由四部分组成:
在这个流程里面是没有中台,只涉及信息流、物流以及现金流。
在广阔而高度分散的线下市场,利用互联网搭建这些分散的商家难以自营的系统能力和数据能力,提升这些分散的商家的效率,成为整合服务的提供者,甚至产业中台,是当下一个结构性的机会。
1)建立中台组织
以智慧办公/会议行业中台组织为例:
中台组织将以SaaS作为基础,用NB/LoRa技术资源为行业提供赋能服务。
硬件厂家/研发机构可以通过API模块对接,迭代出基于NB/LoRa技术的生态链产品;已有PaaS平台的公司,通过软件API接口协议转换,把LoRa系统/产品融合在一起,成为行业解决方案;
2)建立架构:API激活ESB融合传统IT
3)建立基础共享服务,从用户管理、权限、流程、门户开始
4)建立数据中台
5)建立业务中台
在电子纸行业,结合中台能力,商业模式主要分两大类:长期战略、降本增效、直接获益。
卖中台和设备,但不靠中台和设备赚钱,只收个成本价甚至免费,占据入口或者获得一个资质,做长线,主要靠增值服务获益。
现在大部分公司的中台都在建设中,主要还是服务于内部用户,建中台的目的还是在降本增效,降低成本赋能前端,间接产生商业价值。
中台包括业务中台(应用)、技术中台(平台)、数据中台(数据)、组织中台(人),盈利模式可以单独售卖,也可以组合打包售卖。
1)业务中台(应用)
只有真正为客户解决问题,客户才更愿意为此付费。因此,从业务切入是一个不错的选择。
以美团的产业中台为例:
美团正在成为餐饮行业的产业中台,它为餐馆提供配送服务、流量及数据支撑。但是所有的餐馆都保持个体独立的发展,保留了自己的品牌,保持自我。
美团的流量并不封闭,用户购买哪个商家的菜品,可能来自美团的推荐,也可能因为用户本来就是这个商家的粉丝。
商家为什么要选择美团呢?
于是,美团就可以成为这些餐饮企业,数字智能部分的共享中台。
2)技术中台(平台)
这种模式在国内比较少,在国外做的比较好的是Dataiku,卖数据平台,做私有化部署。
优点:
边界清晰,成一单就收一单的钱,后续实施维护等成本较低。
缺点:
3)数据中台
可以卖支撑数据中台的数据平台,这部分可以参考技术中台。
可以卖数据,卖数据集、模型、服务,这部分需要慎重考虑合法合规问题,最佳输出方式还是数据服务 DAAS,这部分可以参考业务中台。
4)组织中台
组织中台不会单独售卖,它渗透在业务中台、技术中台、数据中台中。
业务解决方案、业务平台、数据平台的部署和实施,以及数据建设和规划等都离不开组织中台(人)。
曾鸣教授给中台这种模式起了一个名字叫S2B2C,S就是一个能提供系统的公司,它赋能很多的小B,就是小型企业,一起服务最终用户。结合在电子纸领域的独特优势,提供整体方案的同时,打造中台能力,着重提升自身核心竞争力。
作者:简约,公众号:简一商业
本文由 @简一商业 原创发布于CSDN,未经作者许可,禁止转载
三大文档 FSD一般包含在PRD
1.BRD一般是去向决策层汇报 2.产品介绍的各项是可选的 不是必备的
产品线路图就是roodmap。团队一般是偏技术的团队。
BRD案例。
痛点。定性的描述。不会非常细致。
当前的手段。
价值。
竞品。
计划与目标。
BRD的亮点。协调资源。
产品的功能结构。
转载于:https://www.cnblogs.com/newt/p/9218947.html
本篇文章以笔者负责过的一款硬件产品为例,解构硬件产品PRD文档写作标准,供大家参考学习。
案例涉及PRD流程、电子标签产品领域内容。
文章会涉及大量流程图示,电脑端查看效果更佳。
这也是产品三大文档的最后一篇,前期回顾:
BRD对应产品之道(方向目标),MRD对应产品之法(路径流程),PRD对应产品之器(物理实施)。
PRD文档的目的
BRD的目的是决定为什么要去做一件事情,MRD的作用是如何去做,提供一套方法与指导实施的文档。
而PRD直接面对研发设计人员,作用在于打磨产品,实现需求。
在网上看到过一个很形象的类比,分享给大家:
BRD:
唐僧出发前,参见唐皇(投资人),告诉唐皇西去取经的重要意义与大兴佛法的好处,唐皇答应并发放免签护照(授权),于是唐僧带着任务出发了。
MRD:
唐僧上路了,但是他需要选择走哪条路线,带几个人,为什么这么走,为什么带这些人,要说清楚:
A路线:妖怪多
B路线:神仙多
C路线:美女多
经过分析,唐僧决定选择C路线,所以才有了三打白骨精,路过女儿国等经典故事。
PRD:
获得了授权,而且已经确定了要走的路线,剩下的就是打造装备(产品)了。
需要把装备的需求给工匠(研发人员),就需要把PM对装备(产品)的要求讲清楚。
金箍棒:需要能缩短到耳朵里面,直径1毫米,长度6毫米,需要金色,重量必须控制在1KG;
九齿钉耙:必须要9个齿,废话啊,黑色,齿长8里面,把手长1.5米,直径2.5厘米;
于是工匠(研发人员)根据需求,打造出了旷世的武器。
由于研发人员专注于功能的实现与性能,所以他们对运营、市场、设计等表现相对不太关心,对于产品更多的了解来至于产品经理的产品宣讲。
设计人员更多的会关注与产品的调性与原型图,所以对PRD文档的需求是相对较弱的。
对于PRD文档来说,最主要的作用是把要做的事情讲明白,便于与研发设计人员的沟通,不需要过分强调呈现形式。
PRD文档常见的有两种形式:文字模式(Word、PPT、Excel皆可)、原型图模式,大家可以根据团队协作习惯,自行选择。
笔者喜欢使用PPT的形式来展现PRD,主要是便于演示,另外会结合Project和Axsure管理需求。
文档信息:
一款硬件产品往往涉及多部门协调,首先需要将任务排期表展示出来,这样研发设计人员会有一个基本的时间观念。
避嫌,仅做展示,产品示意图可以让大家对产品形态有一个基本认识。
图片来源:Indiegogo
新一代电子标签产品需要结合时代下的互联特性,满足用户基本使用需求的同时获取心理满足感,在提供基本标签展示功能的同时增加温湿度监测功能。
产品包括主控制器、低功耗蓝牙BLE模块、实时时钟RTC模块、温度传感器、湿度传感器、电子墨水屏显示模块、蜂鸣器、振动马达、按键、LED指示灯和电源控制模块。
产品通过低功耗蓝牙将微信端定制编辑的显示内容传送至电子墨水屏显示,更新任务或事件信息及时间节点;
通过RTC时钟模块保证时间的准确性,到达定时任务时间节点后,蜂鸣器语音提示、马达振动提示、LED灯光提示或组合提示方式。
提示方式也可以根据用户喜好自行设置,实现智能办公;
通过温湿度传感器模块持续监测环境温湿度变化并将温湿度信息显示在电子墨水屏上,方便用户了解室内温湿度情况。
学生场景:
场景1:必备物品清单(开学、日常物品清单等)
场景2:番茄工作法 – 专注学习、备考
上班族场景:
场景1:待办事项,消灭手机大堆“提示红点”;
场景2:生日、纪念日;
场景3:记事本,参考MAC的Day Plan;
老人&日常:
场景1:吃药提醒
场景2:记事贴(联系电话等)
场景抽象:便于研发设计固件结构及信息存储
电子标签作为一款硬件产品,首先需要让ID、结构和硬件工程师了解其硬件规格及组成。
整体规格框图:
硬件需求:
硬件组成框图:便于硬件工程师设计电路
产品特点:
结构特点:便于ID及结构工程师设计参考
性能参数:硬件、软件、结构设计参考
软件需求:
1、配对流程
第一次使用电子标签需要完成蓝牙配对,配对成功后便可以定制事件任务信息。
2、事件提醒
设置事件提醒,主要包括学习、家长会、旅游、吃药、做饭等提醒。
提醒设置包括:
是否开启提醒
事件名
提醒时间段,默认公历:年月日、时间点
重复:不重复、重复(天、周、月)
提醒间隔:无/分
提醒方式
示例:
家长会
2020-03-20 15:00 —— 2020-03-20 – 18:00
喝水提醒流程图:
吃药提醒流程图:
2、倒计时提醒
设置日期倒计时提醒,如高考倒计时、生日、纪念日提醒等。
提醒设置:
是否开启提醒
标题
重复:不重复、每周、每月、每年
提醒时间:当天、提前1天、提前3天、提前5天
默认按照公历设置日期:周重复设置星期数、月重复设置几号、年重复设置月和日
提醒方式
示例:
标题:生日提醒
重复:每年
提醒时间:当天
日期:11月12日
生日提醒流程图:
高考提醒流程图:
3、温湿度监测
持续监测室内温湿度变化,提醒用户随时调整,改善环境舒适度。
最佳室内温度范围:17℃ ~ 27℃;
最佳室内湿度范围:20%RH ~ 85%RH;
环境舒适度提示表情。
4、日历功能
支持显示日历信息,周、年、月、日、时间点信息。
日历信息
星期、月
几号
农历信息:如冬月初五
5、会议及待办事项
通过小程序或其它终端将视频会议、工作报表等重要事件添加为待完成事项在标签上展示,以便及时提醒。
提醒设置包括:
会议及待办事项
提醒时间:年月日、时间点
重复提醒:不重复、重复(每五分钟提醒一次)
结束时间:年月日、时间点
示例:
下午开会
2020-03-20 15:00
重复
2020-03-20 – 16:00
6、OTA升级
支持OTA升级功能,通过BLE升级设备固件。
升级信息
新版本推送通知
升级引导页面
升级过程设计
升级结束提示
由于这款产品设计时没有UI设计师,笔者则将原型设计和UI设计做到了一起,原型页面即最终版页面。
当然,在人员配置足够的情况下,不建议大家使用这种方式,否则会影响UI设计师的发挥。
下面仅展示配对流程:
硬件产品后续还会涉及生产、良品率等问题,每一个环节都可能决定产品的成败。
而精品之路更是难上加难,需要产品经理具备丰富的行业经验,一路踩坑,一路前行。
漫漫产品路,祝好~
作者:简约,公众号:简一商业
本文由 @简一商业 原创发布于CSDN,未经作者许可,禁止转载
在软件工业领域,有许多不同的需求文档类型,如 BRD,MRD,PRD,FSD,PSD,SRS,IRS等等。下面对这些文档进行简单的讲解。
商业需求文档——BRD(Business Requirements Document)
商业需求文档重点放在定义产品的商业需求,要说明产品能够解决的、客户碰到的一个或多个商业问题,然后提出建议解决方案——通常是用新产品或者改进现有的产品来解决这些问题。
BRD也可能包括一个高级的商业案例,例如收益预测、 市场&竞争分析、 销售/市场策略。 BRD通常是由产品经理,产品市场经理、商业分析师编写。在小公司,可能由高级主管或者甚至创始人撰写。 BRD通常是一份 1~3页 Word 文档,或者是不超过 10页的 PowerPoint 文档。
———————————————————————————————————————————————例子:
我们假设你的公司是开发一款客户关系管理(CRM)软件。BRD文档重点是放在销售经理面临的追踪所有进行中的交易和能够进行可靠的预测的问题上。文档中要说明:
1、谁遇到了痛苦: 财富500大公司的销售经理
2、是什么样的痛苦:无法实时的可视化交易状态 、无法创建可靠的预测报告
3、建议解决方案:创建一款基于 Web的软件,追踪交易和创建预测
市场需求文档——MRD(Market Requirements Document)
市场需求文档(MRD)重点是对这个被提议的新产品或现有的改进产品的市场需求进行定义。BRD 是要说明商业问题和提议解决方案,而 MRD 则是对提议解决方案的细节进行深入研究。它包括一些或者所有这些细节:
a. 解决商业问题所需要的特性
b. 市场和竞争分析
c. 功能和非功能需求
d. 特性/需求的优先级
e. 用例(Use cases)
MRD 通常是由产品经理、产品市场经理、商业分析师撰写。 MRD 通常是一份 5~25页 Word文档,或如后文中描述那样在一些公司中甚至更长。
———————————————————————————————————————————————
例子:
还是以上面提到的 CRM 软件为例,MRD 重点是放在说明需求和定义优先级,同时也描述用例。需求包括功能和非功能性需求:
功能需求:运行于 Internet Explorer(6.0及以上)和Firefox(1.5及以上); 必须使用SSL保障安全性; … ;用户应该能够通过浏览器界面输入数据:客户、公司、联系方式、机会、交易额,等等;
非功能需求 :必须支持最多 100,000用户同时在线; 必须使正常运行时间大于 99.9%; … ;有完整的英语、德语、日语的用户手册;
注意:有些公司将 MRD 和 PRD 组合为一个文档进行描述,并称之为 MRD。这时,MRD 也会包含后面提到的PRD中描述的内容。整个文档长度会大于 50页。
产品需求文档——PRD(Product Requirements Document)
产品需求文档(PRD)重点是对这个被提议的新产品或改进现有的产品定义产品需求。MRD 侧重于从市场需要角度看需求,而 PRD 侧重于从产品本身角度看待需求。通常在特性和功能需求上更深入细节的研究,并也可能包括屏幕截图和用户界面流程。
在 MRD中不包括具体详细需求和用例的公司中,PRD 就包含这些具体详细内容。 PRD 通常是由产品经理、商业分析师、产品分析师撰写。 PRD 通常是一份 20-50页 Word文档,对于复杂产品甚至会更长。
———————————————————————————————————————————————
例子:
让我们继续前面的关于开发一个 CRM软件的例子。PRD 文档重点会描述以下详细需求:
1、 登陆屏幕应该包括用户名和密码字段。也应该包含一个“忘记密码”的链接 ;
2、 “联系人”屏幕应该包含的字段有姓名、电话、email,… ;
3、 … ;
4、 “预测”屏幕应该有一个 5步骤的向导,引导用户一步步创建年度预测报告。每一步应该按照以下…
PRD 也可能包括详细的用例。
———————————————————————————————————————————————
提醒:一些公司将这里描述的PRD 和前面描述的 MRD 合并成一个文档,称为PRD。这时,PRD除包括本段描述的内容,也包括前面描述MRD 的内容,并且可能超过 50页。
功能规格文档——FSD( Functional Specifications Document)
功能规格文档(FSD)把焦点集中在实现,定义产品功能需求的全部细节。FSD 可能通过一张张的截屏和一个个特性来定义产品规格。这是一份可以直接让工程师创建产品的文档。
与 MRD 和 PRD 侧重于以市场需要和产品角度看需求不同,FSD 把重点放在让工程师实现的角度定义产品细节。FSD 也可能包括完整的屏幕截图和 UI设计细节。 FSD通常是由产品分析师、工程领导、项目经理撰写——作者通常属于工程部门。 FSD通常一个几十页的 Word 或类似文档。
最后要提醒各位的是,不同的公司对以上文档有不同的叫法和使用方法,具体还应该结合公司和产品的实际情况。本文中对产品需求文档的描述和解析仅作参考。