Как выбрать студию разработки сайта: RFP, договор, команда и реальные критерии

1. Начните с RFP: что именно вы просите оценить

RFP — request for proposal — нужен не только крупным корпорациям. Даже если вы выбираете студию для корпоративного сайта, RFP помогает сравнивать подрядчиков по одинаковым вводным. Без него одна команда оценит дизайн и верстку, другая включит backend, третья заложит аналитику и SEO, четвёртая не учтёт сопровождение, а на встрече все будут выглядеть убедительно. В итоге вы сравните не предложения, а разные представления о проекте.

Хороший RFP описывает бизнес-цель, аудиторию, текущие проблемы, желаемые сценарии, типы страниц, интеграции, требования к контенту, SEO, аналитике, безопасности, доступности, срокам и поддержке. Не нужно писать идеальное ТЗ на сто страниц. Важно дать подрядчику достаточно контекста, чтобы он показал мышление: какие вопросы задаёт, какие риски видит, как дробит работу, где предлагает discovery, а где готов сразу оценивать реализацию.

• Опишите результат для бизнеса: лиды, продажи, сервис, автоматизация, снижение ручных операций или выход на новый рынок.
• Перечислите обязательные интеграции: CRM, 1С, платежи, рассылки, телефония, аналитика, ERP, внутренние API.
• Укажите ограничения: домен, хостинг, брендбук, юридические требования, сроки кампании, существующий стек.
• Попросите структуру оценки: этапы, роли, допущения, риски, исключения, сроки, артефакты и формат поддержки.

Если подрядчик не задаёт уточняющих вопросов по RFP, это не признак уверенности. Часто это признак того, что риски просто переедут в середину проекта.

2. Портфолио важно, но процесс важнее

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

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

3. Состав команды: кто реально будет делать проект

В коммерческом предложении должно быть понятно, какие роли участвуют в проекте и на каких этапах. Для простого сайта это могут быть project manager, UX/UI designer, frontend developer, QA и DevOps на релизе. Для портала добавляются backend developer, architect или tech lead, analyst, integration specialist, security reviewer, иногда content strategist и SEO specialist. Если студия продаёт сложный проект, но не показывает backend, QA или DevOps, риски просто спрятаны в цене.

Важно также понять, кто принимает технические решения. Иногда в продажах участвует сильный руководитель, а после подписания договор уходит junior-команде без архитектурного надзора. Спросите, будет ли tech lead на старте, кто проверяет pull requests, кто отвечает за безопасность, кто проектирует модель данных, кто общается с вашей IT-службой. Это нормальные вопросы, а не недоверие.

• Project manager отвечает за ритм, статусы, риски, согласования и прозрачность ожиданий.
• Analyst или product-minded lead переводит бизнес-требования в сценарии, user stories и критерии приёмки.
• Tech lead отвечает за архитектуру, стек, качество кода, интеграционные решения и технический долг.
• QA нужен не только в конце: тестовые сценарии полезно готовить параллельно с требованиями.

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

4. Сравнение оценок: цена без состава работ ничего не значит

Разница в цене между студиями часто объясняется не маржой, а разным пониманием состава работ. Одна оценка включает discovery, UX, адаптив, дизайн-систему, разработку, тестирование, SEO-шаблоны, аналитику, инфраструктуру, релиз и гарантийный период. Другая включает только несколько экранов и верстку. Снаружи оба предложения называются разработка сайта. Поэтому сравнивать нужно не итоговую сумму, а декомпозицию, допущения и исключения.

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

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

5. Договор: права, исходники, лицензии и ответственность

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

Отдельно проверьте лицензии. В проекте могут использоваться open-source библиотеки, коммерческие шрифты, платные иконки, стоковые изображения, CMS, SaaS-сервисы, карты, аналитика, платёжные модули. Кто оплачивает лицензии? На кого оформлены аккаунты? Можно ли использовать материалы в рекламе? Что происходит, если сервис меняет тарифы? Эти вопросы лучше решить до старта, потому что после релиза они превращаются в юридические и операционные проблемы.

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

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

