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

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

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