Запуск платформенных команд

Константин Евтеев из компании X5 FoodTech, в своем выступлении на конференции Saint TeamLeadConf 2021, поделился опытом создания платформенных команд и процессов для достижения максимальной эффективности и скорости.

В докладе даны ответы на следующие вопросы:

• Масштабирование архитектуры и оргструктуры при росте компании. В докладе описан переход от небольшого набора команд и сервисов к существенно более сложной архитектуре и количеству команд. Рост был связан с резким изменением бизнес-планов и нагрузки, а также необходимостью перестроить сервисную архитектуру под новые реалии. Ключевым вызовом стало одновременное масштабирование архитектуры и команд с сохранением управляемости, понятных границ ответственности и предсказуемых процессов взаимодействия;
• Как учитывать и применять закон Конвея. Константин разобрал, что архитектура неизбежно отражает коммуникации оргструктуры, и поэтому целевую архитектуру нужно поддерживать целевой структурой команд. В докладе был упомянут маневр Конвея как практический прием: сначала спроектировать структуру организации под желаемую архитектуру, чтобы уменьшить количество лишних связей между командами и сократить неэффективные взаимодействия;
• Какие есть показания к применению подхода Team Topologies. В докладе перечислены признаки, что текущая топология перестает работать: команда становится больше 15 человек, планирование начинает упираться в вопрос "кто может сделать", растет незавершенная работа из-за функциональных зависимостей, увеличивается количество интеграций и инцидентов на стыках, а также ухудшается переиспользование и перенос решений между частями системы. Отдельно отмечалось, что при росте сложности продуктовые команды теряют целостное видение end-to-end сценариев.
• Как выбрать целевую топологию, исходя из размера компании и инженерной зрелости. В докладе был показан ход рассуждений от целевой архитектуры к набору команд, которые должны закрывать группы сервисов и продуктовые домены. Константин опирался на типы команд из подхода Team Topologies: Stream-aligned команды для доменов, Platform team для предоставления capabilities как сервиса (например, база как сервис, деплой как сервис), Enabling team для исследования и передачи практик, Complicated-subsystem team для специализированных подсистем. Также были упомянуты способы взаимодействия (collaboration, facilitation, as a service) и необходимость понимать текущую позицию организации по шкале "размер и сложность продукта" и "зрелость инженерной культуры", чтобы выбирать реалистичный путь эволюции;
• С какими вызовами столкнулись продуктовые команды и как помогли платформенные команды. В докладе показан типовой сценарий: продуктовая команда, решая доменную задачу, сталкивается с техническими блокерами (авторизация между сервисами, асинхронное взаимодействие, построение бизнес-транзакций), реализовывает решение и затем вынуждена поддерживать его как для себя, так и для других команд. В результате время команды уходит в технические решения вместо продукта. Для решения платформенные команды забирают на себя развитие и поддержку платформенных продуктов, а продуктовые команды сохраняют фокус. Подчеркивался эффект экономии на масштабе: чем больше продуктовых команд, тем сильнее выгода от платформенных команд;
• Как снижать когнитивную нагрузку с продуктовых команд. В докладе когнитивная нагрузка связывалась с ростом количества доменов и постоянным переключением контекста. Переход к доменным командам снижает переключения, а платформенные команды дополнительно снимают с продуктовых команд необходимость глубоко разбираться в инфраструктурных и кросс-доменных решениях. Отдельно был приведен пример, как не надо строить платформу: много разрозненных команд эксплуатации, отсутствие единой точки входа, необходимость согласований и запросов по почте, слабая наблюдаемость и непрозрачные причины проблем;
• Применение продуктового подхода в платформенных командах и улучшение DX. Константин подчеркнул, что платформа должна ускорять продуктовые команды и конкурировать по удобству с доступными рыночными и open source решениями. Платформенный продукт должен иметь понятную точку входа и скрывать внутреннюю сложность, а также развиваться через цикл коммуникации: заранее рассказывать, что делается и зачем, собирать обратную связь, делать прозрачные итерации и вовлекать команды;
• Как перейти от команды эксплуатации в платформенную команду и что учитывать при переходе. В докладе было отмечено, что команда инфраструктуры часто состоит из инженеров эксплуатации, перегруженных разнородными задачами и инцидентами, с неясными приоритетами, из-за чего продуктовые команды вынуждены ждать. Переход к платформенным продуктам предполагает выделение "как сервис" capabilities и команд вокруг них (например, CI/CD как сервис, мониторинг как сервис, тестирование как сервис). Также подчеркивалось, что enabling команда не должна делать за продуктовые команды: ее задача обучить и передать практику так, чтобы команда могла поддерживать решение самостоятельно. Отдельно упоминались Team API как инструмент описания миссии, зоны ответственности, каналов коммуникации, SLA ожиданий и целей команды, а также необходимость усиления команд зрелыми инженерами и, при необходимости, привлечения внешней экспертизы для запуска команд и процессов;
• Применение и выбор OKR для платформенных команд. В докладе OKR рассматривались как частный случай прозрачного целеполагания. Был описан контекст: у продуктовых команд горизонт планирования около месяца-полутора, а у инфраструктурных и платформенных команд поток задач разнообразен и легко уводит в несвязанные активности. Прозрачное целеполагание помогает выравнивать приоритеты между командами, снижать неопределенность, мотивировать инженеров и связывать работу платформы с потребностями бизнеса.

Подробнее в записи выступления и презентации:

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

Не забывайте подписываться на наш канал Enabling.team Insights, чтобы оставаться в курсе технологических трендов.