业务理解有偏差,产品和开发如何达成共识?

  1. 云栖社区>
  2. 云栖号资讯>
  3. 博客>
  4. 正文

业务理解有偏差,产品和开发如何达成共识?

云栖号资讯小编 2020-06-10 12:43:03 浏览401
展开阅读全文

云栖号资讯:【点击查看更多行业资讯
在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来!

image

阿里妹导读:在考虑如何对业务模型进行抽象从而建立领域模型之前,必须解决业务与产品、开发之间“沟通”的问题。如何让业务人员和开发人员顺畅沟通,在业务流程设计中不遗漏成败攸关的业务场景?如何才能让业务沟通的过程顺畅过渡到架构设计、编码乃至测试?阿里巴巴技术专家李建结合团队的实际案例,分享了他们在使用 Event Storming(事件风暴) 进行领域建模时的经验、收获和思考。

一 软件研发的困境

“失效”的语言交流

日常研发过程中不同角色经常需要进行各种交流:沟通业务需求、讨论产品原型、讨论设计方案等。每个环节不同角色反复沟通,这是研发过程非常重要的环节。但问题是:我们花费大量时间沟通,真的“说” 清楚了吗?

让我们看两个例子:

image

上面的两段对话发生在一次项目 Review 的过程中。通过第一个对话,我们能看出不同的角色在沟通的时候遇到了障碍;通过第二个对话说明即便是相同的角色,沟通在某种程度也遇到了障碍。

软件研发的困境

无论传统的瀑布流程还是敏捷模式,软件研发总体上能划分成几个阶段:提出需求,产品设计,研发,测试,最后上线。不同阶段会产出不同交付物,有些比较简单,也有些比较详尽:MRD,PRD,技术方案,验收方案等。在整个过程中,我们还会组织不同会议,或者是线下讨论。

image

大家想一想,在哪一个阶段暴露了最多的问题?

不管我们多么期望在早期发现问题,然而现实是越到研发晚期越会暴露更多问题。当产品进入测试阶段,当上线后真实数据开始跑起来,当业务同学开始使用产品,这时候问题会像泉水一样主动涌现出来,用户会反馈各种问题:“这个不是我想要的功能”,“XX 和我的预期不一样”等等。通常在软件研发的后期发现很多这种类似的问题。软件研发发展到今天,这个问题依然没有被很好的解决。

阻碍产品正确交付的原因

我们通过下面一个例子来分析什么原因阻碍了产品的正确交付。

image

当产品同学提出需求的时候,研发同学做了好的回应,但实际上双方想的内容并不一致,这种情况我们称之为表面一致;当产品上线后,产品同学提出需求疑问时,研发同学的回答充满了各种技术行话:定时系统,原子性等。显然大部分产品同学不能理解这些技术行话,对话进入停滞状态,我们称这种现象为沟通障碍。在软件研发中该问题反复的出现:沟通不畅阻碍了产品价值的正确交付。在不同角色进行交流时,三个原因阻碍了沟通的顺畅进行:

image

  • 得到的信息不同:产品同学和业务同学关注的是业务需求,市场情况,近中远期规划,以及运营数据等;开发同学关注的是一个个具体的需求列表,功能点,是实现层次的细节信息。
  • 思维方式不同:产品同学关注业务/需求的合理性,产品逻辑,用户体验;而开发同学关注方案的可行性,实施成本,系统稳定性等。
  • 沟通语言不同:产品同学用描述性的语言,语言的模糊会导致不同角色理解的不同;而开发同学习惯使用技术语言,SDK、数据库、一致性等。不同角色交流的时候,会因为语言不相容,沟通不到一起去。

由于以上的原因,沟通容易陷入“鸡同鸭讲”的窘境:讨论很热烈,甚至能取得表面的一致,实际并没有“说”清楚。

洞察软件研发困境

Event Storming 方法的发明者 Alberto Brandolini 认为:产品体现了程序员对业务的理解(或误解)。很多时候沟通失败导致的误解进入产品实现。于是真正的业务需求在产品中没有得到体现。沟通失败是软件研发的一个痛点,有待解决。

image

二 Event Storming

Event Storming 介绍

Event Storming(ES):由不同角色共同参与,用彩色贴纸进行交流的工作坊。

image

如上图,一群同学围绕一个业务场景,用贴纸进行交流,这就是 ES 工作坊。通过贴纸进行交流,让大家用同一种沟通语言,同一个思维方式,让大家的思维在一个频道上,这是 ES 的形式,也是 ES 的目的。

Event Storming 语法

ES 定义了一套彩色贴纸的“语法”:不同颜色的贴纸都有定义。浅黄色代表 Actor (角色)、蓝色表示 Command (命令)、粉色代表 Policy (业务规则)、浅粉色代表System(系统)、橙色代表 Event (事件),浅绿色表示 Read Model (读模型)、红色代表 HotSpot (热点/问题)。

image

