Как выбрать разработчика или команду: чек‑лист заказчика (без воды и “волшебных” обещаний)
Запросы “как выбрать разработчика”, “как нанять программиста”, “как выбрать подрядчика на разработку” обычно появляются, когда вы уже поняли главное: красивое портфолио не гарантирует сроки, качество и предсказуемость.
Ниже — практичный чек‑лист, который помогает отличить профессиональную разработку от “давайте попробуем”.
1) Сначала — 3 вещи, которые надо зафиксировать вам (до поиска исполнителя)
- Цель: что изменится в бизнесе после релиза (метрика/результат)
- MVP: что обязательно в первой версии, а что позже
- Ограничения: сроки, бюджет, платформы, интеграции
Если этого нет, вы не выбираете разработчика — вы выбираете “у кого красивее разговор”.
2) Портфолио: как смотреть правильно
Проверяйте не “красиво”, а “похоже на ваш риск”:
- есть ли проекты с интеграциями (платежи/CRM/вебхуки)
- есть ли опыт поддержки продакшена (логи, мониторинг, инциденты)
- есть ли проекты с ролями/правами, админками
- есть ли примеры архитектурных решений, а не только UI
Если в портфолио только “лендинги” — вероятно, сложный продукт будет проблемой.
3) Оценка: что считается нормой, а что красный флаг
Норма
- оценка диапазоном (X–Y) + допущения
- декомпозиция по модулям/сценариям
- список рисков и неизвестностей
- предложение итераций (MVP → релизы)
Красные флаги
- “сделаю за 2 недели” без сценариев и критериев
- “фикс‑прайс” без scope и out‑of‑scope
- игнор интеграций (“подключим как‑нибудь”)
- нет вопросов про нагрузку/безопасность/данные
4) 10 вопросов, которые быстро показывают уровень исполнителя
- Как вы превращаете идею в требования/ТЗ?
- Как вы фиксируете scope и защищаете бюджет от “допработ”?
- Как вы работаете с интеграциями (ретраи, очереди, идемпотентность)?
- Как вы предотвращаете регресс (тесты, чек‑лист релиза)?
- Что такое Definition of Done?
- Как вы ведёте “прод”: логи, метрики, алерты?
- Как вы документируете решения (ADR/README/runbook)?
- Как выглядит процесс коммуникации (демо, отчёты, частота)?
- Как вы принимаете работу (acceptance criteria)?
- Что вы делаете, когда сроки начинают “плыть”?
Если на эти вопросы нет внятных ответов — риск высокий.
5) Тестовое задание: когда оно нужно и каким должно быть
Для небольших задач тестовое может помочь, но оно должно быть:
- коротким (2–4 часа)
- похожим на реальную работу (интеграция/обработка ошибок/чистота кода)
- с критериями “готово”
Тестовое “на 3 дня” — обычно сигнал проблемного процесса найма.
6) Контракт и процесс: как защитить себя как заказчик
Минимальные элементы:
- scope + out‑of‑scope
- поэтапная приёмка по критериям
- демо раз в 1–2 недели
- прозрачный доступ к репозиторию и трекеру задач
- правила изменения требований (change request)
7) Самый частый “лучший” подход
Для большинства проектов хорошо работает:
- короткая discovery‑сессия → требования → оценка диапазоном
- MVP‑релиз
- итерации
Так вы покупаете не “обещание”, а управляемую поставку.
FAQ
Как понять, что исполнитель “сеньор”, а не просто уверенно говорит?
По вопросам к требованиям, интеграциям, рискам, quality gates и прод‑эксплуатации.
Команда лучше, чем один разработчик?
Не всегда. Команда ускоряет только при реальной параллельности и нормальном процессе.
Что самое важное в начале?
Сценарии, интеграции, scope/out‑of‑scope и критерии приёмки.
Если хотите — дам короткий чек‑лист выбора подрядчика: вопросы на интервью, красные флаги, критерии приёмки и как читать смету.