Как составить запрос предложений (RFP) на разработку ПО
Практика3 минРедакция Innovialabs
Коротко
Хороший RFP описывает задачу, пользователей, функции, ограничения и формат ответа, а предложения сравниваются по заранее заданным критериям с весами — не только по цене.
Что такое RFP и когда он нужен
RFP (Request for Proposal) — документ, который вы отправляете нескольким подрядчикам, чтобы получить сопоставимые предложения по проекту. Он нужен, когда вы выбираете исполнителя из нескольких компаний и хотите сравнивать ответы по одним и тем же параметрам.
Главная цель RFP — дать подрядчикам достаточно информации для точной оценки. Чем меньше неясностей, тем меньше «запаса на риски» закладывается в цену и тем ближе ответы друг к другу.
Структура RFP
1. О компании и проекте
Кратко: чем занимается компания, зачем нужен проект и какую бизнес-проблему он решает. Укажите, как вы будете измерять успех.
2. Пользователи и сценарии
Кто будет пользоваться системой и что именно они будут делать. Сценарии вида «менеджер получает заявку, назначает исполнителя, клиент видит статус» дают подрядчику больше, чем абстрактный список функций.
3. Функциональные требования
Перечислите функции и отметьте приоритет каждой: обязательно для запуска, желательно, можно позже. Это позволит подрядчикам предложить поэтапный план.
4. Нефункциональные требования
- ожидаемая нагрузка и число пользователей;
- требования к безопасности и хранению данных;
- языки интерфейса;
- платформы: веб, iOS, Android;
- требования к доступности и скорости работы.
5. Интеграции и текущая инфраструктура
Какие системы уже есть: CRM, 1С, платёжные сервисы, складской учёт. Есть ли у них API, кто их поддерживает.
6. Ограничения
Желаемые сроки, рамки бюджета (хотя бы диапазон), предпочтения по технологиям, если они обоснованы, — например, ваша команда будет поддерживать продукт на определённом стеке.
7. Что вы ожидаете в ответе
Задайте единый формат ответа, иначе сравнивать будет трудно:
- понимание задачи своими словами;
- предлагаемое решение и стек;
- план по этапам и срокам;
- оценка стоимости с разбивкой по этапам;
- состав команды;
- релевантный опыт;
- модель оплаты и условия поддержки;
- допущения и риски.
8. Процесс и сроки отбора
Дата отправки вопросов, дата ответа, когда будет решение, контактное лицо.
Как сделать оценки точнее
- Приложите материалы: макеты, примеры, схемы процессов.
- Разрешите вопросы и делитесь ответами со всеми участниками — это уравнивает условия.
- Попросите указать допущения. Часто разница в цене объясняется тем, что компании по-разному поняли объём.
- Не требуйте фиксированной цены, если требования ещё сырые. Лучше попросить диапазон и стоимость этапа аналитики.
Как оценивать ответы
Составьте таблицу критериев с весами до того, как получите ответы. Пример набора:
| Критерий | Что проверять |
|---|---|
| Понимание задачи | Пересказал ли подрядчик вашу проблему, а не шаблон |
| Качество решения | Обоснован ли стек, учтены ли интеграции |
| Опыт | Есть ли похожие проекты, можно ли их посмотреть |
| Команда | Кто конкретно будет работать над проектом |
| Сроки и план | Реалистичность, наличие промежуточных результатов |
| Стоимость | Прозрачность разбивки, что включено |
| Процесс | Отчётность, коммуникация, работа с изменениями |
Каждый оценщик ставит баллы независимо, затем результаты сводятся. Веса выбираете вы — исходя из того, что для проекта критичнее.
Частые ошибки
- Слишком общий документ — ответы получатся несравнимыми.
- Слишком детальный документ с готовой архитектурой — вы лишаете себя экспертизы подрядчиков.
- Выбор только по цене. Самое дешёвое предложение часто просто включает меньше работы.
- Рассылка десяткам компаний. Качественно сравнить много ответов сложно; разумнее заранее отобрать короткий список.