Как собрать команду разработки с нуля: роли, состав и порядок найма

Статья для собственников, CEO и CTO, которые запускают цифровой продукт или новое направление, и для HR-директоров, которым поручили собрать команду. Разбираем, какие роли нужны, в каком порядке нанимать, сколько людей брать, как оценивать кандидатов и что выбрать: штат, аутсорс или аутстафф.

С чего начать: цель продукта определяет состав команды

Одна и та же компания на разных этапах нуждается в разных командах. Прежде чем открывать вакансии, ответьте на три вопроса:

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

Технический долг - решения, принятые ради скорости, которые потом приходится переделывать. На стадии MVP он нормален, если команда понимает, где его взяла и когда будет отдавать.

Состав команды разработки: роли и зачем каждая нужна

Команда разработки продукта обычно строится как кросс-функциональная: у её участников вместе есть все навыки, чтобы довести задачу от идеи до релиза, не ожидая других отделов.

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

Сколько человек нужно в команде разработки

Универсального числа нет, но есть два ориентира.

Небольшие команды работают быстрее. Руководство по Scrum (Scrum Guide) описывает команду как достаточно маленькую, чтобы оставаться гибкой, и достаточно большую, чтобы за спринт сделать значимую работу: обычно это 10 человек или меньше. Если команда разрастается, её делят на несколько команд с общей целью продукта.

Причина простая: с ростом команды число связей между людьми растёт быстрее, чем число людей. В команде из 5 человек 10 пар, которым нужно договариваться, в команде из 10 уже 45.

Добавить людей не значит ускориться. Закон Брукса из книги Фредерика Брукса «Мифический человеко-месяц» звучит так: добавление людей в опаздывающий программный проект задерживает его ещё больше. Новичкам нужно время, чтобы войти в проект, а опытным участникам приходится тратить время на их обучение и координацию.

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

Кого нанимать первым: порядок найма

Шаг 1. Технический лидер. CTO, технический сооснователь или tech lead. Он выбирает стек, проектирует архитектуру, участвует в собеседованиях и отвечает за качество найма всех остальных. Если в компании нет никого, кто может оценить инженера, начинать с найма рядовых разработчиков рискованно: вы не сможете проверить ни их уровень, ни их решения. Для поиска CTO и руководителей направлений обычно используют прямой поиск руководителей, потому что сильные технические лидеры редко откликаются на вакансии.

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

Дмитрий Чудинов, CTO airSlate (ex-Kuper, ex-ABBYY), в интервью Benchmark Executive, декабрь 2025¹

Шаг 2. Ядро команды. Два-три сильных разработчика под ключевые части продукта, дизайнер, продакт. На этом этапе опыт важнее цены: ядро закладывает архитектуру и культуру, которую потом унаследуют все новички.

Шаг 3. Качество и инфраструктура. QA, DevOps, аналитики по мере того, как появляются регулярные релизы и пользователи.

Шаг 4. Масштабирование. Руководители команд, вторая и третья продуктовая команда, платформенная команда.

Люди, которые уже работали вместе. Сильный приём на шагах 2 и 3: нанимать не отдельных специалистов, а связку людей с общим опытом. Психолог Брюс Такман описал стадии, через которые проходит новая группа: формирование, конфликт (притирка), выработка норм и продуктивная работа. У людей, которые уже работали вместе, часть этого пути пройдена, поэтому они быстрее выходят на рабочий ритм. Именно так мы собираем команды в проектах подбора IT-команды под ключ: ищем профессионалов с опытом совместной работы.

Как искать и оценивать кандидатов

Где искать:

• рекомендации технического лидера и первых сотрудников: самый быстрый канал для ядра;
• профессиональные сообщества: Habr, профильные Telegram-каналы, митапы и конференции;
• hh.ru и другие площадки: для позиций с большим числом активных кандидатов;
• прямой выход на людей, которые работу не ищут: для лидов и редких специалистов;
• партнёр по подбору, когда нужно много людей быстро или в компании нет своих IT-рекрутеров.

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

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

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

Если в компании нет технического специалиста, не оценивайте разработчиков сами по резюме. Пригласите внешнего технического интервьюера, CTO-консультанта на несколько часов или партнёра по подбору, который проверяет навыки на рабочих задачах. Лучше всего сначала нанять технического лидера (шаг 1), а он уже возьмёт оценку на себя.

Штат, аутсорс или аутстафф

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

Как команде быстро начать работать

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

До выхода людей:

