ИТ-отрасль стоит на пороге серьезных изменений. Онлайн-школы и курсы ежемесячно выпускают тысячи новых разработчиков, нейросети могут генерировать шаблонные интерфейсы по текстовому описанию, все больше специалистов из других отраслей осваивают JavaScript, Python или SQL для решения рабочих задач. Программирование перестает быть уделом узкого круга специалистов, навык работы с кодом становится доступен многим. Что это значит для команд и компаний, которые занимаются аутсорс-разработкой?
Как меняется рынок аутсорс-разработки
Skipp работает на стыке интересов заказчиков и студий аутсорс-разработки. Первым мы помогаем сформулировать цель, перевести ее на язык разработки и получить результат, а вторым — эффективно использовать опыт и компетенции на интересных и релевантных проектах. Так что мы понимаем рынок с двух сторон и вот что мы видим:
Развиваются решения, которые позволяют обойтись без кода
Собрать посадочную страницу и даже продавать курсы можно на конструкторе Tilda или Webflow. Интегрировать сервисы можно с помощью Zapier или IFTTT. Glide может превратить Google-таблицу в приложение. При этом с этими сервисами справится менеджер, маркетолог или дизайнер.
Простые задачи можно решить внутри компании, это будет быстрее, дешевле и чаще стабильнее, чем силами внешних исполнителей. Из этого вытекает второй тренд:
На аутсорс отдают более сложные продукты, чем раньше
Все реже на аутсорс отдают стандартные онлайн-магазины или сайты о компании. Часто к разработчикам приходят с идеей сложного сервиса, для которого нужно сделать прототип и потом запрограммировать. Или приносят большой список макетов с нестандартной функциональностью, которую сложно реализовать с помощью no-code-решений.
В итоге на рынке оказываются сложные со всех сторон продукты: с микросервисами на бэке, фронтом в виде SPA, высокими требованиями к аналитике. Разработчикам приходится подстраиваться:
У команд разработки появляется специализация
Редко одна команда может одинаково качественно сделать и сложную логику на бэке, и нестандартный фронт. Проще и эффективнее сконцентрироваться на конкретной технологии и выдавать высокий результат на ней, а не распыляться на несколько языков и фреймворков.
Заказчикам тоже выгодно работать со специализированными командами. Например, вам нужно создать маркетплейс. Для веба и приложения вам важно найти команду фронтенда с релевантным опытом. Но если они не специализируются на базах данных, то для бэкенда логично подобрать еще одну команду. Так в проекте будет участвовать не один аутсорсер, которому вне зависимости от опыта придется делать сразу все, а две команды разработчиков. Каждая из них возьмется за задачу, которую решает лучше всего. В итоге результат может быть получиться быстрее и качественнее.
В таких проектах речь уже не идет о «написании кода по техническому заданию»: заказчики приходят с комплексными запросами, а исполнители готовы с ними работать в рамках своей специализации. Из-за этого появляется следующий тренд:
Клиенты хотят платить за конечный продукт
Бизнесу не так важно, сколько часов разработчик потратил на создание модуля и сколько написал строк кода. Важно, чтобы конечный продукт решал задачу бизнеса: конвертировал, продавал, удерживал пользователей, приносил деньги.
Бизнес заказывает сложную функциональность и ожидает хорошее решение. Но раз речь уже не идет о том, чтобы один раз сделать, запустить и забыть, то и характер отношений меняется:
Отношения становятся длиннее
Заказчикам интересно развивать продукт, расширять функциональность, решать с его помощью новые задачи. Растет спрос на поддержку и периодически не только техническую. Клиенты готовы обсуждать не только модули системы, но и то, каким способом можно больше заработать или сэкономить с помощью технологий.
В долгосрочных отношениях заказчику становится выгодно работать с агрегатором команд разработки, а не с одним конкретным аутсорсером. Потребности заказчика могут поменяться и, если у аутсорсера нет релевантного опыта и компетенций для новых задач, ему придется либо отдать работу на субподряд, либо отказаться от проекта. Если заказчик работает с агрегатором, то на любую задачу найдут команду опытных разработчиков.
В итоге складывается такая картина:
Больше no-code-решений → На аутсорс отдают сложные задачи → Команды находят нишу для специализации → Растет спрос на конечный результат, а не на часы разработки → Меняется характер и длительность отношений.
Со стороны эти изменения могут быть незаметны: на рынке все еще высокая доля типовых запросов и многие аутсорс-команды чувствуют себя неплохо. Но в ближайшие годы ситуация будет меняться.
Что делать с этими изменениями
От этих изменений выиграют в итоге все: заказчики получат более качественные и жизнеспособные продукты, а разработчики — задачи, которые соответствуют их интересам и уровню компетенций. Но для этого командам предстоит измениться:
Развивать подход к работе
В крупном бизнесе обычно есть директор по продукту (CPO), который хорошо понимает, что и в каком порядке нужно разрабатывать, может поставить задачу и аргументировано ответить на вопросы. Но в небольших компаниях — а их намного больше — все часто завязано на основателях, у которых нет ресурса разбираться в деталях, им нужен результат.
Задача команды разработки в таком случае — помочь конкретизировать цель и подобрать оптимальные инструменты, а не просто реализовать то, что описано в брифе или задании. Так исполнитель сможет создавать ощутимую ценность для заказчика: быть технологическим партнёром.
Взаимодействовать с другими командами
Специализация приведет к тому, что над одной задачей будет работать сразу несколько команд: одна команда будет администрировать сервера, другая — писать логику на бэке и API, третья — алгоритмы для сбора и анализа данных и модели машинного обучения, четвертая — весь фронт, пятая — тестировать, шестая — готовить дизайн и текст. Команды могут быть из разных стран и часовых поясов, иметь разную структуру и внутренние процессы.
В таких условиях преимущество получат компании, которые умеют работать в паре с другими. Это подразумевает способность договариваться, подстраиваться под новые инструменты и работать на общую, а не индивидуальную цель. Становится выгодно иметь знакомые команды с дополняющими компетенциями и уметь выстраивать с ними совместный процесс.
Автоматизировать бизнес-процессы
Аутсорс тоже бизнес. Изменения выше неизбежно повлекут за собой дополнительные расходы на администрирование. Значит, командам придётся искать пути снижения издержек и повышения эффективности. Здесь решения могут быть разные: тот же no-code, искусственный интеллект или платформы для взаимодействия с клиентами.
Мы уже обсудили, что код — это еще не результат, который устроит заказчика. Поэтому становится не так важно, откуда этот код берется: если прототип можно собрать на Webflow или даже с помощью нейросети, так и стоит поступить. Новые инструменты, которые эффективно решают старые задачи, полезны не только заказчикам, но и исполнителям.
Это же касается и процесса работы с клиентом: командам предстоит автоматизировать процесс получения задачи, подбора свободных и подходящих исполнителей для неё. А еще контролировать сроки, быстро замечать и устранять проблемы.
ИТ-завод будущего
Погружение в задачи бизнеса, координация с другими командами, автоматизация процессов и другие изменения могут оказаться сложными вызовами. В конце концов у разработчиков есть конкретный фокус — они пишут код. А у небольших команд на такие изменения может просто не хватить ресурсов. Поэтому есть и другой путь — стать частью ИТ-завода будущего.
В таком заводе уже есть часть, которая занимается администрированием: погружается в задачу, исследует рынок, помогает описать цель. Она агрегирует ИТ-студии, проверенные на реальных проектах, и под каждую задачу собирает команды с подходящими компетенциями, погружает их в специфику бизнеса, переводит цели на язык разработки, ставит конкретные задачи. Берёт на себя автоматизацию процессов. Специалистам остаётся самое интересное — сконцентрироваться на разработке.
Заказчикам: вовлеченный технологический партнер
Клиенту не нужно разбираться в технологиях или самому искать команду, которая сможет реализовать задумку. Не придется проводить множество встреч, слепо выбирать исполнителя и отвечать на множество неочевидных тонких вопросов. Всю эту работу возьмет на себя завод. Вот как это работает в Skipp:
Когда к нам приходит заказчик, мы начинаем с собственного продуктового исследования. Погружаемся в специфику бизнеса и запроса, изучаем проект, предлагаем собственные варианты решения. Затем разбиваем решение на части. И подбираем исполнителей, которые справятся с ними лучше всего.
Затем управляем процессом производства: погружаем разработчиков в задачу, объясняем, в чем ценность для клиента, контролируем сроки и бюджет. Если что-то идет не так — решаем трудные ситуации.
Исполнителям: поток интересных и конкретных задач
Это работает и в обратную сторону: на таком заводе программисту не нужно тратить время на чуждую работу, постоянно прерываться на общение с заказчиком, пытаться понять его потребности. Он получает постоянный поток понятных задач, которые подходят по его компетенциям и опыту. Если он отлично работает с React, он сможет спокойно реализовывать проекты именно на нём, а не спешно разбираться с Vue.Js, потому что других сейчас нет.
Процесс организован так, чтобы разработчики разных профилей участвовали в более-менее постоянных командах. Благодаря этому они срабатываются, как будто бы они из одной компании, хотя на самом деле могут быть вообще с разных континентов. При этом они знают, что работают над общей целью и хорошо ее понимают — это тоже отличает такой завод от стандартного подхода.
Что в итоге
Рынок разработки меняется. С одной стороны, задачи становятся сложнее и потребность смещается от кода в сторону бизнес-задач, с другой — растет специализация исполнителей.
Характер взаимодействия между заказчиками и исполнителями тоже меняется: появляются агрегаторы команд, с которыми выгодно работать обеим сторонам. Заказчикам удобно, что в агрегатор можно передать любую задачу, а командам разработки агрегатор помогает эффективно дополнять друг друга и браться за новые сложные проекты.
Чтобы адаптироваться к будущему, командам разработки также предстоит измениться: глубже погружаться в бизнес клиента, научиться работать с другими командами, автоматизировать процессы. Но все это можно сделать проще — стать частью большого ИТ-завода.
Миссия такого завода — обеспечить для программистов стабильное количество задач, которые подходят им по интересам и опыту, и помочь им решить задачи бизнеса. При этом повысить для клиентов ценность от разработки, стать не просто менеджером проекта, но и менеджером продукта, который помогает принимать правильные решения.
Проблемы плохо проработанного технического задания, непонимания бизнес-цели, непрофильных задач или бесполезных продуктов на выходе скоро останутся в прошлом. И в этом помогут ИТ-заводы, которые решают и боль разработчиков, и боль клиентов.
