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

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

版权声明:本文源自 网络, 于,由 楠木轩 整理发布,共 2215 字。

转载请注明: 复盘:B端应该如何撰写BRD? - 楠木轩