Rfi rfp что это

Sidebar

Свежие записи

Свежие комментарии

Архивы

Рубрики

Один из способов сделать тендер более эффективным. Правила процесса RFI.

ОПУБЛИКОВАНО oremizov в 06.02.2017

Каждый раз, когда успешно проводим тендер, мы используем множество различных техник и подходов. Одним из ключевых шагов являются стадии RF(x), что в переводе на русский означает процессы получения информации, условий или цен от поставщиков.

RF(x) — это аббревиатура, которая указывает на три отдельных составляющих (x означает использование нескольких процессов в одном тендере):

RFI – Запрос информации.

RFQ – Запрос на предоставление условий.

RFP – Запрос на предоставление предложения.

В интернете возможно найти большое количество статей и описаний по каждому из пунктов.

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

Проверено лично и коллегами множество раз 🙂 Успешных раз….

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

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

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

Правило: Прежде чем отправить RFI – позвоните поставщику, которого собираетесь пригласить, и кратко опишите условия и требования. Если участник новый – расскажите о компании. Часто сотрудники просто отправляют RFI по e-mail, ставят сроки, ждут ответа, теряя время тендера на тех, кто не хочет участвовать или просто не получил запрос…

Также я рекомендую запросить у поставщика общую информацию касательно Вашего объема тендера. Это позволит поставщику на этой стадии чувствовать себя более комфортно и не подгонять свое предложение под рамки Вашего RFI.

Цель RFI — не получить окончательное предложение. Цель RFI предоставить Вам полную информацию о товарах или услугах, на которые Вы планируете провести тендер.

По моему опыту, первоначальное обсуждение в телефонном режиме дает не только подробное понимание процессов. Оно также позволяет рассказать поставщику о каких-либо новых технологиях или новых решениях, предлагаемых на рынке. Что будет трудно сделать, если Вы загоните поставщика в рамки формального ответа на формальные документы RFI? Я могу рассказать десятки примеров, когда неформальные переговоры на стадии RFI о ситуации на рынке давали мне возможности оптимизировать планируемый тендер и получить не только лучшие цены, но и современные решения для внутренних заказчиков.

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

Правило: Избегайте ситуации, когда RFI трактуется как: «Это будет нелишним», «У нас такие правила — всегда посылать RFI” и т.д. Помните, если у Вас есть полное представление о товарах или услугах, которые планируются в тендере, выпуская RFI, Вы неэффективно используете не только свое личное время, но и заставляете поставщиков делать бессмысленную работу. Это может перерасти в потерю заинтересованности (такое тоже бывало).

Я хочу привести один пример:

В 2009 г. у меня был тендер на услуги по покраске фасада здания. К текущему пулу был найден в Гугле менее крупный поставщик, которому я просто позвонил, описал ситуацию и наши требования. Мы даже посмеялись над ситуацией с требованиями, и во время разговора, как бы между делом, Поставщик спросил меня: «А почему Вы выбрали именно такую краску и именно такую технологию? Ведь можно сделать это и дешевле, и лучше, и не красить фасад каждые два года». Конечно же, после этих слов RFP был изменен. И в итоге все поставщики пула уже предлагали совершенно новое, более эффективное и дешевое решение. Хотя изначально рассматривали старый процесс, как единственно возможный.

Я согласен, правильная стадия RFI не может быть решающим фактором эффективности. Ей вполне под силу расширить границы следующих стадий RFQ/RFP и дать нам возможность получить именно то, что нужно компании — по самой лучшей цене и от самого лучшего поставщика 🙂

@olegremizov

Уважаемые коллеги. Данные статьи я пишу как часть моей небольшой научной работы в профессиональном обучении.

Источник

Запрос предложения (англ. Request for Proposal, RFP) — документированный запрос организации, заинтересованной в приобретении каких-либо товаров или услуг. Создается заказчиком для проведения конкурса/аукциона. В которых находят отражение те цели, которых хочет достичь заказчик, KPI, критерии к участникам тендера и ряд других важных показателей.

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

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

