Как проверить подрядчика и предложение на сайт в США — и снизить риск переделки

Гипотетический сценарий: одинаковое количество страниц — разные проекты

Представим два предложения на сайт из пяти страниц.

Предложение A включает дизайн, сборку страниц, контактную форму и публикацию. Тексты предоставляет заказчик. Сайт запускается в аккаунтах подрядчика, а перенос старых URL и аналитика не упоминаются.

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

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

Проблема возникает не из-за узкого объёма. Проблема возникает, когда узкий объём выглядит как полный проект.

Главное правило:

Сначала нормализуйте объём работ (scope), затем сравнивайте цену.

Proposal, SOW и договор должны описывать один проект

В американских проектах рядом могут использоваться несколько документов:

• proposal — коммерческое предложение с подходом, предполагаемым результатом и ценой;
• Statement of Work, или SOW — документ, определяющий объём работ, обязанности, сроки и критерии завершения;
• contract, или agreement — договор с юридическими условиями отношений сторон;
• estimate или quote — предварительная или фиксированная оценка стоимости, в зависимости от формулировки;
• приложения — спецификации, лицензии, графики, цены, дополнительные соглашения или запросы на изменение объёма (change orders).

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

Если в продаже обсуждались:

• стратегия;
• тексты;
• поисковая настройка;
• двуязычная версия;
• интеграции;
• аналитика;
• поддержка после запуска;

а в SOW осталось только «дизайн и разработка страниц», до подписания попросите включить важные обещания в SOW, договор или однозначно присоединённое приложение.

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

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

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

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

Практически любое предложение на сайт можно проверить по семи самостоятельным областям.

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

Реестр рисков предложения

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

Объём (scope)

• ВКЛЮЧЕНО
• ИСКЛЮЧЕНО
• НЕ РЕШЕНО

Ответственный

• ЗАКАЗЧИК
• ПОДРЯДЧИК
• СОВМЕСТНО

Внешняя зависимость

• НЕТ
• ТРЕТЬЯ СТОРОНА

Доказательство приёмки

Укажите:

• что должно быть передано;
• как это будет проверено;
• какое свидетельство подтверждает результат;
• блокирует ли несоответствие запуск.

Источник в документах

Укажите proposal, SOW, договор или приложение, а также раздел, страницу, версию и дату.

Один пункт может одновременно:

• входить в проект;
• быть ответственностью подрядчика;
• требовать материалы или решение заказчика;
• зависеть от внешнего сервиса;
• иметь определённый критерий приёмки.

Используйте НЕ ПРИМЕНЯЕТСЯ, когда поле действительно не относится к явно исключённому пункту. Не назначайте искусственного ответственного или критерий приёмки тому, что осознанно не входит в проект.

Статус «не решено» особенно важен: он может превратиться в задержку, спор, запрос на изменение объёма (change request) или дополнительный счёт.

Хорошее исключение лучше скрытого предположения. Фраза «тексты не входят; заказчик предоставляет утверждённый материал до начала дизайна» понятна. Фраза «контент обсудим по ходу проекта» оставляет риск обеим сторонам.

2. Что входит в проект — и чего в нём нет

Количество страниц — только один параметр.

Проверьте пять групп.

Страницы и контент

• URL и маршруты;
• тексты и редактирование;
• фотографии и другие материалы;
• блог или ресурсы;
• языковые версии.

Функции

• формы и уведомления;
• календарь;
• CRM;
• платежи;
• интеграции с электронной почтой и другими системами.

Перенос

• существующий контент;
• файлы и данные;
• старые URL и перенаправления (redirects);
• блог или архив материалов.

Настройка и проверка

• аналитика;
• Search Console;
• sitemap и robots;
• тестирование;
• проверка доступности;
• проверка производительности.

Запуск и передача

• публикация;
• обучение;
• учётные данные;
• документация;
• резервная копия или откат;
• переход к поддержке.

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

Не каждый проект должен включать всё перечисленное. Главное — видимая граница.

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

3. Кто предоставляет контент и принимает решения

Многие задержки начинаются не в разработке, а в отсутствии ответственного за материал, доступ, утверждение или решение.

Заранее определите, кто предоставляет и утверждает:

• позиционирование;
• список и границы услуг;
• профессиональные факты;
• тексты;
• переводы;
• бренд-материалы;
• фотографии;
• отзывы;
• сведения о лицензиях;
• доступы;
• финальную версию.

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

