我们像代码一样重构文化
Source: Woowahan Tech
团队介绍
商务网页前端开发团队（以下简称“商务前端团队”）负责外卖骑手（배달의민족）所有商务服务与平台，以及从后台管理系统到物流系统的整个网页客户端领域，是一个规模庞大的团队。原本负责不同服务的团队汇聚成一个大团队，迈出了开启外卖骑手所憧憬的商务新篇章的坚定步伐。
刚上任的新人团队长很快意识到，单凭个人难以承担如此庞大组织的复杂度。幸好商务前端团队中有许多有能力且愿意帮助团队的成员。我们认同“带领团队的不是人，而是共同打造的文化”，于是组建了一个像代码一样持续重构的“文化领航小组”。
今天，我们想从“组织结构”“沟通方式”“记录体系”三个视角，分享商务前端团队与文化领航小组一起扫除低效、构建更好结构的思考过程。希望正在组建团队、制定文化，或因陈旧代码导致的低效而迫切需要重构的团队，能从我们的得失中获得一点帮助。
一个目标，灵活的组织：无边界的分部
商务前端团队既是追求技术深度的功能组织成员，又兼具负责各业务任务的目标组织属性。能够和谐地兼顾这两种角色是团队的重要特征。
然而，仅由约 20 人规模的前端开发者组成的团队，要高效处理业务任务和工单一直是难题。让全体成员聚在一起制定计划既会分散注意力，又会消耗大量时间。单一团队的沟通成本已经逼近上限。最终不得不将团队拆分为多个分部，但“如何”拆分成为最大的难题。
摒弃低效的拆分方式
在思考如何让规模化团队高效运转时，我们面前摆着一个宏大的目标——“ONE COMMERCE”。这是一项需要在技术层面和体验层面整合外卖骑手内部散落的 B 超市、外卖商店等多种商务服务的复杂任务。
为实现目标，我们首先审视了常规的组织构成方式。但很快发现，几种传统的拆分方式反而阻碍了我们追求的“整合”和“灵活性”。
- 按项目拆分：任务发生的时间和规模不规律，导致某些时段只有少数分部承担大量工作，资源不均衡。
- 按页面/漏斗拆分：以漏斗（客户阶段体验）为基准划分后，成员对自己负责页面之外的领域了解不足，难以把握整体服务流程。
- 服务 vs 后台拆分：仅把团队简单二分，阻断了相互交流，难以产生协同效应。
通过分析这些问题，我们找到了一个共同根源：成员被过度绑定在特定业务域上。固定角色的僵化结构成为在快速变化的业务环境和整合任务中缺乏灵活性的最大障碍。
为此，我们决定创建无边界的分部。去除专职分区的围栏，让全体成员能够围绕“ONE COMMERCE”这一统一目标，随时灵活移动，不受业务域限制。
从 R＆R 到 R＆E：责任与可扩展性
无边界的分部要正常运作，需要改进传统的 R&R（Role & Responsibility）方式。我们提出了 R&E（Responsibility & Expandability） 这一新方向。
“不设工作边界，问题到底解决”为优雅兄弟（우아한형제들）的工作原则 Own It 的精神相通。它意味着不局限于分配的角色，而是超越责任、打破边界、扩展工作范围，互相帮助。
实际工作流程如下：
- 业务请求 → 团队长‑分部长同步
- 在三个分部中挑选合适的分部进行分配
- 在分部内部通过无边界协作灵活填补空缺
与组织目标相符的成果
灵活的组织结构成为将 “ONE COMMERCE” 目标落地的关键钥匙。无边界分部能够覆盖所有产品，识别服务间的域差异，实现真正的整合，效果显著。
- 在 B 超市与外卖商店的商品卡片·详情页整合、API 结构统一过程中展现了优势。
- 若仍由各服务单独负责，了解遗留代码和对齐规格将耗费大量时间。
- 通过无边界分部，成员能够广泛共享各服务的域背景，从全局商务视角审视结构。
- 大胆剔除重复逻辑，抽象为公共模块，确保代码库一致性，构建稳固的整合架构。
业务成果转化为成员成长。团队成员不再局限于单一服务，而是同步学习从 UX 到后台数据流的全链路域知识。这大幅提升了 Bus Factor，即使关键人员缺席，其他人也能快速接手，形成安全的组织结构。
此外，分部轮换与广泛的代码评审让大家与不同同事合作，保持新鲜感与学习动力。
成长的痛点与克服
实验性的组织结构并非完美，我们为补足现实问题并行开展了以下工作。
知识碎片化与依赖性
覆盖范围广导致难以记住所有上下文，且对特定人员的依赖风险上升。为此我们强化 ADR（Architectural Decision Record） 文化，将知识从“人”转移到“文档”。详细内容稍后展开。
上下文切换的困难
为降低频繁任务切换带来的疲劳感，尽量让同一成员负责连续的后续任务。大型任务采用两人配对或通过每周时间共享 ADR 内容，使非负责人也能随时了解上下文并投入。
防止分部之间的孤岛化
分部仅是任务分配的单元，禁止为分部单独制定规则。好的尝试会快速在全团队共享，推动共同进步。
超越结构的沟通重构
为解决 20 人团队的低效与僵化，我们找到了 “无边界分部” 与 “R&E” 这两把钥匙。灵活的结构让成员拓展边界、交流知识，在大型项目中也能保持强大的机动性。
然而，仅仅重构组织结构（硬件）并不能让系统完美。随着分部边界的消失、角色的扩展，成员需要掌握的上下文呈指数增长，进而产生新的沟通与协作瓶颈。
要让 20 个人像一个有机体一样运转，需要配套的新沟通协议。于是我们再次对 沟通方式 进行重构。
重构带来的副作用消解
首要解决的是 上下文共享。团队成员之间的距离既近又远。一起攻克同一任务的成员沟通紧密，而旁边做其他任务的成员则可能感觉像是另一个团队。
传统的每周例会（Weekly）是连接团队的重要环节。但随着 R&E 扩大了责任范围，需要在例会上讨论的上下文增多，导致会议时间延长。20 人每人发言，会议时长轻易超过 2.5 小时，注意力也随之下降。即使转到 Slack 线程，热烈的讨论也难以持续。
“烤盘”：最容易燃起讨论的地方
我们把 GitLab Issue 用作技术讨论专用空间，并取名为 烤盘。把问题贴到烤盘上会在 Slack 频道收到提醒，感兴趣的成员随时加入。
GitLab Issue 与代码评审环境相似，提供表格、视频、图片、代码等多种编辑工具，并支持指派人、标签、截止日期等上下文信息。与 Slack 线程不同，Issue 随时可查，讨论不会消失。
烤盘的优势
- 不遗漏时机：随时发布，无需等待会议安排。
- 与每周例会衔接：将 2‑3 天的讨论要点在例会上简要提及，后续讨论继续在烤盘进行。
因此每周例会时间缩短至原来的一半左右，会议更加专注。
请帮忙审阅 MR
团队 Slack 频道每天都会出现 “请审阅 MR（Merge Request）” 的信息，这是大多数开发团队都会碰到的问题。代码评审能够帮助成员了解其他任务的上下文和整体服务，是实现 R&E 目标必须解决的关键环节。
Codezilla：只要给一根香蕉就不会被抢走
代码评审之所以需要“文化”这个词，是因为单靠强制难以长期维系。我们开发了 Codezilla（코질라） 这款 Slack Bot，将激励与最低限度的强制结合。
- 自动检测当天未进行任何代码评审的成员并在频道提醒。
- 根据评审难度贴上 High 标签，评审者完成后可获得 香蕉 奖励。
- 获得香蕉的成员次日可免除一次代码评审义务（即 1 天 1 代码评审）。
引入 Codezilla 后，未完成的 MR 数量平均降至 10 条左右，MR 合并时间也压缩至 2‑3 天。但随着时间推移，这一机制仍需调适。若名字长期出现在频道，成员会产生免疫，必要时会考虑向上级组织渠道扩展。
不停留在昨日方式的团队
商务前端团队不仅在功能开发上持续重构，也对工作方式本身进行不断迭代。工作流程越熟悉，低效越容易被隐藏，“我们一直这么做” 的说法也会自然出现。我们正是对这类惯性保持警惕。只要是因为“熟悉”而被保留下来的结构、流程，就会被质疑；把繁琐的例行事务、记录方式、重复性工作逐一挑出来重新设计，持续进行实验。
例行事务也要重构：重复工作的再设计
例行事务随着时间容易僵化。冲刺会议或每日例会（Daily）也是如此。起初它们帮助团队对齐节奏，但久而久之往往只剩形式。（以下内容将在后续更新）