Как выбрать подрядчика на разработку ПО

Передайте всем кандидатам одинаковую исходную задачу

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

Разделите обязательный результат первой версии и последующие пожелания. Назовите человека, который отвечает на вопросы по процессу, и человека, который принимает работу. Если ими окажутся разные сотрудники, согласуйте между ними критерии до получения оценок.

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

Сопоставьте состав работ и условия изменения цены

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

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

Таблицу можно прокрутить по горизонтали.

Фиксированная цена подходит для согласованного объёма с проверяемой приёмкой. Укажите, как стороны оформляют изменение требований и пересчитывают срок. При оплате времени команды, или Time & Materials, согласуйте ставки, доступную загрузку, лимит расходов на период и порядок остановки работ. Сам способ оплаты не гарантирует предсказуемый результат.

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

Обсудите один сопоставимый проект с будущей командой

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

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

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

Проведите платный этап с самостоятельным результатом

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

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

Оцените также способ работы: как команда фиксирует решения, сообщает о препятствиях и показывает сделанное. Если необходимый доступ задерживается, полезен своевременный список последствий и вариантов действий. Молчание до даты демонстрации лишает заказчика возможности управлять сроком.

Согласуйте приёмку через воспроизводимые сценарии

Критерий должен содержать исходное состояние, действие и наблюдаемый результат. Формулировка «интеграция работает» не определяет поведение при повторе запроса или недоступности другой системы. Таблица ниже показывает формат требований для условной системы заказов; её значения нужно адаптировать к вашему процессу.

Таблицу можно прокрутить по горизонтали.

Если проверяете производительность, укажите объём базы, набор операций, число одновременных пользователей и среду испытания. Например, требование «95% запросов списка заказов быстрее 800 мс» имеет смысл только вместе с этими условиями и допустимой долей ошибок. Число 800 мс здесь иллюстративное, его не следует копировать без оценки пользовательского сценария.

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

Попросите доказательства работы с безопасностью

Вместо обещания «используем безопасные технологии» запросите перечень применимых требований и способ их проверки. Для веб-приложений отправной точкой может служить OWASP ASVS, стандарт проверки безопасности приложений. Согласуйте версию и конкретные требования к вашему продукту. Фраза «соответствует OWASP» без области проверки не объясняет, что именно было проверено.

Для оценки процесса разработки можно использовать NIST SSDF 1.1. Этот документ описывает практики безопасной разработки и общий язык взаимодействия заказчика с поставщиком. Он не заменяет испытание вашего приложения и не подтверждает безопасность конкретного подрядчика.

Практические вопросы к команде:

• Как проверяются права на уровне отдельных объектов, например заказов разных клиентов, включая прямые обращения к API?
• Где хранятся секреты и как закрывается доступ специалисту после завершения его работы?
• Как фиксируются версии зависимостей, обнаруживаются уязвимости и согласуется исправление найденных проблем?
• Какие данные попадают в журналы и тестовые среды, кто имеет к ним доступ?
• Кто принимает сообщения об уязвимостях после выпуска и как отслеживается устранение?

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

Источники: OWASP Application Security Verification Standard; NIST SP 800-218: Secure Software Development Framework 1.1.

Проверьте передачу проекта до последнего платежа

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

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

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

Разделите исправление согласованных дефектов, новые функции и эксплуатационную поддержку. В поддержке уточните время реакции, порядок диагностики, часы обслуживания и условия восстановления. Обещание ответить за час не означает обещания восстановить сервис за час.