На одном проекте клиент пришел с просьбой: "помогите найти программиста". После короткого аудита мы выкинули из первой версии половину идей, и стартовый бюджет упал на 30-40%. Не потому, что нашли кого-то подешевле, а потому, что задача наконец стала нормальной: с границами и приоритетами.
Я это вижу постоянно: бизнес ищет человека под продукт, который еще толком не описан. В такой ситуации даже сильный разработчик начинает додумывать за заказчика, а потом все удивляются срокам, правкам и лишним счетам.
Сначала соберите первую версию, потом открывайте поиск
Первый вопрос всегда один: что именно надо запустить. Сайт с заявками, кабинет для дилеров, модуль в CRM, интеграцию с 1С, внутреннюю автоматизацию. От этого зависит не только стек, но и сам формат найма.
У нас был запрос: "нужен разработчик на маркетплейс". После двух созвонов задача ужалась до каталога, кабинета продавца, загрузки товаров и приема оплаты. Логистику, отзывы и бонусы убрали. В итоге первая версия стала короче на 8 недель, а бюджет старта - меньше почти на 35%.
Частая ошибка: "нужен разработчик, который сделает платформу под ключ". Как правильнее: "нужно запустить первую версию с 3 сценариями, оплатой и админкой, без лишнего на старте".
До поиска я бы зафиксировал три вещи: что входит в первую версию, кто принимает результат, какой роли реально не хватает. Иногда нужен один Laravel 11 разработчик. Но если там роли, документы, обмен с CRM и приемка по нескольким сценариям, без QA и аналитики проект быстро начинает буксовать.
ТЗ должно помогать оценке, а не делать вид порядка
Мы давно ушли от ТЗ на 40 страниц для старта. Для первой оценки хватает документа на 1-2 страницы, если в нем есть цель, сценарии, ограничения, интеграции и критерии готовности. Самый полезный кусок - путь пользователя: что он делает, где может ошибиться и в какой момент задача считается завершенной.
Шаблон простой:
Цель:
Аудитория:
3 ключевых сценария:
Интеграции:
Ограничения:
Критерии готовности:
Must / Should / Could / Won't:
Кто принимает результат:
Пример из жизни. Вместо "нужна форма заказа" пишем так: клиент выбирает услугу, загружает 1-3 файла, выбирает дату, платит 30% предоплаты, менеджер получает уведомление в Telegram и email, заявка уходит в amoCRM. После такой записи оценка уже не похожа на гадание.
Можно искать человека без полного ТЗ? Можно. Но тогда нужен список допущений. Кандидат должен вслух сказать, что он считает известным, а что пока неизвестно. Если этого разговора нет, срок в 6-8 недель легко превращается в 10-12 недель.
На собеседовании смотрите, как человек думает
Сильного инженера видно по вопросам. Человек, который за 15 минут говорит "все сделаю", у меня всегда вызывает больше тревоги, чем тот, кто лезет в детали, спорит про риски и просит показать текущие процессы.
Я бы спросил вот это:
- Каких вводных не хватает для оценки?
- Как бы вы разбили работу на этапы?
- Что оставили бы в первой версии, а что отложили?
- Где тут самые вероятные риски?
- Как фиксируете договоренности - Jira, GitHub, документация?
Полезно услышать знакомые инструменты: Postman, Swagger, Docker, Sentry. Не ради красивых слов. По ним понятно, думает ли человек про деплой, диагностику и поддержку после релиза.
У нас был неудачный эпизод у клиента из оптовой торговли. Они настояли на кандидате, который почти не задавал вопросов и сразу пообещал кабинет дилера за 5 недель. В реальности вышло 11 недель: всплыли права доступа, обмен с 1С, сценарии ошибок и приемка по ролям. Проблема была не в человеке самом по себе - собеседование проверяло уверенность, а не зрелость.
Один разработчик - не всегда хорошая экономия
Когда бизнес спрашивает, где искать разработчика, я обычно перевожу разговор в другую плоскость: кто будет отвечать за результат целиком. Если задача узкая, без тяжелых интеграций, один сильный специалист или маленькая студия - нормальный вариант. Если это B2B-кабинет на Node.js 20 + NestJS, PostgreSQL 16, с документами и обменом с CRM или ERP, один человек быстро станет узким местом.
| Формат | Когда подходит | Главный риск |
|---|---|---|
| Фрилансер | Небольшая задача, мало зависимостей | всё держится на одном человеке |
| In-house | Постоянный поток доработок | Найм тянется 6-10 недель |
| Студия | Сайт, личный кабинет, быстрый запуск | Не все тянут сложную бизнес-логику |
| Подрядная dev-команда | Интеграции, B2B, поддержка после релиза | Ставка выше, но и ответственность шире |
На одном проекте по оптовым поставкам клиент сначала хотел одного "универсала" на кабинет дилера. После разбора стало ясно, что там роли, документы, история цен, уведомления и обмен с 1С. Мы собрали маленькую команду: аналитик, бэкенд, фронтенд и QA. Одним человеком там можно было только начать, а потом все равно пришлось бы расширяться, уже в авральном режиме.
Красные флаги видны еще до оффера
Если кандидат не спрашивает про цель бизнеса, не проговаривает допущения, не говорит про тестирование и поддержку, я бы не шел дальше, даже если резюме красивое. То же самое, если человек обещает сделать все сам там, где проект явно шире одной роли.
Еще один простой фильтр - может ли он объяснить решение обычным языком. Если после созвона у вас стало туманнее, чем до него, дальше будет много лишних встреч и мало движения. Хороший разработчик после разговора обычно упрощает картину, а не усложняет ее.
Перед поиском сделайте одну вещь: на одной странице напишите, что должно заработать в первую очередь и кто скажет "да, готово". Именно этот лист в истории из начала статьи и срезал лишние 30-40% бюджета - не торг, а ясность.
