Запрос цен (RFQ) — формализованный документ, который рассылают IT-компаниям с целью получения от них предложений с расчетами стоимости проекта. По сути, именно подготовка данного документа является отправной точкой в путешествии под названием «выбор подрядчика».
Чтобы процесс обсуждения проекта был максимально эффективным, а полученные предложения актуальными, необходимо тщательно проработать RFQ. В противном случае — длительные переговоры или даже задержка запуска проекта.
В первую очередь RQF должен содержать разделы, которые описывают проект максимально полно, а также важные условия, которые Вы как заказчик предъявляете к исполнителям. В целом, информация, содержащаяся в данных разделах, позволяет разработчикам определиться по следующим ключевым моментам:
степень соответствия имеющейся экспертизы предъявляемым требованиям к проекту,
готовность к сотрудничеству в рамках заданного проекта,
стоимость услуг по разработке программного обеспечения в рамках заданного проекта.
Здесь Вы даете четкое представление о своем бизнесе — отрасли, существующей инфраструктуре и проблемах, которые требуют автоматизации в рамках текущего проекта. Прочитав введение, разработчики должны определиться, готовы ли они взяться за этот проект.
Например, Вы являетесь застройщиком полного цикла и Вам нужно специализированное решение для проектирования зданий, основанное на BIM-технологиях. Если IT-компания специализируется только на небольших CRM-системах, она понимает, что не сможет выполнить данный проект. Другой пример — когда Вам необходимо мобильное приложение, а компания занимается исключительно веб-разработкой.
Пример шаблона раздела «Введение»:
Введение |
(указывается специализация бизнеса, инфраструктурная среда, проблемы, требующие автоматизации и т.д.) |
Здесь укажите решение, которое необходимо разработать. Опишите, кто будет использовать это приложение (конечные пользователи) и какие результаты Ваша компания планирует достичь с помощью этого решения (цель проекта).
Пример шаблона раздела «Общая характеристика проекта»:
Общая характеристика проекта |
Требуемое решение: (что) |
Конечные пользователи: (кто) |
|
Цель проекта: (зачем) |
Данный раздел преследует сразу две задачи. Во-первых, подробно представить Ваше видение необходимого Вам решения (каким должен быть функционал разрабатываемого ПО и т.д). Во-вторых, пояснить, какие услуги Вам требуются. Например, у Вас может быть проект «под ключ» и Вам требуется полный спектр услуг, начиная от бизнес-анализа и UI/UX дизайна и заканчивая тестированием. А, возможно, у Вас уже есть определенная информационная система и Вам необходимо ее адаптировать, развить функциональность, или же сделать рефакторинг. Наконец, возможно, Вам необходимы только услуги независимого аудита, тестировщиков и т.д.
Пример шаблона раздела «Детализация задач по проекту»:
Детализация задач по проекту |
Требуемые услуги: (услуги по разработке полного цикла, бизнес-аналитика, UI/UX дизайн, тестирование, аудит и т.д.) |
Требуемый функционал: (что и как должно работать)
|
Если у Вас проект с нуля, опишите здесь требуемую функциональность минимально жизнеспособного продукта (MVP). Для любого проекта — приоритизируйте задачи, указав, задачи первой очередности, второй и так далее.
Пример шаблона раздела «Объем проекта и ожидаемые результаты»:
Объем проекта и ожидаемые результаты |
Минимально жизнеспособный продукт: (его функциональность) |
Приоритизация задач: Задачи первой очередности: (реализуемая пользовательская история/модуль, реализуемый рефакторинг / аудит по отдельным модулям) Задачи второй очередности: (реализуемая пользовательская история/модуль, реализуемый рефакторинг / аудит по отдельным модулям) ... И т.д. |
Здесь укажите языки программирования, библиотеки, базы данных и иные технологии, на основе которых должна (планируется) вестись разработка. Если допускается вариативность в реализуемом технологическом стеке, укажите этот аспект.
Пример шаблона раздела «Стек технологий»:
Стек технологий |
Язык программирования: (для back-end и front-end разработки, при необходимости) |
Фреймворк: (Наименование/Альтернатива, если уместно) |
|
БД: (Наименование /Альтернатива, если уместно) |
|
Библиотеки: (Наименование /Альтернатива, если уместно) |
|
Иные детали: (при наличии) |
Здесь обозначьте, когда планируете начать проект, получить MVP, реализацию функционала, развертывание готовой системы. Таким образом, Вы выдаете разработчикам определенные временные ориентиры, чтобы они смогли определиться, смогут ли они уложиться в заданные сроки. Кроме того, срочность может вызвать необходимость введения повышающих коэффициентов при определении стоимости проекта.
Пример шаблона раздела «Этапы и сроки проекта»:
Этапы и сроки проекта |
Старт проекта: (дд.мм.гг) |
Дата поставки MVP: (дд.мм.гг) |
|
Дата завершения проекта (развертывание готового ПО): (дд.мм.гг) |
|
Промежуточные этапы:
|
Цель данного раздела — определить общие условия контракта. Укажите целевую модель ценообразования, приемлемую максимальную часовую ставку (если используете модель оплаты по фактически затраченному времени), бюджет проекта (если в качестве модели ценообразования таргетируете контракт с фиксированной ценой), способы оплаты и т.д.
Если для Вас важным является вопрос защиты интеллектуальной собственности, сохранности коммерческой тайны и т.д., отразите этот аспект в данном разделе. При наличии, укажите иные условия.
Пример шаблона раздела «Общие условия»:
Общие условия |
Целевая модель ценообразования: (контракт с фиксированной ценой, оплата по фактически отработанному времени, выделенная команда) |
Максимальная часовая ставка: (руб.) |
|
Способы оплаты: (предоплата, авансовый платеж, пост оплата и т.д.) |
|
Бюджет проекта: (руб.) |
|
Защита интеллектуальной собственности: (да/нет, способ защиты) |
|
Коммерческая тайна: (да/нет, способ защиты) |
|
Иные общие условия: (да/нет, какие именно) |
Данные разделы касаются не столько самого проекта, сколько вопросов взаимодействия контрагентов в рамках процедуры сбора и анализа предложений. Один RFQ может быть отправлен множеству компаний, занимающихся разработкой программного обеспечения. Поэтому необходимо установить определенные временные рамки, а также оговорить способ взаимодействия в период проведения тендерной процедуры.
Укажите здесь дату, когда Вы начинаете и заканчиваете принимать заявки и предложения от компаний-разработчиков. Основная цель данного раздела — это определение сроков. С одной стороны, Вы даете компаниям четкое представление о том, сколько у них есть времени для оценки Вашего запроса цен и подачи заявок. С другой стороны, Вы предельно четко обозначаете, что предложения, представленные после этой даты, исключаются из дальнейшего рассмотрения.
Пример шаблона раздела «Период сбора заявок»:
Период сбора заявок |
(дд.мм.гг) |
В данном разделе Вы указываете, кто с Вашей стороны будет отвечать за ответы и уточнения по вопросам, которые могут возникнуть у разработчиков в процессе обработки Вашего запроса цен и формирования предложений. Также, здесь следует указать контакты (номер рабочего телефона и/или email), по которым можно связаться для уточнений и получения необходимой информации.
Пример шаблона раздела «Контактное лицо»:
Контактное лицо |
Контактное лицо: (ФИО, должность,) |
Контакты для связи: (моб. тел., email) |
Укажите каналы, по которым компании могут направлять Вам свои предложения в рамках данного запроса цен, а также способы и форматы их представления. Например, это может быть подача посредством простого email или же регистрации на специальной платформе и подача заявки через данную платформу. Если есть — особые требования по формату и размеру прикрепляемых файлов.
Также можно разработать унифицированную форму и уведомить потенциальных контрагентов о необходимости подачи заявок исключительно по данной форме.
Пример шаблона раздела «Способ подачи коммерческих предложений»:
Способ подачи коммерческих предложений |
Метод подачи КП: (email, адрес платформы в сети и т.д.) |
Требуемый формат: (MS Word, PDF, и т.д.) |
|
Иные требования: (максимальный размер файла т.д.) |
|
Шаблон заявки: (при наличии) |
Основная цель данного раздела — установить входной барьер для участия IT-компаний в процедуре отбора. Данный раздел является элективным и включается в RFQ на Ваше усмотрение.
Например, здесь Вы можете указать, минимальный штат компании-заявителя, уровень квалификации и опыт разработчиков, которые будут работать над проектом, релевантную информацию о предыдущих проектах.
Пример шаблона раздела «Способ подачи коммерческих предложений»:
Требования к квалификации |
Размер компании: (минимальное количество разработчиков) |
Допустимый уровень квалификации: (junior, middle, senior, владение технологиями, опыт и т.д.) |
|
Проектный опыт: (какие проекты выполнялись) |
|
Минимальная продолжительность завершенных проектов: (в днях, неделях или месяцах) |
|
Проверка уровня заявленной экспертизы: (тестовое задание, собеседование, пилотный проект и т.д.) |
|
Другие требования: (при наличии) |
Следует отметить, что вполне допустимо, если Вы включите свои разделы в представленный шаблон запроса цен. Однако, важным здесь является условие целесообразности включения этих разделов, чтобы не перегружать документ.
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.