用 ES 的语法表达用户的下单流程:买家 (浅黄色贴纸) 提交订单(蓝色贴纸),如果订单里商品是在线状态,购买量小于商品库存量 (粉色贴纸 Policy) ,那么订单创建成功(橙色事件贴纸),已创建的订单 (绿色贴纸) 展示给用户。订单创建后需要通知买家(业务规则,粉色贴纸),系统执行发送站内信(蓝色贴纸)。

image

如何在业务中使用 ES

下面我们通过一个业务场景(优惠券的投放和使用)介绍如何使用 ES。

业务背景介绍

电商网站提供各种优惠券:满减券,折扣券,有无门槛券。

image

下图描述电商运营小二在活动中投放优惠券的整体流程:小二先创建优惠券,然后再创建一个活动,把优惠券和活动关联起来。活动通过公司财务的审批后才可发布上线。消费者在活动页面领取优惠券,在下单流程使用优惠券抵消金额。最后活动结束时要对整体活动的数据进行统计分析。

image

准备 Event Storming

在开始 ES 前,先做好准备:

image

  • 准备物料:彩色贴纸、笔纸、一个足够大的房间等。房间里不要有椅子,因为在 ES 过程中,我们希望大家都全神贯注的投入,而不是坐在椅子上开始放松。
  • 邀请正确的人:有问题的人和有答案的人。程序员、交互设计师、测试等都是有问题的人,需要通过 ES 理解业务和产品;有答案的人通常是用户、业务或产品,他们通常能回答业务的背景,诉求和目标。

Event Storming 的过程

ES 可以分为开场介绍、ES 沟通业务和讲故事三个阶段。

开场介绍

在 ES 中有一个特殊的角色叫做 Facilitator(推动者),一般是 ES 的组织者。在 ES 开始前,Facilitator 向大家介绍 ES 是什么,有什么好处,以及彩色贴纸的用法。然后介绍讨论的范围和目标。

比如,今天讨论优惠券场景,目标是理清营销活动过程中优惠券的业务流程。最后 Facilitator 强调 ES 的规则:所有的讨论都写在贴纸上;不允许使用电脑,手机;也不允许坐下。在 ES 的后续过程中,Facilitator 还需要承担另外两个重要职责:保持参与者的专注,通过提问驱动交流。

image

ES 的方式沟通业务

第一步先梳理事件(橙色贴纸): 事件是已发生且重要的事情。事件必须是既成事实,且业务关注的事情。通常 Facilitator 会先准备第一个事件(可以是系统中任一事件), 然后把它贴到墙上。

image

假设第一个事件是:优惠券已领取。接下来 Facilitator 通过提问引导大家找到更多的事件:

  • 事件发生前有哪些事件(“优惠券已领取”前须先有“活动已发布”事件)?
  • 事件发生后下一个事件是什么(“优惠券已领取”后有“优惠券已使用”,“优惠券已过期”等事件)?

提问会引导参与 ES 的同学将新发现的事件不断补充到墙上。事件要保持整体的时间顺序:先发生的事情贴在左边,后发生的事情在右边。通常大家容易关注系统的正常流程,也就是 Happy path。这时候 Facilitator 需要引导大家关注业务的非正常流程 Unhappy path。边界条件,异常情况通常是业务复杂性的重要原因,也是非常容易被忽视的部分。

  • 事件一定会发生吗(优惠券一定领取成功吗?不是,贴上“优惠券领取失败”事件)?

追问 unhappy path 梳理出业务的完整视图,当大家发现新事件的速度接近停滞的时候,就应进入梳理业务规则的阶段了。

Policy,业务逻辑或规则,这是业务中最重要的部分。Facilitator 会提出以下问题:

  • 事件是否一定成功?如果不是,那么成功的前提条件是什么?
  • 该事件是否会导致其他事件的发生(Reaction)?

例如“活动已提交”事件:

  • 活动提交成功的前提条件:活动已关联有效优惠券,且已选择了生效方式,并且选择了适用人群。
  • 活动提交后,会导致审核任务已创建事件,这里的业务规则是:活动提交或需创建审核任务。

image

接下来找出三个角色:Actor (和系统交互的人),Command (用户动作) 和 Read Model (辅助用户决策的工具)。Facilitator 提出以下问题:

  • 是什么触发了事件?即事件发生的原因 (ES 的语法:when Event, then Command)。
  • 谁执行了动作。是人,系统,还是时间(例如定时触发的事件)?
  • 做出动作前,用户需要获取哪些信息?

以上的问题会引导大家找到 Actor, command 和 Read Model。 在营销活动已提交事件中:小二(Actor)执行了提交活动(Command), 从而产生了“活动已提交”事件。

image

最后介绍 Hotspot:业务痛点、瓶颈、模糊点。Hotspot 是 ES 过程中随时都应该发现并记录下来的。Facilitator 可以引导大家发现业务中未描叙到的问题,例如:用户使用优惠券进行支付的场景中,如果用户支付失败,已使用的优惠券该如何处理呢?优惠券应该返还给用户,还是不做处理?通过提出这样的问题,引导大家对业务流程进行更深入的讨论。通常在 ES 的过程中,识别并记录 Hotspot,不要在 ES 中尝试解决所有的 hotspot。

