Кейс «Датапрофи»: подбор команды разработки из пяти человек за 4 месяца
Клиент: Датапрофи — ИТ-сервисная компания из Электростали: 20 лет на рынке, больше 2000 клиентов, ИТ-аутсорсинг, 1С, CRM, серверы, кибербезопасность, сети и видеонаблюдение.
Услуга: подбор IT-специалистов
Срок сотрудничества: 4 месяца, разовый проект под запуск направления
Позиции: Python-программист, Backend-разработчик, Frontend-разработчик, тестировщик
Результат: за 4 месяца собрали команду разработки из 5 человек, а через полгода её работы первая версия клиентского портала открылась для клиентов на поддержке.
Разработка внутри сервиса
Датапрофи двадцать лет живёт по законам сервиса: заявка, ответ в среднем за 15 минут, выезд, закрытие. В штате инженеры, 1С-специалисты, сетевики. Своего программного продукта у компании не было: всё, что нужно клиентам, внедрялось и настраивалось на готовых системах. Но с ростом базы до двух тысяч клиентов стало понятно, что часть работы проще автоматизировать, чем делать руками. Клиентам нужен понятный портал с заявками и статусами, инженерам данные мониторинга серверов клиентов в одном месте, внедренцам 1С и CRM повторяемые интеграции вместо скриптов, которые каждый раз пишутся заново.
Руководство решило запустить внутри компании своё направление разработки и начать с клиентского портала (сервис-деск с личным кабинетом), автоматизации мониторинга и интеграций 1С с CRM и сайтами. Нужны были четыре роли: Backend-разработчик, Python-программист, Frontend-разработчик и тестировщик.
Главный риск мы увидели на первой же встрече. В сервисной компании всегда горит какая-то заявка, и самый удобный человек, чтобы её закрыть, это программист, который сидит рядом и «всё равно разбирается в серверах». Если не защитить разработчиков от этого, через месяц они станут ещё одними инженерами поддержки, а портал так и останется в планах. Кандидаты это чувствуют: слово «аутсорсинг» в вакансии многих разработчиков отпугивает сразу.
Центральная идея проекта: разработчиков в сервисную компанию нужно нанимать как отдельную продуктовую команду с защищёнными задачами, и кандидат должен видеть это с первой строки вакансии.
Как мы устроили работу
До начала поиска мы вместе с техническим директором Датапрофи зафиксировали три правила. Первое: команда разработки не берёт заявки первой линии, исключения только через техдиректора. Второе: стек выбран заранее (Python и FastAPI на бэкенде, PostgreSQL, Vue на фронте), чтобы не собирать людей под разные вкусы. Третье: у продукта есть внутренний заказчик и описанная первая версия, а не «будем думать вместе».
Затем развели роли. Backend-разработчик отвечает за ядро портала: модель заявок, SLA-таймеры, роли и права клиентов, API для фронта. Python-программист работает на периферии: агенты и сборщики мониторинга, интеграции с 1С через HTTP-сервисы, обмены с Битрикс24 и amoCRM. Frontend-разработчик делает личный кабинет клиента, тестировщик проверяет и портал, и интеграции.
Формат: офис в Электростали плюс гибрид. Фронтендер и тестировщик 2 дня в неделю в офисе, потому что им нужно общаться с инженерами поддержки, будущими пользователями портала. Бэкенд и Python могут работать удалённо, с приездом раз в две недели на планирование. Офисные роли искали по Электростали, Ногинску, Балашихе, Щёлкову и Орехово-Зуеву, удалённые по всей России.
Сложности и решения
1. Слово «аутсорсинг» в вакансии. Первая версия вакансии, написанная внутри компании, начиналась с истории Датапрофи как ИТ-аутсорсера. Откликались системные администраторы, а разработчики пролистывали. Мы переписали текст от продукта: «строим клиентский портал для 2000 компаний, которые уже на поддержке», с описанием первой версии и прямой фразой, что разработка не дежурит на заявках. Доля целевых откликов выросла с четверти до двух третей.
2. Два питониста, которые не должны быть одинаковыми. Backend-разработчик и Python-программист пишут на одном языке, и первые кандидаты подходили на обе вакансии сразу. Мы сделали разные скрининги. Бэкендеру задавали вопросы про проектирование: как хранить историю статусов заявки, как считать SLA с учётом рабочих часов конкретного клиента. Python-программисту про интеграции: что будет, если выгрузка документа из 1С придёт дважды, и как сделать обмен идемпотентным. Пересечение кандидатов между вакансиями почти исчезло, и каждый финалист был сильнее именно в своей зоне.
3. Python без 1С и 1С без Python. Хорошие питонисты почти никогда не знают 1С, а программисты 1С редко пишут на Python. Ждать человека, который совмещает оба, можно было месяцами. Мы предложили опереться на то, что у компании уже есть: свои 1С-специалисты делают сторону 1С (HTTP-сервисы, OData), а Python-программист отвечает за обмен и его логику. Искали людей с опытом интеграций любых учётных систем и маркетплейсов, а знание 1С сделали плюсом, а не требованием.
4. Мониторинг на чужих серверах. Сборщики мониторинга ставятся на серверы клиентов, и ошибка в агенте может нагрузить или положить чужую инфраструктуру. От Python-программиста здесь нужна аккуратность системного администратора. В финал брали тех, кто без подсказки спрашивал про права агента, потребление ресурсов и обновления. Одного сильного по коду кандидата клиент сам отклонил после вопроса о том, как откатить неудачную версию агента сразу на 300 серверах.
5. Портал для бухгалтеров, а не для айтишников. Основные пользователи личного кабинета это бухгалтеры и офис-менеджеры клиентов, которым нужна одна кнопка «у нас не работает 1С». При подборе Frontend-разработчика искали кандидатов с опытом личных кабинетов и внутренних систем, а не лендингов, и в тестовом давали задачу сверстать список заявок с фильтрами так, чтобы в нём разобрался неподготовленный пользователь. По решениям было сразу видно, кто думает о человеке за экраном.
6. Тестировщик на стыке портала и учёта. Проверять нужно не только интерфейс, но и цепочки: заявка, статус, уведомление, выгрузка в 1С и CRM. Поэтому при подборе тестировщика искали кандидатов с опытом API-тестирования и работы с учётными системами. На скрининге просили составить тест-кейсы для ситуации, когда один и тот же документ изменили одновременно в 1С и в CRM.
Час с HR-директором бесплатно
Продуктивный разговор о найме с HR-директором A2. Только для компаний от 20 сотрудников
Аналитика по воронке
Сводная воронка по позициям, за весь проект
| Позиция | Кандидатов | Скрининг | Техническое интервью | Финал | Оффер | Вышли |
|---|---|---|---|---|---|---|
| Backend-разработчик | 134 | 29 | 12 | 4 | 2 | 1 |
| Python-программист | 176 | 41 | 16 | 6 | 3 | 2 |
| Frontend-разработчик | 152 | 33 | 13 | 5 | 2 | 1 |
| Тестировщик | 189 | 40 | 14 | 5 | 1 | 1 |
| Итого | 651 | 143 | 55 | 20 | 8 | 5 |
Python-программист, конверсии по этапам
| Этап | Количество | Конверсия |
|---|---|---|
| Отклики и активный поиск | 176 | — |
| Прошли скрининг (вкл. вопрос про повторную выгрузку) | 41 | 23,3% |
| Техническое интервью | 16 | 39,0% |
| Финал с техническим директором | 6 | 37,5% |
| Оффер | 3 | 50,0% |
| Вышли на работу | 2 | 66,7% |
Целевые отклики до и после смены текста вакансий
| Период | Всего откликов | Из них разработчики и тестировщики | Доля |
|---|---|---|---|
| Первые 2 недели | 212 | 54 | 25,5% |
| Следующие 2 недели | 186 | 124 | 66,7% |
Источники кандидатов
| Позиция | Основные каналы |
|---|---|
| Backend-разработчик и Python-программист | hh.ru (~45%), прямой поиск (~30%), Хабр Карьера (~25%) |
| Frontend-разработчик | hh.ru (~55%), telegram-чаты (~25%), Хабр Карьера (~20%) |
| Тестировщик | hh.ru (~65%), telegram-чаты тестировщиков (~20%), рекомендации (~15%) |
Смена текста вакансии дала больше, чем любой новый канал: за две недели доля целевых откликов выросла с 25,5% до 66,7% при почти том же общем потоке. Дальше самый жёсткий фильтр стоял у Backend-разработчика: до финала дошли 4 человека из 134, потому что вопросы про модель данных и SLA быстро отделяли тех, кто проектировал системы, от тех, кто писал эндпоинты по готовому ТЗ. По Python-программисту воронка шире, и мы закрыли двух человек: второй занялся мониторингом, когда стало ясно, что агенты и интеграции одному не потянуть. У тестировщика из пяти финалистов оффер получил один, клиент сознательно ждал кандидата с опытом проверки обменов с учётными системами.
Что в итоге
За 4 месяца Датапрофи получила команду разработки из пяти человек: Backend-разработчика, двух Python-программистов, Frontend-разработчика и тестировщика. Правило «разработка не берёт заявки» компания удержала, и через полгода работы команды первая версия клиентского портала открылась для клиентов на поддержке: заявки, статусы, история обращений и базовые данные мониторинга. Интеграции 1С с CRM, которые раньше каждый раз писались заново, начали собираться из общих модулей.
Главный вывод: когда сервисная компания запускает разработку, найм начинается не с вакансии, а с договорённости внутри компании о том, что разработчиков не будут забирать на текущие задачи. Без неё сильные кандидаты либо не придут, либо уйдут через полгода, а слабые растворятся в поддержке.
И второе. Не надо искать единорога, который знает и Python, и 1С, и мониторинг. Гораздо быстрее разделить работу между новыми людьми и теми, кто уже есть в компании, и нанимать под свою часть задачи.
Если вы сервисная или интеграторская компания и запускаете своё направление разработки, напишите нам. Подбор IT-специалистов начнём с того, как защитить новую команду, и только потом перейдём к вакансиям.
