Представьте типичную продуктовую команду. У них все просто и понятно: вот бэклог, вот новые фичи, вот спринты, а в конце довольный бизнес считает прибыль. Метрики эффективности прозрачны: выпустили фичу вовремя, и если за ней не последовал шлейф багов, все молодцы.

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

Команда Платформы и ее продукт

Меня зовут Станислав Решетнев, я руковожу отделом разработки в Sape (направление Link Building). Внутри нашей структуры есть та самая команда Платформы, которая упрощает жизнь продуктовым командам.

Чтобы понять особенности их работы, давайте посмотрим на цели команд:

Продуктовые команды VS платформенная команда

Основным продуктом команды Платформы является IDP (Internal Developer Platform) — набор инструментов разного уровня, обобщенных лучших практик, сервисов и т.п. Его главная цель — упростить и ускорить процесс создания, тестирования и запуска программного обеспечения. IDP можно понимать достаточно широко, и меня всегда радует, что здесь есть простор для творчества.

*Разработчик из продуктовой команды любуется просторами техстека*

Задачи у Платформенной команды бывают разные, разделим их условно на четыре типа.

1. Поиск универсальных решений для рутины, которая раздражает разработчиков

Например:

быстрое разворачивание микросервиса;
написание OpenAPI-спецификаций через ИИ-агента;
автоматизированная отправка технических метрик и т.п.

2. Поиск точечных решений проблемы продуктовой команды

Например:

сделать ИИ-бота, оставляющего комментарий с решением бага на основе решений из предыдущих тикетов;
создать нейро-ревьюера.

3. Ускорение цикла разработки SDLC через аналитику

Если процесс разработки прозрачен и хорошо отслеживается (логируется время, отмечаются переходы статусов тикета «В работу», «В ревью»), можно ускорять цикл разработки SDLC, приглядевшись к аналитике. Причем платформизация (сама система IDP) уже делает процессы более универсальными и ускоряет этапы разработки.

4. Обеспечение актуальности техстека

С одной стороны, это может показаться задачей DevOps. Но что, если речь идет не о переходе на новую мажорную версию базы данных, а о ее замене на другую? Это уже не просто обновление, а пересборка архитектуры.

А что, если у команд возникла потребность в чем-то принципиально новом, например, в автомасштабируемой базе данных, чтобы не беспокоиться об объемах хранения? В таком случае команда Платформы берет на себя всё:

провести исследование;
создать рабочий прототип;
качественно запустить новую БД;
провести обучение;
написать документацию;
передать мониторинг админам;
отдать SRE-отделу алгоритм диагностики проблем и реагирования.

Постановка целей на год по OKR

Наша компания уже некоторое время работает по методологии OKR (Objectives and Key Results), и мне было интересно продумать, как команда Платформы может не отставать от других отделов и тоже ставить перед собой амбициозные цели. У разработчиков всегда много идей, а текучка способна поглотить любое количество ресурсов. Хотелось сделать так, чтобы команда Платформы вносила свой вклад в достижение общей цели компании так же, как это делают продуктовые команды.

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

В риск-менеджменте распространен подход оформлять такие вызовы в виде таблицы. В ней фиксируется сам риск, его вероятность, потенциальное влияние на систему и варианты действий в случае возникновения (митигация). У нас получилось примерно так:

Может показаться, что к нам заглянул Капитан Очевидность, но ценность такого подхода в системности: заранее осмыслить возможные проблемы, увидеть наиболее востребованные решения и сфокусироваться на них. Причем такой анализ не обязательно каждый раз запускать с нуля. Его можно обновлять при очередном планировании по OKR.

С учетом этих рисков был составлен черновик дерева OKR команды Платформы (привожу его здесь в общем виде, без деталей):

Основными целями стали:

O: снять блокеры и риски технологического характера
KR1: отсутствуют репорты по критическим уязвимостям из техстека в пределах Платформы
KR2: количество технологических блокеров сокращено минимум на 1

O: сократить расход времени на обслуживание в Links
KR1: снижено время на решение bugs
KR2: снижено время на решение service requests

O: ускорить процесс разработки в Sape (пользователи Платформы)
KR1: типовой этап разработки ускорен в среднем на 30%
KR2: скорость доставки на prod увеличена на 30%

На первый квартал по каждой цели были выбраны подцели, которые наиболее заметно влияют на результат (на схеме они отмечены зеленым):

O: своевременно обновлять технологический стек
KR1: техстек полностью описан
KR2: есть общедоступный roadmap обновлений, который поддерживается и доводится до команд, использующих продукты Платформы
KR3: 80% приложений Платформы обновляются по SLA

O: ускорить решение багов за счет улучшения наблюдаемости через Data Platform
KR1: появился инструментарий для 3 наиболее проблемных участков
KR2: время решения багов в legacy-бэкенде сокращено на 30%

O: ускорить создание прототипов приложений (research, early MVP)
KR1: половина прототипов создается с помощью универсального инструмента
KR2: запущен один early MVP при помощи универсального инструмента

Кстати, на этапе черновика удобно формулировать KR тезисно, в общем виде, а уже после принятия цели можно переводить их вместе с командой в конкретные технические метрики.

Как видно, цели напрямую связаны с рисками из таблицы выше. Интересно, что на основе этого дерева и инициатив (на схеме они отмечены желтым и заботливо заблюрены) были отобраны технологии.

Оказалось, что часть технологий работает сразу на несколько целей, а значит, мы можем таким образом определить приоритетность их внедрения. Например, n8n оказалась полезной и как инструмент для упрощения запуска MVP, и как средство автоматизации сбора метрик для OKR и других управленческих задач.

Хотя n8n в Sape используется давно, стало очевидно, что нам он нужен в масштабируемом варианте. А значит, пора переходить на кластерную версию и проводить полноценную внутреннюю раскатку: обучать, документировать и помогать с первыми внедрениями разработчикам и менеджерам.

С целями определились, но дальше возникает следующий вопрос: как их оцифровать?

Метрики Платформы

Поделюсь тем, как мы измеряли не самые очевидные платформенные метрики.

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

Возьмем в качестве примера метрику «Актуальность техстека». Она относится к следующей цели:

O: своевременно обновлять технологический стек
KR2: по всем компонентам техстека обновления происходят в общесистемном порядке до окончания срока поддержки ПО

Мы выстроили процесс, в котором ведем список компонентов техстека и для каждого задаем SLO на обновление — предельный срок после появления версии LTS, к которому компонент должен быть обновлен. После завершения обновления сразу планируется следующее — пусть даже с ориентировочной датой, которую позже можно уточнить.

В результате сформировалось инфополе, на основе которого мы рассчитали общий процент обновления компонентов по SLA и вывели его на верхнеуровневый дашборд:

Еще одна метрика — «Критические уязвимости». Она описывает следующий KR:

O: знаем о критических уязвимостях нашего техстека
KR2: автоматически собираются оповещения о критических проблемах по техстеку

Это бинарный KR, который подразумевает создание системы сбора уведомлений о найденных проблемах в используемых нами компонентах. Здесь мы полагаемся на базу уязвимостей National Vulnerability Database (NVD) и регулярно отслеживаем появление новых тикетов.

На инфополе выводится количество найденных уязвимостей за последний месяц:

Кстати, это и другие инфополя и метрики мы собираем с помощью n8n. Подробнее об этом я рассказывал в статье «Как быстро построить метрики для измерения эффективности разработчиков: готовое решение».

В заключение

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

А какие платформенные решения используете вы? И как измеряете результаты платформенной разработки?

От риск-менеджмента к метрикам: как построить прозрачное дерево OKR для команды Платформы