Запрос может диктовать структуру и формат предложений поставщиков для возможности сопоставления предложений.

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

Претенденты возвращают предложение в установленную дату и время. Опоздавшие предложения могут рассматриваться или не рассматриваться, в зависимости от условий начального запроса. Предложения используются, чтобы оценить пригодность подавшего как поставщика, продавца или партнера. По предложениям могут вестись обсуждения (часто разъясняются технические детали или отмечаются ошибки в предложении). В некоторых случаях, всех или только выбранных претендентов могут пригласить участвовать в последующих предложениях, или могут попросить представить своё лучшее техническое и финансовое предложение, обычно называемое Лучшим и Конечным Предложением (англ. Best and Final Offer, BAFO).

Запрос цены (англ. Request for Quotation, RFQ) документированный запрос организации, заинтересованной в приобретении товаров или услуг, к определённой или неопределённой группе поставщиков с целью определения возможных закупочных цен. Используется, когда обсуждения с претендентами не требуются (главным образом, когда спецификации продукта или сервиса уже известны), и когда цена — основной или единственный фактор выбора претендента. RFQ может также использоваться как предварительный шаг перед полноценным запросом предложения для определения общего диапазона цен. В этом сценарии продукты, службы или поставщики могут быть выбраны по результатам RFQ для дальнейшего исследования.

RFQ обычно включает больше чем запрос цены на товар или услугу: часто от поставщиков требуется представить также информацию об условиях платежа, уровень качества товара или объём контракта. Чтобы получить корректные расценки, в RFQ часто включают спецификации товаров или услуг, чтобы удостовериться, что все поставщики предлагают цену для того же товара или услуги. Как правило, поставщики должны ответить на запрос в установленную дату и время. Ценовые предложения могут обсуждаться (часто разъясняют технические возможности или отмечают ошибки в предложении).

Запрос информации (англ. Request for Information, RFI) запрос, который публикует или рассылает организация, заинтересованная в приобретении каких-либо товаров или услуг. Цель документа — собрать письменную информацию о возможностях различных поставщиков. Как правило, запрос предполагает определённый структурированный формат ответа, благодаря чему может использоваться для сравнения информации.

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

Запрос квалификации (англ. Request for Qualifications, RFQ) является документом, часто распространяемым перед запросом предложения. Он используется для сбора информации о продавцах от разных компаний, чтобы генерировать пул потенциальных клиентов. Он упрощает процесс рассмотрения предложений по RFP благодаря суженному кругу кандидатов с необходимой квалификацией.

Запрос на решение (англ. Request for Solution, RFS) аналогичен RFP, но более открытый и общий. Является коммерческим документом, который описывает технологическую или организационную ситуацию и требует решения для возможных поставщиков решений. Организация, которая сделала данный запрос на решение, ведет диалог с потенциальными поставщиками для определения наилучшего из них.

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

Заявка на тендер (англ. Request for Tender, RFT), также известная как Приглашение к тендеру (англ. Invitation to Tender, ITT) обычно используется правительством.

Источник

Presales процесс в IT

Всем добрый день. Сегодня я хочу поднять достаточно слабо освещенную, но довольно значимую тему — «presale в IT». В статье я раскрою очень спорные и скользкие моменты предпродажной подготовки, которые стоит знать каждому руководителю:

1. Где в цикле сделки происходит presale?

2. Какие виды запросов от клиентов существуют на данном этапе продаж?

3. Когда стоит вводить в игру presales команду?

4. Роли и функции в presale: что обязательно стоит учесть?

5. Постоянный или временный отдел предпродажной подготовки?

6. Как отслеживать эффективность работы на presale-стадии?

