Как собрать в компании отдел разработки
Генрик Мкртчян, сооснователь и CEO агентства веб-разработки «Кодеры» (входит в ГК Digital Hub) рассказал, как нанимать разработчиков, проверять их скиллы и контролировать работу.
Чтобы набрать нужных специалистов, не разориться на найме и сформировать классную команду, нужно правильно выбрать формат занятости сотрудников и методы их контроля, после чего поставить процесс на поток. А ещё избежать ошибок, если наймом занимается собственник или технический специалист, а не эйчар.
Но обо всём по порядку.
Выберите формат занятости сотрудников
Определите, как хотите нанять сотрудников и сформировать отдел разработки. Выбрать можно из 3 основных форматов:
Аутстаффинг
Аутстаффинг — это формат занятости, при котором вы получаете профессионалов и берёте на себя проектное управление. Идеальный вариант, если у вас уже есть команда технических специалистов, налажен менеджмент, но не хватает рук или нужно масштабироваться.
Эффективная и выгодная реклама с сервисом от МегаФона
Широкий выбор рекламных каналов, более 100 параметров по интересам, подробная аналитика и другие возможности уже ждут в Личном кабинете. А еще кешбэк 100% за запуск рекламы в первый месяц и еще 10% — каждый месяц.
Используя аутстаффинг, можно:
-
быстро найти разработчиков, прособеседовать их и подключить к проекту;
-
сохранить экспертизу внутри команды;
-
самостоятельно курировать рабочий процесс.
Вы получаете рабочие руки, общаетесь с исполнителем напрямую и «правите бал».
Аутсорсинг
Аутсорсинг — это аренда сотрудников под конкретные задачи на определённый срок. Формат подходит большинству компаний на любом этапе развития — как стартапам, так и большим корпорациям. Идеален для компаний без опыта в разработке. Преимущество аутсорсинга в том, что вы платите только за результат, а процессом управляет подрядчик.
Используя аутсорсинг, можно:
-
отдать подрядчику управление и менеджмент;
-
платить за результат;
-
получить упакованную работу.
Можно нанять команду полного цикла, где продукт разработают, проверят и проконтролируют каждый этап работы.
Инхаус
Обычный найм, формирование команды внутри компании. Инхаус — формат не для всех, ведь собирать команду долго и дорого. Найм может занять годы: это мешает, когда бизнес требует быстрых результатов.
Используя инхаус, можно:
-
сохранить и развить экспертизу внутри компании;
-
получить свой штат разработчиков под любую задачу;
-
в моменте влиять на качество работы.
Инхаус — отличный вариант для крупных IT-компаний, которые могут потратить время и деньги, вложившись в сотрудников. Они «в теме», давно работают в отрасли и понимают, кого и зачем нанимать. Но, если собирать отдел без опыта, можно сделать это неправильно. Например, набрать ненужных сотрудников и разориться на одном только ФОТе. Инхаус — самый сложный формат, потому что здесь вы собираете команду с нуля. Нужна отдельная экспертиза, чтобы оценить профессиональные навыки, выстроить процессы, сформировать команду, планировать занятость и численность.
Наймите сотрудников и соберите команду
Найм сотрудников и формирование команды не зависят от того, какой формат занятости вы выбрали. В любом случае алгоритм найма будет одинаковым.
1. Определитесь с технологиями и ресурсами
Команда разработчиков может состоять из трёх сотрудников, а может превышать тысячу. Чтобы встроить разработчиков в процесс, словно в паззл, ещё до начала найма определите:
-
какие технологии надо использовать на проекте (оптимальный стек технологий);
-
какие ресурсы надо использовать на проекте — сколько сотрудников нужно для реализации продукта и какой срок на разработку стоит заложить.
Важно: чтобы чётко определить технологии и ресурсы, имейте при себе сметы и план проекта. Тогда вы сможете обосновать каждый рубль и понять, в какие сроки и какими силами сделаете проект.
2. Спланируйте состав команды
Его наполнение зависит от специфики проекта, объёма работы, бюджета и графика.
К примеру, при работе с комплексным продуктом нанимают полноценную команду, состоящую из проджект-менеджера, frontend- и backend-разработчиков, тестировщиков, тимлида, дизайнера, аналитика, системного администратора и архитектора.
Если поиском занимается штатный эйчар, можно воспользоваться пабликами, каналами и группами, где общаются потенциальные кандидаты. Например, For Web — фронтенд, дизайн, программирование (ВКонтакте), RADUG (Facebook, есть специальный пост для вакансий), FrontEndDev (Telegram, можно опубликовать вакансию на правах рекламы). Кроме того, есть профессиональные форумы и Хабр, где можно искать людей по стеку технологий или по компаниям, которые вы считаете хорошим источником персонала. А ещё могут сработать рекомендации и сарафанное радио.
3. Получите резюме специалистов
Разработчики должны подходить вам по опыту, стеку технологий и прочим требованиям. Со своей стороны лучше подключить профессионального рекрутера, который:
-
обратит внимание на несодержательные пункты в резюме. Это позволит создать гипотезы и подготовить вопросы для интервью;
-
оценит грамотность, логичность и структурированность текста, словарный запас и лаконичность. Обычно кандидат пишет код так же, как излагает мысли.
4. Проведите интервью с кандидатами
Для оценки навыков нужны эйчар и технический специалист с вашей стороны. На собеседовании они:
-
узнают, с кем работал кандидат. Был ли у него коллега, который делал ревью кода, делился опытом, обращал внимание на спагетти-код;
-
оценят его опыт работы. Узнают, сколько у него было проектов в работе, какой длительности, на каком этапе он подключался, сколько проектов завершил и «живы» ли они сейчас;
-
проверят кандидата на стек технологий и навыки. Нужно обратить внимание, как он рассказывает об этом. Просто перечисляет навыки или рассказывает о них в связке с конкретными проектами и задачами? Чёткие, адекватные ответы — признак того, что кандидат быстро и с умом вникнет в работу.
Лучше отказать кандидату, если он ничего не делал с нуля, а выполнял простые задачи и лишь поддерживал проект. Если у вас долгий проект, кандидат, который отработал на похожем лишь пару месяцев, не подойдёт.
5. Адаптируйте сотрудника
Когда разработчик оказался в вашей команде, проведите онбординг: дайте доступы, покажите, как устроены процессы в компании, объясните, где принимать задачи и отчитываться. Проводите код-ревью по каждой задаче и организуйте обмен обратной связью: так вы сможете быстро корректировать работу новичка.
Поставьте процесс на поток
Чтобы наладить работу команды разработчиков, нужно сделать четыре шага.
Составьте грамотное техническое задание
ТЗ гарантирует, что вы не потратите время зря и получите нужный результат. Оно поможет:
-
оценить задачу по бюджету, срокам и объёму человеко-часов;
-
объяснить специалисту, как устроена система работы по проекту и какую документацию нужно готовить «на выходе»;
-
адекватно принять задачу.
Создавать ТЗ должен технический специалист или подрядчик. Оно обеспечит техническое развитие продукта в дальнейшем и позволит всем участникам процесса видеть идею целиком.
Декомпозируйте техническое задание по задачам
Разбивайте большие задачи, которые занимают более 20 человеко-часов, на простые и мелкие. В агентствах веб-разработки есть правило: одна задача не должна занимать более 8 часов, иначе разработчик может наделать ошибок при её выполнении.
Небольшие задачи делают работу проще и быстрее. Кроме того, вы снизите риск застрять на одной задаче и застопорить проект. Съешьте слона по частям, чтобы не выпускать дефектный продукт.
Постройте график реализации проекта
Учитывайте специфику, сдвиг сроков задач и продумайте, как они зависят друг от друга. Соблюдайте их логику и последовательность.
Помните: задачи нужно грамотно делегировать. Не отдавайте сложные задачи новичку. Или закрепляйте за ним опытного разработчика. А перед началом работы соберите команду и расскажите о задачах каждого: все должны понимать, зачем они здесь, что делают и какую ответственность несут.
Контролируйте работу и сроки
Если разработчики работают удалённо, на первых порах совместно составляйте план задач на день, а в конце дня получайте отчёт об их выполнении.
Выстраивайте процесс разработки так, чтобы в любой момент отследить, что происходит в работе. Для этого каждая задача должна сопровождаться комментариями и статусами. Также это позволит быстро заменять исполнителей или вводить в работу новых людей.
Рассчитывайте время на коммуникацию и саму задачу: у каждой есть трудоёмкость и срок выполнения. Проверяйте, сколько времени разработчик уделил задаче — либо по её завершении, либо по итогам каждого дня.
Новичков сразу интегрируйте в команду: подключайте их к общим совещаниям, добавляйте в рабочий чат проекта.
Такая степень контроля снизит риск заплатить разработчику ни за что, позволит соотнести его временные затраты с результатом работы и быстро внедрить его как командного игрока.
Что важно помнить при формировании команды разработчиков
-
Аутстаффинг — это быстро и удобно. Плюс экспертиза остаётся у заказчика.
-
Ауторсинг — быстро, не требует компетенций, но дороже аутстаффинга. Экспертиза остаётся у подрядчика.
-
Инхаус — экспертиза остаётся внутри компании, но набирать сотрудников дорого, долго и сложно.
Пользуйтесь аутстаффингом, если в компании есть IT-процессы и налажен менеджмент. И аутсорсингом, если этого нет. Инхаус подойдёт там, где задачи по разработке находятся «на потоке», а сама компания прочно стоит на ногах. В противном случае вы рискуете неэффективно потратить бюджет, набрать ненужных сотрудников и получить отдел разработки за сумасшедшие деньги.
Источник фото на тизере: Damien TUPINIER on Unsplash
Рекомендуем:
- Интервью: еx-CMO сервиса «Чердак» о тонкостях построения инхаус-маркетинга
- Кому доверить разработку цифрового продукта: выбираем между аутсорсингом, аутстаффингом и фрилансом
- 25 инструментов профессионального разработчика. Личный топ Станислава Елисеева, Userstory
- Как быстро собрать команду мечты в соцсетях: гид для рекламных агентств
- Главные hard и soft скиллы разработчика. Личный топ Олега Власенко SimbirSoft
- Инструменты для управления командой в стиле Scrum и Agile на удалёнке. Личный топ Ольги Кварацхелия
Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.