Паттерны организационного дизайна в AvitoTech: от обратного манёвра Конвея до платформенных команд
Организационная структура инженерных подразделений не может создаваться один раз и на всю жизнь компании. Когда продукт меняется, выстраивает новые бизнес-направления или сталкивается с технологическими ограничениями, прежняя схема распределения людей начинает тормозить разработку. Руководитель разработки Авито Недвижимости Игорь Гранщиков в практическом руководстве для блога AvitoTech обобщил опыт трансформации команд, показав, как выбор организационных паттернов зависит от стадии зрелости продукта, ограничений по ресурсам и целевой архитектуры.
Главная оптимизационная цель современного организационного дизайна — максимальное устранение внешней когнитивной нагрузки. Внутреннюю сложность решаемой инженерной задачи убрать невозможно, а полезная когнитивная нагрузка необходима инженерам для построения ментальных моделей и обучения. Однако внешняя нагрузка — постоянные межкомандные согласования, размытые зоны ответственности, ожидание решений от смежников и переключение контекста — напрямую снижает скорость поставки ценности.
Обратный манёвр Конвея и командные домены
В основе проектирования современных инженерных организаций лежит закон Конвея, который гласит: архитектура создаваемых систем повторяет коммуникационную структуру самой организации. Если три независимые группы специалистов работают над одной программой без чёткого разделения обязанностей, создаваемая система неизбежно превратится в монолит с тесно связанным кодом и постоянными конфликтами при слиянии веток.
Обратный манёвр Конвея предлагает перевернуть эту последовательность. Сначала инженеры и архитекторы проектируют целевую архитектуру системы, разбивают её на автономные домены с высокой внутренне связностью и слабой внешне связанностью, а затем под эти домены формируются изолированные команды. Каждая команда получает полную ответственность за свой домен — будь то отдельный сервис, пользовательский экран или инфраструктурный пакет.
Этот подход наиболее эффективен в период стабильного роста продукта, когда традиционное увеличение числа разработчиков перестает приносить пропорциональный прирост производительности. Если же организация находится в фазе поиска идеального соответствия продукта рынку, жёсткая компонентная нарезка может оказаться вредной: на раннем этапе важнее гибкость перераспределения ресурсов, чем строгое закрепление границ.
Платформенный подход и сервисный контракт X-as-a-Service
По мере увеличения числа продуктовых команд возникает необходимость в общих возможностях: системах авторизации, инфраструктуре развёртывания, инструментах наблюдаемости или сервисах рассылки уведомлений. Если позволить продуктовым командам самостоятельно разрабатывать эти компоненты или напрямую вносить изменения в чужой код, организация быстро завязнет в хаосе согласований.
Решением становится разделение команд на продуктовые и платформенные с использованием паттерна X-as-a-Service (всё как сервис). Продуктовые команды фокусируются на доставке ценности конечным пользователям. Платформенные команды объединяют сложную внутреннюю экспертизу и предоставляют её другим подразделениям через фиксированные контракты: программные интерфейсы (API), библиотеки (SDK) или готовые инфраструктурные сервисы.
При таком подходе платформенная команда не превращается в очередной центр согласований, куда нужно писать в личные сообщения с просьбой выполнить задачу вручную. Её ценность заключается именно в создании понятного интерфейса самообслуживания и документации, позволяющих другим разработчикам использовать платформенные возможности без личных контактов и ожиданий. Яркими примерами такого подхода в мировой практике стали портал Backstage в Spotify, платформы наблюдаемости в Netflix и известный сервисный мандат в Amazon, предписавший командам взаимодействовать исключительно через публичные интерфейсы.
Разрешение проблемы легаси через паттерн Strangler Fig
Одной из самых сложных задач для растущего бизнеса остаётся проведение масштабных архитектурных изменений без остановки действующего сервиса. Попытки полностью переписать старую систему с нуля требуют гигантских инвестиций и часто заканчиваются неудачей, так как старый монолит продолжает развиваться параллельно.
Для безопасной миграции в организационном дизайне применяется паттерн Strangler Fig (инжир-душитель). Существующая легаси-система закрывается единым программным фасадом, который перехватывает все поступающие запросы. Новые модули и функции разрабатываются за пределами старого контура в виде изолированных сервисов с новыми автономными командами. Фасад постепенно перенаправляет трафик со старых компонентов на новые.
Этот подход решает одновременно техническую и организационную проблему. Новые команды защищены от погружения в технический долг монолита и развиваются по современным стандартам. Старая система поэтапно уменьшается в размерах, пока полностью не уступит место целевой архитектуре.
Размер команд, распределённый менеджмент и компетенции
Эффективность команд существенно зависит от их размера. Автор отмечает эффект Рингельмана: при увеличении группы индивидуальный вклад каждого участника имеет тенденцию снижаться из-за усложнения внутренних коммуникаций. Оптимальным размером компактной группы считаются 3–5 человек, а известное правило Amazon «двух пицц» задаёт эвристический диапазон в 5–10 участников.
Однако дробление большого отдела на компактные группы требует решения вопроса с управлением. В руководстве предлагается раскладывать менеджмент на четыре составляющие: работа с людьми, развитие домена, техническая архитектура и управление процессом поставки. Доменную экспертизу может забрать продуктовый менеджер или аналитик, процессы — мастер процессов, а техническую часть — архитектор. Единственная функция, которую нельзя полностью распределить без потери качества, — это непосредственная забота о людях, их профессиональном росте и мотивации.
Для оценки готовности команд к организационным изменениям полезно использовать квалификационные карты. Карта компетенций показываем текущие навыки инженеров, а тепловая карта — потребности целевой архитектуры. Расхождение между ними формирует точный план обучения и найма.
При выборе между универсальными командами фич (Feature teams) и компонентными командами важно учитывать стадию проекта. Команды фич берут задачи из общего бэклога и работают с разными частями системы, что идеально для быстрого тестирования гипотез. Компонентные команды обеспечивают глубокую экспертизу и высокое качество стабильных модулей.
Четыре сценария подбора оргструктуры
Практический фреймворк предлагает выбирать организационные паттерны исходя из двух ключевых осей: уровня стабильности продукта и режима финансирования бизнеса.
В условиях стабильного продукта и растущих ресурсов приоритетом становятся обратный манёвр Конвея, платформенные команды и четкая топология доменов. Если ресурсы ограничены, но продукт стабилен, эффективнее использовать компактные команды с вынесением общих функций (DevOps, автоматизированное тестирование, релизные процессы) в единые сервис-группы.
Для фазы поиска новых направлений при ограниченных ресурсах лучшим выбором остаются универсальные команды фич с единым бэклогом и широким нормативом управления. Если же компания проходит этап масштабной трансформации и замены устаревших систем при наличии инвестиций, необходимо комбинировать паттерн Strangler Fig с организационной изоляцией новых продуктов от legacy-контура.
Главный вывод исследования заключается в том, что идеальной универсальной схемы не существует. Руководителям разработки следует регулярно оценивать очереди на согласование, количество межкомандных встреч и скорость поставки задач, чтобы вовремя адаптировать организационную структуру под меняющиеся задачи бизнеса.