Откуда берётся вопрос
У вас несколько продуктовых команд, и каждая перед каждым релизом делает работу, которая к продукту отношения не имеет: поднимает окружение, чинит пайплайн, настраивает выкатку, раздаёт доступы, прикручивает мониторинг. Релизы идут, но медленнее, чем могли бы. На ретро звучит одно и то же: «тонем в обвязке». И тут кто-то произносит слова «платформенная команда», и они звучат то как спасение, то как модный налог, который большие компании платят, потому что могут.
Снимать вопрос вкусом бесполезно. Платформенная команда — это внутренний продукт: пользователи в нём — ваши же команды, а ценность — в переиспользовании. Одну и ту же работу сделать один раз и раздать многим. Как всякая ставка на переиспользование, она окупается при одной конъюнктуре и разоряет при другой. Конъюнктуру можно посчитать — на ваших числах, без чужих бенчмарков. Этим и займёмся.
Что пробуют первым — и почему это не работает
Первым почти все пробуют одно и то же: команду не заводить, а описать. Пишется стандарт: как собирать окружение, как выкатывать, как называть ветки. Выкладывается в вики. Объявляется обязательным.
Механика провала простая. Документация передаёт знание, но не труд. Читатель всё равно собирает пайплайн руками — по инструкции, а не по догадке. Экономия только на придумывании; вся сборка, вся отладка и всё сопровождение остаются в каждой команде и повторяются в каждом релизе. Дальше хуже: у стандарта нет исполнителя-владельца, есть автор-энтузиаст. Продукт меняется, гайдлайн протухает, команды один раз обожгутся — и перестают ему верить; возвращать доверие дороже, чем переписывать. И последнее: стандарт без исполнителя не принуждает. Команда под давлением дедлайна обойдёт его, и никто не заметит, пока не стрельнет.
Рядом второй тупик: нанять одного инфра-инженера «на все команды». Он делает ту же работу столько же раз, только быстрее и в одном месте. Его очередь становится новым узким местом: команды стоят в тикетах к нему так же, как раньше стояли в своих проблемах, только теперь ждут чужого человека. Плюс он не может уйти в отпуск. Это не платформа, это человек-очередь.
Выход из тупика — не писать документацию лучше, а перестать требовать от команд сборку вообще: сделать путь, где работа уже сделана за них. Про это у нас есть отдельный материал — golden path вместо документации. Но у golden path есть свойство, которое и порождает наш вопрос: это продукт, а продукты делают команды. Отсюда — «когда заводить».
Проверка руками: четыре шага
-
Разметьте повторяющийся труд. Возьмите пару последних спринтов — или месяц тикетов, если спринтов нет — и попросите каждую команду пометить задачи, которые не про её продукт: окружения, пайплайны, выкатка, мониторинг, доступы, обновления, дежурства по инфраструктуре. Разметка живых тикетов честнее опроса по памяти: рутина не запоминается как работа и в опросе занижается. Сложите по командам — получится число А: сколько человеко-времени организация тратит на обвязку за период. Само по себе оно пока ничего не значит; понадобится на шаге три.
-
Проверьте, что труд один и тот же. Платформа собирает только одинаковую работу. Тест дешёвый: попросите по одному инженеру из разных команд описать, как у них сервис проходит путь от коммита до продакшена — где живёт код, как собирается, как выкатывается, как наблюдается. Если описания совпадают по сути, общий знаменатель есть. Если один тянет монолит на виртуалках, второй — функции, третьему нужно железо, общего слоя почти нет, и платформа неизбежно станет компромиссом: избыточной для одних, недостающей для других. Тогда сначала сузьте разнообразие — или признайте, что платформа не ваш жанр.
-
Посчитайте ставку. Сравните число А с ценой платформенной команды: зарплаты, плюс координация — время на встречи и согласования, которое теперь платят обе стороны, — плюс налог миграции: командам придётся переезжать с привычных пайплайнов, и эта работа ляжет на них же. Считайте в одних единицах: если А вышла в человеко-днях за квартал, цену команды тоже приведите к человеко-дням за квартал. Зарплата в дни переводится тривиально; координацию и миграцию оценивайте сверху, с запасом — на старте они всегда кажутся меньше, чем выходят. Ставка окупается, когда А устойчиво больше цены команды — не в одном удачном спринте, а из периода в период. И условие, о котором забывают чаще всего: освободившееся время должно попадать в узкое место организации. Если команды и так не упираются в доставку — или упираются не в неё, а в решения о продукте, — ускорения не увидит никто, и платформу объявят провалом. Ускорение не-узкого звена ничего не ускоряет; старая мысль из теории ограничений, и здесь она работает буквально.
-
Проверьте спрос. Платформенной команде нужны пользователи, как продуктовой — покупатели. Составьте список команд, которые переедут на платформу, как только она появится: не «когда-нибудь», а фактически готовых. Если список не собирается, спроса нет — и команда начнёт строить платформу под воображаемых пользователей: красивую и никому не нужную. Второй сигнал спроса — частота онбординга. Если путь «новый сервис от нуля до продакшена» у вас случается регулярно, это и есть поток клиентов будущей платформы. Если сервисы не заводятся и команды не растут, платформе будет некому продаваться.
Когда заводить не надо
Коротко, без сочувствия.
- Если все пользователи будущей платформы помещаются в одной переговорке, команда выродится либо в тикет-очередь, либо в ещё одну продуктовую команду с красивым названием.
- Если стеки команд принципиально разные и останутся такими — регуляторика, купленные системы, политика — общего знаменателя нет, и шаг два это покажет.
- Если узкое место не в доставке, платформа ускорит то, что и так не тормозит.
- Если некого посадить — об этом ниже.
- Обратное тоже верно: платформенная команда — не условие для современного инфра. Kubernetes можно тянуть силами одной команды — мы разбирали такой сценарий на примере команды из двенадцати человек. Не заводите команду ради инструмента.
Если условия сошлись
Кадровое условие жёсткое: ядро команды — люди, которые делали эту обвязку руками в продуктовых командах. Они знают, где болит, и им верят те, кто болел рядом. Платформенная команда из «кого не жалко» — это свалка, и продуктовые команды это посчитают быстрее, чем вы думаете.
Первая итерация — не «внутренняя облачная платформа» с лендингом, а один путь: от коммита до продакшена, пройденный без инфра-знаний. Как его делать — тема материала про golden path; здесь управленческое: принятие добровольное, но измеримое. Считайте, сколько команд переехало и сколько вернулось. Вернувшаяся команда — самый честный отзыв из возможных; идите к ней с вопросами, а не с увещеваниями. Переезжайте по одной команде за раз и начинайте с той, что сама просилась: она даст обратную связь и станет примером. Одновременный переезд всех — это одновременный простой всех.
Не начинайте и с портала самообслуживания. Портал — интерфейс к платформе, которой ещё нет; сначала сделайте то, к чему можно строить интерфейс.
Держите очередь платформы короткой. Момент, когда команда ждёт платформу дольше, чем сделала бы руками, — момент, когда ставка начинает проигрывать: вы добавили в процесс посредника, а выгоду ещё не выдали.
Дальше платформенная команда живёт как продуктовая: у неё пользователи, обратная связь и роадмап. Как только она начинает жить как отдел — «пришлите заявку, разберём после праздников» — она деградирует в бюро заявок, и все шаги выше придётся пересчитывать заново.
Позиция редакции
Мы считаем: платформенную команду заводят не когда стало тяжело, а когда сошлись три условия — повторяющийся труд у нескольких команд один и тот же; его объём устойчиво больше цены небольшой команды; есть очередь из команд, готовых переехать хоть завтра. Тяжесть сама по себе аргументом не является: тяжёлая, но разнородная работа от платформы не лечится — она централизуется, и вместо боли в каждой команде вы получаете ту же боль в одной, плюс ожидание.
И вот когда мы неправы. Если труд повторяется и объёмы сходятся, но разнородность команд неустранима — регуляторика, купленные системы, особые требования к надёжности у немногих, — платформа станет общим знаменателем, который замедлит всех. Тогда правильная форма — сильный инфра-инженер внутри каждой команды, и наша позиция не работает. Проверяется это шагом два: если описания пути до продакшена не совпадают и сблизить их нельзя, закройте статью и не заводите ничего.
Если же после разметки тикетов число А оказалось меньше цены команды — тоже не заводите. Перемерьте, когда команд и сервисов станет больше: платформенная команда — ставка на масштаб, и она честно дождётся своего часа.