Как грамотно составить RFQ для проекта разработки программного обеспечения20.03.2023 15:01

Запрос цен (RFQ) — формализованный документ, который рассылают IT-компаниям с целью получения от них предложений с расчетами стоимости проекта. По сути, именно подготовка данного документа является отправной точкой в путешествии под названием «выбор подрядчика».

Чтобы процесс обсуждения проекта был максимально эффективным, а полученные предложения актуальными, необходимо тщательно проработать RFQ. В противном случае — длительные переговоры или даже задержка запуска проекта.

Разделы RFQ, касающиеся непосредственно проекта и условий взаимодействия

В первую очередь RQF должен содержать разделы, которые описывают проект максимально полно, а также важные условия, которые Вы как заказчик предъявляете к исполнителям. В целом, информация, содержащаяся в данных разделах, позволяет разработчикам определиться по следующим ключевым моментам:

• степень соответствия имеющейся экспертизы предъявляемым требованиям к проекту,

• готовность к сотрудничеству в рамках заданного проекта,

• стоимость услуг по разработке программного обеспечения в рамках заданного проекта.

Введение

Здесь Вы даете четкое представление о своем бизнесе — отрасли, существующей инфраструктуре и проблемах, которые требуют автоматизации в рамках текущего проекта. Прочитав введение, разработчики должны определиться, готовы ли они взяться за этот проект.

Например, Вы являетесь застройщиком полного цикла и Вам нужно специализированное решение для проектирования зданий, основанное на BIM-технологиях. Если IT-компания специализируется только на небольших CRM-системах, она понимает, что не сможет выполнить данный проект. Другой пример — когда Вам необходимо мобильное приложение, а компания занимается исключительно веб-разработкой.

Пример шаблона раздела «Введение»:

Введение

(указывается специализация бизнеса, инфраструктурная среда, проблемы, требующие автоматизации и т.д.)

Общая характеристика проекта

Здесь укажите решение, которое необходимо разработать. Опишите, кто будет использовать это приложение (конечные пользователи) и какие результаты Ваша компания планирует достичь с помощью этого решения (цель проекта).

Пример шаблона раздела «Общая характеристика проекта»:

Общая характеристика проекта	Требуемое решение: (что)
Конечные пользователи: (кто)
Цель проекта: (зачем)

Детализация задач по проекту

Данный раздел преследует сразу две задачи. Во-первых, подробно представить Ваше видение необходимого Вам решения (каким должен быть функционал разрабатываемого ПО и т.д). Во-вторых, пояснить, какие услуги Вам требуются. Например, у Вас может быть проект «под ключ» и Вам требуется полный спектр услуг, начиная от бизнес-анализа и UI/UX дизайна и заканчивая тестированием. А, возможно, у Вас уже есть определенная информационная система и Вам необходимо ее адаптировать, развить функциональность, или же сделать рефакторинг. Наконец, возможно, Вам необходимы только услуги независимого аудита, тестировщиков и т.д.

Пример шаблона раздела «Детализация задач по проекту»:

Детализация задач по проекту	Требуемые услуги: (услуги по разработке полного цикла, бизнес-аналитика, UI/UX дизайн, тестирование, аудит и т.д.)
Требуемый функционал: (что и как должно работать)

Объем проекта и ожидаемые результаты

Если у Вас проект с нуля, опишите здесь требуемую функциональность минимально жизнеспособного продукта (MVP). Для любого проекта — приоритизируйте задачи, указав, задачи первой очередности, второй и так далее.

Пример шаблона раздела «Объем проекта и ожидаемые результаты»:

Объем проекта и ожидаемые результаты	Минимально жизнеспособный продукт: (его функциональность)
Приоритизация задач: Задачи первой очередности: (реализуемая пользовательская история/модуль, реализуемый рефакторинг / аудит по отдельным модулям) Задачи второй очередности: (реализуемая пользовательская история/модуль, реализуемый рефакторинг / аудит по отдельным модулям) … И т.д.

Стек технологий

Здесь укажите языки программирования, библиотеки, базы данных и иные технологии, на основе которых должна (планируется) вестись разработка. Если допускается вариативность в реализуемом технологическом стеке, укажите этот аспект.

Пример шаблона раздела «Стек технологий»:

Стек технологий	Язык программирования: (для back-end и front-end разработки, при необходимости)
Фреймворк: (Наименование/Альтернатива, если уместно)
БД: (Наименование /Альтернатива, если уместно)
Библиотеки: (Наименование /Альтернатива, если уместно)
Иные детали: (при наличии)

Этапы и сроки проекта

Здесь обозначьте, когда планируете начать проект, получить MVP, реализацию функционала, развертывание готовой системы. Таким образом, Вы выдаете разработчикам определенные временные ориентиры, чтобы они смогли определиться, смогут ли они уложиться в заданные сроки. Кроме того, срочность может вызвать необходимость введения повышающих коэффициентов при определении стоимости проекта.