Внешняя зависимость не отменяет ответственности за процесс. Если используется третья сторона, предложение должно определить:

• кто координирует подключение;
• кто предоставляет доступ;
• кто утверждает и оплачивает расходы;
• кто проверяет результат;
• что происходит при изменении или отказе внешнего сервиса.

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

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

Карта прав и практического контроля

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

5. Почему выбрана именно эта технология

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

Попросите объяснить:

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

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

Интеграции

Фраза «интеграция календаря входит» недостаточно точна.

Нужно определить:

• конкретный сервис;
• место подключения;
• владельца аккаунта;
• какие данные передаются;
• что получает клиент после записи;
• кто оплачивает сторонний сервис;
• что и как тестируется;
• какой резервный сценарий предусмотрен при отказе сервиса.

То же относится к CRM, автоматизации электронной почты, чатам, платёжным системам и другим внешним сервисам. Отдельно проверьте, что должно происходить после формы, звонка или сообщения: кто фиксирует контекст, кто отвечает и как запускается follow-up.

6. Когда проект считается завершённым

Запуск — это событие. Приёмка — решение о том, соответствует ли результат согласованному объёму.

Возможные области проверки:

• согласованные страницы и контент;
• мобильное поведение;
• навигация и ссылки;
• формы и уведомления;
• языковые маршруты;
• заголовки, описания, канонические адреса (canonical) и hreflang, если применимо;
• перенаправления;
• sitemap и robots;
• Analytics и Search Console;
• проверка доступности и производительности;
• учётные данные и документация;
• резервная копия или откат;
• утверждение владельца.

Для существенных проверок фиксируют не только название, но и доказательство.

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

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

Одна оценка Lighthouse также не должна быть единственным определением качества.

7. Правки, изменение объёма, ошибки и поддержка — разные вещи

Правка

Изменение внутри согласованного результата до его утверждения.

Запрос на изменение (change request)

Новая задача или изменившееся решение, расширяющее первоначальный объём.

Ошибка (defect)

Результат не соответствует согласованному поведению или критериям приёмки.

Поддержка (maintenance)

Работа после запуска, например:

• обновления;
• резервные копии;
• безопасность;
• небольшие изменения контента;
• проверка интеграций;
• обслуживание платформы.

Предложение должно объяснять:

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

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

8. Как проверять портфолио и доказательства

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

Красивый скриншот показывает внешний вид. Он не доказывает качество процесса или бизнес-результат.

Сначала определите, что именно вы смотрите:

• опубликованный сайт;
• скриншот;
• концептуальный проект (Concept Project);
• шаблон;
• макет редизайна;
• кейс;
• отзыв;
• подтверждённую метрику.

Проверьте:

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

Концептуальный проект (Concept Project) может показывать мышление, структуру и направление дизайна. Но он не должен выдаваться за клиентский результат.

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

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

9. Какие формулировки требуют уточнения

Существенные предупреждающие сигналы:

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

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

Вместо категоричного вывода задайте два вопроса:

1. Какой риск создаёт эта модель?
2. Описан ли риск и приемлем ли он для бизнеса?

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

10. Как сравнить несколько предложений

Сравнивайте не количество обещаний, а закрытые и осознанно принятые риски.

Для каждого существенного обещания укажите документ, раздел, страницу и актуальную версию. Ссылка на место в proposal, SOW, договоре или приложении полезнее отметки «обсуждали на созвоне».

Где возникает риск повторных расходов

Риск появляется, когда контент, мобильное поведение, интеграции, перенос, доступы, лицензии, проверка или поддержка не были:

• включены;
• явно исключены;
• назначены конкретной стороне;
• связаны с приёмкой;
• закреплены в актуальном документе.

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

Последовательность решения

Перед подписанием:

1. Сопоставьте обсуждение на этапе продажи, proposal, SOW, договор и приложения.
2. Для каждого существенного результата определите объём.
3. Назначьте ответственного и зафиксируйте материалы и решения заказчика.
4. Зафиксируйте внешние зависимости и регулярные расходы.
5. Проверьте аккаунты, права, лицензии, оплату и порядок передачи.
6. Определите результат и доказательство приёмки.
7. Укажите документ, раздел, страницу и версию каждого важного обещания.
8. Разделите правки, новые задачи, ошибки и поддержку.
9. Уточните, исключите или осознанно примите красные риски.
10. Только после этого сравнивайте цену.

Цель не в том, чтобы удалить любой риск.

Цель — не позволить важному риску спрятаться внутри предположения.