В чём студия может быть лучше своей команды? Разбор идеальной модели штата сотрудников и подрядчиков

Меня зовут Владислав, больше 5 лет я помогаю создавать продукты в digital.
В рамках Art UX нашей ключевой экспертизой всегда были и остаются UX–проектирование и дизайн интерфейсов.

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

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

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

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

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

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

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

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

Создать MVP с минимальным бюджетом — это одна задача, и совсем другая — развивать продукт после его релиза. Каким компетентным бы ни был подрядчик, ни одна бизнес-модель не сможет масштабироваться, если весь продукт находится на аутсорсе и зависит от него.

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

Отсюда первый вывод:

Модель, при которой на стороне заказчика есть бизнес-экспертиза, но отсутствует опыт IT–реализации. 90% работы отдается на аутсорс или аутстаф.

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

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

Вторая самая распространенная комбинация, в которой у заказчика уже есть опыт в разработке, но UX и UI — слабая сторона.

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

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

Формат, при котором ключевые интересы заказчика — сократить срок реализации продукта за счет увеличения мощностей, и привлечь взгляд со стороны. Также подходит, когда своя команда занята другим проектом, а задачи выполнять надо.

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

Если есть экспертиза и бюджет — нанимать свою команду и параллельно заказывать у студии, чтобы увеличивать мощности и сокращать сроки.

Если есть деньги, но нет экспертизы — заказывать у студии, учиться на практике, и потихоньку нанимать свою команду.

Если есть экспертиза, но мало денег, то поэтапно собирать свою команду, и периодически заказывать консалтинг, чтобы решать проблемы, которые возникают по пути.

Ну а если нет ни экспертизы в создании IT–продуктов, ни ресурсов, но при этом очень хочется воплотить идею, то имеет смысл разбираться самостоятельно и создавать что-то на коленке через no-code сервисы.

К слову, у нас есть статья, как быстро проектировать интерфейсы в Figma.