[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f3ho7fvi28rtjv":3},{"slug":4,"title":5,"published":6,"publishedAt":7,"createdAt":7,"section":8,"preview":9,"heroImage":8,"previewImage":10,"headMarkup":11,"lifecycleId":42,"bodyMd":43,"bodyHtml":44},"rfp-na-razrabotku-sayta-struktura-dokumenta-i-kriterii-sravneniya-predlozheniy-agentstv","RFP на разработку сайта: структура документа и критерии сравнения предложений агентств",true,"2026-07-04T09:00:00+03:00",null,"Как подготовить RFP на разработку сайта, собрать сопоставимые ответы и выбрать подрядчика по составу работ, допущениям и процессу.","\u002Fcontent-media\u002Farticles\u002Frfp-na-razrabotku-sayta-struktura-dokumenta-i-kriterii-sravneniya-predlozheniy-agentstv\u002Fassets\u002F2ae56b50301a.webp",[12],{"tag":13,"type":14,"key":15,"json":16},"script","application\u002Fld+json","rfp-na-razrabotku-sayta-struktura-dokumenta-i-kriterii-sravneniya-predlozheniy-agentstv-faq",{"@context":17,"@type":18,"mainEntity":19},"https:\u002F\u002Fschema.org","FAQPage",[20,26,30,34,38],{"@type":21,"name":22,"acceptedAnswer":23},"Question","Сколько подрядчиков приглашать в RFP?",{"@type":24,"text":25},"Answer","Столько, сколько заказчик сможет качественно сравнить. Небольшое число релевантных участников с одинаковым вводом полезнее длинной рассылки без времени на вопросы.",{"@type":21,"name":27,"acceptedAnswer":28},"Нужно ли раскрывать бюджет?",{"@type":24,"text":29},"Диапазон помогает получить реалистичный состав решения, но его раскрытие зависит от закупочного порядка компании. Если бюджет не называют, особенно важны границы первого релиза и форма ответа.",{"@type":21,"name":31,"acceptedAnswer":32},"Как оценивать портфолио?",{"@type":24,"text":33},"Смотрите не только на внешний вид страницы, но и на похожие ограничения: каталог, интеграция, миграция, роли редакторов, поддержка. Портфолио не отменяет проверку состава конкретного предложения.",{"@type":21,"name":35,"acceptedAnswer":36},"Что делать, если предложения отличаются по сроку?",{"@type":24,"text":37},"Попросите участников связать срок с этапами, зависимостями и действиями заказчика. Один срок может включать ожидание контента, другой — считать его готовым к старту.",{"@type":21,"name":39,"acceptedAnswer":40},"Можно ли менять RFP после ответов?",{"@type":24,"text":41},"Можно, но изменения рассылают всем участникам одновременно и дают время пересчитать ответ. Нельзя сравнивать предложения, подготовленные по разным исходным данным.","lc_a985e97d7663454db26d25c0e308256e","# RFP на разработку сайта: структура документа и критерии сравнения предложений агентств\n\nПодрядчики могут прислать пять предложений на один сайт, а заказчик всё равно не получит пять сопоставимых оценок. Причина обычно не в цене, а в разном понимании границ: кто готовит контент, что включено в дизайн, как считается интеграция и кто принимает результат.\n\n## Зачем RFP нужен заказчику\n\nRFP нужен не для того, чтобы собрать пять цен в одной таблице. Его задача — дать участникам одинаковые исходные данные, а заказчику получить ответы, которые можно сравнить по составу, предположениям и способу работы. Без этого одна команда оценит только шаблоны страниц, другая включит контент и интеграции, а третья оставит их за скобками.\nДокумент не обязан превращаться в техническое задание на сотню страниц. Достаточно описать цель сайта, аудиторию, ключевые сценарии, известные ограничения, исходные материалы и порядок принятия решений. Неопределённость лучше назвать прямо, чем скрыть её за общим словом «современный сайт».\n\n## Какие разделы включить в RFP\n\nВ начале указывают контекст: зачем меняется сайт, какая проблема в текущей версии, какие пользователи и подразделения будут с ним работать. Затем описывают границы первого релиза: разделы, языки, каталог или услуги, формы, личный кабинет, интеграции, миграцию контента и требования к запуску.\nОтдельно фиксируют то, что предоставляет заказчик: тексты, фотографии, брендбук, доступы, выгрузки, правила обработки заявок и список согласующих. Если решение ещё не принято, его помещают в список открытых вопросов с владельцем. Это честнее, чем требовать от подрядчика угадать будущий процесс.\n\n## Как задать форму ответа\n\nПопросите участников отвечать в одной структуре: состав работ по этапам, перечень результатов, срок при указанных допущениях, команда, стоимость, условия поддержки и список исключений. Свободная презентация может быть полезна на встрече, но не заменяет форму, по которой сравнивают предложения.\nДля сметы нужны отдельные колонки: включено, не включено, оценивается после уточнения, зависит от внешнего сервиса. Тогда неполная оценка не маскируется под низкую цену. Участнику стоит оставить поле для вопросов: хороший вопрос часто показывает, что команда заметила зависимость раньше, чем она стала проблемой.\n\n## Как составить матрицу оценки\n\nМатрица не обязана притворяться точной математикой. В неё обычно попадают соответствие задаче, полнота состава работ, понятность допущений, опыт с похожими ограничениями, процесс коммуникации, стоимость и условия передачи результата. Веса задаёт заказчик до чтения предложений, иначе симпатия к первой презентации начнёт менять критерии.\nОценка по строке должна ссылаться на конкретный фрагмент ответа или встречи. Вместо «понравилась команда» лучше записать: «описан тестовый контур обмена, но не указан владелец данных». Такая запись позволяет вернуться к решению через неделю и объяснить его коллегам.\n\n## Что делать с несопоставимыми сметами\n\nСначала приводят сметы к общей карте работ. Если в одном предложении есть проектирование, дизайн, разработка, контент, интеграция, тестирование и запуск, а в другом только «сайт», нельзя сравнивать итоговые суммы. Заказчик отмечает отсутствующие строки и отправляет одинаковые вопросы всем участникам.\nИногда подрядчик честно оставляет диапазон, потому что данных для точной оценки нет. Такой ответ не хуже фиксированной цены автоматически. Его нужно читать вместе с допущениями, планом детализации и точкой, где диапазон превратится в согласованную оценку.\n\n## Как провести финальную встречу\n\nНа финальной встрече полезно разобрать один маршрут проекта: кто готовит прототип, как утверждается дизайн, что происходит при изменении данных, как проверяется интеграция и что передаётся после запуска. Презентация портфолио не отвечает на эти вопросы.\nПосле встречу фиксируют в той же матрице. Устные обещания не стоит переносить в вывод без подтверждения в предложении или отдельном письме. Так RFP остаётся рабочим документом до подписания, а не забытым файлом после выбора подрядчика.\n\n![RFP и сравнение](\u002Fcontent-media\u002Farticles\u002Frfp-na-razrabotku-sayta-struktura-dokumenta-i-kriterii-sravneniya-predlozheniy-agentstv\u002Fassets\u002Fa56f470d3375.webp)\n\n## Вопросы и ответы\n\n### Сколько подрядчиков приглашать в RFP?\n\nСтолько, сколько заказчик сможет качественно сравнить. Небольшое число релевантных участников с одинаковым вводом полезнее длинной рассылки без времени на вопросы.\n\n### Нужно ли раскрывать бюджет?\n\nДиапазон помогает получить реалистичный состав решения, но его раскрытие зависит от закупочного порядка компании. Если бюджет не называют, особенно важны границы первого релиза и форма ответа.\n\n### Как оценивать портфолио?\n\nСмотрите не только на внешний вид страницы, но и на похожие ограничения: каталог, интеграция, миграция, роли редакторов, поддержка. Портфолио не отменяет проверку состава конкретного предложения.\n\n### Что делать, если предложения отличаются по сроку?\n\nПопросите участников связать срок с этапами, зависимостями и действиями заказчика. Один срок может включать ожидание контента, другой — считать его готовым к старту.\n\n### Можно ли менять RFP после ответов?\n\nМожно, но изменения рассылают всем участникам одновременно и дают время пересчитать ответ. Нельзя сравнивать предложения, подготовленные по разным исходным данным.\n\n## Вывод\n\nХороший RFP не делает выбор механическим, но убирает ложное сравнение. Он даёт заказчику общую карту работ, а подрядчику — возможность назвать допущения до того, как они станут неожиданным исключением.\n","\u003Ch1>RFP на разработку сайта: структура документа и критерии сравнения предложений агентств\u003C\u002Fh1>\n\u003Cp>Подрядчики могут прислать пять предложений на один сайт, а заказчик всё равно не получит пять сопоставимых оценок. Причина обычно не в цене, а в разном понимании границ: кто готовит контент, что включено в дизайн, как считается интеграция и кто принимает результат.\u003C\u002Fp>\n\u003Ch2>Зачем RFP нужен заказчику\u003C\u002Fh2>\n\u003Cp>RFP нужен не для того, чтобы собрать пять цен в одной таблице. Его задача — дать участникам одинаковые исходные данные, а заказчику получить ответы, которые можно сравнить по составу, предположениям и способу работы. Без этого одна команда оценит только шаблоны страниц, другая включит контент и интеграции, а третья оставит их за скобками.\nДокумент не обязан превращаться в техническое задание на сотню страниц. Достаточно описать цель сайта, аудиторию, ключевые сценарии, известные ограничения, исходные материалы и порядок принятия решений. Неопределённость лучше назвать прямо, чем скрыть её за общим словом «современный сайт».\u003C\u002Fp>\n\u003Ch2>Какие разделы включить в RFP\u003C\u002Fh2>\n\u003Cp>В начале указывают контекст: зачем меняется сайт, какая проблема в текущей версии, какие пользователи и подразделения будут с ним работать. Затем описывают границы первого релиза: разделы, языки, каталог или услуги, формы, личный кабинет, интеграции, миграцию контента и требования к запуску.\nОтдельно фиксируют то, что предоставляет заказчик: тексты, фотографии, брендбук, доступы, выгрузки, правила обработки заявок и список согласующих. Если решение ещё не принято, его помещают в список открытых вопросов с владельцем. Это честнее, чем требовать от подрядчика угадать будущий процесс.\u003C\u002Fp>\n\u003Ch2>Как задать форму ответа\u003C\u002Fh2>\n\u003Cp>Попросите участников отвечать в одной структуре: состав работ по этапам, перечень результатов, срок при указанных допущениях, команда, стоимость, условия поддержки и список исключений. Свободная презентация может быть полезна на встрече, но не заменяет форму, по которой сравнивают предложения.\nДля сметы нужны отдельные колонки: включено, не включено, оценивается после уточнения, зависит от внешнего сервиса. Тогда неполная оценка не маскируется под низкую цену. Участнику стоит оставить поле для вопросов: хороший вопрос часто показывает, что команда заметила зависимость раньше, чем она стала проблемой.\u003C\u002Fp>\n\u003Ch2>Как составить матрицу оценки\u003C\u002Fh2>\n\u003Cp>Матрица не обязана притворяться точной математикой. В неё обычно попадают соответствие задаче, полнота состава работ, понятность допущений, опыт с похожими ограничениями, процесс коммуникации, стоимость и условия передачи результата. Веса задаёт заказчик до чтения предложений, иначе симпатия к первой презентации начнёт менять критерии.\nОценка по строке должна ссылаться на конкретный фрагмент ответа или встречи. Вместо «понравилась команда» лучше записать: «описан тестовый контур обмена, но не указан владелец данных». Такая запись позволяет вернуться к решению через неделю и объяснить его коллегам.\u003C\u002Fp>\n\u003Ch2>Что делать с несопоставимыми сметами\u003C\u002Fh2>\n\u003Cp>Сначала приводят сметы к общей карте работ. Если в одном предложении есть проектирование, дизайн, разработка, контент, интеграция, тестирование и запуск, а в другом только «сайт», нельзя сравнивать итоговые суммы. Заказчик отмечает отсутствующие строки и отправляет одинаковые вопросы всем участникам.\nИногда подрядчик честно оставляет диапазон, потому что данных для точной оценки нет. Такой ответ не хуже фиксированной цены автоматически. Его нужно читать вместе с допущениями, планом детализации и точкой, где диапазон превратится в согласованную оценку.\u003C\u002Fp>\n\u003Ch2>Как провести финальную встречу\u003C\u002Fh2>\n\u003Cp>На финальной встрече полезно разобрать один маршрут проекта: кто готовит прототип, как утверждается дизайн, что происходит при изменении данных, как проверяется интеграция и что передаётся после запуска. Презентация портфолио не отвечает на эти вопросы.\nПосле встречу фиксируют в той же матрице. Устные обещания не стоит переносить в вывод без подтверждения в предложении или отдельном письме. Так RFP остаётся рабочим документом до подписания, а не забытым файлом после выбора подрядчика.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fcontent-media\u002Farticles\u002Frfp-na-razrabotku-sayta-struktura-dokumenta-i-kriterii-sravneniya-predlozheniy-agentstv\u002Fassets\u002Fa56f470d3375.webp\" alt=\"RFP и сравнение\">\u003C\u002Fp>\n\u003Ch2>Вопросы и ответы\u003C\u002Fh2>\n\u003Ch3>Сколько подрядчиков приглашать в RFP?\u003C\u002Fh3>\n\u003Cp>Столько, сколько заказчик сможет качественно сравнить. Небольшое число релевантных участников с одинаковым вводом полезнее длинной рассылки без времени на вопросы.\u003C\u002Fp>\n\u003Ch3>Нужно ли раскрывать бюджет?\u003C\u002Fh3>\n\u003Cp>Диапазон помогает получить реалистичный состав решения, но его раскрытие зависит от закупочного порядка компании. Если бюджет не называют, особенно важны границы первого релиза и форма ответа.\u003C\u002Fp>\n\u003Ch3>Как оценивать портфолио?\u003C\u002Fh3>\n\u003Cp>Смотрите не только на внешний вид страницы, но и на похожие ограничения: каталог, интеграция, миграция, роли редакторов, поддержка. Портфолио не отменяет проверку состава конкретного предложения.\u003C\u002Fp>\n\u003Ch3>Что делать, если предложения отличаются по сроку?\u003C\u002Fh3>\n\u003Cp>Попросите участников связать срок с этапами, зависимостями и действиями заказчика. Один срок может включать ожидание контента, другой — считать его готовым к старту.\u003C\u002Fp>\n\u003Ch3>Можно ли менять RFP после ответов?\u003C\u002Fh3>\n\u003Cp>Можно, но изменения рассылают всем участникам одновременно и дают время пересчитать ответ. Нельзя сравнивать предложения, подготовленные по разным исходным данным.\u003C\u002Fp>\n\u003Ch2>Вывод\u003C\u002Fh2>\n\u003Cp>Хороший RFP не делает выбор механическим, но убирает ложное сравнение. Он даёт заказчику общую карту работ, а подрядчику — возможность назвать допущения до того, как они станут неожиданным исключением.\u003C\u002Fp>\n"]