В чём студия может быть лучше своей команды? Разбор идеальной модели штата сотрудников и подрядчиков
Меня зовут Владислав, больше 5 лет я помогаю создавать продукты в digital.
В рамках Art UX нашей ключевой экспертизой всегда были и остаются UX–проектирование и дизайн интерфейсов.
Когда я впервые захотел сделать свой собственный стартап, при этом не имея на это ресурсов, то думал: «Ну вот пускай у меня сначала появится куча денег на команду, а потом я уж как нибудь справлюсь». По факту же, когда мы провели сделку по слиянию с крупным игроком на рынке недвижимости, и я как руководитель продуктовой разработки получил возможность собрать ну почти любой стек специалистов для создания сервиса Arenta.Space, все трудности только начались.
В этой статье я постараюсь помочь продактам и руководителям, которые столкнулись с задачей сформировать стек для создания нового продукта. Мы разберем плюсы и минусы классической in-house разработки, модель с частичным и полным аутсорсом и аутстафом. Все рекомендации ниже основаны на собственном и клиентском опыте.
Что выбрать: штат или аутсорс?
Разумеется, каждый проект уникален, поэтому формата, который идеально подходит всем, не существует. И перед формированием команды есть несколько главных вопросов, которые нужно себе задать.
1. Необходимая экспертиза.
Какой стек специалистов нужен, и насколько они должны быть сработанны между собой. Теоретически, не бывает такой команды у подрядчика, которую было бы невозможно нанять самостоятельно. Другой вопрос, что на это уйдет много месяцев, которых у стартапов часто нет, когда стоит цель быстро создать MVP и доказать жизнеспособность. Отсюда вытекает второй вопрос.
2. Доступные ресурсы и время.
Помимо времени, необходимого на найм, и бюджета, которым вы располагаете, ключевым является ваш собственный опыт создания продуктов, и наличие связей с людьми в теме разработки.
Если вы уже знакомы с рынком на практике, то сформировать команду будет проще — вы уже знаете, кому можно написать, чтобы предложить работу, и на чем делать акценты на собеседованиях. Даже не имея огромных бюджетов и сроков, вы сможете сформировать главный стек специалистов, а какие-то компетенции передать на аутсорс.
Другая ситуация, если у вас мало представления, о том, как всё должно работать. Риск напороться в процессе найма на некомпетентных людей сильно возрастает. В таком случае, нужно либо искать тимлида в качестве полноправного партнера, который сделает все за вас, либо идти в студию, и заказывая услуги, параллельно прокачивать собственную компетенцию.
К слову, мы также написали статью про ценообразование студий и возможные форматы сотрудничества с ними.
3. Долгосрочные цели.
Создать MVP с минимальным бюджетом — это одна задача, и совсем другая — развивать продукт после его релиза. Каким компетентным бы ни был подрядчик, ни одна бизнес-модель не сможет масштабироваться, если весь продукт находится на аутсорсе и зависит от него.
Здесь я снова возвращаюсь к идее, что независимо от бюджета, на стороне заказчика вовремя должен сформироваться свой сильный стек специалистов, который будет работать вместе со студией, или самостоятельно.
Отсюда первый вывод:
Закрывайте студиями свои слабые компетенции, и учитесь у них, чтобы впоследствии вы могли сформировать собственную команду.
Комбинированные команды.
1. С нас идея, с вас воплощение.
Модель, при которой на стороне заказчика есть бизнес-экспертиза, но отсутствует опыт IT–реализации. 90% работы отдается на аутсорс или аутстаф.
Часто так делают состоявшиеся компании, которые хотят впервые разработать приложение к своему бизнесу, в буквальном смысле. Заказчик берет на себя роль продакта, который знает конечного потребителя лучше новой пришедшей команды, и помогает на всех этапах прототипирования и тестирования продукта.
В целом, когда люди в первый раз обращаются в агентство, чаще всего, они представляют себе именно эту модель, где они передадут всю ответственность за реализацию.
2. Есть программисты, нужен только UI.
Вторая самая распространенная комбинация, в которой у заказчика уже есть опыт в разработке, но UX и UI — слабая сторона.
При этом, логику продукта, создание прототипов и ответственность за итоговый вид также часто берет на себя заказчик, что не всегда правильно. Потому что техническая подкованность и опыт в IT не гарантирует, что в результате получится хороший продукт.
Если вы планируете разработку по данной модели, заранее определите, достаточно ли у вас продуктовой экспертизы для того, чтобы командовать, где какие элементы располагать, или также стоит доверить этот этап студии.
3. Есть своя команда, но нужно больше рук.
Формат, при котором ключевые интересы заказчика — сократить срок реализации продукта за счет увеличения мощностей, и привлечь взгляд со стороны. Также подходит, когда своя команда занята другим проектом, а задачи выполнять надо.
Подразумевает, что у вас уже есть экспертиза в управлении командами разработки. Поэтому при данной модели удобнее выкупать специалистов на аутстаф, чтобы работать с ними напрямую.
Резюме.
Если есть экспертиза и бюджет — нанимать свою команду и параллельно заказывать у студии, чтобы увеличивать мощности и сокращать сроки.
Если есть деньги, но нет экспертизы — заказывать у студии, учиться на практике, и потихоньку нанимать свою команду.
Если есть экспертиза, но мало денег, то поэтапно собирать свою команду, и периодически заказывать консалтинг, чтобы решать проблемы, которые возникают по пути.
Ну а если нет ни экспертизы в создании IT–продуктов, ни ресурсов, но при этом очень хочется воплотить идею, то имеет смысл разбираться самостоятельно и создавать что-то на коленке через no-code сервисы.
К слову, у нас есть статья, как быстро проектировать интерфейсы в Figma.