Первого программиста я нанимал дважды, и во второй раз уже понимал, что это не про код, а про деньги и нервы. Первый заход был классическим: я, основатель небольшого бизнеса с бухгалтерией в Excel и заявками в мессенджере, решил, что мне нужен «сильный разработчик, который всё сделает». Разместил вакансию, получил три сотни откликов, провёл двадцать собеседований и в итоге взял человека, который через четыре месяца ушёл, оставив после себя папку с кодом и ноль документации. Стоило это дороже, чем весь мой маркетинговый бюджет за год. Так что ниже — не теория из книжки, а то, что я вынес из своих ошибок и из ошибок знакомых предпринимателей.
Начинать надо не с поиска, а с вилки. Самая частая ошибка новичка — писать «зарплата по результатам собеседования» и надеяться, что рынок сам подскажет. Рынок подскажет, только когда вы уже потратили месяц. Я теперь делаю так: считаю, сколько денег могу отдавать в месяц без ущерба для бизнеса, вычитаю налоги и взносы, и только потом смотрю, кто попадает в этот диапазон. Важный момент — разброс цен на одного и того же специалиста может отличаться в два раза в зависимости от региона, формата занятости и того, готов ли человек работать на проект, а не в штат. Не гонитесь за сеньором на старте: для задачи «прикрутить оплату и убрать ручную работу менеджера» часто хватает крепкого мидла, а разницу в цене лучше потратить на второй месяц его работы.
Где искать — отдельная история. Я перестал верить в холодные отклики на агрегаторах: там слишком много людей, которые рассылают резюме веером. Работающие каналы оказались скучными и человеческими: знакомые, которые уже нанимали разработчиков, профильные чаты, локальные IT-сообщества, преподаватели с курсов. Кадровые агентства на этапе первого найма я считаю роскошью — комиссия за закрытие вакансии может съесть два-три месячных бюджета, а гарантия обычно длится ровно до конца испытательного срока. Зато рекомендация от человека, который работал с кандидатом лично, экономит недели собеседований.
Тестовое задание — мой главный фильтр, но только если оно сделано правильно. Я больше не даю алгоритмические задачки с LeetCode: они показывают умение решать головоломки, а не умение разобраться в чужом проекте. Вместо этого я вырезаю из своего бэклога реальную небольшую задачу на три-пять часов и, что важно, плачу за неё. Платное тестовое сразу отсекает тех, кто рассылает одинаковые решения, и не выглядит как бесплатная работа. Смотрю не столько на результат, сколько на процесс: задаёт ли человек уточняющие вопросы, пишет ли, что именно непонятно, что он предполагает и какие видит риски. Тот, кто молча присылает идеальный код без единого вопроса, в реальной команде часто оказывается самым проблемным.
На собеседовании я перестал спрашивать про фреймворки и начал спрашивать про опыт. Прошу рассказать о случае, когда что-то сломалось на продакшене, и смотрю, как человек об этом говорит: обвиняет других или разбирает собственную часть ответственности. Прошу объяснить простыми словами, как он будет делать конкретную фичу в моём продукте, какие видит подводные камни. Любой специалист с реальным опытом начнёт задавать встречные вопросы про нагрузку, про данные, про то, кто будет принимать результат. Это хороший знак. И обязательно смотрю на историю активности: регулярные коммиты в публичные репозитории говорят больше, чем красивое портфолио из картинок.
Теперь про риски, о которых обычно молчат. Первый и главный — автобусный фактор. Если все знания о вашей системе живут в одной голове, вы не бизнесмен, а заложник. С самого начала договаривайтесь о минимальной документации и доступах: репозиторий, хостинг, домен, панель платежей должны быть оформлены на вас, а не на разработчика. Второй риск — юридический. Работа с самозанятым или ИП дешевле штата, но требует аккуратных договоров и понимания, что налоговая может пересмотреть такие отношения. Я не даю юридических советов, но советую не экономить на консультации бухгалтера до подписания, а не после. Третий риск — люди уходят: закладывайте испытательный срок, постепенное расширение доступа и план на случай, если человек исчезнет через два месяца.
И последнее — про экономику. Первый программист почти никогда не окупается в первый месяц. Я считаю честно: два-три месяца он вникает, и всё это время вы платите и не получаете быстрых результатов. Если денег впритык, иногда разумнее взять не человека в штат, а небольшую команду на конкретный результат — дороже за час, зато без обязательств и с фиксированным сроком. Но если у вас есть повторяющиеся задачи и вы готовы вкладываться в отношения, свой человек в команде со временем даёт то, что не даст никакой подрядчик: понимание вашего бизнеса изнутри.
В итоге мой рецепт простой: сначала считаете бюджет, потом ищете через людей, а не через доски, проверяете реальной оплаченной задачей, разговариваете про ошибки, а не про технологии, и с первого дня страхуете себя контрактом, доступами и документацией. Всё остальное — опыт, который придётся набивать самому. А теперь вопрос к вам, форумчане: нанимали ли вы первого разработчика в команду, и что оказалось самым неожиданным — цена, уровень кандидатов или то, сколько времени ушло на онбординг? Делитесь историями, вместе мы точно соберём неплохой гайд для тех, кто только собирается это повторить.
Начинать надо не с поиска, а с вилки. Самая частая ошибка новичка — писать «зарплата по результатам собеседования» и надеяться, что рынок сам подскажет. Рынок подскажет, только когда вы уже потратили месяц. Я теперь делаю так: считаю, сколько денег могу отдавать в месяц без ущерба для бизнеса, вычитаю налоги и взносы, и только потом смотрю, кто попадает в этот диапазон. Важный момент — разброс цен на одного и того же специалиста может отличаться в два раза в зависимости от региона, формата занятости и того, готов ли человек работать на проект, а не в штат. Не гонитесь за сеньором на старте: для задачи «прикрутить оплату и убрать ручную работу менеджера» часто хватает крепкого мидла, а разницу в цене лучше потратить на второй месяц его работы.
Где искать — отдельная история. Я перестал верить в холодные отклики на агрегаторах: там слишком много людей, которые рассылают резюме веером. Работающие каналы оказались скучными и человеческими: знакомые, которые уже нанимали разработчиков, профильные чаты, локальные IT-сообщества, преподаватели с курсов. Кадровые агентства на этапе первого найма я считаю роскошью — комиссия за закрытие вакансии может съесть два-три месячных бюджета, а гарантия обычно длится ровно до конца испытательного срока. Зато рекомендация от человека, который работал с кандидатом лично, экономит недели собеседований.
Тестовое задание — мой главный фильтр, но только если оно сделано правильно. Я больше не даю алгоритмические задачки с LeetCode: они показывают умение решать головоломки, а не умение разобраться в чужом проекте. Вместо этого я вырезаю из своего бэклога реальную небольшую задачу на три-пять часов и, что важно, плачу за неё. Платное тестовое сразу отсекает тех, кто рассылает одинаковые решения, и не выглядит как бесплатная работа. Смотрю не столько на результат, сколько на процесс: задаёт ли человек уточняющие вопросы, пишет ли, что именно непонятно, что он предполагает и какие видит риски. Тот, кто молча присылает идеальный код без единого вопроса, в реальной команде часто оказывается самым проблемным.
На собеседовании я перестал спрашивать про фреймворки и начал спрашивать про опыт. Прошу рассказать о случае, когда что-то сломалось на продакшене, и смотрю, как человек об этом говорит: обвиняет других или разбирает собственную часть ответственности. Прошу объяснить простыми словами, как он будет делать конкретную фичу в моём продукте, какие видит подводные камни. Любой специалист с реальным опытом начнёт задавать встречные вопросы про нагрузку, про данные, про то, кто будет принимать результат. Это хороший знак. И обязательно смотрю на историю активности: регулярные коммиты в публичные репозитории говорят больше, чем красивое портфолио из картинок.
Теперь про риски, о которых обычно молчат. Первый и главный — автобусный фактор. Если все знания о вашей системе живут в одной голове, вы не бизнесмен, а заложник. С самого начала договаривайтесь о минимальной документации и доступах: репозиторий, хостинг, домен, панель платежей должны быть оформлены на вас, а не на разработчика. Второй риск — юридический. Работа с самозанятым или ИП дешевле штата, но требует аккуратных договоров и понимания, что налоговая может пересмотреть такие отношения. Я не даю юридических советов, но советую не экономить на консультации бухгалтера до подписания, а не после. Третий риск — люди уходят: закладывайте испытательный срок, постепенное расширение доступа и план на случай, если человек исчезнет через два месяца.
И последнее — про экономику. Первый программист почти никогда не окупается в первый месяц. Я считаю честно: два-три месяца он вникает, и всё это время вы платите и не получаете быстрых результатов. Если денег впритык, иногда разумнее взять не человека в штат, а небольшую команду на конкретный результат — дороже за час, зато без обязательств и с фиксированным сроком. Но если у вас есть повторяющиеся задачи и вы готовы вкладываться в отношения, свой человек в команде со временем даёт то, что не даст никакой подрядчик: понимание вашего бизнеса изнутри.
В итоге мой рецепт простой: сначала считаете бюджет, потом ищете через людей, а не через доски, проверяете реальной оплаченной задачей, разговариваете про ошибки, а не про технологии, и с первого дня страхуете себя контрактом, доступами и документацией. Всё остальное — опыт, который придётся набивать самому. А теперь вопрос к вам, форумчане: нанимали ли вы первого разработчика в команду, и что оказалось самым неожиданным — цена, уровень кандидатов или то, сколько времени ушло на онбординг? Делитесь историями, вместе мы точно соберём неплохой гайд для тех, кто только собирается это повторить.