Коротко: рекомендую гибридную модель «stream‑aligned + platform + enabling» (Team Topologies) с кросс‑функциональными «племенами/tribes» и централизованными платформой и общими службами. Ниже — структура, какие функции централизовать/децентрализовать и поэтапный план перехода.
1) Предложенная структура (вкратце)
- Исполнительная команда: CEO, CPO, CTO, COO, CFO.
- Племена (tribes): каждая отвечает за продуктовую область/горизонтальную бизнес‑линию. Внутри — потоково‑выравненные (stream‑aligned) команды (squads).
- Платформенная организация: платформа инфраструктуры/CI‑CD/данные/аутентификация/SDK — сервис для всех stream‑teams.
- Enabling teams: временные команды для внедрения новых практик/технологий (performance, security enablement, ML).
- Chapters/Functional leads: сквозные компетенции (backend, frontend, QA, UX, data) для практик и найма.
- Shared services: финансы, юридический, HR, безопасность, procurement.
2) Размеры и разбивка (рекомендации)
- Общая численность: $300$.
- Число племен: примерно $4\text{–}6$ племен (чтобы каждое племя было $30\text{–}60$ чел).
- Размер команды (squad): $5\text{–}9$ человек (плюс продукт‑ и технический владельцы).
- Платформенная команда(s): несколько команд, каждая $6\text{–}10$ человек, по областям (infra, data, auth, billing).
3) Что централизовать и почему
- Централизовать:
- Инфраструктура и CI/CD, общие библиотеки, observability — для снижения дублирования и ускорения delivery.
- Безопасность, соответствие (compliance), риск‑менеджмент — единые политики и ответственность.
- Финансы, юридический, procurement, payroll — эффективность, контроль затрат.
- Data platform & governance — единая семантика данных, качество и аналитическая база.
- Identity, billing, core‑services (ядро продукта), если они обслуживают множество команд.
Причина: эти функции дають инфраструктурный рычаг, уменьшают когнитивную нагрузку команд и ускоряют принятие решений на уровне продукта.
- Оставить децентрализованными (в командах/племенах):
- Приоритезация продуктовых фич, roadmap, UX/дизайн, эксперименты A/B.
- Взаимодействие с клиентами, продажи и CS (территории/вертикали), локальные адаптации.
- Непосредственная реализация фич и инкрементов — быстрые независимые решения.
Причина: высокоскоростная адаптация к клиентским требованиям требует автономии.
4) Управление границами ответственности и решениями
- Ясные Decision Rights (RACI) для: roadmap vs platform changes vs infra ops.
- SLA/SLO платформы: например, реакция на инцидент, время доставки изменений платформы.
- Архитектурный совет (ARB) — lightweight, встреча 1× в неделю или по необходимости для критических решений.
- Метрики: lead time, deployment frequency, MTTR, time‑to‑decide по ключевым типам решений.
5) План перехода (этапы и сроки)
- Этап 0 — мгновенные меры (1–2 недели)
- Назначить временного операционного/технического лидера (COO/Head of Platform).
- Провести срочный аудит «узких мест» в принятии решений (сбор примеров задержек).
- Этап 1 — оценка и дизайн ( $4$ недели )
- Карта продуктов, команд, процессов; выделение кандидатов в племена.
- Определение наборов платформенных услуг и SLA.
- Согласование Decision Rights и KPI.
- Этап 2 — пилот ( $8\text{–}12$ недель )
- Запуск $1\text{–}2$ племен в новой модели + платформа для них.
- Формирование chapters для практик.
- Оценка результатов: скорость принятия решений, delivery rate, эпик‑lead time.
- Этап 3 — поэтапный rollout ( $12\text{–}20$ недель )
- Расширение на остальные племена, настройка взаимодействия платформы и enabling teams.
- Настройка бюджетирования, HR процессов (перераспределение ролей, рекрутинг).
- Тренинги для product owners, tech leads по новой модели.
- Этап 4 — стабилизация и оптимизация (после rollout, постоянный)
- Формализация ARB, регулярные ретроспективы организационных KPI.
- Автоматизация платформенных потоков, измерение экономии времени.
Итого ориентировочный горизонт: $24\text{–}36$ недель от старта оценки до стабильного состояния (в зависимости от скорости исполнения).
6) Практические советы для снижения рисков
- Начинайте с пилота: одна продуктовая область + платформа для неё.
- Фиксируйте SLA/SLIs для платформы и измеряйте.
- Поддерживайте сквозную коммуникацию (town‑halls, docs, decision logs).
- Сохраняйте механизмы координации (еженедельные product councils) — автономия с синхронизацией.
- Убедитесь, что показатели эффективности (включая удовлетворённость команд) отслеживаются и корректируются.
Если нужно, могу прислать схему ролей/матрицу RACI для ключевых решений или подробный чеклист по пилоту.