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

1. Попросите разобрать один реальный процесс

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

2. Отделите доказательства от красивой истории

Кейс должен отвечать:

• что было построено;
• за какую часть отвечала команда;
• какой результат измерялся;
• в каком контуре это проверено;
• что является клиентским продуктом, собственным продуктом или прототипом.

Например, формулировка «99 из 100 ответов оценены отлично в контрольном прогоне» проверяема и ограничена конкретным eval. «Точность 99%» без набора, даты и методики — уже маркетинговое обобщение.

3. Узнайте, кто действительно будет работать

Познакомьтесь не только с продавцом. Кто принимает архитектурные решения? Кто отвечает за QA, безопасность, инфраструктуру и коммуникацию? Как меняется состав команды и как передаются знания?

Опасный сигнал — CV сильных специалистов без подтверждения, что они выделены на проект.

4. Дайте маленькую неизвестную задачу

Короткий оплачиваемый discovery или technical spike полезнее бесплатного большого конкурса концепций. Возьмите самый рискованный вопрос: старое API, качество документов для RAG, миграция, производительность. Оцените не только результат, но и прозрачность допущений, код, тесты и вывод «не делать».

5. Проверьте инженерный контур

Попросите показать обезличенный пример:

• структура репозитория;
• code review;
• автоматические проверки;
• среды и deployment;
• secrets management;
• мониторинг;
• backup/restore;
• rollback.

Зелёная CI не доказывает успешный production, а локальная сборка — тем более. Хорошая команда чётко разделяет эти границы и не называет непроверенный этап завершённым.

6. Спросите о плохом сценарии

Что произойдёт, если платёжный API вернул timeout после списания? Если импорт запустился повторно? Если новый RAG-индекс собрался наполовину? Если загруженный файл вредоносный?

Конкретный ответ включает idempotency, очередь, reconciliation, staging, scan, журнал и rollback. Ответ «мы всё тщательно тестируем» ничего не описывает.

7. Проверьте безопасность по процессу, а не сертификатам

Кто получает production-доступ? Как выдаются и отзываются права? Где хранятся секреты? Попадут ли реальные данные в тест? Как проверяются зависимости и uploads? Как сообщается об инциденте?

CISA в Secure by Demand предлагает покупателям задавать поставщикам конкретные вопросы о безопасной разработке и уязвимостях. Даже если формальный документ рассчитан на software products, логика подходит и для заказной разработки: ответственность должна быть видна до покупки.

8. Уточните владение и переносимость

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

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

9. Согласуйте приёмку до разработки

«Соответствует ТЗ» бесполезно, если ТЗ описывает только функции. Нужны проверяемые сценарии, роли, ошибки, performance, security и материалы запуска. У каждого этапа должен быть observable result.

10. Разделите гарантию, поддержку и развитие

Гарантия исправляет несоответствие согласованному результату. Поддержка держит продукт работоспособным в рамках SLA. Развитие меняет продукт. Когда всё называется «поддержкой», после запуска начинаются споры о каждой задаче.

Спросите часы реакции, каналы, уровни критичности, дежурство, лимиты, порядок обновлений и стоимость работ вне SLA.

11. Потребуйте exit plan

Нормальный подрядчик не боится вопроса «как мы уйдём». Нужны актуальная документация, инструкции запуска, доступы заказчика, экспорт данных, список зависимостей и период передачи знаний.

Vendor lock-in иногда оправдан сильным managed service. Но он должен быть осознанным и оценённым, а не обнаружиться после конфликта.

12. Посмотрите, умеет ли команда говорить «нет»

Подрядчик, который обещает любую дату, бюджет и функцию, вероятно, продаёт согласие. Сильная команда объясняет, какое требование конфликтует с безопасностью, сроком или качеством, и предлагает меньший проверяемый этап.

Красные флаги

• Точная цена после получасового звонка при неизвестных интеграциях.
• «AI сделает разработку в десять раз быстрее» без границ и eval.
• Нет доступа заказчика к репозиторию и инфраструктуре.
• Production-секреты передаются в мессенджере.
• Нет негативных тестов и rollback.
• Успех описан только количеством функций.
• Поддержка обещана «по договорённости» без SLA.
• Нельзя объяснить, кто отвечает за конкретное решение.

Как сравнить финалистов

Оцените по одной шкале: понимание процесса, работа с неизвестностью, доказательства качества, безопасность, прозрачность стоимости, управляемость после запуска и человеческая совместимость. Последнее не вторично: даже хорошая архитектура не спасёт проект, где плохие новости скрывают до дедлайна.

Самый дешёвый подрядчик редко остаётся самым дешёвым, если цену удержали за счёт невидимых обязательных работ. Самый дорогой тоже не становится лучшим автоматически. Ищите команду, которая превращает риск в конкретную проверку и оставляет после себя работающую систему, а не зависимость от героев.