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

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

Выбор подрядчика на разработку — решение на месяцы работы и существенный бюджет, которое на практике принимается за пару встреч и по впечатлению от презентации. Ошибка обнаруживается не сразу: первые недели идут бодро, а через три месяца выясняется, что сроки сорваны, код никто, кроме этой команды, не поддержит, а договор не позволяет забрать проект без потерь. Ниже — как выбирать подрядчика системно: какие типы исполнителей бывают и кому какой подходит, как организовать сам отбор, двенадцать вопросов, которые стоит задать до подписания договора, и как интерпретировать ответы, красные флаги в коммерческих предложениях и что обязательно должно быть в договоре. Если подрядчик уже выбран и работа с ним не складывается, пригодится другая статья — о том, как сменить подрядчика без потерь . Почему цена — плохой главный критерий Разброс цен на одну задачу объясняется не жадностью одних и щедростью других, а разным пониманием объёма. Подрядчик, назвавший вдвое меньшую сумму, обычно не заложил аналитику, тестирование, перенос данных или приёмку. Вы доплатите за них позже — но уже без возможности сравнить предложения и сменить исполнителя без потери времени. Сравнивать нужно состав работ, допущения и то, что явно исключено, а не итоговую цифру. Как читать смету, мы подробно разбирали в статье о стоимости разработки . Какие бывают подрядчики Фрилансер. Подходит для небольших и хорошо описанных задач. Риски — зависимость от одного человека, отсутствие тестирования и подмены на время болезни или отпуска. Небольшая студия. Команда из нескольких специалистов разного профиля, прямой контакт с людьми, которые делают проект. Важно проверить, что в команде есть все нужные роли, а не только разработчики. Агентство полного цикла. Аналитика, дизайн, разработка, тестирование, запуск и продвижение в одной команде. Подходит для продуктов, где важна связность всех этапов и нет своей продуктовой команды. Крупный интегратор. Сильные процессы, соответствие корпоративным требованиям, работа с госзаказчиками. Выше накладные расходы и дальше расстояние между заказчиком и исполнителями. Аутстаффинг. Специалисты работают под управлением заказчика. Подходит, если у компании есть свой руководитель продукта и технический лидер; без них превращается в найм без управления. Правильный тип зависит не столько от бюджета, сколько от того, есть ли у вас внутренняя экспертиза для управления проектом. Чем её меньше, тем важнее, чтобы подрядчик брал на себя аналитику, управление и качество, а не только написание кода. Как организовать отбор Сформулировать задачу. Бриф на несколько страниц: цели, пользователи, ключевые сценарии, интеграции, ограничения по срокам и бюджету. Детальное ТЗ до обращения не обязательно — как его составлять и почему лучше вместе с разработчиком, мы писали в статье о техническом задании . Собрать короткий список. Три-пять подрядчиков с релевантным опытом: похожие продукты, отрасль или технологии. Провести встречи. Оценивать не презентацию, а вопросы, которые подрядчик задаёт о задаче. Хорошая команда начинает с уточнения целей и рисков, а не с рассказа о себе. Получить предложения по одному брифу и сравнить их по составу работ, допущениям и рискам. Проверить репутацию — отзывы, контакты клиентов, открытые данные о компании. Начать с небольшого этапа. Оплачиваемая аналитика, прототип или первый функциональный блок показывают, как команда работает на самом деле. Двенадцать вопросов до договора 1. Кто конкретно будет работать над проектом? На продажах часто участвует сильная команда, а работает другая. Попросите имена и роли тех, кто выйдет на проект, и их опыт. Хороший ответ: конкретные люди, возможность познакомиться с техническим лидером до договора. Плохой: «подберём команду после подписания». 2. Сколько проектов ведёт эта команда параллельно? Разработчик на трёх проектах одновременно — это не треть времени на ваш проект, а меньше: переключение между задачами стоит времени и внимания. Спросите, какая загрузка планируется и как фиксируется в договоре. 3. Покажите код прошлого проекта Не портфолио с картинками, а репозиторий или его фрагмент. Отказ со ссылкой на соглашение о конфиденциальности законен, но тогда попросите обезличенный пример или внутреннюю библиотеку команды. Если в компании нет своего технического специалиста, привлеките независимого для короткого ревью. 4. Как вы оцениваете изменения вне согласованного объёма? Требования изменятся — это норма любого живого проекта. Ненормально, когда порядок оценки изменений не описан заранее. Хороший ответ: запрос на изменение, письменная оценка влияния на сроки и бюджет, согласование до начала работ. Плохой: «разберёмся по ходу». 5. Что входит в приёмку? Должен быть явный порядок: какие сценарии проверяются, на каких браузерах и устройствах, какой срок у заказчика на проверку, что считается принятым и как оформляются замечания. Без этого приёмка превращается в спор о субъективных впечатлениях. 6. Кому принадлежит результат? Исключительные права на код, дизайн и документацию должны переходить заказчику, и это должно быть записано в договоре. Отдельно уточните: где хранится репозиторий, у кого права администратора на инфраструктуру, домены и аккаунты сторонних сервисов. Лучший вариант — всё зарегистрировано на заказчика с первого дня, а подрядчик получает доступ. 7. Что происходит, если мы разойдёмся на середине? Хороший ответ: передаём код, документацию и доступы, помогаем новой команде в переходный период, порядок описан в договоре. Плохой: уход от вопроса или обида на сам вопрос. Подрядчик, уверенный в своей работе, спокойно обсуждает условия расставания. 8. Как устроено тестирование? Если тестирует сам разработчик — это не тестирование. Спросите про выделенного тестировщика, автоматические тесты, проверку регрессий перед каждым выпуском и то, как фиксируются и приоритизируются ошибки. 9. На чём будете писать и почему? Ответ «на том, в чём у нас больше всего опыта, и вот почему это подходит вашей задаче» честнее, чем список модных технологий. Плохой признак — редкий стек или собственная закрытая платформа, на которой продукт сможет поддерживать только эта студия. 10. Кто отвечает за инфраструктуру после запуска? Хостинг, домены, сертификаты, резервные копии, мониторинг, обновления безопасности. Эта зона чаще всего оказывается ничьей, и о ней вспоминают, когда истёк сертификат или упал сервер. Как договариваться о поддержке после запуска, — в статье о поддержке сайта и SLA . 11. Как часто мы будем видеть работающую версию? Разумный ориентир — демонстрация работающего продукта раз в одну-две недели на тестовом стенде, к которому у заказчика есть доступ. Проект, который показывают один раз в конце, почти гарантированно приедет не туда. 12. Дайте контакт клиента, с которым не всё прошло гладко Самый информативный вопрос. Идеальных проектов не бывает; важно, как подрядчик ведёт себя, когда что-то ломается: признаёт ли ошибки, как быстро реагирует, берёт ли на себя последствия. Как проверить подрядчика до договора Открытые данные о компании: дата регистрации, руководитель, судебные споры, связь с заявленным брендом. Кейсы с проверяемыми деталями: ссылка на работающий продукт, отрасль, задача, результат в цифрах, роль подрядчика — делал всё или отдельную часть. Разговор с клиентами , а не только письменные отзывы на сайте подрядчика. Техническое ревью примера кода или архитектурного решения независимым специалистом. Процессы: как ведётся задачник, как выглядит отчётность, есть ли регламенты выкладки и работы с инцидентами. Красные флаги в коммерческом предложении Оценка без вопросов. Если смета пришла после первого письма без единого уточнения, оценивали не вашу задачу. Готовность начать завтра большой командой. Хорошие команды загружены. Немедленная доступность — повод спросить почему. Отказ дробить проект на этапы. Этапы с оплатой по результату защищают обе стороны. Фиксированная цена за размытые требования. Фикс возможен только при зафиксированном объёме, иначе риск закладывается в цену или в качество. Одна строка вместо сметы. «Разработка платформы — N рублей» без декомпозиции. Нет тестирования, аналитики и управления проектом в составе работ. Портфолио без результатов. «Сделали сайт» — не результат. Результат — что изменилось у клиента. Обещание гарантированных бизнес-показателей без понимания вашего бизнеса. Что обязательно должно быть в договоре состав работ и результатов по этапам, критерии и порядок приёмки каждого этапа; порядок оценки, согласования и оплаты изменений; переход исключительных прав на результат и момент перехода; порядок передачи кода, документации и доступов — и при завершении, и при досрочном расторжении; регистрация доменов, аккаунтов сервисов и инфраструктуры на заказчика; сроки по этапам и последствия их нарушения для обеих сторон; гарантийный период на исправление ошибок и его условия; конфиденциальность и, если подрядчик получает доступ к персональным данным, — поручение на их обработку; порядок коммуникации: ответственные лица, частота отчётов и демонстраций. Первые недели работы: как понять, что выбор верный подрядчик задаёт много вопросов и фиксирует договорённости письменно; у вас есть доступ к задачнику, репозиторию и тестовому стенду; первая демонстрация состоялась в оговорённый срок и показывает работающий функционал, а не слайды; риски и проблемы подрядчик поднимает сам, до того как они стали срывом сроков; оценки изменений приходят письменно и до начала работ. Если через месяц ничего из этого нет, лучше обсудить это открыто сейчас, чем через полгода. Как мы строим работу с заказчиками — этапы, демонстрации, приёмку и передачу результата, — можно посмотреть на страницах услуг — разработки веб-проектов и мобильных приложений — и в разделе кейсов . Частые вопросы Стоит ли выбирать подрядчика по портфолио? Портфолио показывает, что команда умеет, но не показывает, как она работает. Оно отсеивает неподходящих, а выбирает — разговор, проверка процессов и первый небольшой этап. Фиксированная цена или почасовая оплата? Фикс подходит, когда объём зафиксирован и меняться не будет. Почасовая — когда продукт исследовательский и требования уточняются по ходу. На практике чаще работает гибрид: аналитика по времени, разработка согласованного объёма фиксом по её результатам. Нужно ли своё ТЗ до обращения? Нет. Для первого разговора достаточно брифа с целями и ключевыми сценариями. ТЗ, написанное без участия разработчика, обычно приходится переписывать, поэтому разумнее делать его вместе с выбранным подрядчиком отдельным этапом. Стоит ли давать тестовое задание? Бесплатное тестовое задание для серьёзного проекта — плохая практика: сильные команды от него отказываются, а результат мало говорит о работе на реальном проекте. Лучше оплачиваемый первый этап — аналитика или прототип, — который полезен вам независимо от дальнейшего выбора. Сколько подрядчиков рассматривать? Три-пять в коротком списке. Меньше — не с чем сравнить, больше — отбор затягивается, а сравнение превращается в сопоставление несопоставимых предложений. Что важнее: отраслевой опыт или технологический? Зависит от сложности предметной области. В финтехе, медицине или госсекторе отраслевой опыт экономит месяцы на понимании требований и регуляторики. В продуктах без сложной предметной логики важнее опыт с похожими технологическими задачами — нагрузкой, интеграциями, мобильными платформами.