Yelp计费系统现代化改造:从遗留架构到行业标准的演进之路

本文详细介绍了Yelp如何通过两年多的跨组织协作,成功将其遗留计费系统现代化,解决了数据格式不一致问题,实现了与第三方收入自动化工具的集成,提升了财务准确性和系统可扩展性。

收入自动化系列:现代化改造Yelp的遗留计费系统

概述

本博客重点介绍Yelp如何成功实施一个多年期、跨组织的计划,以现代化其计费流程。目标是通过增强与第三方财务系统的集成能力,自动化其收入确认系统,同时保持用户期望的准确性和可靠性。

遗留系统挑战

当Yelp在十年前首次开发其计费系统时,数据库设计基于当时已知的需求。这些初始选择为计费系统奠定了基础,多个Yelp系统和流程都建立在此基础之上。然而,随着公司的发展,这些设计选择显然并不理想,并导致了各种挑战。

Yelp遗留计费系统的设计选择在公司寻求与第三方收入自动化工具集成时,由于数据格式差异而成为重大障碍。这种集成对于扩展Yelp的收入系统以匹配公司增长至关重要,目标完成日期为2024年7月。然而,Yelp独特的发票处理方式导致了不对齐,就像试图将不匹配的碎片拼入拼图一样。

为解决这些挑战,Yelp决定彻底改革其计费系统以符合行业标准。这一计划需要对业务关键系统进行更改,任何中断都可能产生严重后果,例如无法向客户开具账单或收费。执行此计划的复杂性最好用"在汽车仍在行驶时更换轮胎"的类比来描述。

技术问题分析

Yelp的遗留计费系统大约在十年前引入了"发票规避"概念,这导致客户的未付余额从一张发票结转到下一张。这一概念成为计费行为的核心,最近的发票反映了账户的总余额。

在Yelp的遗留计费系统中,付款只需应用于最近的发票,需要在付款和发票之间建立一对一关系。

几年后,我们意识到标准计费系统不会将余额从一张发票结转到另一张,这导致Yelp的解决方案与行业规范行为大相径庭。

在标准计费系统中,单次付款可以收集一次但应用于多张发票,允许付款和发票之间存在一对多关系。

这导致Yelp系统与任何其他标准计费系统之间的数据差异:

在Yelp的遗留系统中,针对1月、2月和3月的付款被错误地仅应用于3月的发票,导致收入记录在错误的收入期间,并且难以确定发票账龄。这种错误应用不仅影响付款,还影响其他概念,如贷项和借项备忘录。这些不一致也阻碍了Yelp与第三方收入自动化和其他财务工具的集成能力。

解决方案架构

为解决此问题,Yelp决定投资于更强大的计费模型,该模型符合当前需求并支持长期增长。新模型旨在:

  • 消除发票规避概念
  • 启用一对多关系,允许付款和贷项/借项备忘录应用于多张发票
  • 通过确保在特定收入期间内准确分配收入来纠正数据差异,从而提高财务准确性和报告

执行计划

实施此类更改需要50多人的团队两年多的协作努力,因为我们必须从根本上改变基础,然后在其上重建功能。因此,制定强大的执行计划是实现此计划成功交付的关键。

步骤1:需求收集

确保使用重要工程资源重新设计的系统不是短视的,并且真正符合业务需求至关重要。我们与业务利益相关者保持密切合作,确保收集正确的长期需求。

我们早期采用了领域驱动设计原则中的通用语言概念;模仿预先存在的会计术语,并依赖领域专家作为单一事实来源。凭借通用词汇表,我们能够在系统最终状态上达成高度共识。

步骤2:目标架构

为满足利益相关者概述的特定需求集,我们探索了行业中广泛使用的各种第三方解决方案。然而,没有现成产品能够完全满足所有新需求以及Yelp的现有用例。经过仔细考虑,我们决定开发专门针对我们业务模型的定制计费架构。

我们本可以选择修补现有系统,这可能看起来是更简单的解决方案。然而,这种方法带来了引入意外副作用的风险。相反,我们从计费架构的行业标准中汲取灵感来定义我们的目标状态。尽管目标状态代表了漫长的路线图,但我们承诺通过未来几个季度和多年的多个项目逐步朝着它前进。

步骤3:项目规划

识别依赖关系和执行顺序

定义目标架构后,我们规划了所有必要流程及其依赖关系。例如,要支持账户级付款收集,必须启用新的付款功能,实施账户级退款,并确保用户界面在账户级别准确显示付款和退款。我们根据利益相关者/业务需求对这些流程进行了优先级排序。

跨职能团队

处理这种规模的项目需要在多个系统中进行更改,涉及多个团队的参与。我们没有让每个团队在各自领域内负责工作,而是创建了多个由4-6名工程师组成的跨职能团队,每个团队分配给一个进行中的项目。我们称它们为老虎团队——专注、不可战胜且目标驱动!大多数团队在项目期间持续存在,任何时候都有2-4个团队并行工作,适应不断变化的优先级。

跨团队协调

指派了一名工程经理监督这些老虎团队,管理时间表、人员配备和优先级排序。引入了多个新流程来帮助工程经理管理这些跨职能团队:

  • 为老虎团队开发了新流程来进行冲刺计划,促进跨职能协作
  • 工程经理维护甘特图以跟踪时间表、人员配备和障碍
  • 设立定期同步会议以跟踪障碍

步骤4:增量交付

我们通过多次迭代交付较小的更改,真正理解了迭代开发的含义,始终确保我们提供最小可行产品。虽然我们有时在交付的功能数量上妥协,但我们从不交付未完成的功能。最初,我们将推出限制在不需要高级功能的一小部分客户。这种方法使我们能够在受控环境中确保正确性,同时在开发其他功能时继续支持这些客户。

步骤5:单A/B推出

我们没有对此项目中引入的单个功能进行A/B测试,而是选择向单一用户组增量发布新功能。这避免了管理多个实验的复杂性,并简化了关键指标的测量。

步骤6:用户验收测试

进行如此根本性更改的影响非常广泛。我们无法仅依赖自动化测试,因为技术更改影响了许多非工程团队的业务流程,包括财务、会计、客户支持、分析等。因此,我们决定对用户验收测试极其彻底,以测试系统和流程的正确性。

步骤7:系统可观测性

确保系统可观测性对于快速向所有客户推出基础性更改以满足公司2024年7月的收入自动化时间表至关重要。我们实施了多层方法来监控和维护系统的完整性:

  • 警报/日志记录和监控:设置全面的警报、日志记录和监控仪表板,提供系统性能和异常的实时可见性
  • 完整性检查器:开发完整性检查器作为最后一道防线
  • 利益相关者仪表板:为利益相关者创建仪表板,提供相关指标和见解

成功交付

尽管该计划需要50多人两年多协作的巨大努力,但通过遵循上述结构化执行计划,它成功交付。与Yelp关键系统的传统推出(通常涉及逐步发布)不同,我们采用了加速方法以满足与第三方收入自动化系统集成的紧张时间表。我们于2023年10月向一小部分客户启动了更新,并通过稳步提高推出速度,在2024年7月前实现了100%的客户采用。

对于我们组织来说,推出速度异常高,因为计费系统需要高准确性,且客户通常每月只收到一张账单,提供了有限的机会来验证更新的正确性。

该执行计划使我们能够在满足截止日期的同时确保无缝过渡,而不影响系统完整性或功能,这要归功于团队的奉献和跨职能协调。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计