И начну я с аналитики, которая вас точно заинтересует. По данным Harvard Business Review, компании, которые уделяют особое внимание предпродажным процедурам, достигают Win Rate (закрытий сделок) на уровне 40-50% при продаже новым клиентам, и 80-90% — при продаже уже действующим партнерам.

По моим наблюдениям, сегодня средний показатель Win Rate на рынке — 15-25%, в лучшем случае — 30%. Но всегда хочется выше, всегда хочется больше закрытий. И, как показывает анализ, это возможно. Давайте разберемся, с чего начать и как усилить предпродажную подготовку.

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

1. Поиск возможностей и привлечение лидов.

2. «Квалификация» лидов по различным, индивидуальным для компании критериям.

3. Генерирование предложения потенциальным клиентам.

5. Онбординг клиента.

6. Ведение клиента и получение регулярного дохода.

7. Поиск возможностей для получения дополнительной прибыли.

Непосредственно на 3 этапе и происходит захват клиента (RFх), а также работа с его запросами. И выполняет такую работу Account executive или Sales Development Representative, либо даже целый RFx отдел. О том, какие роли существуют в отделе продаж и его типовых структурах, я больше рассказываю в этом материале.

Но давайте разберемся, что же конкретно значит «работа с запросами»?

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

RFx (Request for X) — запрос чего-то. И в IT выделяют 4 основных вида запросов:

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

2. RFP — запрос предложения. Самый популярный тип запроса. В данном случае клиент хочет получить конкретику по продукту и цене в отношении четкой задачи или потребности. Отчасти, это КП, которое можно дополнять портфолио, исследованиями или другими материалами по продукту. Чаще всего такие запросы отправляются продуктовым компаниям для сравнения «предмета» закрытия потребности.

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

4. RFB — запрос на участие в торгах/тендере. Редкий вид запросов, применяемый, обычно, крупными компаниями в случае отбора поставщиков услуг через тендерные процедуры. В данном случае нужно предложить не варианты решения проблемы клиента с помощью своих услуг, а точную стоимость работ, перечень которых запрашивает клиент.

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

Компании развиваются не по прямой линии, а гибридно, увеличиваясь в разные стороны и плоскости. Чтобы понять, что вот, уже сейчас стоит выводить presale в обособленную единицу компании, изучите несколько направлений:

· Win Rate — как уже упоминалось выше, хороший показатель — 20-30%, удовлетворительный — 15-25%. Процент ниже — звоночек, что стоит усилить работу над запросами клиентов.

· Конверсия (MQL>SQL) (SQL>WIN) — чем меньше клиентов вообще доходят до стадии принятия решения по продажам, тем меньшему количеству клиентов поступают такие предложения.

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

· Удовлетворенность клиента — то, насколько услуга смогла удовлетворить клиента, определяет, были ли у него ложные ожидания, которые как раз и формируются во время работы с RFx.

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

RFx, будь-то команда или отдельный сотрудник, выступает связующим звеном между отделами разработки и продаж. Это одновременно и бизнес-эксперты, и технические консультанты. Если вы планируете собрать команду, укомплектуйте ее такими специалистами:

· Технический специалист (бывший разработчик, архитектор или другой специалист «изнутри» производства).

· Менеджер проектов (специалист, который умеет курировать производственные процессы шаг за шагом).

· Бизнес-аналитик (эксперт, который понимает специфику бизнес-процессов, желательно, в предметной области клиента).

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

Разумеется, предпродажную подготовку может проводить не 3 специалиста, а 1 или хоть 10. Но именно такие навыки как аналитика, организованность, понимание технических аспектов продукта или услуги — must have в рresale-команде.

Если вы четко решили, что вам нужно отдать рresale на одного человека/отдел, определите, будет это постоянная работа или временная. Разумеется, тут играет роль ваша ниша, продуктовая ориентированность, габариты бизнеса, таргетинг. Дополнительно понять, что рентабельней, поможет следующий чек-лист:

1. Есть ли возможность постоянного финансирования специалиста/команды?

