复盘:B端应该如何撰写BRD?

凉凉Lxy
4 评论 18732 浏览 76 收藏 8 分钟
🔗 产品经理的职业发展路径主要有四个方向:专业线、管理线、项目线和自主创业。专业线是指沿着技能线不断提升自己..

编辑导语:BRD,即商业需求文档,指的是基于商业目标或价值所描述的产品需求内容文档(报告),其核心的用途就是用于产品在投入研发之前,是由企业高层作为决策评估的重要依据。对于产品经理来说,对于BRD一定都不陌生。那么,B端应该如何撰写BRD呢?

原本我只是负责产品设计,因为公司流程、人力资源紧张等等的复杂原因,在最近 2 周接手一个新任务,协助业务方进行 BRD 产出。

怀着紧张与期待,终于在昨日通过 BRD 的评审,大大的舒了一口气。正好做一个 B 端 BRD的复盘,分享给各位。

一、BRD 定义

BRD 是英文” Business Requirement Document “的缩写,也就是”商业需求文档“,指的就是基于商业目标或价值所描述的产品需求内容文档(报告)。

BRD 主要给产品、运营、研发、财务、老板等管理层人看的,决定是否要开始某个产品,是否要给你的项目投资源、人力、物力。

二、BRD 与 PRD 的关系

PRD 是英文”Product Requirement Document“的缩写,也就是”产品需求文档“的意思, PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。

PRD 是非常具体的产品设计方案,涉及到交互、文案、逻辑规则等说明,主要给研发、交互设计师、运营、用户等查看的,用来体现产品逻辑、功能、性能、交互设计等。

结合 BRD 的定义,两者的关系简单来说,BRD 决定要不要做,PRD 是决定做成什么样。先决定要做了,才会有 PRD 的产出。

通过 BRD 和 PRD 的双重审核,可以很好的避免伪需求带来的资源浪费。

三、BRD 如何写

在我们这个环境里,BRD 的要求是要将背景、收益、目标、需要的能力说清楚讲明白。也就是为什么要做,值不值得做,做了有哪些好处,需要怎么做。

背景是从现状、问题来出发,那这些来自哪?

——可以是业务方直接提供的结果,也可以是自己主动参与业务调研收集而来的各种问题。

现状要紧扣要解决的问题,不要扣过大的帽子。比如,要做一个局部迭代优化,那现状描述要围绕这个局部里业务上存在什么问题,而不是说整个业务上存在哪些不足。

收益上,建议是量化指标,但是在 B 端存在诸多无法量化的情况,那采用定性的描述也是可以的,比如降低借款坏账风险。

需要的能力,主要包括流程上需要哪些调整、涉及了哪些系统的哪些方面进行优化。主要是一个大致的描述,不会像 PRD 里那样详细。

在第一次负责的 BRD 中,涉及到了审批金额、审批流的调整、以及三个系统的打通。审批流中的金额比原来高了 5 倍,所以在原有业务、财务审核的基础上,提高了审批人的级别,增加了必要的复审环节,防控坏账风险。

撰写 BRD 的模板也非常重要,通过研发小哥哥的支援,找到了一个非常合适的框架,也分享给大家。包括但不限于问题描述(why)、期望目标、解决方案(What & How)、预期收益(ROI)和附录。

四、BRD Review过程中发现的问题

第一版 BRD 写完之后,leader review时指出了如下问题:

  • 背景中的帽子扣得过大(上文中已经提到);
  • 流程是最原始、旧的版本,而不是最新的流程;
  • 要解决的问题中有一个根本不存在,有一部分预期收益,在此次优化中也不能体现。

这些问题的原因,写 BRD 的经验不足是一方面,更多的是对业务理解不足、了解不深。没有找到正确的人、没有找到核心问题,只听别人说而没有自己再去想。

五、PRD & BRD 协作过程中发现的问题

在 BRD 定稿之后,由产品同学进行产品设计。这次负责产品设计的同学是位实习生,陆陆续续提出了小 20 个问题,包括审批流中各个节点的角色是做什么的,各个系统间是如何配合的,实际的使用者是如何完成工作的等等。

有些问题,是 BRD 里已经考虑到的,有些问题是我也没有注意到的,通过四处联络,终于全部搞定,同时也对复杂的业务链路有了一个更清晰的认知,PRD 是对 BRD 的一次细化和审核。

六、BRD 评审过程中发现的问题

昨天进行了BRD的评审,由业务负责人主讲,我和另一位小伙伴旁听。

评委在过程中提出了2个问题,一个是业务问题,这块业务主要是做什么的;另一个是说此次涉及的流程调整,在之前刚刚调整过,为什么又要调整。

第一个问题反映出,一个公司中不是所有人都会了解所有业务,下次写 BRD 时,需要有用户视角,方便评审快速了解业务背景。

第二个问题反映出,关注业务的大佬们可以轻轻松松、一针见血的指出问题。所以需要对业务非常熟悉,才可以在评审时气定神闲的对答如流。

旁听的我和小伙伴挺紧张的,但业务负责人答得特别溜。气势足、胆子大,非常重要,向业务方小姐姐学习。

最终评审顺利通过~~

七、参与 BRD 的收获

写 BRD 最大的感受是,非常锻炼逻辑、整体全局的思考,而不像 PRD 聚焦于产品的落地方案。

即便没有很多的文字,没有高保真的图,仍然需要花费非常多的时间梳理整体的逻辑。只有言之有物,经得起推敲,才能说服各位评审、各个业务合作方一起协作,一起解决问题。

八、最后

第一个 BRD 经过 2 周的打磨,终于评审通过;第二个 BRD 已经完成,等待各位大佬的评议;第三个 BRD 已启动调研。

成为 BRD 的专家,成为 为业务解题的专家,还远么?

不远~~

 

本文由 @凉凉Lxy 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 有模板吗?可以分享一下,或者有什么实例可以介绍介绍

    来自安徽 回复
  2. 您好,可否分享下文档,或者深入交流下 哈哈哈

    来自北京 回复
  3. 能不能分享一下最终结构呢

    来自辽宁 回复
  4. 你好,模板怎么获取呢

    来自浙江 回复
专题
14482人已学习13篇文章
用户体验是用户在使用产品过程中建立起来的一种纯主观感受。本专题的文章分享了如何撰写用户体验报告。
专题
15967人已学习12篇文章
本专题的文章分享了交互设计文档的撰写指南。
专题
39319人已学习11篇文章
世间万物皆有套路,面试更是如此,多拿几个靠谱offer。
专题
18156人已学习14篇文章
批量导入是用户在工作中经常需要用到的功能。本专题的文章分享了批量导入的设计思路和优化思路。
专题
18030人已学习13篇文章
本专题的文章分享了小程序介绍、小程序搭建、优化设计规范和功能设计指南
专题
12204人已学习12篇文章
数据管理系统在后期能够为企业提供基础数据服务,保证企业往更好的方向运营。本专题的文章分享了如何做好数据管理。