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

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

Спросите о последовательности работ

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

Проверьте похожесть ограничений, а не отраслевых картинок

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

Уточните, кто владеет доступами

Домен, хостинг, CMS, аналитика, почта, CRM и репозиторий не должны оставаться только в аккаунтах подрядчика. На встрече фиксируют владельца, способ выдачи прав, резервные контакты и порядок отзыва доступа. Это не недоверие к исполнителю, а нормальная подготовка к поддержке и смене сотрудников.

Попросите пример тестового подхода

Фраза «протестируем перед запуском» не раскрывает состав проверки. Уместно спросить, как проверяют формы до CRM, мобильные сценарии, ошибки, роли редакторов, ссылки, резервный план релиза. Для заказчика полезен ответ, в котором названы проверяемые сценарии и способ фиксации критичных проблем до публикации, а не дано обещание отсутствия всех ошибок.

Обсудите состав передачи

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

Разберите поддержку как отдельный процесс

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

Сведите ответы в матрицу

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

Часто задаваемые вопросы

Достаточно ли портфолио для выбора?

Нет. Портфолио показывает визуальный результат, но не порядок работы, управление доступами и качество передачи. Эти вещи нужно обсудить отдельно.

Можно ли запросить контакты клиентов?

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

Когда обсуждать права на исходники?

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

Нужен ли отдельный SLA?

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

Что делать, если ответы кандидата несопоставимы?

Отправить одинаковый короткий список уточнений всем кандидатам. После этого сравнение можно вести по одной матрице.

Какие материалы запросить дополнительно

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

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

Итог

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