2. Существует ли инфраструктура в компании, куда можно вписывать специалиста/отдел?

3. Требуются долгосрочные выгоды или закрытие сделок «здесь и сейчас»?

4. Есть ли возможность выделить ресурсы на построение рresale с нуля или нужна уже готовая команда?

5. Планируется ли масштабирование рresale с развитием компании или процессы будут идти по конвейеру постоянно?

6. Есть ли конкретная цель внедрения рresale с понятными, измеримыми показателями или требуется что-то протестировать?

Тут вопрос, который, уверен, заинтересовал каждого — как платить специалисту/команде? — Так же, как и менеджеру по продажам. Ведь от рresale зависит 50% успеха сделки. Лично я считаю оптимальной оплату «ставка + процент», аналогичную и оплате сейлзу. С вопросом оплаты привлеченной команде все понятно — столько, сколько с вас потребуют.

Кстати, о метриках. Если вы все-таки готовы по всем пунктам выделять полный отдел или присваивать обязанности конкретному сотруднику, вам нужно понимать, как оценивать результаты.

Источник

Запросы относительно цен, коммерческих предложений, дополнительных сведений.

Запросы RFx

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

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

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

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

Тип запросы (требования)

Определение (дефиниция)

Когда можно использовать?

Запрос на цены (расценки) ( RFQ – Request for Quotation)*

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

Запрос на коммерческое предложение (RFP – Request for Proposal)

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

Запрос на (дополнительные) сведения ( RFI – Request for Information)

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

RFI бывает полезен, если фирме-покупателю недостает полной информации о продукте или состоянии рынка и пока преждевременно составлять RFQ или RFP.

* RFQ или RFP иногда используются в практике некоторых фирм как синонимы, но это не верно. RFQ или RFP применяют при различных обстоятельствах; «уравнение» их в правах нивелирует сложную природу RFP.

Управление закупками и поставками/ М.Линдерс, Ф.Джонсон, А.Флинн, Г.Фирон – М.,2013

Другие способы закупок и схемы оценки поставщика мы разбираем на тренингах по закупкам. Расписание открытых тренингов

Источник

Как правильно писать RFP на разработку ПО

Данная статья предназначена вам, дорогие заказчики, будущие и настоящие, наши и не наши. Говорят, что правильно заданный вопрос — половина ответа. Правильно написаное задание заказчиком — залог хорошего и точного предложения от нас, разработчиков, а в итоге — хорошо сделанного проекта, в срок, в рамках бюджета и с высоким качеством. Такую первичную постановку задачи, предназначенную для отправки разработчику, называют запросом на предложение, или RFP (request for proposal).

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

Итак, перед вами поставлена задача — найти достойного подрядчика на разработку ПО. Чтобы найти самого лучшего, вы решаете подготовить и разослать по списку достойных компаний запрос на предложение, провести тендер, и в итоге сделать выбор. Вы открыли чистый лист в ворде и… С чего начать?

С чего начать?

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

Внятно сформулировать цели. При написании целей следует помнить две вещи:

Совсем хорошо, если цели получится сделать иерархическими — от общих к частным.

Конкретно сформулировать задачи. Задачи — это то, что нужно сделать, чтобы достигнуть цели. Это конкретные работы, результат которых приблизит компанию к цели. Это очень важный блок, потому что в его отсутствие из документа эти задачи приходится вытаскивать по разным намекам и недоговоркам. Обычно задачи указываются в виде списка «Сделать…» «Разработать…» «Обучить…»

Хорошо, если этот список станет чеклистом по прогрессу проекта в итоге. Не должно быть задач, которые никак не бьются с целями. Например, задача «Разработать мобильное приложение» может иметь цель «Увеличить конверсию с мобильного канала с 0,5% до 1%».

Совсем хорошо, если задачи получится сделать иерархическими. Например, можно разделить задачу «Разработать мобильное приложение» на «Разработать дизайн приложения», «Разработать приложение».

