Какой аутсорс нужен продуктовой разработке на разных фазах зрелости продукта

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

Расскажу, как мы пользовались аутсорсом по мере того, как наш продукт — облачная платформа MCS — проделал путь от MVP до зрелого продукта. Надеюсь, наш кейс поможет другим разработчикам получить от аутсорса максимум.

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

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

Сначала на аутсорс мы отдали frontend. Ключевые вещи — самые сложные в облаке — это backend и инфраструктура. Если нанимать собственную frontend-команду, нужен ее менеджмент и поддержка на уровне технологий. Это сложная задача.

Мы решили сфокусироваться на ключевой гипотезе: что получится создать backend с нужной производительностью, поэтому взяли frontend-команду на аутсорс. В таком режиме мы работали примерно полгода.

Лайфхаки:

• Полностью отдать на аутсорс какой-то модуль или процесс — это самый простой вариант.
• На этапе, когда ресурсов немного, выгоден фикспрайс-контракт, то есть договор на определенную сумму, по которому команда делает определенные задачи в определенный срок.
• Стороннюю команду можно в какой-то мере контролировать, но по факту приходится просто надеяться, чтобы аутсорсеры не опоздают в два-три раза и сдадут продукт с нормальным качеством.

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

Чтобы контроль всё-таки был, фронтендеров нужно было включить в нашу команду. Мы встроили их в scrum-команду, объединяющую backend- и frontend-специалистов, то есть перешли к формату аутстаффинга. Так быстрее коммуницировать, изменять требования, проще масштабировать гипотезы и разрабатывать новый функционал.

Этот этап, когда команда аутсорсеров интегрировалась в проект, занял примерно год.

Лайфхаки:

• На этом этапе в проекте нужна новая роль — человек, который следит за загрузкой конкретных разработчиков, планирует их резервирование для нас с их компанией.
• Команду на аутсорсе стоит встроить в работу над проектом и обучать. Для аутсорсеров это также полезный опыт, они видят как устроены рабочие процессы в Mail.ru. Таким образом мы выстраиваем систему аутсорса для долгосрочной работы, показываем подрядчикам, почему им выгодно работать с нами, держать запас ресурсов под нас, работаем в формате команды.

Проект масштабируется, у нас появляются новые ресурсы, растет число команд, мы можем больше инвестировать в штатных сотрудников. И когда встал выбор: вкладывать ресурсы в аутсорс или собственный штат, мы выбрали последнее.

Работа с аутсорсерами в прежней роли, и по сравнению с нашими внутренними сотрудниками, становится менее эффективной. И мы переходим к другому формату работы — передаем аутсорсерам преимущественно рутинные задачи: технического долга, unit-тестирования, развертывания. Штатным сотрудникам остаются ключевые и креативные задачи.

По этой схеме мы проработали еще полгода-год.

Наша команда выросла до 100 человек, проект получил признание на рынке, у аутсорса появились две новые функции.

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

Например, согласование новых штатных ставок происходит раз в квартал или год. После того как согласовали найм специалистов, нужно время для их поиска — 3-4 месяца. На этот период можно отдать новые задачи аутсорсерам.

Контракты с аутсорсерами позволяют снизить риски, связанные с долгим закрытием вакансий: на время отсутствия своих ресурсов мы берем их на аутсорсе.

Лайфхаки:

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

Сейчас проект вырос, каждый новый модуль или уникальная функция в продукте может разрабатываться командой из 4-5 человек. И на ключевые экспертизы мы находим аутсорсеров не по функциям, например: DevOps, Kubernetes, frontend, а по наличию эксклюзивной экспертизы в узких областях, интересных нам, например, построение кастомных SDN-решений. Чтобы собрать такую команду в штат, пришлось бы потратить много сил на поиск и найм.

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

Аутсорс — инструмент, который управленец должен оценивать с точки зрения стратегического продуктового развития, следить, чтобы на каждом этапе компания могла использовать его максимально эффективно. Наш проект, облачная платформа MCS, прошел путь от MVP до зрелого и развитого продукта, и на каждом этапе мы осознанно выбирали наиболее подходящий стиль использования аутсорсеров.

Ну а как с аутсорсом у вас?

Статья — по мотивам моего выступления на бизнес-завтраке «Масштабирование разработки за счет аутсорса» (тут видео).