+7 (495) 240-82-92
+7 (495) 240-82-92 Позвоните мне
Главная Блог Как выбрать подрядчика на разработку: чек-лист для бизнеса

Как выбрать подрядчика на разработку: чек-лист для бизнеса

Разработка
10 марта 2026
12 мин чтения

Практичный чек-лист выбора подрядчика на разработку: критерии, red flags, вопросы на встрече, сравнение Fixed и T&M и чек-лист старта проекта.

Содержание

На рынке много исполнителей, которые одинаково уверенно обещают «сроки, качество и ответственность». Но реальная разница — не в красивой презентации, а в зрелости процессов: как подрядчик уточняет требования, управляет рисками, обеспечивает качество и фиксирует договорённости.

Эта статья — инструмент для бизнеса: чек-лист, по которому можно быстро отсеять слабых кандидатов и выбрать управляемого IT-подрядчика под ваши цели.

Какой формат подрядчика выбрать под задачу

Ниже — быстрый ориентир. Он не про «кто лучше», а про «кто подходит» под ваш риск-профиль и масштаб.

Мини-сравнение форматов

Формат Подходит, если… Рискованно, если…
Фриланс маленькие задачи, понятные требования, есть сильный техлид/CTO внутри нет внутренней экспертизы, нужен SLA/поддержка, сложная интеграция
Небольшая студия нужен сайт/лендинг/типовой проект, важна цена требуется стабильная команда, масштабирование, глубокая аналитика и QA
Агентство / продуктовая команда нужен результат «под ключ», прозрачное управление, инженерия, QA/DevOps вы хотите «только код» без процессов и регулярной коммуникации
In-house (в штат) продукт — ключевая компетенция компании, долгий горизонт развития нужно стартовать быстро или проект нерегулярный/волнами

Практическое правило:

  • если проект сложный, интеграционный, с риском простоя, выбирайте тех, кто умеет управлять разработкой и качеством;
  • если задача локальная и понятная, можно оптимизировать бюджет более простым форматом — но только при наличии контроля внутри.

18 критериев выбора подрядчика

Ниже — основной чек-лист. Для каждого пункта: как проверить, что запросить, признак «ок», красный флаг.

A) Экспертиза и релевантный опыт

1. Опыт в вашем домене (или в похожей бизнес-логике)

  • Как проверить: попросить 2–3 кейса «похожей сложности» (не обязательно той же отрасли).
  • Что запросить: описание задачи, ограничения, архитектурные решения, метрики результата.
  • Ок: подрядчик говорит про компромиссы и причины решений.
  • Red flag: только «красивые экраны» и общие слова без деталей.

2. Понимание цели бизнеса, а не только требований

  • Как проверить: на созвоне спросить «как вы поймёте, что проект успешен?».
  • Что запросить: список гипотез/рисков и что нужно уточнить в Discovery.
  • Ок: задают вопросы про метрики, пользователей, ограничения, процессы.
  • Red flag: «давайте просто сделаем как в ТЗ» без уточнений.

3. Релевантный стек и зрелость архитектуры

  • Как проверить: попросить объяснить, почему выбран стек, как обеспечивают масштабирование.
  • Что запросить: high-level архитектурную схему, подход к интеграциям/данным.
  • Ок: объясняют простым языком и показывают варианты.
  • Red flag: «у нас один стек на всё» без аргументов.

B) Процессы и управление

4. Наличие этапа Discovery (или аналогичного предпроектного анализа)

  • Как проверить: спросить, что именно делают до оценки и разработки.
  • Что запросить: состав артефактов (беклог, прототипы, acceptance criteria).
  • Ок: есть понятные выходы и сроки Discovery.
  • Red flag: оценка «с ходу» без вопросов и уточнений.

5. Прозрачное планирование и контроль прогресса

  • Как проверить: попросить пример отчёта/дашборда по проекту.
  • Что запросить: формат спринтов/демо, частота статусов, кто участвует.
  • Ок: регулярные демо, понятные статусы, прогноз по срокам.
  • Red flag: «мы пришлём, когда будет готово».

