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

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

Эта статья актуальна на 17 августа 2026 года. Она предназначена для собственников и маркетологов, которые выбирают подрядчика на корпоративный сайт, сайт услуги, каталог, лендинг или небольшой веб-сервис. Здесь не разбирается, как писать техническое задание на разработку: фокус — на оценке исполнителя, его процесса и будущей передаче результата. Цель не в том, чтобы найти «идеальное агентство», а в том, чтобы сделать выбор проверяемым и снизить число решений, которые придётся принимать в кризисе.

Сначала отделите выбор подрядчика от выбора красивого макета

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

Начните с короткой внутренней карточки проекта. В ней достаточно ответить на пять вопросов:

1. Какую задачу бизнеса должен поддерживать сайт: получать обращения, объяснять сложную услугу, собирать заявки на расчёт, давать клиентам доступ к данным, сокращать ручную обработку?
2. Какие сценарии для посетителя критичны в первом релизе?
3. Что уже есть: домен, контент, CRM, аналитика, бренд-система, редакторы, хостинг, учётные записи?
4. Какие ограничения нельзя нарушить: дата кампании, интеграция, требования к данным, несколько языков, внутреннее согласование?
5. Кто со стороны заказчика вправе принимать решения и подтверждать этапы?

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

Матрица выбора: сравнивайте доказательства, а не впечатление

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

Для каждого пункта поставьте оценку от 0 до 5 и кратко укажите доказательство: ссылка на рабочий проект, фрагмент плана, демонстрация тестовой среды, список ролей, пример инструкции. Финальный балл — это не математическая истина, а защита от ситуации, когда сильное впечатление от дизайна перекрывает отсутствие процесса. Отдельно внесите «красные флаги» — условия, при которых кандидат не проходит независимо от суммы баллов: например, подрядчик настаивает, что домен и счётчик должны остаться на его личных учётных записях.

Как читать портфолио: вопрос не «нравится ли», а «можем ли мы проверить пригодность»

Портфолио полезно, но изображение первого экрана ничего не говорит о мобильных сценариях, форме, CMS, скорости, доступах и поддержке. Попросите выбрать два-три кейса, сопоставимых с Вашим проектом по задаче, а не по отрасли. Например, для B2B-сайта с длинным циклом сделки ценнее опыт объяснения сложной услуги и маршрутизации лида, чем десять визуально эффектных сайтов ресторанов.

Что попросить показать в живом кейсе

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

Проверьте следующие признаки:

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

W3C описывает WCAG 2.2 как набор тестируемых и технологически независимых критериев доступности; в нём есть уровни A, AA и AAA. Это полезный ориентир для вопросов к подрядчику, но фраза «сайт будет по WCAG» сама по себе недостаточна. Нужны согласованные страницы, конкретные критерии и способ проверки. В стандарте отдельно подчёркнуто, что автоматические и человеческие методы дополняют друг друга.

Осторожнее с неподтверждаемыми результатами

«Увеличили конверсию на 300 %» может быть правдой, но без исходной точки, периода, канала, состава трафика и изменений на стороне клиента не помогает прогнозировать Ваш проект. Не просите у агентства чужие закрытые данные. Попросите объяснить метод: какая гипотеза была, какие решения приняли, что проверяли перед запуском, какие ограничения признали. Хороший разбор умеет различать вклад сайта, рекламы, цены, сезонности и работы отдела продаж.

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

Оцените не «агентство», а конкретную команду и её доступность

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

• руководитель проекта — управляет сроком, рисками и решением блокеров;
• UX/UI-дизайнер — исследует сценарии и проектирует интерфейс;
• разработчик или технический лидер — отвечает за технические решения, интеграции, качество кода и развёртывание;
• контент-специалист, редактор или SEO-эксперт — если в объём входит содержание и поисковая подготовка;
• QA-специалист либо назначенный ответственный — проводит проверки по плану;
• со стороны заказчика — владелец продукта и эксперты, которые дают материалы и принимают решения.

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

Вопросы, которые проявляют процесс

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

1. Какие решения Вы предлагаете принять до дизайна и какие данные для этого нужны?
2. Какие артефакты будут по этапам: карта страниц, прототип, дизайн-система, контент-план, тест-кейсы, инструкции?
3. Где фиксируются решения, замечания и смена объёма: в задаче, письме, системе управления проектом?
4. Как Вы проводите демонстрации и кто подтверждает этап с нашей стороны?
5. Как проверите форму, CRM, аналитику и уведомления до публикации?
6. Что произойдёт, если нужный контент, доступ или решение заказчика задерживаются?
7. Что Вы считаете дефектом, а что новым требованием?
8. Какие материалы и доступы мы получим при передаче, в каком формате и когда?

Зрелый подрядчик может не знать ответа на каждый вопрос до исследования. Но он должен уметь назвать допущение, владельца следующего действия и момент, когда ответ будет зафиксирован. Опасный сигнал — уверенные обещания срока и цены при отсутствии вводных либо обещание «всё решим по ходу» без механики управления изменениями.

Смета: ищите границы, зависимости и цену неопределённости

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

Попросите коммерческое предложение разложить на этапы и результаты, а не только на часы. Для каждого этапа должны читаться:

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

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

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

Права, аккаунты и доступы: договоритесь до первого платежа

