1. Ищите опыт в задаче сопоставимой сложности

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

По релевантному кейсу спросите:

  • какую задачу решала команда;
  • за какую часть отвечала студия;
  • какие ограничения были у проекта;
  • какие решения пришлось принимать;
  • работает ли проект сейчас.

Сильный кейс объясняет ход работы. Скриншот без контекста показывает только финальную картинку.

2. Сравнивайте одинаковый состав работ

Цена без состава проекта почти бесполезна.

Проверьте, включены ли в оценку:

  • исследование и структура;
  • прототипирование;
  • тексты и перенос контента;
  • адаптивные состояния;
  • разработка;
  • CMS;
  • интеграции;
  • тестирование;
  • аналитика;
  • запуск;
  • поддержка после релиза.

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

3. Узнайте, кто будет работать после подписания договора

Количество сотрудников в агентстве не определяет качество проекта. Важнее состав конкретной команды.

До старта должно быть понятно:

  • кто ведёт проект;
  • кто отвечает за архитектуру и структуру;
  • кто проектирует интерфейс;
  • кто принимает технические решения;
  • кто тестирует;
  • с кем заказчик обсуждает изменения.

Особенно полезно выяснить, останутся ли специалисты, участвовавшие в пресейле, в проекте после договора.

4. Посмотрите на вопросы, которые задаёт команда

По качеству пресейла часто видно, как подрядчик будет принимать решения дальше.

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

Хороший подрядчик может не знать ответ сразу. Гораздо важнее, замечает ли он неизвестные параметры и фиксирует ли их.

5. Разберите правила изменений

Новые идеи во время разработки нормальны. Проблемы начинаются, когда никто не знает, относятся они к согласованному объёму или создают новую работу.

Спросите:

  • что считается правкой;
  • что становится новой задачей;
  • кто оценивает изменение;
  • как пересчитывается срок;
  • где фиксируется решение.

Обещание «безлимитных правок» приятно слышать, но границы проекта оно не объясняет. Понятный процесс изменений обычно спокойнее для обеих сторон.

6. Договор и техническое приложение должны описывать результат

В документах проверяют состав работ, этапы, сроки, порядок приёмки, изменение объёма, расторжение, передачу доступов и права на созданные материалы.

Отдельного внимания требуют сторонние компоненты: библиотеки, CMS, шрифты, стоки и другие материалы могут использоваться по собственным лицензиям. В договоре полезно различать результат, созданный специально для заказчика, и компоненты, права на которые регулируются сторонними условиями.

7. Проверьте, что получите после сдачи

До старта договоритесь о передаче:

  • репозитория кода;
  • доступа к домену и хостингу;
  • CMS;
  • дизайн-файлов;
  • аналитики;
  • рекламных кабинетов, если они входят в проект;
  • документации;
  • инструкций по развёртыванию, когда они нужны.

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

8. Критерии приёмки должны проверяться

Фраза «сделать современный сайт» не помогает ни заказчику, ни разработчику.

Проверяемые условия выглядят иначе:

  • форма отправляет согласованный набор полей в CRM;
  • каталог фильтруется по заданным параметрам;
  • страницы работают на согласованном наборе браузеров и устройств;
  • аналитические события фиксируются по согласованной схеме.

Подробные требования удобнее держать в ТЗ. О том, как его составлять, рассказываем в статье «Техническое задание на сайт».

9. Для существующего сайта отдельно спросите о миграции

При редизайне потерять поисковый трафик можно ещё до того, как новый дизайн начнёт приносить пользу: достаточно удалить важные URL или неправильно настроить перенаправления.

На этапе выбора подрядчика нужен не полный технический чек-лист, а ответ на вопрос: кто отвечает за карту старых и новых URL, редиректы и контроль после релиза?

Подробная проверка миграции входит в чек-лист запуска сайта.

10. Уточните, что происходит после запуска

Поддержка бывает абонентской, почасовой или по отдельным задачам. Любая модель может работать, если она понятна заранее.

Спросите:

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

Когда студия действительно может быть лишней

Простую страницу из готового контента иногда рациональнее собрать на конструкторе или передать хорошему фрилансеру.

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

Если бюджет не соответствует объёму, разумнее сократить первый релиз, чем выбирать подрядчика только по минимальной цене.

Хороший знак, если студия предлагает подходящий формат, даже когда он меньше максимального объёма работ.

Короткий список вопросов на встречу

  1. Покажите два сопоставимых проекта и объясните свою роль.
  2. Что входит и не входит в оценку?
  3. Кто работает над проектом после договора?
  4. Как оформляются новые задачи?
  5. Какие исходники и доступы я получу?
  6. Как оформлены права и сторонние лицензии?
  7. По каким критериям принимается результат?
  8. Кто отвечает за миграцию существующего сайта?
  9. Как устроена поддержка?
  10. Можно ли без проблем передать проект другой команде?

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