Приветствую! Я – Данил Вильховский, генеральный директор компании по кастомной разработке программного обеспечения.

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

Итак, исходная ситуация: есть проект на разработку программного обеспечения, например CRM-системы.

Нужно: разослать запросы на просчет стоимости проекта по нескольким IT-компаниям и/или выставить проект на тендер.

Задача: составить эффективный запрос цены (RFQ, request for quotation).

Почему важно нужно подготовить эффективный запрос цены

Запрос цены является важным документом. По сути, является приглашением к участию в тендере.

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

Эффективный RFQ одновременно достигает две цели:

• Во-первых, предоставляет компаниям-разработчикам программного обеспечения четкое представление о Ваших потребностях и требованиях, как в отношении необходимого решения, так и в отношении условий партнерства. При этом существенно сокращая количество и время коммуникаций, направленных на прояснение требований по проекту.

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

Какие разделы включать в RFQ

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

Введение

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

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

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

Здесь необходимо представить краткое описание того, какое программное обеспечение Вам необходимо.

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

Подробное описание проекта

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

Например, для CRM-системы можно начать с таких пользовательских историй как переговоры с клиентами, корреспонденция (в том числе и внутри организации), уведомления и средства взаимодействия пользователей. Затем следует раскрыть каждую из этих функций, чтобы разработчики имели полное представление о том, что должно быть на входе и выходе по каждой.

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

Здесь Вы определяете MVP, минимально жизнеспособный продукт, который Вы ожидаете получить, а также расставляете задачи по приоритетам.

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

Кроме того, при проработке данного раздела было бы неплохо произвести внутреннюю оценку объемов, чтобы впоследствии иметь некоторую базу для сравнения.

Требуемый стек технологий

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

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

Требования к качеству

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

Например, это может быть расстановка приоритетов по уязвимостям, определение времени восстановления работоспособности программы при DDoS-атаках.

Основные этапы и сроки проекта

Здесь следует указать ожидаемые сроки создания MVP, ориентиры по итерациям. Так Вы поможете ИТ-компаниям понять Ваши ожидания и определить, смогут ли они их оправдать.

Например, вы можете установить дедлайны в виде точной даты или определенного периода в конвейере проекта. А также указать ожидаемую продолжительность спринтов и т.д.

Общие положения и условия

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

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

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

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

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

Шаблон ценообразования

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

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

Предквалификационные требования

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

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

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

Сроки сбора заявок

В данном разделе можно указать дату, до которой будут приниматься заявки. Важно, чтобы сроки, с одной стороны, были обоснованно ограниченные (Вы же не можете собирать заявки месяцами). А с другой – достаточно продолжительными, т.е. достаточными для того, чтобы разработчики могли верно оценить объемы и подходящие решения (Вам же не нужны наспех составленные заявки, в которых множество неучтённых аспектов и т.д.).

Например, для небольшого проекта стоимостью менее 1 млн рублей подходящим сроком сбора заявок является одна-полторы недели. Для тендерных процедур в крупных, вертикально структурированных организациях, и более объемных проектов, сроки как правило, выше и могут достигать месяца и более.

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