Больше, чем просто увеличение штата: как Центр компетенций (CoE) превращает команды в «фабрику программного обеспечения»

Проблема: почему «больше» обычно означает «медленнее»

Когда бэклог растет, естественным желанием становится добавление еще одной команды. Но увеличение штата без изменения структуры лишь умножает затраты на координацию, не увеличивая при этом объем выпускаемой продукции.

Подумайте, как это выглядит на практике. Три команды создают собственные коннекторы к CRM организации, потому что нет общего каталога и не у кого спросить. Старший разработчик тратит две недели на интеграцию, которую другая команда завершила в прошлом квартале. Новое приложение выпускается с совершенно другим шаблоном UX, потому что не было руководства по стилю, на которое можно было бы сослаться. А без рекомендаций о том, как команды должны взаимодействовать друг с другом, по умолчанию возникает тесная связанность. Появляются прямые зависимости, которые кажутся удобными в создании, но дорогими в обслуживании. Когда одна команда меняет внутренний сервис, у нее нет способа узнать, сколько других команд только что сломалось. Это может показаться проблемой коммуникации, но на самом деле это архитектурная проблема.

Каждый из этих примеров — симптом одной и той же проблемы. Вы масштабируете количество людей, не масштабируя систему, в которой эти люди работают.

Стройте фабрику, а не толпу

Структурный сдвиг, который необходимо совершить, чтобы изменить всё, проще, чем кажется. Вы создаете набор команд для управления и Центр компетенций (CoE) и начинаете управлять «фабрикой программного обеспечения». Это означает проведение четкой границы между двумя типами работы.

Ваши команды доставки сосредоточены на создании и поддержке приложений, необходимых бизнесу. Они ориентированы на такие домены, как финансы, операции, клиентский опыт, и их задача — выпускать продукт. Ваш CoE, напротив, не владеет дорожной картой продукта. Он владеет фундаментом, который делает выпуск быстрым и последовательным для всех остальных. Это включает в себя повторно используемые компоненты, общие стандарты, конвейеры и защитные барьеры, включая Agent Guardrails.

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

Превратите своих экспертов в множители силы

Возникает соблазн назначить своего лучшего архитектора на самый сложный проект. Сопротивляйтесь этому инстинкту. Внедрение старшего эксперта в одну команду доставки запирает его знания в одном месте; однако они гораздо ценнее, когда достигают всех ваших команд.

Когда вы переводите этого человека в CoE, его роль фундаментально меняется. Его оценивают уже не по коду, который он пишет, а по возможностям, которые он создает для всей организации. На практике это означает:

• Владение централизованным руководством по стилю UI, на которое ссылаются команды
• Определение ядра общих сервисов для стандартных интеграций, таких как аутентификация, уведомления и аудит-логирование
• Проведение архитектурных обзоров до того, как проблемы попадут в продакшн
• Поддержка CI/CD конвейера, где автоматизированы проверки качества.

Один отличный архитектор, масштабированный на десять команд, неизменно превосходит одного отличного архитектора в одной команде.

Выберите модель, которая подходит вашей организации

Не существует единственно верного способа структурировать CoE. Это связано с тем, что модель должна соответствовать тому, как ваша организация принимает решения. На практике постоянно встречаются три шаблона.

Централизованный CoE хорошо работает в регулируемых отраслях, где последовательность не является опциональной, таких как финансовые услуги, здравоохранение и государственный сектор. CoE устанавливает стандарты, а команды работают в их рамках. Децентрализованная модель подходит для небольших или высокоавтономных организаций, где CoE функционирует скорее как внутренний консалтинг и уровень координации, чем как управляющий орган.

Для большинства предприятий федеративная модель, или «ступица и спицы» (hub and spoke), как правило, обеспечивает правильный баланс. Стандарты управления и архитектуры находятся в центре, а отраслевая экспертиза внедрена в бизнес-подразделения. «Ступица» определяет защитные барьеры, а «спицы» адаптируются к ним. Если вы не уверены, с чего начать, это обычно правильный вариант.

Фреймворк возможностей для руководства на этом пути

Создание CoE — это путь, а не проект. Организации, которые делают это хорошо, как правило, фокусируются на четырех областях возможностей, рассматривая их как прогрессию зрелости, а не как контрольный список для выполнения по порядку.

Производительность разработки стоит на первом месте: создание общих компонентов, стандартов кодирования и автоматизации конвейеров, которые позволяют командам двигаться быстро, не накапливая технический долг. Отсюда фокус смещается на время до получения ценности, сокращая расстояние между бизнес-идеей и работающей функцией в продакшне. По мере взросления фабрики приоритетом становится надежность: обеспечение того, чтобы рост не происходил за счет безопасности, устойчивости или соответствия требованиям. И через все это проходит опыт внедрения, потому что инструменты и шаблоны, предоставляемые CoE, должны быть достаточно хорошими, чтобы команды хотели их использовать. Если они пытаются их обойти, вам следует вернуться к чертежной доске.

Вывод: масштабируйте систему, а не только штат

Организации, которые масштабируются, инвестируют на раннем этапе в систему, в которой работают люди, включая стандарты, общие компоненты, модель управления и культуру повторного использования.

CoE — это способ сделать эти инвестиции конкретными. Перестаньте спрашивать «сколько еще разработчиков нам нужно?» и начните спрашивать «как нам построить систему, в которой любое количество разработчиков сможет добиться успеха?». Превратите своих экспертов в коучей, выберите модель, которая подходит вашей организации, и целенаправленно двигайтесь к ней. Именно так набор команд становится «фабрикой программного обеспечения».

Готовы увидеть эти принципы в действии? Не пропустите эту эксклюзивную сессию, где клиент OutSystems раскрывает ощутимое влияние своего пути с CoE. Посмотрите сессию здесь.

Руи Мадалено — опытный архитектор с сильным фокусом на корпоративной архитектуре и архитектуре решений. Обладая более чем 20-летним опытом работы в сложных, постоянно развивающихся ИТ-средах, он преуспевает в решении сложных задач и объединении разнообразных технологий в сплоченные, высокопроизводительные системы. Будучи частым спикером, он известен своей устойчивостью, преданностью делу и стремлением к обучению. Он также преодолевает разрыв между ИТ и бизнесом благодаря четкой коммуникации, лидерству в управлении проектами и командами, а также страсти к исследованиям и постоянному совершенствованию.

Посмотреть все публикации этого автора