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

Перед договором важно выяснить:

• как команда поймёт цели сайта и сценарии пользователей;

• что именно включено в оценку и что потребует отдельного бюджета;

• какие интеграции, данные и роли нужно описать до старта;

• кто участвует в проекте и как принимаются решения;

• где проверяются изменения перед запуском;

• кому принадлежат домен, лицензии, код и доступы после публикации.

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

В Ameton рекомендуем начинать разговор не с вопроса «сколько будет стоить сайт», а с вопроса «какую задачу бизнес хочет решить через сайт». От этого зависит и состав команды, и технология, и границы первого запуска.

Сначала спросите, как подрядчик будет разбираться в задаче

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

Полезно спросить:

• Какие действия посетителя вы считаете ключевыми для нашего сайта?

• Какие данные нужны для этих действий?

• Какие роли пользователей вы видите в проекте?

• Что нужно запустить в первую очередь, а что можно перенести на следующий этап?

• Какие риски вы видите в задаче уже сейчас?

• Какие материалы и решения мы должны подготовить со своей стороны?

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

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

Какие вопросы задать о составе работ и смете

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

Спросите подрядчика:

• Какие этапы входят в предложение?

• Что будет результатом аналитики, дизайна, разработки и тестирования?

• Какие функции входят в первый запуск?

• Что не включено в смету?

• Какие допущения использованы при оценке?

• В каких случаях бюджет может измениться?

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

Уточните, как подрядчик видит техническое решение

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

Вопросы зависят от типа проекта, но обычно полезно обсудить:

• почему для задачи подходит 1С-Битрикс и какая редакция потребуется;

• нужен ли готовый шаблон или индивидуальная разработка;

• как будет устроен каталог, личный кабинет или оформление заказа;

• с какими системами нужно обмениваться данными;

• где будут храниться товары, цены, остатки, заявки и заказы;

• как команда проверит критичные сценарии перед запуском.

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

Пример из практики Ameton: компания хотела запустить сайт с каталогом и запросом цены. Во время обсуждения выяснилось, что клиентам нужны разные условия, а менеджерам — возможность видеть историю обращений. Команда разделила запуск на этапы: сначала подготовила структуру каталога и передачу заявок, затем запланировала личный кабинет с персональными условиями. Без такого разделения в первый релиз попали бы одновременно несовместимые по приоритету задачи.

Спросите, как организована разработка и коммуникация

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

У подрядчика стоит уточнить:

• Кто будет участвовать в проекте и за что отвечает каждый специалист?

• Когда заказчик видит прототипы и дизайн?

• Как согласуются изменения в уже утверждённой задаче?

• Где фиксируются решения, комментарии и результаты?

• Как часто команда сообщает о ходе проекта?

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

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

Почему оценки отличаются у разных подрядчиков

Предложения различаются не только из-за ставки или размера команды. Чаще подрядчики по-разному понимают исходную задачу и включают в неё разный объём ответственности.

Один подрядчик может оценить «интеграцию с 1С» как стандартный обмен товарами. Другой включит анализ структуры данных, правила обновления цен и остатков, обработку ошибок, повторную передачу заказов и проверку результата. Формулировка в предложениях похожа, но результат для бизнеса будет разным.

При сравнении предложений важно сопоставлять:

• глубину аналитики до старта;

• состав функций первого запуска;

• проработку интеграций и данных;

• тестирование критичных сценариев;

• порядок внесения изменений;

• поддержку и развитие после публикации.

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

Обсудите запуск сайта до начала разработки

Запуск — это не момент, когда сайт просто появляется в интернете. Команда должна заранее понимать, какие данные будут перенесены, кто проверит контент, как будет опубликована новая версия и какие сценарии нельзя нарушить.

Для корпоративного сайта критичным может быть получение заявок. Для интернет-магазина — оформление заказа, оплата, доставка и передача данных. Для B2B-портала — корректные права доступа, персональные цены и документы.

Спросите подрядчика:

• Где будут проверяться изменения до публикации?

• Какие сценарии будут протестированы перед запуском?

• Кто готовит и загружает контент?

• Как переносится каталог, история заказов или пользователи, если есть старый сайт?

• Что происходит, если после запуска обнаружится критичная ошибка?

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

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

Уточните, что останется у компании после разработки

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

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

Какие ответы подрядчика должны насторожить

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

Поводом уточнить детали будут такие формулировки:

• «Точную цену назовём без изучения задачи».

• «Интеграцию с 1С сделаем потом, это несложно».

• «Тестировать будем уже на рабочем сайте».

• «Сайт передадим, а что будет дальше — неважно».

• «Все доступы можно оставить на стороне подрядчика».

• «Сначала сделаем всё, потом определимся, что действительно нужно».

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

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

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