В конце 2025 года эксперт Том Слендерс (Tom Slenders) из компании ASML представил инструмент и шаблон Platform Enablement Services Canvas с целью помощи организациям эффективно создавать и масштабировать внутренние платформы. В компании ASML шаблон используется как отправная точка для диалога с платформенными командами. Он помогает понять на чем они сосредоточены и что остается вне поля внимания и что можно улучшить.
Инструмент и шаблон Platform Enablement Services Canvas позволяет:
- Структурировать обсуждения с платформенными командами и их пользователями;
- Выявлять пробелы в платформенных сервисах в более широком контексте;
- Делать возможности и сервисы платформы прозрачными для стейкхолдеров;
- Синхронизироваться по направлениям развития платформы.
Автор отмечает, что шаблон особенно полезен при формировании новых платформенных команд, поддержке существующих команд в развитии их сервисов и выравнивании ожиданий и целей между командами и стейкхолдерами.
Шаблон состоит из 11 разделов, каждый из которых отражает одну ключевую возможность поддержки и развития (Enablement capability):
- Документация и база знаний (Documentation and Knowledge Base). Есть ли у пользователей доступ к нужной информации в нужный момент?
- Обучение и воркшопы (Training and Workshops). Эффективно ли пользователи обучаются инструментам и практикам платформы?
- Внедрение возможностей (Capability Adoption). Как мы поддерживаем пользователей во внедрении возможностей и сервисов платформы?
- Коммуникация и каналы обратной связи (Communication and Feedback Channels). Как мы информируем пользователей и собираем их обратную связь?
- Поддержка сотрудничества и инноваций (Collaboration and Innovation Support). Как мы используем сообщества для сотрудничества и развития инноваций между пользователями и платформенной командой или командами?
- Интерфейсы самообслуживания (Self-Service Interfaces). Какие возможности есть у пользователей для самостоятельного предоставления инфраструктуры и сервисов?
- Paved ways и другие шаблоны (Paved Ways & Other Templates). Есть ли у пользователей готовые и одобренные шаблоны и способы работы, которые упрощают старт и направляют их к стандартным практикам использования платформы?
- Техническая поддержка и управление инцидентами (Technical Support & Incident Management). Какая техническая поддержка платформы организована, и как команды потребители выстраивают собственную поддержку?
- Инструменты поддержки SDLC (SDLC Enablement Tools). Какие инструменты предоставляются пользователям для поддержки жизненного цикла разработки программного обеспечения?
- Ограничивающие механизмы (Guardrails). Какие ограничивающие механизмы, включая безопасность, контроль затрат и соответствие требованиям, внедрены, и как пользователи получают обратную связь?
- Мониторинг и аналитика (Monitoring & Analytics). Как пользователи формируют инсайты по своим нагрузкам на платформе и интегрируют их с собственными инструментами наблюдаемости?
Использование шаблона Platform Enablement Services Canvas начинается с тщательной подготовки. Важно заранее определить круг участников: к обсуждению стоит привлекать платформенные и продуктовые команды, архитекторов, специалистов по безопасности, продакт менеджеров и других заинтересованных сторон. Работа с шаблоном предполагает достаточный уровень зрелости фасилитации и понимания платформенных возможностей, поэтому его может использовать опытный разработчик, технический agile коуч или технический лидер, способный на высоком уровне объяснить содержание каждой области. До начала сессии необходимо зафиксировать цель: это может быть оценка текущих возможностей, выявление пробелов или совместное формирование бэклога для улучшений. В качестве инструмента можно использовать распечатанную версию шаблона или цифровую доску, например Miro, MURAL или любой другой Whiteboard.
Воркшоп рекомендуется строить вокруг 11 сервисных областей, представленных в шаблоне. Сессию целесообразно начать с краткого введения и фиксации целей, затем перейти к картированию текущего состояния, чтобы определить, какие сервисы уже предоставляются. После этого обсуждаются потребности и пробелы, позволяющие выявить недостающие или недостаточно используемые возможности и сервисы. Отдельный этап посвящается приоритизации улучшений, а завершается встреча определением следующих шагов и назначением ответственных. Такая структура позволяет сохранить фокус и обеспечить переход от обсуждения к конкретным действиям.
Каждый раздел шаблона отражает одну ключевую возможность поддержки и развития. При этом логика расположения разделов выстроена так, что сверху находятся сервисы, наиболее близкие к пользователям, а ниже — возможности, относящиеся непосредственно к самой платформе и ее технологической основе. Это помогает увидеть баланс между пользовательским опытом и внутренними платформенными механизмами.
После обсуждения необходимо провести анализ и расставить приоритеты. Для этого можно использовать различные техники, например Dot voting. Важно отделить быстрые улучшения, которые можно реализовать в короткий срок, от инициатив, требующих более длительных инвестиций и системных изменений.
Работа с шаблоном не должна ограничиваться одной сессией. По итогам необходимо сформировать бэклог инициатив, закрепить ответственность за каждое направление и договориться о регулярном пересмотре, например ежеквартально, чтобы отслеживать прогресс и актуальность выбранных решений.
Для фасилитаторов важно использовать шаблон как инструмент повышения осознанности о необходимых возможностях при создании или развитии платформенной команды. Следует поощрять кроссфункциональное взаимодействие, поскольку развитие платформы затрагивает не только саму платформенную команду. Шаблон рекомендуется рассматривать как живой артефакт, который обновляется по мере эволюции платформы, а также адаптировать под контекст конкретной организации, учитывая ее зрелость, структуру и стратегические приоритеты.
Подробное описание сервисных разделов с примерами:
Документация и база знаний (Documentation and Knowledge Base). Есть ли у пользователей доступ к нужной информации в нужный момент?
Примеры:
- Комплексные материалы в формате самообслуживания (Self-service);
- Руководства, FAQ и инструкции по устранению неисправностей (Troubleshooting manuals);
- Портал самообслуживания с доступом к руководствам и лучшим практикам (Best practices).
Обучение и воркшопы (Training and Workshops). Эффективно ли пользователи обучаются инструментам и практикам платформы?
Примеры:
- Онбординг-сессии для новых пользователей и команд;
- Практические воркшопы по инструментам, сервисам и возможностям платформы;
- Регулярные вебинары, сессии обмена знаниями и поддержание обучающих программ.
Внедрение возможностей (Capability Adoption). Как мы поддерживаем пользователей во внедрении возможностей и сервисов платформы?
Примеры:
- Полная программа внедрения с обучением и парным программированием (Pair programming) с экспертом;
- Поддержка на этапах анализа и проектирования решений;
- Встраивание инженеров в команды для консультаций и проведения ревью кода (Code review).
Коммуникация и каналы обратной связи (Communication and Feedback Channels). Как мы информируем пользователей и собираем их обратную связь?
Примеры:
- Выделенные каналы коммуникации, например, в Mattermost, Slack или Teams;
- Рассылка обновлений платформы через новостные и почтовые рассылки;
- Регулярные встречи для сбора обратной связи во время PI, Sprint review, опросов и других активностей.
Поддержка сотрудничества и инноваций (Collaboration and Innovation Support). Как мы используем сообщества для сотрудничества и развития инноваций между пользователями и платформенной командой или командами?
Примеры:
- Стимулирование инноваций через хакатоны и совместную работу;
- Создание или использование существующих сообществ (Communities of Practice, CoP) для обмена и развития лучших практик;
- Признание команд за вклад в развитие платформы.
Интерфейсы самообслуживания (Self-Service Interfaces). Какие возможности есть у пользователей для самостоятельного предоставления инфраструктуры и сервисов?
Примеры:
- Интерфейсы самообслуживание через CLI или API;
- Порталы самообслуживания для потребления сервисов.
Paved ways и другие шаблоны (Paved Ways & Other Templates). Есть ли у пользователей готовые и одобренные шаблоны и способы работы, которые упрощают старт и направляют их к стандартным практикам использования платформы?
Примеры:
- Шаблоны для быстрого старта пользователей;
- Paved ways или golden paths, направляющие пользователей к предопределенным и предварительно одобренным способам работы.
Техническая поддержка и управление инцидентами (Technical Support & Incident Management). Какая техническая поддержка платформы организована, и как команды потребители выстраивают собственную поддержку?
Примеры:
- Многоуровневая поддержка (L1, L2, L3) и On-call;
- Формализованные процедуры управления инцидентами (incident management);
- Поддержка 24/7 для критических инцидентов.
Инструменты поддержки SDLC (SDLC Enablement Tools). Какие инструменты предоставляются пользователям для поддержки жизненного цикла разработки программного обеспечения?
Примеры:
- Преднастроенные CI/CD конвейеры для автоматизации;
- Автоматизация тестирования, развертывания и отката изменений;
- Интеграция CI/CD конвейеров с сервисами платформы.
Ограничивающие механизмы (Guardrails). Какие ограничивающие механизмы, включая безопасность, контроль затрат и соответствие требованиям, внедрены, и как пользователи получают обратную связь?
Примеры:
- Преднастроенные политики безопасности и автоматические проверки;
- Уведомления при приближении к бюджетным лимитам;
- Автоматизация проверок соответствия требованиям (Compliance) в конвейерах развертывания.
Мониторинг и аналитика (Monitoring & Analytics). Как пользователи формируют инсайты по своим нагрузкам на платформе и интегрируют их с собственными инструментами наблюдаемости?
Примеры:
- Дашборды в реальном времени для мониторинга использования и производительности;
- Отслеживание потребления API и состояния систем;
- Регулярные отчеты о производительности платформы.
Шаблон Platform Enablement Services Canvas приведен ниже: