Пять предложений на один сайт — и ни одного честного сравнения. Так заканчивается большинство подборов подрядчика: заказчик получает пять документов, написанных под разные исходные данные, и пытается выбрать по цене.
Проблема почти никогда в цене. Она в границах. Кто-то оценил только шаблоны страниц, кто-то включил контент и интеграции, кто-то честно оставил диапазон, потому что данных для точной оценки нет. Сравнивать итоговые суммы в такой ситуации — сравнивать несопоставимое.
Выход — RFP (request for proposal). Не техническое задание на сотню страниц, а короткий рабочий документ, который выравнивает вводные для всех участников.
Что должно быть внутри
Начните с контекста: зачем меняется сайт, какая проблема в текущей версии, кто будет с ним работать. Дальше — границы первого релиза: разделы, языки, формы, личный кабинет, интеграции, миграция контента, требования к запуску.
Отдельным блоком зафиксируйте, что предоставляет заказчик: тексты, фотографии, брендбук, доступы, выгрузки, правила обработки заявок, список согласующих. Решения, которых ещё нет, не прячьте — выносите в открытые вопросы с владельцем. Подрядчик, увидевший неопределённость до старта, дешевле подрядчика, который нашёл её в середине проекта.
Форма ответа важнее красоты презентации
Просите всех отвечать в одной структуре: состав работ по этапам, перечень результатов, срок при указанных допущениях, команда, стоимость, условия поддержки, список исключений.
Для сметы попросите колонки: «включено», «не включено», «оценивается после уточнения», «зависит от внешнего сервиса». Тогда неполная оценка не будет маскироваться под низкую цену. А поле для вопросов участнику оставлять стоит: хороший вопрос часто показывает, что команда заметила зависимость раньше, чем та стала проблемой.
Матрица оценки
Матрица не обязана притворяться точной математикой. В неё обычно попадают соответствие задаче, полнота состава работ, понятность допущений, опыт с похожими ограничениями, процесс коммуникации, стоимость и условия передачи результата.
Важно: веса ставятся до чтения предложений. Иначе симпатия к первой презентации начнёт подстраивать критерии под себя.
Оценка по каждой строке должна ссылаться на конкретный фрагмент ответа. Вместо «понравилась команда» — «описан тестовый контур обмена, но не указан владелец данных». Такую запись можно показать коллеге через неделю, и она объяснит решение сама.
Несопоставимые сметы
Сначала приведите сметы к общей карте работ. Если в одном предложении есть проектирование, дизайн, разработка, контент, интеграция, тестирование и запуск, а в другом просто «сайт» — итоговые суммы сравнивать нельзя. Отметьте отсутствующие строки и отправьте одинаковые вопросы всем участникам.
Диапазон вместо фиксированной цены — не признак слабости. Читайте его вместе с допущениями и точкой, где диапазон превратится в согласованную оценку.
Финальная встреча
На встрече разберите один маршрут проекта: кто готовит прототип, как утверждается дизайн, что происходит при изменении данных, как проверяется интеграция, что передаётся после запуска. Портфолио на эти вопросы не отвечает.
Все договорённости фиксируйте в той же матрице. Устные обещания в вывод не переносятся без подтверждения в предложении или письме.
Из практики
Самая частая ошибка — менять RFP после получения ответов и сравнивать предложения, подготовленные по разным исходным данным. Если изменения нужны, рассылайте их всем участникам одновременно и давайте время пересчитать ответ. Иначе вы выбираете не лучшую команду, а самую удачливую в угадайке.
Хороший RFP выбор механическим не делает, но убирает ложное сравнение: заказчик получает общую карту работ, а подрядчик — возможность назвать допущения до того, как они станут неожиданным исключением в счёте.
Top comments (0)