Где-то в этот момент можно придумать название проекта. Задачи есть, цели есть — обычно это уже не составляет труда. Лучше, если оно будет максимально информативным, но при этом коротким.

Далее я предположу, что вы точно знаете, что хотите от разрабатываемой системы или услуг разработчика (здесь и далее под разработчиком понимаем компанию-разработчика ПО, а не отдельного программиста). Давайте рассмотрим основные темы, связанные с конкретной постановкой задачи. О чем стоит помнить, формулируя требования?

Важные моменты по основному содержанию RFP

Разделять работы и услуги. Работы направлены на получение уникального результата. Как правило, перед выполнением работ исполнитель получает задание, а после выполнения — отчитывается. Услуги — регулярная, непрерывная деятельность. Услуги могут состоять из набора работ, но результатом оказания услуг обычно является прогресс. Заказчик оценивает прогресс, и решает продолжать с компанией тему с услугами или искать нового подрядчика. Для работ результатом является продукт.

Разделять требования к процессу разработки или управления проектом от требований к продукту. Это больше имеет отношение к техническим заданиям, чем к RFP, но тоже встречается частенько.

Есть довольно простое разделение «обязанностей»: Техническое задание для технических требований к продукту, Устав и план работ — для требований к процессу создания продукта. Любую «хотелку» заказчика можно легко отнести либо к одному, либо к другому.

Разделять функциональные и нефункциональные требования. Разница между ними простая: нефункциональные требования — это требования к характеристикам системы, а не к ее функциям.

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

Выносить в отдельный раздел ограничения. Очень полезно выделять ограничения отдельно от требований. Порой это не очень очевидно. Например, использовать в качестве базы данных Oracle — требование или ограничение? Ответ простой: если оно не имеет «родительского» бизнес-требования, то ограничение. Иначе — требование. Бизнес-требование должно иметь такую же связку с целью. Например, требования к производительности, хоть и являются нефункциональными, могут иметь бизнес-требования.

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

«Что делать» и «как делать»

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

Большая ошибка — написать такое RFP, который каждый из разработчиков поймет по-разному. Тогда предложения от разных разработчиков в итоге нельзя будет сравнить.

Давайте разберемся, почему так происходит. Если вы прямо не диктуете подрядчику формат, то оценка разработки заказного программного обеспечения происходит у всех разработчиков так:

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

Вам в лучшем случае удается сравнить только оценки сроков и стоимости («за сколько»). Хотя можно и нужно экспертно сравнивать реализации («как делать»), так почти никто не поступает.

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

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

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

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

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

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

Оценка отдельных требований

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

Например, пакетом работ может быть верстка шаблонов, отдельным пакетом — набор задач на форму обратной связи, отдельным пакетом — тестирование. А может быть по-другому: пакет работ — это задачи по программированию формы обратной связи, ее оформлению, и по ее тестированию.

В последнем случае пакет работ представляет собой сценарий использования системы вида «Покупатель должен иметь возмжоность связаться с администрацией, отправив ей вопрос и свои контакты». То есть, в этом случае пакет работ — законченная единица системы, готовая к использованию по завершению и внедрению. В первом случае пакет работ является просто группировкой задач по какой-то одному виду работ. Это довольно полезно для построения конвейера, когда ради эффективности разработки группируются однотипные работы.

Итак, единицей оценки является пакет работ, т.е. набор требований/задач, которые имеет смысл рассматривать вместе, а не поодиночке. И как я показал в примере выше, разбиение по пакетам можно сделать различными способами. Каждый подрядчик будет делать это разбиение удобным и привычным ему образом.

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

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

Например, требования могут дублировать друг друга, могут предполагать общие задачи, а могут подразумевать задачи, которые заказчиком не были выделены в отдельные требования, а не делать их нельзя — не будет требуемого результата. В итоге сумма трудозатрат по вашим требованиям хоть и будет составлять оценку проекта подрядчиком, но будет «натянута» и «подогнана».

