Чтобы проверить подрядчика по разработке сайта, оцените не только портфолио и цену. Запросите состав команды, декомпозицию работ, описание процесса, условия приемки, порядок передачи доступов и прав на результат. Затем подтвердите заявленную экспертизу на конкретных проектах и зафиксируйте договоренности в договоре.
Этот чек-лист поможет сравнить студию, агентство или фрилансера по единым критериям, заметить риски до начала работ и задать вопросы, которые показывают реальный уровень исполнителя. Проверку удобно проводить после первого созвона, но до подписания договора и внесения аванса.
1. Сначала определите, какого подрядчика нужно найти
Оценка исполнителя начинается с задач бизнеса. Сильная команда для интернет-магазина может не подходить для сложного личного кабинета, а разработчик типовых лендингов — для проекта с интеграциями и нестандартной логикой.
До общения с кандидатами составьте короткое описание проекта:
- цель сайта и ожидаемые действия пользователей;
- типы страниц и основные функции;
- необходимые интеграции с CRM, ERP, платежными, складскими и другими системами;
- требования к дизайну, адаптивности, скорости и поисковой оптимизации;
- планируемые сроки и допустимый бюджетный диапазон;
- сотрудники со стороны заказчика, которые согласуют решения и предоставляют материалы;
- потребность в поддержке после запуска.
Необязательно заранее составлять исчерпывающее техническое задание. Для первичного отбора достаточно вводных, которые позволяют подрядчику определить масштаб проекта и задать уточняющие вопросы.
Хороший признак — исполнитель не называет окончательную стоимость после двух предложений о будущем сайте. Подрядчик сначала выясняет бизнес-задачу, аудиторию, функциональность, требования к контенту и ограничения. Если данных недостаточно, команда предлагает отдельный этап аналитики или обозначает предварительную вилку с допущениями.
2. Проверьте юридическую и деловую надежность
Сайт, презентация и уверенное выступление на встрече не подтверждают надежность компании. Перед договором нужно убедиться, что исполнитель существует как юридическое лицо или зарегистрированный специалист, а реквизиты в документах принадлежат выбранному подрядчику.
Что следует проверить:
- наименование, регистрационные данные и статус организации или предпринимателя;
- совпадение реквизитов в договоре, счете и коммерческом предложении;
- полномочия человека, который подписывает договор;
- наличие судебных, исполнительных или иных обстоятельств, способных повлиять на выполнение проекта;
- срок работы компании и изменения в регистрационных данных;
- понятный канал связи для официальных уведомлений и передачи документов.
Сам по себе спор или недавняя регистрация не доказывают ненадежность. Важны предмет, масштаб и контекст. Например, единичный спор по хозяйственному договору и череда претензий клиентов имеют разное значение. Если потенциальные риски существенны, документы лучше передать юристу.
Уточните, кто фактически будет выполнять работу. Агентство может привлекать субподрядчиков, и это не обязательно проблема. Риск возникает, когда подрядчик скрывает модель работы, не контролирует внешнюю команду или не готов отвечать за ее результат, сроки и конфиденциальность.
3. Разберите портфолио и подтвердите экспертизу
Портфолио показывает уровень подрядчика только в том случае, если понятны роль команды, сложность задачи и полученный результат. Красивые изображения интерфейса не подтверждают качество разработки, удобство администрирования или способность вести проект.
Выберите два-три релевантных проекта и задайте по каждому одинаковые вопросы:
- Какую задачу поставил клиент?
- Что именно сделал подрядчик: аналитику, дизайн, программирование, интеграции, контент или поддержку?
- Какие специалисты участвовали в работе?
- Какие ограничения и сложные решения возникли?
- На какой платформе создан сайт и почему выбрана именно она?
- Как проверяли качество перед запуском?
- Поддерживает ли подрядчик проект сейчас?
Если команда заявляет измеримый эффект, попросите объяснить методику оценки. Рост заявок может зависеть от рекламы, сезонности, ассортимента, работы отдела продаж и других факторов, поэтому приписывать изменение одному редизайну некорректно.
Полезно самостоятельно открыть сайты из портфолио на компьютере и смартфоне. Проверьте навигацию, формы, сообщения об ошибках, читаемость текста и базовую скорость загрузки. Учтите, что действующий сайт мог измениться после завершения проекта, поэтому текущие недостатки нельзя автоматически относить к работе первоначального подрядчика.
Отзывы ценнее, когда содержат название клиента, задачу и описание взаимодействия. При выборе исполнителя для крупного проекта можно попросить контакт одного-двух заказчиков, если подрядчик вправе его предоставить. Спросите у клиента не только о результате, но и о соблюдении договоренностей, реакции на проблемы и качестве поддержки после запуска.
4. Сравните коммерческие предложения и сметы
Корректное коммерческое предложение объясняет, что получит заказчик, как будет организована работа и от чего зависят сроки и стоимость. Одна итоговая сумма без состава работ не позволяет сравнить кандидатов и повышает риск доплат.
| Что проверить | Признак прозрачного предложения | Риск |
|---|---|---|
| Состав работ | Этапы и результаты перечислены отдельно | Формулировка «сайт под ключ» без расшифровки |
| Функциональность | Описаны ключевые сценарии, формы и интеграции | Функции предполагаются устно |
| Контент | Указано, кто пишет, переносит и размещает материалы | Наполнение не учтено или трактуется по-разному |
| Правки | Определены порядок согласования и границы этапа | «Неограниченные правки» без правил и сроков |
| Тестирование | Перечислены виды проверок и ответственные | Тестирование обозначено одной строкой |
| Запуск | Учтены перенос, настройка окружения и контроль после публикации | Работа заканчивается передачей архива |
| Поддержка | Условия гарантийных исправлений и дальнейших работ разделены | Любая проблема после запуска оплачивается отдельно |
Сравнивайте предложения по одинаковому объему. Низкая цена может объясняться отсутствием аналитики, шаблонным дизайном, ограниченным тестированием, переносом контента на заказчика или исключением интеграций. Более высокая оценка также не гарантирует качества: подрядчик должен обосновать состав команды и трудоемкость.
Обратите внимание на модель оплаты. Фиксированная цена подходит, когда требования подробно описаны и редко меняются. Оплата по фактическим трудозатратам удобна для развивающегося продукта, но требует прозрачного учета часов, приоритетов и лимитов. Поэтапная оплата снижает риск обеих сторон, если каждый платеж привязан к понятному результату.
Сроки должны учитывать не только производство, но и согласования со стороны заказчика, подготовку контента, доступность внешних систем и обработку изменений. Обещание быстро разработать сложный сайт без анализа требований — повод запросить подробный календарный план.
5. Оцените команду, процесс и коммуникацию
Результат зависит не только от навыков программиста. Для проекта могут потребоваться аналитик, UX/UI-дизайнер, разработчики, тестировщик, специалист по контенту и менеджер. Состав определяется сложностью сайта, поэтому отсутствие отдельного специалиста не всегда критично. Важно, чтобы необходимые функции были распределены и не оставались без ответственного.
До старта выясните:
- кто руководит проектом и принимает решения со стороны подрядчика;
- кто будет работать над аналитикой, дизайном, разработкой и тестированием;
- может ли ключевой специалист быть заменен и как проходит замена;
- где фиксируются задачи, комментарии и согласования;
- как часто команда показывает промежуточный результат;
- как обрабатываются новые требования и оценивается их влияние;
- какие действия ожидаются от заказчика и сколько времени занимает обратная связь.
Попросите показать типовой план проекта и примеры рабочих артефактов без конфиденциальных данных: структуру технического задания, прототипа, отчета о тестировании или реестра задач. Смысл проверки не в объеме документов, а в управляемости процесса.
Обратите внимание на качество вопросов подрядчика. Компетентная команда обсуждает пользовательские сценарии, источники трафика, роли администраторов, интеграции, миграцию данных, дальнейшее развитие и критерии готовности. Сосредоточенность только на цветах, референсах и количестве страниц указывает на поверхностное понимание задачи.
Коммуникацию стоит проверять еще до договора. Насколько быстро и содержательно команда отвечает? Фиксирует ли итоги встречи? Сообщает ли о неопределенности? Умеет ли объяснять решения без лишней терминологии? Продажа и производство могут выполняться разными людьми, поэтому познакомьтесь с будущим руководителем проекта до подписания документов.
6. Зафиксируйте результат, права и техническую независимость
Договор должен описывать не абстрактную «разработку сайта», а конкретные результаты этапов, порядок передачи и критерии приемки. Приложениями могут быть техническое задание, календарный план, смета и требования к инфраструктуре.
Особое внимание уделите следующим условиям:
- предмету договора и составу работ;
- стоимости, графику платежей и правилам учета дополнительных задач;
- срокам этапов и последствиям задержек каждой стороны;
- порядку согласования, приемки и исправления недостатков;
- правам на дизайн, программный код, тексты и другие результаты;
- условиям использования сторонних компонентов, лицензий, шрифтов и изображений;
- конфиденциальности и обработке данных, к которым получает доступ команда;
- порядку расторжения договора и передачи незавершенных материалов;
- гарантийным исправлениям и границе между ошибкой и новой функцией.
Формулировки о правах должны учитывать выбранную технологию. Подрядчик не может передать исключительные права на стороннюю CMS, библиотеку или готовый модуль, если условия их использования предусматривают другое. При этом заказчику важно получить законное право использовать созданные специально для проекта дизайн, код и контент в согласованных пределах. Конкретные условия следует проверять с профильным юристом.
Техническая независимость означает, что бизнес может управлять критически важными активами без обязательного участия разработчика. Домен желательно регистрировать на заказчика. Хостинг, облачные сервисы, системы аналитики, почта и другие аккаунты также должны быть оформлены так, чтобы компания сохраняла административный доступ.
В перечень материалов для передачи обычно включают:
- административные доступы к сайту и инфраструктуре;
- исходный код и историю изменений, если она предусмотрена процессом;
- редактируемые макеты и дизайн-систему;
- документацию по развертыванию, интеграциям и настройкам;
- перечень лицензий и платных сервисов со сроками продления;
- инструкцию для редакторов и администраторов;
- резервную копию и порядок восстановления.
Пароли не следует пересылать в открытой переписке или хранить в общедоступных документах. До начала работ определите безопасный способ выдачи и отзыва доступов, а после завершения проекта проверьте учетные записи и права пользователей.
7. Итоговый чек-лист перед подписанием договора
Чтобы проверить подрядчика по разработке веб-сайта без субъективных впечатлений, поставьте каждому кандидату отметку по следующим пунктам:
- Релевантность. Есть опыт с сопоставимыми задачами, функциями или технической сложностью.
- Подтверждение портфолио. Подрядчик ясно описывает свою роль, процесс и ограничения проектов.
- Понимание задачи. Команда задает вопросы о бизнесе, пользователях, интеграциях и развитии сайта.
- Прозрачная оценка. Цена разложена по этапам, а исключения и допущения указаны письменно.
- Реалистичный план. Учтены производство, согласования, контент, тестирование и запуск.
- Понятная команда. Известны роли, ответственные и порядок замены специалистов.
- Управляемый процесс. Определены инструменты, отчетность, демонстрации и работа с изменениями.
- Контроль качества. Есть критерии готовности, тестирование и процедура исправления ошибок.
- Корректный договор. Зафиксированы результаты, платежи, приемка, права и условия прекращения работ.
- Передача активов. Заказчик получает доступы, исходные материалы, документацию и информацию о лицензиях.
- Поддержка после запуска. Разделены гарантийные исправления, обслуживание и новое развитие.
- Качество коммуникации. Подрядчик отвечает по существу, фиксирует решения и открыто сообщает о рисках.
Необязательно выбирать кандидата с максимальным числом формальных документов. Маленькой команде не нужен процесс крупной корпорации, а простому сайту — избыточная проектная отчетность. Критично, чтобы способ работы соответствовал масштабу задачи, а значимые договоренности можно было проверить.
Красные флаги: давление с требованием срочно внести аванс, отказ раскрыть состав работ, обещание гарантированного коммерческого результата, использование только устных договоренностей, регистрация домена на сотрудника подрядчика и нежелание передавать исходные материалы без заранее оговоренной причины.
Частые вопросы
Нужно ли заказывать тестовое задание?
Для небольшого сайта обычно достаточно портфолио, интервью и разбора подхода. Бесплатное создание дизайна или программного модуля плохо моделирует реальный проект. Для сложной задачи полезнее оплатить ограниченный этап аналитики, прототипирования или технического исследования.
Как проверить техническую квалификацию без разработчика в штате?
Запросите архитектурное описание простым языком, перечень технологий, подход к тестированию и порядок передачи проекта. Для значимого бюджета можно привлечь независимого технического специалиста, который проверит оценку, решения и договорные требования.
Стоит ли выбирать самого дешевого подрядчика?
Самая низкая цена оправданна только при сопоставимом объеме и качестве работ. Сначала приведите предложения к единому составу: учтите аналитику, дизайн, контент, интеграции, тестирование, лицензии, запуск и поддержку.
Можно ли начинать разработку без подробного технического задания?
Можно, если первым этапом предусмотрена аналитика, а требования уточняются управляемо. Начинать программирование сложного сайта по общему описанию рискованно: стоимость, сроки и критерии приемки останутся неопределенными.
Что делать, если подрядчик использует собственную CMS?
Уточните условия лицензии, стоимость дальнейшего использования, доступность документации, возможность переноса и зависимость от одного поставщика. Заказчик должен заранее понимать, сможет ли другая команда поддерживать сайт и получить необходимые доступы.
Когда привлекать юриста к проверке договора?
Юридическая проверка особенно важна при крупном бюджете, сложных правах на код и дизайн, обработке чувствительных данных, привлечении субподрядчиков или использовании нескольких сторонних лицензий.
Если нужен не только аудит кандидатов, но и команда для полного цикла работ, изучите условия разработки сайтов в Granat. До старта стоит обсудить задачу, ограничения и ожидаемый результат, чтобы определить подходящий состав проекта.