image

以上介绍了 ES 的主要元素:Event,Policy,Actor,Command,Read Model,Hotspot。用 ES 描述了优惠券发放的业务流程,最后一步是“讲故事” (storytelling) 的阶段。

讲故事

Facilitator 邀请不同的人担任志愿者,每个志愿者讲一段故事:按时间顺序和 ES 描叙的逻辑, 向其他人介绍业务流程。过程中,听众注意到不一致的地方随时提出问题,大家讨论问题,通过增加/删除/移动贴纸来修复问题,并继续讲故事的流程。

最开始大家会按时间正序讲故事,最后大家还可以倒序讲故事。梳理业务的异常场景,倒序讲故事的方法更有效。例如为什么会发生“优惠券领取失败”事件,事件的原因是 balabala…

经过讲故事阶段的完善,大家获得了业务的完整理解,这时候可以结束讨论,保存相关材料,遗留下来的 Hotspot 交由相关同学跟进。

image

Event Storming 常见问题

ES 比其他方式更能帮助大家顺畅的沟通,但是对于首次参与或组织 ES 的同学也有一些疑问。 以下列出一些常见问题:

Q:ES 通常邀请多少人参加?我需要邀请所有角色吗?

A:不一定。ES 鼓励不同角色共同参与,但是参与人的态度更重要,积极主动参与是 ES 成功的关键。通常一个 Pizza (8 - 10人) 的规模,是适合 ES 人数。

Q:我的业务场景和复杂,在 ES 中要梳理完整个业务流程吗?

A: 不需要。ES 需要大家高度参与,因此需要控制好时间。每次 ES 的范围选择复杂业务场景的一部分,保证 ES 的效果。

Q:我应该在什么阶段做 ES?

A:项目的任何阶段都可以做 ES。ES 既可用于梳理业务现状,也可以用于设计业务的未来方案。

Event Storming 小结

下面的四个图直观的解释了 ES 的作用:

image

  • 图 1,说明不同角色通过语言交流,虽然达成表面一致,实际上大家理解不一致。
  • 图 2,ES 要求大家通过贴纸的形式可视化出来脑海中的想法,从而使分歧自动显现。
  • 图 3,ES 通过不断的提问触发讨论,从而能够拉通认知,消除分歧点和模糊点。
  • 图 4,ES 拉通了大家对业务的理解,从而达成了真正的共识。

总的来说,ES 让不同的角色用同一种语言(彩色贴纸)从全局对业务达成共识。

从 ES 到代码

简单介绍下 ES 如何顺畅过渡到 DDD(Domain-Driven Design 领域驱动设计)。

提取业务概念

DDD 中最重要的是统一语言:交流使用统一语言;模型表达统一语言;代码表达统一语言。语言是由概念组成的,ES 的过程已经将概念写在贴纸上,并且在交流中反复使用。例如:优惠券,营销活动,已领取优惠券,领取方式,人群等。

一部分概念有生命周期,并且有唯一的标识符。例如:营销活动,优惠券,已领取优惠券。这些就是 DDD 中的实体;还有一部分概念标识一个完整的业务含义,但是没有生命周期,并且属性相同的两个对象可以替换,这些对象就是 DDD 中的值对象,例如:领取方式,生效方式,人群。

image

提炼模型

概念和概念之间是有关系的。比如说,优惠券和营销活动有关联关系,已领取优惠券是在某个营销活动下领取的,营销活动也包含很多信息,它的生效方式是什么,领取方式是什么,人群是谁。概念与概念之间的关系也就是领域模型。

image

从模型到实现

将 ES 贴纸重新组合:围绕一个核心概念,将与该概念有关的 Event,Command,Policy 组合在一起。例如下图左边围绕营销活动为中心重新组织了贴纸(Command,Policy,Event),这些贴纸和右边的代码映射起来,这也就是 DDD 中说的代码表达统一语言。到此,简单介绍了如何从 ES 到概念,从概念到模型,以及模型和代码实现是怎么关联起来的。

image

架构,代码和约束

下图简单描述应用架构,代码结构,以及如何通过 ArchUnit 实现架构约束。

image

四 总结

ES 的价值在于:不同角色在具体业务场景下用一种共同语言(彩色贴纸)进行交流,通过不断提问触发探索、讨论,最终达成真正共识。

【云栖号在线课堂】每天都有产品技术专家分享!
课程地址:https://yqh.aliyun.com/live

立即加入社群,与专家面对面,及时了解课程最新动态!
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

原文发布时间:2020-06-10
本文作者:李建
本文来自:“阿里技术公众号”,了解相关信息可以关注“阿里技术

网友评论

登录后评论
0/500
评论
云栖号资讯小编
+ 关注
所属团队号: 云栖号资讯