Разбиение на пакеты работ осуществляется уже после проектирования, хотя бы поверхностного, с учетом реализации, придуманной подрядчиком. Как уже я писал выше, реализаций («как сделать») может быть на одни и те же требования («что делать») много, и какая из них будет выбрана — зависит от опыта подрядчика, существующих наработок (в т.ч. в аналитике), от предпочитаемых подходов.

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

Как выбрать лучшего?

Универсального ответа на этот вопрос нет, но есть самый близкий к идеалу.

Два проекта вместо одного

Я предлагаю разбивать проект на два последовательных этапа: проектирование и реализация, и проводить запросы на предложения по каждому отдельно.

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

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

Итак, мы выделяем в этом случае два проекта, выполняемых последовательно:

Проект №1. Проектирование

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

Типичным документом на этом этапе является документ «Технический проект»

Здесь же разрабатывается план работ и смета от подрядчика, выполняющего проект.

Проект №2. Реализация

Оценить этот этап более-менее точно можно, имея результат с этапа №1. В процессе разработки подход «как делать» почти точно изменится, поэтому нужно сразу планировать по итогам получение документации по архитектуре системы, которая будет иметь в основе «Технический проект», но с исправлениями и изменениями.

Управление стоимостью

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

Для этого и стоят в результатах первого этапа смета и план работ от подрядчика, выигравшего первый тендер. Как его ограничить в аппетитах? Ставьте сразу в ограничениях RFP максимальную сумму и/или трудозатраты и/или длительность проекта. Если подрядчик не чувствует силы, он не будет участвовать в тендере на проектирование вообще.

Конечно, у вас есть право не объявлять второй тендер, а продолжить работать с первой компанией и дальше, если все идет хорошо.

Waterfall или Agile?

Этот вопрос поднимается почти у каждого заказчика. Проектный подход («Waterfall») представляет собой прогнозируемый подход к разработке, когда сначала создается технический проект, план работ, а потом по этим эскизам выполняется работа. Итеративный подход («Agile») представляет собой много очень коротких простых по структуре проектов, длительностью в 2-3 недели. В итеративном подходе предполагается очень плотное участие заказчика в процессе, он буквально должен жить с командой, а в случае срыва сроков делить с ней риски. Проектный подход предполагает большую автономность для подрядчика — здесь есть риск узнать, что подрядчик оказывается неспособен сделать систему слишком поздно.

В интернете очень много информации по сравнению этих двух подходов, эта тема очень холиварная. Поэтому я не буду повторяться, просто поделюсь коротким советом:

Выбирайте Agile, если:

Выбирайте Waterfall, если:

Функциональные требования

Если для формулировки функциональных требований, хотя бы привычных, вы не прибегаете к помощи специально обученных людей, постарайтесь следовать следующим простым правилам:

Очевидное и непроверяемое можно не писать. Это сэкономит время и вам, и нам. Например, не надо писать в требованиях, что интернет-магазин должен быть удобным и современным, а страницы загружаться быстро и легко.
Сгруппируйте требования в разделы по темам. Разбейте группы на подгруппы. Постарайтесь сделать структуру логичной и понятной, чтобы ей было удобно пользоваться.
Полнота. Постарайтесь сохранять достаточную для первичного документа глубину проработки требований.
Атомарность. Одно требование — одна идея..
Однозначность. Избегайте повторов и противоречий. Все работающие с ним должны понимать его одинаково.
Без жаргонизмов. Постарайтесь использовать общепринятую понятную широкой аудитории лексику.
Краткость Постарайтесь обойтись минимумом слов. Убрать все лишнее и оставить только самое главное.
Проверяемость. Представьте, что перед вами уже готовая система и вам нужно проставить галочки напротив своих же пунктов. Сможете ли вы проверить их?