• доступы, рабочие места, репозиторий, среда разработки, CI/CD;
• описание продукта, целей на квартал и архитектурных решений, если они уже приняты;
• понятные роли: кто принимает продуктовые решения, кто технические, кто отвечает за релиз.

В первые недели:

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

Адаптация людей, а не только задач. Процессы и документация не заменяют разговора о том, как устроена компания и чего от команды ждёт бизнес. Для ключевых ролей и целых команд это можно выстроить как отдельную программу: онбординг руководителей, IT-специалистов и команд.

Продуктовый лидер Илья Меньшенин среди «вредных советов» при формировании команд называет именно это:

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

Илья Меньшенин, ex-владелец продукта «Кредитные карты» в МТС Финтех, в интервью Benchmark Executive, 2026²

Ошибки при формировании команды разработки

1. Нанимать разработчиков раньше технического лидера. Без него некому выбрать архитектуру и проверить качество найма.
2. Собирать команду из звёзд, которые не умеют работать вместе. Сильные по отдельности люди без общих правил тратят силы на споры.
3. Искать «универсального солдата». Человек, который сам пишет код, рисует макеты и настраивает серверы, редко делает всё это хорошо.
4. Нанимать слишком много и слишком быстро. По закону Брукса рост команды сначала замедляет работу.
5. Оставлять продукт без владельца. Если никто не отвечает за приоритеты, команда делает то, что громче просят.
6. Откладывать QA и DevOps до кризиса. Первые серьёзные сбои обходятся дороже, чем специалист, нанятый вовремя.
7. Оценивать только технические навыки. Мотивация и поведение в команде проявляются позже, когда заменить человека уже сложнее.
8. Забывать про информационную безопасность в продуктах с персональными и финансовыми данными.
9. Не планировать адаптацию. Новички без контекста работают медленнее и уходят чаще.

Когда звать партнёра, чтобы собрать команду разработки

Собрать команду своими силами реально, если есть технический лидер, свои IT-рекрутеры и время. Партнёр нужен, когда:

• команду нужно собрать быстро и сразу большую;
• открывается новое направление, в котором у компании нет экспертизы и контактов;
• в компании нет своего IT-рекрутинга или он загружен текущими вакансиями;
• нужны редкие специалисты или руководители направлений.

Как это устроено у нас. Мы собираем команды от 20 человек под проект или на постоянную работу: в анализе данных, разработке продукта, тестировании, системном администрировании, разработке, дизайне и информационной безопасности. Можем сформировать готовый отдел, от младшего уровня до руководителя направления, и стараемся объединять людей, которые уже работали вместе. Каждого кандидата оцениваем по четырём параметрам из раздела выше, а после выхода помогаем участникам команды быстрее пройти адаптацию. Подробнее: подбор IT-команды под ключ.

Пример. Международному холдингу с активами в MENA нужна была управленческая команда для запуска с нуля P2P-платформы микрокредитования: CTO, CPO и Chief Data Officer. Ключевой фигурой был CTO, который определял технологические решения проекта. Мы подобрали семь кандидатов с разным опытом, клиент выбрал CTO с опытом в банковском секторе и финтехе, и весь поиск занял меньше месяца. Подробности в кейсе о поиске CTO для финтех-проекта.

Если вы стартап и собираете первую команду вместе с руководителями, посмотрите, как мы работаем с наймом руководителей и продуктовой команды в стартап.

Частые вопросы

Кого нанимать первым в команду разработки? Технического лидера: CTO, технического сооснователя или tech lead. Он выбирает архитектуру и стек, участвует в оценке всех следующих кандидатов и отвечает за качество найма. Вторым по важности идёт владелец продукта, эту роль на старте часто берёт основатель.

Сколько человек должно быть в команде разработки? Руководство по Scrum ориентирует на команды из 10 человек или меньше. Для первой версии продукта обычно хватает небольшого ядра. Если людей нужно больше, лучше собрать несколько небольших команд с общей целью, чем одну большую.

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

Сколько времени занимает сбор команды? Зависит от числа ролей, редкости специалистов и того, есть ли в компании технический лидер и свои рекрутеры. Быстрее всего идёт найм, когда первым уже нанят технический лидер, а поиск ведут параллельно по нескольким ролям.

Что лучше: штатная команда или аутсорс? Если продукт - основа бизнеса, ядро лучше держать в штате, чтобы знания и ключевые решения оставались в компании. Аутсорс подходит для разовых проектов и прототипов, аутстафф для временного усиления.

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

Источники