Mimecast → Team Topologies: 150 инженеров, 15 команд, 12 месяцев
Как Mimecast реорганизовал 15 команд по принципам Team Topologies и снизил когнитивную нагрузку на инженеров
Контекст: кибербезопасность и компонентные команды
Mimecast — компания из сферы кибербезопасности: защита электронной почты, архивирование и управление угрозами для бизнеса. В описываемый период — 150 инженеров в 15 командах.
Команды строились по компонентам: каждая владела набором сервисов. Команда A — сервисы 1, 2, 3. Команда B — сервисы 4, 5, 6. Линии разделения шли по техническим границам, а не по бизнес-доменам или потоку ценности.
Проблема: зависимости и когнитивная перегрузка
Компонентная модель давала два связанных эффекта.
Зависимости между командами. Большинство пользовательских фич пересекали границы нескольких компонентов. Чтобы выкатить фичу, менеджер координировал три-четыре команды: одна меняла API, вторая — фронтенд, третья — базу, четвёртая — интеграцию. Даже мелкие изменения превращались в цепочки задержек.
Размазанное продуктовое знание. Целиком фичу не понимала ни одна команда. Каждая знала свой кусок: «мы отвечаем за API-слой, что дальше — спросите команду B». Полную картину собирал тот, кто обходил всех участников.
Когнитивная нагрузка инженера росла: контекст своих компонентов, интерфейсы с соседями, процесс согласования изменений. Время уходило на встречи, синхронизацию и ожидание.
Решение: реорганизация по Team Topologies
Инженерное руководство Mimecast взяло за основу книгу Team Topologies Мэтью Скелтона и Мануэля Пайса (подробнее о модели — в главе про Team Topologies). Ключевой тезис книги: команды стоит выстраивать вдоль потоков изменений, а не вдоль технических компонентов.
Определение доменов
Первый шаг — определить домены. Вместо компонентного деления руководство выделило клиенто-ориентированные бизнес-домены. Каждый домен — поток ценности: то, за что клиент готов платить или что прямо влияет на пользовательский опыт.
Четыре типа команд
Все 15 команд распределили по четырём типам из Team Topologies:
Stream-aligned teams (потоко-ориентированные команды) получили end-to-end ответственность за домен. Такая команда владеет всем стеком — от фронтенда до базы — и доставляет фичу без согласований с соседями.
Platform teams (платформенные команды) взяли общую инфраструктуру и shared-сервисы. Их задача — снять когнитивную нагрузку со stream-aligned команд. Разработчик из stream-aligned команды дёргает платформенный сервис через self-service API, в устройство сервиса не вникает.
Enabling teams (помогающие команды) подтягивали stream-aligned команды к новым технологиям и практикам.
Complicated subsystem teams (команды сложных подсистем) владели участками с глубокой специализацией: криптография, machine learning, обработка данных.
Измерение когнитивной нагрузки
Когнитивную нагрузку оценивали процессом, близким к agile-оценке задач. Каждому домену присваивали уровень сложности: low, medium или high — по аналогии с t-shirt sizes для пользовательских историй. Если домен попадал в high, руководство смотрело, можно ли разбить его на два домена полегче.
Результаты
Реорганизация шла 12 месяцев внутри одного «swimlane» — отдельного направления инженерной организации.
Переход на доменные stream-aligned команды снизил количество межкомандных зависимостей для доставки фич. Команда домена доводила изменение до продакшена без согласований с тремя-четырьмя соседями.
Новая модель понравилась стейкхолдерам на всех уровнях: инженеры, delivery- и продакт-менеджеры выбрали доменный подход перед компонентным. У продакт-менеджеров появился чёткий адресат — конкретная stream-aligned команда вместо размытого «нескольких команд, участвующих в фиче».
Проблемы при внедрении
В Mimecast трудности описали честно. Реорганизация прошла в одном swimlane, а не по всей организации. Работа, которая выходила за его границы, выгод не получила. Внутри swimlane процессы поменялись, снаружи остались прежними — это давало путаницу на стыках.
Часть доменов оказались слишком крупными для одной stream-aligned команды. Границы доменов и распределение ответственности пересматривали итеративно.
Уроки
Сначала на одном участке, потом масштабировать. Все 15 команд одновременно не трогали. Один swimlane, эксперимент, обратная связь — и только затем планы расширения. Подход снижает риск: если что-то идёт не так, последствия локальны.
Когнитивную нагрузку можно мерить грубо, и этого хватит. Сложную метрику Mimecast не изобретал. Шкала low/medium/high дала достаточно информации для решений. Heavy домен — бить на части, low — можно слить с соседним.
Компонентные команды порождают зависимости по построению. Любая фича через фронтенд, API и базу требует координации нескольких компонентных команд. Stream-aligned команда владеет всеми слоями домена и снимает эту координацию. Цена — дублирование компетенций. Выигрыш — скорость доставки.
Границы swimlane создают свои сложности. Partial adoption годится как эксперимент, но даёт трение на стыках. Внутри нового swimlane и снаружи говорят на разных языках и работают по разным процессам. Расширение стоит планировать заранее, чтобы переходный период не затягивался.
Team Topologies — фреймворк, а не инструкция. Книга Скелтона и Пайса даёт модель мышления: типы команд, виды взаимодействий, когнитивная нагрузка. Mimecast адаптировал её под свою ситуацию — 150 инженеров, кибербезопасность, компонентная история. Другая компания адаптирует иначе. Копирование чужой структуры без понимания собственного контекста вредит больше, чем помогает.