6. Коммуникации и единая точка ответственности

  • Как проверить: кто ваш контакт, кто принимает решения на стороне подрядчика.
  • Что запросить: RACI или описание ролей (PM, тимлид, аналитик).
  • Ок: есть PM/Delivery, понятные каналы и SLA ответов.
  • Red flag: «пишите в общий чат, кто ответит — тот ответит».

C) Качество и инженерия

7. Code review и стандарты разработки

  • Как проверить: спросить про правила PR, кто ревьюит, критерии качества.
  • Что запросить: краткий гайд/чек-лист ревью (пусть даже шаблон).
  • Ок: есть definition of done и требования к PR.
  • Red flag: «ревью не нужно, мы и так умеем».

8. Тестирование (ручное/авто) и критерии приёмки

  • Как проверить: как предотвращают регресс, кто отвечает за тестирование.
  • Что запросить: стратегия тестирования, примеры тест-кейсов/чек-листов.
  • Ок: тестирование — часть процесса, а не «по желанию».
  • Red flag: «протестируем в конце».

9. CI/CD, релизы и управляемость поставки

  • Как проверить: как часто релизы, как откатывают, где окружения.
  • Что запросить: схема окружений (dev/stage/prod), процесс релиза.
  • Ок: автоматизация сборки/деплоя хотя бы на базовом уровне.
  • Red flag: «зальём руками на сервер».

D) Команда и роли

10. Состав команды соответствует задаче

  • Как проверить: попросить описать роли и занятость ключевых участников.
  • Что запросить: кто будет тимлидом, кто QA, кто аналитик.
  • Ок: роли закрыты, нет «универсального человека на всё».
  • Red flag: «у нас один разработчик и он же PM».

11. Стабильность команды и план замены

  • Как проверить: спросить, как действуют при замене ключевого специалиста.
  • Что запросить: регламент передачи знаний, документация.
  • Ок: есть план continuity (замена без остановки проекта).
  • Red flag: «если уйдёт — посмотрим».

12. Готовность работать в ваших процессах и инструментах

  • Как проверить: готовы ли работать в вашем таск-трекере, репозитории, календаре.
  • Что запросить: список требований по доступам/ИБ.
  • Ок: адаптируются под клиента, соблюдают регламенты.
  • Red flag: «работаем только у себя, отчёты — раз в месяц».

E) Договор, права и поддержка

13. NDA и требования ИБ/конфиденциальности

  • Как проверить: готовы ли подписать NDA до получения деталей.
  • Что запросить: практики по доступам, хранению секретов, логированию.
  • Ок: понятные правила доступа и минимизация прав.
  • Red flag: «скиньте доступы, потом разберёмся».

14. Права на результаты работ и исходный код

  • Как проверить: кто владеет кодом, где репозиторий, кому принадлежат артефакты.
  • Что запросить: формулировку о передаче исключительных прав (или лицензии).
  • Ок: права и доступы закреплены договором.
  • Red flag: код у подрядчика «на его аккаунте».

15. Поддержка, гарантия, SLA

  • Как проверить: что происходит после релиза, какие сроки реакции на инциденты.
  • Что запросить: варианты SLA (реакция/решение, приоритеты).
  • Ок: поддержка — отдельный понятный контур.
  • Red flag: «после сдачи — как получится».

F) Бюджет и модель работы

16. Адекватность оценки и прозрачность сметы

  • Как проверить: попросить декомпозицию на этапы/эпики/задачи.
  • Что запросить: допущения и список «что НЕ входит».
  • Ок: оценка привязана к объёму и рискам.
  • Red flag: одна цифра «за всё» без состава работ.

17. Управление изменениями (change requests)

  • Как проверить: что будет, если поменяются требования.
  • Что запросить: регламент изменений (влияние на срок/бюджет).
  • Ок: изменения фиксируются и пересчитываются прозрачно.
  • Red flag: «всё включено» (обычно это означает скрытые конфликты).

