Первый программист в стартап: как не сжечь бюджет и нервы

E

ElenaHarris

New member
Когда мы с партнёром запускали свой первый продукт, я был уверен, что нанять разработчика — это как нанять дизайнера: посмотрел портфолио, поговорил, взял. Реальность оказалась больнее. Первого кандидата мы отсеяли на тестовом, второй прошёл всё, отработал три месяца и ушёл, оставив после себя половину кодовой базы, в которой не разбирался даже он сам. С тех пор я провёл десятки собеседований и выработал несколько правил, которыми хочу поделиться.

Самое важное, что я понял: тестовое задание нужно не для того, чтобы проверить, умеет ли человек писать код. Это проверяется по резюме и паре вопросов. Тестовое нужно, чтобы увидеть, как человек думает, когда задача сформулирована криво и никто не подскажет. Поэтому мы даём не алгоритмическую головоломку, а кусок реальной продуктовой задачи: небольшой сервис, парсинг данных, простенький API. Два-четыре часа работы, не больше. И обязательно предупреждаем, что идеального решения не ждём.

Отдельно про оплату тестового. Если задача занимает больше двух часов, я плачу. Не потому что я добрый, а потому что бесплатные многочасовые тесты отсеивают сильных кандидатов с горящим рынком — они просто не станут тратить вечер на вашу «небольшую задачку для галочки». А слабые соглашаются. Получается обратная селекция, ровно наоборот от того, чего вы хотите.

На собеседовании я почти не спрашиваю про технологии. Спрашиваю про прошлые проекты: что было самым сложным, что бы сделал иначе, почему выбрал именно этот стек, с кем конфликтовал и как решал. Хороший разработчик легко рассказывает про грабли и ошибки. Плохой — рассказывает только про успехи и как всё было идеально спроектировано с первого раза. Это враньё, потому что так не бывает, и я это слышу сразу.

Красные флаги, которые для меня теперь стоп-сигнал. Первый: кандидат не задаёт ни одного вопроса про продукт, команду и бизнес. Ему интересен только стек и зарплата — значит, через полгода он уйдёт на проект с более модным стеком и плюс двадцать процентов. Второй: на вопрос «почему у вас на прошлом месте так вышло» отвечает исключительно про плохих менеджеров, тупых коллег и глупый бизнес. Возможно, всё так и было, но человек, который ни разу не сказал «я ошибся», в стартапе будет токсичен. Третий: агрессия на уточняющие вопросы. Спросил, почему выбрал эту библиотеку, — а в ответ раздражение и «а вы вообще в теме?». В маленькой команде такая реакция на обычное любопытство выстрелит на второй неделе.

Четвёртый флаг, самый дорогой: неумение сказать «я не знаю». Я специально задаю вопрос за пределами его компетенции, чтобы посмотреть на реакцию. Нормальный человек говорит: «Не работал с этим, но вот как я бы подошёл». Плохой начинает выкручиваться, выдумывать термины и нести чушь с уверенным лицом. В стартапе, где всё делается впервые и наугад, умение честно признать незнание — это половина выживания команды.

Что реально важно для первого найма? Не миллион лет опыта, а чувство ответственности за результат. Я всегда спрашиваю: «Что вы сделаете, если через неделю после релиза окажется, что фича не работает, а вас никто не просил её проверять?» Правильный ответ — что-то вроде «пойду разбираться сам, а потом скажу команде». Формально это не его работа. Неформально — именно такие люди вытаскивают продукты. Ещё я всегда беру испытательный срок и говорю об этом прямо: три месяца, обе стороны смотрят, никто не обижается. Честность на входе экономит месяцы взаимного раздражения.

И последнее, уже про деньги. Первому программисту не обязательно платить как в корпорации, но и торговаться до последнего рубля глупо. Вы покупаете не строчки кода, а человека, который будет рядом, пока вы ищете продукт-маркет фит. Дешёвый senior, которого вы выторговали на двадцать процентов, уйдёт через полтора месяца к тому, кто предложил больше. Дешевле сразу договориться по-человечески и не пересматривать условия каждые три месяца.

А теперь вопрос к вам, форумчане. Какой самый неожиданный красный флаг вы ловили на собеседованиях, который в итоге оказался стопроцентным предсказанием провала? Поделитесь — вместе мы соберём народную энциклопедию найма, которая сэкономит кому-то первому месяцы работы и кучу денег.
 
Как участник, который уже наступал на эти грабли: первый программист — это не «человек-оркестр», а скорее хирург. Сначала опишите MVP и критичные данные, которые он будет трогать: логины, платежи, персональные данные. Иначе он месяц строит идеальную архитектуру, а бюджет и нервы уходят в ноль. Лучше короткие итерации, четкие критерии готовности и обязательный минимум по защите: разграничение доступа, шифрование чувствительных полей, бэкапы и логи.

А вы как решали: брали одного универсала или подключали узких спецов на аутсорс? И где проходит ваша граница «MVP можно без сложной защиты» — или считаете, что базовую защиту данных нужно закладывать с первого коммита?
 
Ох, тема больная. По моему опыту, первый программист в геймдев-стартапе — это не «сеньор с самым красивым резюме», а человек, который быстро собирает прототипы, не страдает перфекционизмом и спокойно относится к тому, что половина фич уйдёт в мусор. Лучше взять крепкого универсала и дать оплачиваемое тестовое на пару дней: пусть сделает маленький вертикальный срез. Так и бюджет не сожжёте, и нервы сохраните.

А у вас как: вы ищете «человека-оркестра» или нанимаете под конкретную задачу? И где та граница, после которой уже пора звать второго программиста, а не героически тащить всё одному?
 
Ох, больная тема. Мне кажется, главная ошибка — искать первого программиста как «руки» под готовое ТЗ. На раннем этапе это скорее софаундер: он должен уметь резать фичи, быстро собирать MVP и честно говорить, где вы закопаетесь. Иначе бюджет уходит на переделки, а нервы — на взаимные ожидания.

Я бы для себя определил три вещи: оплата по этапам, короткие спринты с демо и письменная договорённость, кто владеет кодом и что будет, если не срастёмся. А как вы решали вопрос мотивации: только деньгами или всё-таки опцион и доля? Очень интересно, где проходит граница.
 
Ох, знакомая боль. Мой главный вывод после двух стартапов: первый программист — это не «руки, которые делают по ТЗ», а партнёр, который спорит с основателем. Мы однажды наняли джуна подешевле, чтобы «быстренько собрать MVP» — в итоге за полгода переписали всё с нуля и потеряли больше, чем сэкономили на зарплате. С тех пор правило простое: если не можешь объяснить задачу на пальцах и не готов платить за код-ревью со стороны — не начинай, сначала сам разберись в продуктовой логике.

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

И ещё про нервы: основателю всё равно придётся самому тестировать, писать тикеты и разбираться в продукте. Нанимать разработчика, чтобы «он сам придумал и сделал» — верный путь к выгоранию с обеих сторон. А у вас как было: сразу искали сильного универсала или брали по знакомству, чтобы сэкономить?
 
Вы должны войти или зарегистрироваться, чтобы отвечать здесь.
Назад
Вверх