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

Редакция Romanov Lab · Опубликовано 13 октября 2026

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

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

Сначала опишите, какая команда вам действительно нужна

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

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

• Какой пользовательский сценарий определяет успех первой версии?
• Какие две или три сложности нельзя решить обычным шаблоном?
• Что заказчик делает своими силами, а что ожидает от подрядчика?
• Кто будет поддерживать сайт после сдачи?
• Какие ограничения нельзя менять: платформа, инфраструктура, порядок согласований?

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

Проверяйте в портфолио роль команды, а не только картинки

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

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

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

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

Проведите одинаковое рабочее интервью

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

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

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

Оценивайте не уверенность выступления, а конкретность ответа. «У нас всё в задачнике» недостаточно. Попросите обезличенный пример задачи, отчёта о проверке или комплекта передачи. Подрядчик вправе не показывать материалы клиента; предложите ему описать структуру на вымышленном примере.

Сравнивайте обещания с наблюдаемыми признаками процесса

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

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

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

Проверяйте рекомендации с разрешения участников

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

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

Соберите карточку сравнения без ложной точности

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

Можно использовать простые отметки «подтверждено», «частично», «не проверено». Они честнее итогового балла с десятыми долями. Красивое среднее не должно перекрывать критический пробел: если никто не умеет работать с обязательной интеграцией, высокая оценка дизайна эту проблему не решает.

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

Когда полезен небольшой оплачиваемый этап

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

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

Условный пример выбора

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

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

Что зафиксировать перед окончательным выбором

1. Какие задачи и ограничения кандидат понял одинаково с вами.
2. Какие специалисты участвуют и кто принимает технические решения.
3. Как показывается промежуточный результат и проверяется качество.
4. Какие предположения ещё требуют проверки.
5. Как оформляются изменения и передаётся проект.
6. Почему выбранная команда лучше подходит именно к вашим рискам.

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