18. Финансовая дисциплина и прогнозируемость

  • Как проверить: как выставляют акты/инвойсы, как фиксируют факт работ.
  • Что запросить: пример отчёта по трудозатратам (для T&M) или этапам (для Fixed).
  • Ок: понятная схема закрытия периодов и отчётность.
  • Red flag: «оплатите вперёд, дальше разберёмся».

Короткий callout: 7 красных флагов подрядчика

  • Даёт оценку без вопросов и анализа.
  • Не показывает процесс и артефакты (беклог/демо/отчётность).
  • Нет QA/релизного процесса.
  • Код/доступы «только у подрядчика».
  • Состав команды размытый, нет ответственных ролей.
  • Не готов фиксировать правила изменений.
  • Обещает «точные сроки/цену» без Discovery.

Кейс нашего долгосрочного эффективного сотрудничества с крупнейшей сетью зоомагазинов с доставкой по всей России

Fixed Price vs Time & Materials — обязательная таблица

Критерий Fixed Price (фикс) Time & Materials (T&M)
Когда подходит требования стабильные, понятный объём требования уточняются, нужен гибкий roadmap
Гибкость низкая: изменения через допсоглашения высокая: приоритеты можно менять по ходу
Риск перерасхода чаще скрыт в «запасах» или конфликте по изменениям управляемый: платите за фактическую работу
Прозрачность зависит от детализации ТЗ и приёмки высокая при нормальной отчётности и трекинге
Кто несёт риск подрядчик (но компенсирует условиями) заказчик (но контролирует объём/приоритеты)
Типовые конфликты «это не входило», «переделайте бесплатно» «почему столько часов», «где результат»
Как снизить риски чёткое ТЗ, критерии приёмки, change requests прозрачный трекинг, демо, лимиты, план спринтов

Вопросы подрядчику на первой встрече

  1. Как вы проводите Discovery и что выдаёте на выходе?
  2. Кто будет PM/тимлидом и сколько времени они реально выделяют проекту?
  3. Как вы оцениваете задачи: сверху вниз или через декомпозицию?
  4. Как выглядит ваша отчётность (дашборд/спринт-репорты/демо)?
  5. Как часто будут демо и кто должен присутствовать с нашей стороны?
  6. Как устроено тестирование: кто отвечает за QA и приёмку?
  7. Какие практики качества обязательны (ревью, линтеры, статанализ)?
  8. Как вы делаете релизы: CI/CD, окружения, откаты, “окна” релизов?
  9. Как вы управляете изменениями требований (change requests)?
  10. Где будет репозиторий и кому принадлежат доступы/права на код?
  11. Как вы обеспечиваете безопасность (доступы, секреты, логи)?
  12. Что происходит после релиза: гарантия, поддержка, SLA?
  13. Какие риски вы видите в нашем проекте уже сейчас?
  14. Покажите пример документа/артефакта, который вы делаете всегда (беклог, AC, план релизов).

Чек-лист перед стартом проекта

  1. Цели и метрики успеха (что именно улучшится и как измеряем).
  2. Скоуп v1: список «входит/не входит», приоритеты.
  3. Роли и ответственность (RACI): кто принимает решения, кто согласует.
  4. Артефакты: беклог, прототипы, acceptance criteria, DoD.
  5. Доступы: репозиторий, аналитика, серверы/облака, тестовые стенды.
  6. Окружения: dev/stage/prod, правила деплоя, данные для тестов.
  7. Коммуникации: статусы, демо, каналы, SLA ответов.
  8. Качество: правила PR/review, тестирование, критерии приёмки.
  9. План релизов: итерации, контрольные точки, релиз-календарь.
  10. Управление изменениями: как согласуем, как пересчитываем сроки/бюджет.

Два мини-сценария: “плохо выбрали” и “правильно выбрали”

Сценарий 1 — выбрали “по цене и обещаниям”

Симптомы:

  • оценка “за неделю” без вопросов;
  • нет Discovery;
  • один человек “и разработчик, и PM”;
  • приёмка без критериев.