Самая неприятная передача проекта происходит, когда домен, DNS, хостинг, репозиторий кода, счётчики аналитики, рекламные кабинеты или почта зарегистрированы на личный e-mail бывшего сотрудника либо аккаунт агентства. Даже добросовестный подрядчик может сменить менеджера или закрыть направление; бизнесу нужен контролируемый путь продолжить работу.

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

Вопрос об интеллектуальных правах нельзя закрывать общим «всё будет Ваше». Разные элементы имеют разный режим: исходный код, дизайн, текст, фото, иконки, шрифт, CMS, библиотека и стоковая лицензия. WIPO напоминает, что охрана авторского права и порядок использования зависят от произведения и национального права. Уточните в договоре и приложениях, какие права передаются или лицензируются, в какой момент, на какой территории и сроке, что остаётся с открытой лицензией, а на что нужна отдельная лицензия. За правовой оценкой конкретной сделки обратитесь к профильному юристу.

Никогда не передавайте пароли в одном общем документе или мессенджере «навсегда». Используйте ролевые доступы, персональные учётные записи и безопасный менеджер секретов, а при смене подрядчика отзывайте ненужные права. OWASP ASVS можно использовать как профессиональную основу для обсуждения проверяемых требований к веб-приложению, но он не превращает сайт в «невзламываемый» и не заменяет оценку рисков.

Как устроить этапы и приёмку, чтобы не спорить о вкусе в конце

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

1. Старт и исследование

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

2. Структура и прототип

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

3. Дизайн и контент

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

4. Разработка и интеграции

Результат: рабочая тестовая среда, реализованные сценарии и журнал изменений. Попросите продемонстрировать не только «счастливый путь», но и ошибку в обязательном поле, недоступность внешнего сервиса, повторную отправку формы, права редактора и передачу данных в CRM. Для аналитики полезен тестовый сценарий: визит с меткой — заявка — запись в целевой системе — проверяемое событие.

5. Релиз и передача

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

Критерий приёмки должен быть наблюдаемым

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

web.dev описывает Core Web Vitals как метрики пользовательского опыта, включая LCP, INP и CLS; интерпретировать их важно в контексте полевых данных, устройств и сценариев. Поэтому один скриншот из теста скорости не подтверждает качество всего сайта. W3C также рекомендует сочетать разные способы оценки доступности, а не полагаться на один автоматический сканер.

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

Ошибки при выборе агентства

Выбрать по первой странице портфолио

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

Сравнить только итоговые цены

Без единых границ проекта цена не сопоставима. Сравните этапы, исключения, контент, лицензии, QA, интеграции, запуск и передачу доступов.

Оставить аккаунты подрядчику «для удобства»

Удобство на старте может стать зависимостью на финале. Организационные аккаунты и персональные роли позволяют менять исполнителя без борьбы за восстановление доступа.

Принимать сайт по демонстрации дизайнера

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

Считать поддержку автоматической частью разработки

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

Чек-лист выбора и передачи результата

• Мы сравнили кандидатов по одной матрице и зафиксировали доказательства, а не только впечатления.
• В портфолио есть кейсы со сходной задачей; мы посмотрели хотя бы один живой пользовательский сценарий.
• Названы конкретные роли, загрузка, владелец проекта и порядок эскалации.
• Понятны этапы, результаты каждого этапа, точки согласования и порядок изменений.
• В смете обозначены границы, допущения, исключения, лицензии и условия работ сверх объёма.
• Согласованы тесты для форм, интеграций, мобильных устройств, аналитики, доступности и производительности в нужном проекту объёме.
• Есть реестр домена, DNS, хостинга, кода, CMS, аналитики, рекламы, дизайна и лицензий.
• Владение ключевыми аккаунтами закреплено за заказчиком, а подрядчик получает ролевой доступ.
• Порядок прав на код, дизайн, контент, фото, шрифты и сторонние компоненты сформулирован в документах и проверен специалистом при необходимости.
• На финале предусмотрены инструкции, исходники, доступы, список сервисов, тестовая заявка и журнал устранённых замечаний.

FAQ

Стоит ли выбирать агентство, которое уже работало в нашей отрасли?

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

Можно ли начать с небольшого оплачиваемого этапа?

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

Кто должен владеть доменом и аналитикой?

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

Нужен ли независимый QA, если агентство обещает проверить всё само?

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

Что делать, если после запуска нашли дефекты?

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

Достаточно ли подписать акт, чтобы получить все материалы?

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

Нужен подрядчик, с которым сайт останется управляемым после запуска?

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

Источники и материалы для проверки

Все ссылки проверены 17 августа 2026 года.

1. W3C: Web Content Accessibility Guidelines (WCAG) 2.2 — тестируемые критерии доступности, уровни A, AA и AAA.
2. W3C WAI: Evaluating Web Accessibility Overview — сочетание автоматических, экспертных и пользовательских методов оценки.
3. web.dev: Web Vitals — назначение метрик LCP, INP и CLS и контекст их интерпретации.
4. OWASP: Application Security Verification Standard — проверяемые требования к безопасности веб-приложений.
5. MDN Web Docs: Website security — базовые риски и практики защиты веб-сайтов.
6. NIST: Privacy Framework — добровольная рамка управления рисками приватности.
7. Google Search Central: Creating helpful, reliable, people-first content — критерии полезного, прозрачного и ориентированного на человека контента.
8. WIPO: Copyright — обзор охраны авторских прав и необходимости учитывать применимое право.