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

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

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

Объём (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) может показывать мышление, структуру и направление дизайна. Но он не должен выдаваться за клиентский результат.

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

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

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

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

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

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

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

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

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