Последствия:

  • требования уточняются в процессе → конфликты “это не входило”;
  • релиз с багами → срочные правки и простои;
  • код и доступы у подрядчика → зависимость и сложная передача.

Где ошиблись по чек-листу: критерии 4–9 и 14–17 (процесс, качество, права, change requests).

Сценарий 2 — выбрали “по управляемости”

Что сделали:

  • провели короткий Discovery: цели, скоуп v1, риски;
  • запросили артефакты: беклог с AC, план релизов, пример отчётности;
  • зафиксировали права на код и порядок приёмки;
  • согласовали модель (чаще T&M) + лимиты и регулярные демо.

Результат

  • прозрачный прогресс: демо каждые 1–2 недели;
  • изменения требований не ломают проект — пересчитываются заранее;
  • релизы контролируемые, есть поддержка после запуска.

Готовые формулировки для ТЗ/договора

1) Права на код и результаты работ

Исключительные права на результаты работ, включая исходный код, документацию и иные артефакты, переходят к Заказчику с момента оплаты соответствующего этапа/отчётного периода. Репозиторий проекта размещается в аккаунте Заказчика либо предоставляется Заказчику полный административный доступ.

2) Порядок приёмки и критерии готовности (DoD)

Работа считается выполненной после: (a) прохождения code review, (b) успешного прогона тестов/чек-листа, (c) обновления документации по изменениям, (d) демонстрации функционала на согласованном окружении, (e) устранения критических дефектов, влияющих на бизнес-функции.

3) SLA на инциденты (для поддержки)

Время реакции на инциденты: P1 — до X часов, P2 — до Y часов, P3 — до Z часов. Приоритет определяется по влиянию на ключевые бизнес-процессы. Статус-апдейты предоставляются не реже одного раза в N часов до восстановления работоспособности.

4) Управление изменениями (change request)

Любое изменение требований фиксируется в Change Request с описанием, влиянием на сроки/стоимость и планом внедрения. Изменение считается согласованным после письменного подтверждения Заказчиком в согласованном канале коммуникации.

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

FAQ

1. Как проверить подрядчика, если у нас нет CTO?

Просите артефакты процесса (беклог с AC, план релизов, отчётность, DoD) и проводите встречу по вопросам из статьи. Зрелость процесса видна без глубокой техэкспертизы.

2. Что важнее: цена или процессы?

Процессы. “Дешевле” часто превращается в дороже из-за переделок, простоев и зависимости от подрядчика.

3. Что делать, если у нас нет ТЗ?

Нормально. Начинайте с Discovery: цели, скоуп v1, прототипы, acceptance criteria — и только потом оценка.

4. Как контролировать T&M, чтобы не платитить “за часы”?

Нужны: общий бэклог, спринты, демо, отчёты по задачам, лимиты по бюджету и прозрачный трекинг в таск-трекере.

5. Кто должен владеть кодом и доступами?

Заказчик. Минимум — административный доступ к репозиторию, инфраструктуре, аналитике и учёткам, плюс закрепление прав в договоре.

Содержание

Другие статьи

Разработка
24 апреля 2026
2 мин чтения
Какую CRM систему выбрать для бизнеса: пошаговый гид без ошибок
CRM выбирают часто «на эмоциях»: увидели рекламу, услышали от знакомых, взяли «как у конкурента». А потом — саботаж менеджеров, дубли контактов, разваленная воронка и ощущение, что «CRM не работает». На деле не работает подход к выбору и внедрению.
Менеджмент
29 марта 2026
15 мин чтения
Fixed Price vs Time & Materials: что выгоднее для разработки
Сравнение Fixed Price и T&M: таблица различий, дерево выбора, чек-листы контроля, как сравнить КП и какие формулировки закрепить в договоре.
Менеджмент
2 марта 2026
2 мин чтения
ТЗ на разработку: структура, требования и чек-лист для бизнеса
Что должно быть в ТЗ на сайт/сервис/приложение: 12 разделов, чек-лист “минимум за 1 день”, типовые ошибки, вопросы подрядчику и шаблон формулировок.