Пример шаблона раздела «Этапы и сроки проекта»:

Этапы и сроки проекта	Старт проекта: (дд.мм.гг)
Дата поставки MVP: (дд.мм.гг)
Дата завершения проекта (развертывание готового ПО): (дд.мм.гг)
Промежуточные этапы:

Общие условия

Цель данного раздела — определить общие условия контракта. Укажите целевую модель ценообразования, приемлемую максимальную часовую ставку (если используете модель оплаты по фактически затраченному времени), бюджет проекта (если в качестве модели ценообразования таргетируете контракт с фиксированной ценой), способы оплаты и т.д.

Если для Вас важным является вопрос защиты интеллектуальной собственности, сохранности коммерческой тайны и т.д., отразите этот аспект в данном разделе. При наличии, укажите иные условия.

Пример шаблона раздела «Общие условия»:

Общие условия	Целевая модель ценообразования: (контракт с фиксированной ценой, оплата по фактически отработанному времени, выделенная команда)
Максимальная часовая ставка: (руб.)
Способы оплаты: (предоплата, авансовый платеж, пост оплата и т.д.)
Бюджет проекта: (руб.)
Защита интеллектуальной собственности: (да/нет, способ защиты)
Коммерческая тайна: (да/нет, способ защиты)
Иные общие условия: (да/нет, какие именно)

Разделы RFQ, определяющие условия сбора предложений

Данные разделы касаются не столько самого проекта, сколько вопросов взаимодействия контрагентов в рамках процедуры сбора и анализа предложений. Один RFQ может быть отправлен множеству компаний, занимающихся разработкой программного обеспечения. Поэтому необходимо установить определенные временные рамки, а также оговорить способ взаимодействия в период проведения тендерной процедуры.

Период сбора заявок

Укажите здесь дату, когда Вы начинаете и заканчиваете принимать заявки и предложения от компаний-разработчиков. Основная цель данного раздела — это определение сроков. С одной стороны, Вы даете компаниям четкое представление о том, сколько у них есть времени для оценки Вашего запроса цен и подачи заявок. С другой стороны, Вы предельно четко обозначаете, что предложения, представленные после этой даты, исключаются из дальнейшего рассмотрения.

Пример шаблона раздела «Период сбора заявок»:

Период сбора заявок

(дд.мм.гг)

Контактное лицо

В данном разделе Вы указываете, кто с Вашей стороны будет отвечать за ответы и уточнения по вопросам, которые могут возникнуть у разработчиков в процессе обработки Вашего запроса цен и формирования предложений. Также, здесь следует указать контакты (номер рабочего телефона и/или email), по которым можно связаться для уточнений и получения необходимой информации.

Пример шаблона раздела «Контактное лицо»:

Контактное лицо	Контактное лицо: (ФИО, должность,)
Контакты для связи: (моб. тел., email)

Способ подачи коммерческих предложений

Укажите каналы, по которым компании могут направлять Вам свои предложения в рамках данного запроса цен, а также способы и форматы их представления. Например, это может быть подача посредством простого email или же регистрации на специальной платформе и подача заявки через данную платформу. Если есть — особые требования по формату и размеру прикрепляемых файлов.

Также можно разработать унифицированную форму и уведомить потенциальных контрагентов о необходимости подачи заявок исключительно по данной форме.

Пример шаблона раздела «Способ подачи коммерческих предложений»:

Способ подачи коммерческих предложений	Метод подачи КП: (email, адрес платформы в сети и т.д.)
Требуемый формат: (MS Word, PDF, и т.д.)
Иные требования: (максимальный размер файла т.д.)
Шаблон заявки: (при наличии)

Требования к квалификации

Основная цель данного раздела — установить входной барьер для участия IT-компаний в процедуре отбора. Данный раздел является элективным и включается в RFQ на Ваше усмотрение.

Например, здесь Вы можете указать, минимальный штат компании-заявителя, уровень квалификации и опыт разработчиков, которые будут работать над проектом, релевантную информацию о предыдущих проектах.

Пример шаблона раздела «Способ подачи коммерческих предложений»:

Требования к квалификации	Размер компании: (минимальное количество разработчиков)
Допустимый уровень квалификации: (junior, middle, senior, владение технологиями, опыт и т.д.)
Проектный опыт: (какие проекты выполнялись)
Минимальная продолжительность завершенных проектов: (в днях, неделях или месяцах)
Проверка уровня заявленной экспертизы: (тестовое задание, собеседование, пилотный проект и т.д.)
Другие требования: (при наличии)

Следует отметить, что вполне допустимо, если Вы включите свои разделы в представленный шаблон запроса цен. Однако, важным здесь является условие целесообразности включения этих разделов, чтобы не перегружать документ.

Полный текст статьи читайте на CMS Magazine