6. SLA и сопровождение: что будет после запуска

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

SLA не всегда означает круглосуточную поддержку. Он должен соответствовать критичности проекта. Для промо-сайта достаточно реакции в рабочее время и плановых релизов. Для портала с оплатами и личным кабинетом нужны приоритеты P1/P2/P3, окна обслуживания, мониторинг ошибок, резервные копии, правила отката, регламент обновлений безопасности и ответственные контакты. Главное — не обещание мы на связи, а конкретные условия реакции и восстановления.

• Попросите описать гарантию: что считается дефектом, как он фиксируется и в какие сроки исправляется.
• Согласуйте регулярность релизов: по запросу, раз в неделю, раз в две недели или в рамках monthly retainer.
• Определите, кто мониторит ошибки, uptime, формы заявок, интеграции и скорость сайта.
• Зафиксируйте, как передаются задачи: почта, трекер, чат, SLA-портал или совместный backlog.

7. Коммуникация: ритм, артефакты и прозрачность

Коммуникация в проекте — это не количество сообщений в чате. Это предсказуемый ритм решений. На старте нужно договориться, как проходят статусы, кто участвует во встречах, где хранятся решения, как согласуются макеты, как фиксируются изменения, кто имеет право расширять scope и что происходит, если заказчик задерживает обратную связь. Без этих правил проект часто стопорится не из-за разработки, а из-за ожидания комментариев и бесконечных уточнений.

Хорошая студия показывает работу артефактами: карта проекта, backlog, прототипы, дизайн-система, технические решения, тест-кейсы, demo-среда, отчёты по релизам. Плохая коммуникация выглядит как всё в работе, скоро покажем. Чем дольше команда работает без демонстрации промежуточных результатов, тем выше риск, что ожидания разошлись. Особенно это опасно в кастомной разработке, где продуктовые и технические решения связаны.

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

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

8. Красные и зелёные флаги подрядчика

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

Зелёные флаги тоже конкретны. Подрядчик задаёт неудобные, но полезные вопросы. Объясняет допущения. Делит проект на этапы. Говорит, что неизвестно. Предлагает discovery там, где без него опасно оценивать. Показывает релевантные кейсы с процессом, а не только картинками. Обсуждает тестирование, безопасность, SEO, поддержку и передачу прав. Не давит срочностью и не обещает невозможного. Такая команда может стоить дороже на старте, но обычно дешевле по полной стоимости владения.

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

9. Вопросы для интервью со студией

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

Полезно дать подрядчику маленький реальный сценарий. Например: у нас есть корпоративный сайт на конструкторе, нужно перенести на кастом, сохранить SEO, подключить CRM и сделать ru/en. Попросите описать первые две недели работы. В ответе должны появиться аудит текущего сайта, карта URL, контентная инвентаризация, требования к CRM, архитектура локализации, прототипы ключевых страниц, план миграции и список рисков. Если вместо этого вы слышите сразу нарисуем дизайн, процесс недостаточно зрелый.

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

Лучший вопрос подрядчику: что может пойти не так в нашем проекте и как вы предлагаете снизить этот риск?

10. Как принять решение и не затянуть выбор

Выбор студии должен быть структурированным, иначе он превращается в бесконечное сравнение впечатлений. Сделайте таблицу критериев: понимание задачи, релевантный опыт, качество вопросов, процесс, команда, архитектурная зрелость, прозрачность сметы, договор, права, SLA, коммуникация, культурное совпадение. Оцените каждого подрядчика по шкале и отдельно выпишите риски. Цена должна быть одним из критериев, но не единственным. Самое дешёвое предложение часто становится дорогим, если не включает аналитику, тестирование, SEO, DevOps и поддержку.

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

• Сначала отберите 3-5 студий по релевантности, затем сравнивайте их по одинаковому RFP.
• Проводите интервью с теми, кто будет делать проект, а не только с sales-командой.
• Просите финальное предложение в одинаковой структуре, чтобы видеть реальные отличия.
• Если проект важный и неопределённый, начните с discovery вместо попытки угадать весь scope сразу.

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