Mimecast → Team Topologies: 150 инженеров, 15 команд, 12 месяцев

Контекст: кибербезопасность и компонентные команды

Mimecast — компания в сфере кибербезопасности, которая предоставляет защиту электронной почты, архивирование и управление угрозами для бизнеса. В описываемый период организация насчитывала 150 инженеров в 15 командах.

Команды Mimecast строились по компонентному принципу: каждая команда владела набором сервисов или компонентов. Команда A отвечала за сервисы 1, 2 и 3. Команда B — за сервисы 4, 5 и 6. Логика разделения следовала техническим границам, а не бизнес-доменам и не потоку ценности для клиента.

Проблема: зависимости и когнитивная перегрузка

Компонентная модель создавала два связанных эффекта.

Зависимости между командами. Большинство пользовательских фич пересекали границы нескольких компонентов. Чтобы доставить фичу, менеджер координировал работу трёх-четырёх команд: одна меняла API, вторая — фронтенд, третья — базу данных, четвёртая — интеграцию. Даже мелкие изменения порождали цепочки зависимостей, вызывали путаницу и задержки.

Разбросанность продуктового знания. Ни одна команда не понимала фичу целиком. Каждая команда знала свой кусок: «мы отвечаем за API-слой, что происходит дальше по цепочке — спросите команду B». Продуктовое знание размазывалось тонким слоем по нескольким командам, и собрать полную картину мог только тот, кто опрашивал всех участников.

Когнитивная нагрузка на инженеров росла. Каждый разработчик держал в голове контекст своих компонентов, плюс интерфейсы с соседними командами, плюс процесс координации изменений. Инженер тратил время на встречи, синхронизацию и ожидание, вместо того чтобы писать код и доставлять ценность.

Решение: реорганизация по Team Topologies

Инженерное руководство Mimecast обратилось к книге Team Topologies Мэтью Скелтона и Мануэля Пайса как к фреймворку для реорганизации (подробнее о модели — в главе про Team Topologies). Ключевая идея книги: организуйте команды вдоль потоков изменений, а не вдоль технических компонентов.

Определение доменов

Первый шаг: Mimecast определил домены. Вместо компонентного деления команда руководителей выделила бизнес-домены, ориентированные на клиента. Каждый домен представлял поток ценности: что-то, за что клиент готов платить или что напрямую влияет на пользовательский опыт.

Четыре типа команд

Mimecast распределил свои 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, обработка данных.

Измерение когнитивной нагрузки

Mimecast измерял когнитивную нагрузку через процесс, похожий на оценку задач в Agile. Для каждого домена команда руководителей присваивала уровень сложности: low, medium или high. Это напоминало оценку в t-shirt sizes, которую команды используют для пользовательских историй. Если домен получал оценку high, руководители смотрели, можно ли разбить его на два домена с меньшей нагрузкой.

Результаты

Mimecast проводил реорганизацию в течение 12 месяцев внутри одного «swimlane» — одного направления инженерной организации.

Переход на доменные stream-aligned команды снизил количество межкомандных зависимостей для доставки фич. Команда, отвечающая за домен, могла провести изменение от идеи до продакшена без координации с тремя-четырьмя другими командами.

Стейкхолдеры на всех уровнях оценили новую модель: инженеры, delivery-менеджеры и продакт-менеджеры выбрали доменный подход перед компонентным. Продакт-менеджеры получили чёткого адресата для своих запросов: конкретную stream-aligned команду вместо размытого «нескольких команд, которые участвуют в фиче».

Проблемы при внедрении

Mimecast честно описал трудности. Компания провела реорганизацию в одном swimlane, а не во всей организации. Работа, которая пересекала границы swimlane, не получила преимуществ новой модели. Команды внутри реорганизованного swimlane взаимодействовали по новым правилам, но их коллеги за границами swimlane продолжали работать по-старому. Это создавало путаницу на стыках.

Некоторые домены оказались слишком крупными для одной stream-aligned команды. Руководителям пришлось итеративно пересматривать границы доменов и перераспределять ответственность.

Уроки

Пробуйте на одном участке, потом масштабируйте. Mimecast не реорганизовал все 15 команд одновременно. Компания выбрала один swimlane, провела эксперимент, собрала обратную связь и на основе результатов планировала расширение. Этот подход снижает риск: если что-то пошло не так, последствия локальны.

Когнитивную нагрузку можно измерить грубо, и этого достаточно. Mimecast не изобретал сложную метрику. Простая шкала low/medium/high дала достаточно информации для принятия решений. Если домен «heavy» — бей на части. Если «low» — можно объединить с соседним.

Компонентные команды создают зависимости по определению. Любая фича, которая проходит через несколько слоёв (фронтенд, API, база), требует координации нескольких компонентных команд. Stream-aligned команда владеет всеми слоями для своего домена и устраняет эту координацию. Цена: дублирование компетенций между командами. Выигрыш: скорость доставки.

Границы swimlane создают свои проблемы. Partial adoption работает как эксперимент, но создаёт трение на стыках. Команды внутри нового swimlane и команды снаружи говорят на разных языках и работают по разным процессам. Планируйте расширение заранее, чтобы переходный период не затягивался.

Team Topologies — фреймворк, а не инструкция. Книга Скелтона и Пайса даёт модель мышления о командах: типы команд, виды взаимодействий, когнитивная нагрузка. Mimecast адаптировал эту модель под свою ситуацию: 150 инженеров, кибербезопасность, компонентная история. Другая компания адаптирует иначе. Слепое копирование чужой структуры команд без понимания собственного контекста принесёт больше вреда, чем пользы.