После первой встречи с подрядчиками по разработке сайта выбор кажется простым: у кого сильнее презентация, больше красивых кейсов и короче обещанный срок — тот и берём. Проблема в том, что сайт приходится эксплуатировать после запуска. Менять контент, принимать заявки, подключать сервисы, исправлять ошибки. Поэтому на встрече стоит проверять не вкус исполнителя, а то, как устроена работа между стартом и передачей результата.
Сравнение становится содержательным, когда все кандидаты отвечают на одинаковые вопросы и показывают похожие артефакты: план работ, пример прототипа, правила доступов, подход к тестам и состав передачи.
Спросите о последовательности работ
Исполнитель должен объяснить, что происходит после брифа: исследование, структура, прототип, дизайн, разработка, тестирование, подготовка релиза и передача. Не нужен универсальный набор церемоний, но должна быть связь между решением и артефактом. Формулировка «всё обсудим по ходу» не показывает, как будут управлять изменениями.
Проверяйте похожесть ограничений, а не отраслевых картинок
Кейс полезен, если в нём видны сопоставимые с вашими условия: сложный каталог, несколько ролей, CRM, миграция, права редакторов. Красивый проект из другой области не доказывает, что команда умеет работать с вашим процессом. Просите показать, как принимали конкретное ограничение и как проверяли результат.
Уточните, кто владеет доступами
Домен, хостинг, CMS, аналитика, почта, CRM и репозиторий не должны оставаться только в аккаунтах подрядчика. На встрече фиксируют владельца, способ выдачи прав, резервные контакты и порядок отзыва доступа. Это не недоверие к исполнителю, а нормальная подготовка к поддержке и смене сотрудников.
Попросите пример тестового подхода
Фраза «протестируем перед запуском» не раскрывает состав проверки. Уместно спросить, как проверяют формы до CRM, мобильные сценарии, ошибки, роли редакторов, ссылки, резервный план релиза. Полезен ответ, в котором названы проверяемые сценарии и способ фиксации критичных проблем до публикации, а не обещание отсутствия всех ошибок.
Обсудите состав передачи
Нужен список того, что получит заказчик: исходники, доступы, инструкции по контенту, список интеграций, учётные записи, лицензии, открытые задачи и известные ограничения. Если часть материалов не передаётся — это должно быть названо до договора. Передача в конце проекта не должна зависеть от памяти конкретного менеджера.
Поддержка — отдельный процесс
Уточняют каналы обращений, часы работы, классификацию критичности, первую реакцию, границы работ и формат отчёта. Поддержка может не входить в разработку, но это не повод оставлять сайт без владельца после релиза.
Сведите ответы в матрицу
Сравнивайте кандидатов по одним столбцам: понимание задачи, метод работы, артефакты, доступы, тесты, передача, поддержка и исключения. Цена и срок остаются важными, но их стоит читать вместе с составом работ, а не отдельно от него.
Отдельно проверьте, как кандидат обращается с исключениями: кто готовит контент, что считается готовым для дизайна, сколько итераций включено в этап и что происходит с незакрытым замечанием. Прозрачное исключение полезнее широкого пункта договора без способа проверки.
Итог
Выбор подрядчика после первой встречи стоит строить на сопоставимых данных, а не на впечатлении от презентации. Общая матрица по этапам, доступам, тестированию, передаче и поддержке показывает, какие обязательства подтверждены артефактами, а какие остаются в устных обещаниях.
Top comments (0)