Вернуться к статьям Подрядчики могут прислать пять предложений на один сайт, а заказчик всё равно не получит пять сопоставимых оценок. Причина обычно не в цене, а в разном понимании границ: кто готовит контент, что включено в дизайн, как считается интеграция и кто принимает результат.
Зачем RFP нужен заказчику
RFP нужен не для того, чтобы собрать пять цен в одной таблице. Его задача — дать участникам одинаковые исходные данные, а заказчику получить ответы, которые можно сравнить по составу, предположениям и способу работы. Без этого одна команда оценит только шаблоны страниц, другая включит контент и интеграции, а третья оставит их за скобками. Документ не обязан превращаться в техническое задание на сотню страниц. Достаточно описать цель сайта, аудиторию, ключевые сценарии, известные ограничения, исходные материалы и порядок принятия решений. Неопределённость лучше назвать прямо, чем скрыть её за общим словом «современный сайт».
Какие разделы включить в RFP
В начале указывают контекст: зачем меняется сайт, какая проблема в текущей версии, какие пользователи и подразделения будут с ним работать. Затем описывают границы первого релиза: разделы, языки, каталог или услуги, формы, личный кабинет, интеграции, миграцию контента и требования к запуску. Отдельно фиксируют то, что предоставляет заказчик: тексты, фотографии, брендбук, доступы, выгрузки, правила обработки заявок и список согласующих. Если решение ещё не принято, его помещают в список открытых вопросов с владельцем. Это честнее, чем требовать от подрядчика угадать будущий процесс.
Как задать форму ответа
Попросите участников отвечать в одной структуре: состав работ по этапам, перечень результатов, срок при указанных допущениях, команда, стоимость, условия поддержки и список исключений. Свободная презентация может быть полезна на встрече, но не заменяет форму, по которой сравнивают предложения. Для сметы нужны отдельные колонки: включено, не включено, оценивается после уточнения, зависит от внешнего сервиса. Тогда неполная оценка не маскируется под низкую цену. Участнику стоит оставить поле для вопросов: хороший вопрос часто показывает, что команда заметила зависимость раньше, чем она стала проблемой.
Как составить матрицу оценки
Матрица не обязана притворяться точной математикой. В неё обычно попадают соответствие задаче, полнота состава работ, понятность допущений, опыт с похожими ограничениями, процесс коммуникации, стоимость и условия передачи результата. Веса задаёт заказчик до чтения предложений, иначе симпатия к первой презентации начнёт менять критерии. Оценка по строке должна ссылаться на конкретный фрагмент ответа или встречи. Вместо «понравилась команда» лучше записать: «описан тестовый контур обмена, но не указан владелец данных». Такая запись позволяет вернуться к решению через неделю и объяснить его коллегам.
Что делать с несопоставимыми сметами
Сначала приводят сметы к общей карте работ. Если в одном предложении есть проектирование, дизайн, разработка, контент, интеграция, тестирование и запуск, а в другом только «сайт», нельзя сравнивать итоговые суммы. Заказчик отмечает отсутствующие строки и отправляет одинаковые вопросы всем участникам. Иногда подрядчик честно оставляет диапазон, потому что данных для точной оценки нет. Такой ответ не хуже фиксированной цены автоматически. Его нужно читать вместе с допущениями, планом детализации и точкой, где диапазон превратится в согласованную оценку.
Как провести финальную встречу
На финальной встрече полезно разобрать один маршрут проекта: кто готовит прототип, как утверждается дизайн, что происходит при изменении данных, как проверяется интеграция и что передаётся после запуска. Презентация портфолио не отвечает на эти вопросы. После встречу фиксируют в той же матрице. Устные обещания не стоит переносить в вывод без подтверждения в предложении или отдельном письме. Так RFP остаётся рабочим документом до подписания, а не забытым файлом после выбора подрядчика.
Вопросы и ответы
- Сколько подрядчиков приглашать в RFP?
Столько, сколько заказчик сможет качественно сравнить. Небольшое число релевантных участников с одинаковым вводом полезнее длинной рассылки без времени на вопросы.
- Нужно ли раскрывать бюджет?
Диапазон помогает получить реалистичный состав решения, но его раскрытие зависит от закупочного порядка компании. Если бюджет не называют, особенно важны границы первого релиза и форма ответа.
- Как оценивать портфолио?
Смотрите не только на внешний вид страницы, но и на похожие ограничения: каталог, интеграция, миграция, роли редакторов, поддержка. Портфолио не отменяет проверку состава конкретного предложения.
- Что делать, если предложения отличаются по сроку?
Попросите участников связать срок с этапами, зависимостями и действиями заказчика. Один срок может включать ожидание контента, другой — считать его готовым к старту.
- Можно ли менять RFP после ответов?
Можно, но изменения рассылают всем участникам одновременно и дают время пересчитать ответ. Нельзя сравнивать предложения, подготовленные по разным исходным данным.
Вывод
Хороший RFP не делает выбор механическим, но убирает ложное сравнение. Он даёт заказчику общую карту работ, а подрядчику — возможность назвать допущения до того, как они станут неожиданным исключением.