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

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

Фрилансер, студия или своя команда

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

Красные флаги на этапе переговоров

• Цену и срок назвали на первой встрече, не задав ни одного вопроса про ваш процесс. Значит, оценили не вашу задачу, а некую среднюю.
• Не могут показать работающие проекты — только скриншоты и макеты. Живая ссылка — минимальное подтверждение, что продукт дошёл до пользователей.
• Цена заметно ниже, чем у остальных, без внятного объяснения. Специалисты одного уровня стоят примерно одинаково; разница обычно берётся из объёма работ, который вам не показали, или из того, что делать будут не они.
• Отказ разбивать проект на этапы с отдельной приёмкой и оплатой. Нежелание работать поэтапно чаще говорит о денежном потоке подрядчика, чем об эффективности.
• Не спрашивают про данные, нагрузку, интеграции, права доступа. Эти вопросы всё равно всплывут — в середине проекта, как «дополнительные работы».
• Обещают всё: любой срок, любую функцию, никаких рисков. Подрядчик, который говорит «это делать не надо» или «это займёт больше времени», обычно надёжнее того, кто соглашается со всем.
• Исходники и доступы — «после полной оплаты» или «по запросу». Доступ к репозиторию и серверу должен быть у вас с первого дня.
• Давят сроком: «скидка действует до пятницы», «команда освобождается только сейчас». Решение о проекте на месяцы работы не должно приниматься за два дня.

Что спросить до договора

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

• Кто конкретно будет делать проект? Сколько у этих людей сейчас параллельных задач? Что будет, если ключевой человек уйдёт?
• На каком стеке будет сделан проект и почему именно на нём? Ответ «на нашей собственной платформе» означает, что сменить подрядчика вы, скорее всего, не сможете.
• Где хранится код, кто владелец репозитория, когда вы получите доступ?
• Как организовано тестирование и кто его делает?
• Как часто вы будете видеть промежуточный результат? Правильный ответ — регулярно, на демо-стенде, а не «в конце».
• Что входит в гарантию, сколько она длится и что считается гарантийным случаем?
• Сколько стоит поддержка и развитие после запуска? Это постоянная строка бюджета, а не бонус.
• Как оформляются изменения по ходу проекта: кто оценивает, кто согласует, как это отражается на сроке и цене?
• Какие риски вы видите в нашем проекте? Подрядчик, который не видит ни одного, либо не вник в задачу, либо не хочет о них говорить.
• Как вы защищаете данные и доступы: где хранятся пароли от наших сервисов, кто из команды их видит, что происходит с доступами сотрудника, который уходит из проекта?

Как читать портфолио

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

• Работают ли проекты сейчас — откройте ссылки, пройдите путь пользователя, оставьте тестовую заявку, если это уместно.
• Какая часть работы сделана этой командой: всё целиком или только дизайн, или только доработки чужого проекта.
• Что было после запуска: развивается ли продукт, сопровождает ли его тот же подрядчик. Долгие отношения с клиентами — хороший знак.
• Можно ли поговорить с кем-то из заказчиков. Не всегда возможно из-за конфиденциальности, но сама готовность о многом говорит.

Как сравнивать коммерческие предложения

Предложения разных подрядчиков почти никогда не сопоставимы по одной итоговой цифре. Чтобы сравнение было честным:

• Попросите разбивку по этапам и задачам с оценкой каждого. Отсутствие разбивки — признак того, что задача не разобрана.
• Сведите предложения в общий список: что входит у каждого, а чего нет. Кто готовит тексты, сколько кругов правок, включён ли перенос данных, тестирование, настройка аналитики.
• Сравните сроки по этапам, а не только итоговую дату.
• Посмотрите на модель оплаты: фиксированная цена за этап или оплата по времени, предоплата и оплата по факту приёмки.
• Отдельно сравните стоимость владения на год вперёд: поддержка, хостинг, абонентские платы, лицензии. Что формирует цену самой разработки, мы подробно разбирали в статье сколько стоит разработка сайта.

Условный пример: два предложения на одну задачу

Это иллюстрация, а не реальная история. Компании нужен сайт с личным кабинетом клиента. Подрядчик А присылает одну цифру и срок «два месяца», на вопросы отвечает общими словами, предлагает 70% предоплаты. Подрядчик Б дороже, но присылает разбивку на четыре этапа, задаёт полтора десятка вопросов о том, какие данные клиент видит в кабинете и откуда они берутся, предлагает начать с двухнедельного прототипа и оплачивать каждый этап после приёмки. На первый взгляд выгоднее А. Но у Б вы заранее знаете, за что платите, и можете остановиться после любого этапа, потеряв только его стоимость. У А в случае проблем вы теряете предоплату целиком, а реальный объём работ выяснится уже в процессе — скорее всего, в виде дополнительных счетов.

Пункты договора, без которых не подписывать

• Права на результат. Исключительные права на код, дизайн и документацию переходят к вам — прямо и однозначно, с указанием момента перехода (например, после оплаты этапа).
• Этапы и приёмка. Что именно сдаётся на каждом этапе, по каким критериям принимается, сколько дней у вас на замечания и что происходит, если замечаний нет.
• Сроки и ответственность. Конкретные даты этапов и последствия их срыва — в цифрах, а не формулировками вроде «стороны приложат усилия».
• Изменения. Порядок согласования новых требований: письменно, с оценкой влияния на срок и стоимость.
• Расторжение. Что передаётся при досрочном расторжении: код на момент остановки, доступы, документация, данные. Этот пункт спасает чаще остальных.
• Конфиденциальность и персональные данные. Если система будет работать с данными клиентов, нужно поручение на обработку и обязанности подрядчика по защите. Обязанности оператора по 152-ФЗ остаются на вас, поэтому важно, как их выполняет исполнитель.
• Гарантия. Срок, в течение которого ошибки исправляются бесплатно, и что считается ошибкой, а что — новой доработкой.

Проверьте команду на маленьком куске

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

Требования решают половину конфликтов

Значительная часть споров с подрядчиками возникает не из-за плохого кода, а из-за того, что стороны по-разному поняли задачу. Лечится это документом, а не доверием: до начала работ должно быть письменно зафиксировано, что делается, а что — нет, как выглядит готовый результат и как его проверить. Как составить такое техническое задание, чтобы оно защищало обе стороны и не раздувало бюджет, разобрано в статье техническое задание на разработку.

Как контролировать проект, не будучи программистом

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

Ошибки заказчика, которые губят даже хороший проект

• Менять требования по ходу без фиксации. Каждое «а давайте ещё вот так» сдвигает срок, и через три месяца уже никто не помнит, почему проект не сдан вовремя.
• Пропадать на согласованиях. Подрядчик ждёт ответа неделю, команда переключается на другие задачи, потом возвращается — время и деньги уходят на раскачку.
• Принимать решения коллективом без последнего слова. Правки от пяти человек, противоречащие друг другу, — верный способ получить компромисс, который не нравится никому.
• Не готовить контент. Тексты, фото, прайсы, данные для переноса — это зона заказчика почти в любом проекте, и их отсутствие останавливает запуск.
• Экономить на этапе разбора задачи. Сэкономленные на аналитике дни потом превращаются в недели переделок.

Что проверить в конце

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

Вывод и следующий шаг

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