Купить результат или купить людей, которые его дают?

Управляемые услуги и расширение штата: определения

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

Поэтому первый вопрос, на который нужно ответить, вовсе не коммерческий. Он в том, есть ли у вас свободная управленческая мощность. Расширение штата добавляет руки к машине, которую вы уже ведёте; если внутри некому раздавать задачи, проверять их и снимать блокировки, добавление инженеров удлиняет очередь, а не сокращает её. Управляемые услуги передают это управленческое бремя вместе с работой — ценой некоторой прямоты и части контроля над тем, как именно работа выполняется.

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

Управляемые услуги: за результат отвечает поставщик

В договоре на управляемые услуги вы покупаете определённый объём и определённый стандарт, а не часы. Поставщик приводит свою команду, инструменты и регламенты, согласует цели по реакции и устранению для каждого уровня серьёзности и регулярно отчитывается по этим целям. Вы следите за выполнением SLA и эскалируете, когда оно проседает; вы не раздаёте задачи, не проверяете отдельные работы и не думаете, кто дежурит в два часа ночи.

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

Компромиссы реальны. Вы получаете меньше видимости в ежедневном исполнении и меньше возможности перенаправить усилия в короткий срок, потому что поставщик оптимизируется под подписанный договор, а не под приоритет сегодняшнего утра. Изменение объёма требует разговора, а не сообщения в Slack. А плохо управляемая услуга превращается в чёрный ящик — но это провал в проектировании объёма, отчётности и эскалации, а не врождённое свойство модели.

Расширение штата: руль остаётся у вас

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

Это ещё и самый быстрый способ добавить конкретный недостающий навык. Если вам нужен сильный инженер React, дата-инженер на один квартал или QA-специалист на релиз, расширение штата даёт именно это — без цикла найма, без решения о постоянной штатной единице и без расходов на содержание роли, когда потребность прошла. Ценообразование прозрачно, потому что считается за человека, и это упрощает планирование, пока вы понимаете, сколько людей вам нужно.

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

Как выбрать — и разделение, к которому приходит большинство команд

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

Большинство команд в итоге использует обе модели, и это правильный ответ, а не компромисс. Управляемый поставщик несёт операционный слой под продуктом: инфраструктуру, мониторинг, операции безопасности, резервное копирование и службу поддержки — по SLA. Привлечённые инженеры сидят внутри продуктовой команды и строят то, за что платят клиенты. Если вы взвешиваете смежные вопросы, мы также сравниваем управляемые услуги с построением штатной команды, а расширение штата — с выделенной командой.