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