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

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

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

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

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

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

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

1. Цель любой деятельности лежит вне рамок этой деятельности. То есть, цель разработки сайта — не продавать товар, а увеличить сервис для клиентов предоставлением еще одного коммуникационного канала. Цель разработки B2B-системы не создать ПО для взаимодействия с покупателями через сеть, а снизить издержки и увеличить обороты за счет автоматизации.


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


• Разработчик прикидывает архитектуру и реализацию, т.е. отвечает для себя на вопрос «как делать». Обращаю внимание, что обычно этот этап никак не формализуется..


• Разработчик оценивает работы («за сколько»), которые ведут к результату («что делать») через придуманную им архитектуру и реализацию («как делать»). На этом этапе рождается смета.


• Разработчик направляет смету и план.. Остаток документа на 90% состоит из копипаста и стандартных слов. В лучшем случае немного пишет про выбранный подход.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. цели, задачи, бизнес-требования


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


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


4. сценарии использования системы


5. ограничения.

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

На этапе «Разработка технического проекта» выполняется разработка комплекта документов, отвечающих на вопрос «как делать»:

1. конкретные работы,


2. разбиение на пакеты работ,


3. используемое ПО,


4. предполагаемая серверная инфраструктура


5. методика тестирования (нагрузочного, интеграционного)


6. подходы к миграции данных


7. … и многое другое, зависящее от конкретного проекта

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

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

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

.

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

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

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

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

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

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


2. его документ, вероятно, будет относительно публичным на втором этапе,

… он будет особенно мотивирован работать хорошо, ему будет важно создать хорошее впечатление и сделать свою работу «на отлично.»

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

Waterfall или Agile?

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

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

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

• вы лично и несколько ваших коллег готовы отдать 80%-100% своего времени проекту с полным погружением


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


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


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

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

• вы идете в относительно стандартный проект, который до вас уже делали,


• вы неплохо понимаете, что хотите, уже сейчас,


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


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


• вам важно знать, когда будет завершена разработка, и важно, чтобы подрядчик финансово отвечал за срыв сроков

 

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

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

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

Удобно придерживаться следующих шаблонов при написании требований: Самый распространенный случай — от лица пользователей: «Требование»: <Пользователь такой-то> должен иметь возможность <действие> <объект> [объект/обстоятельство]. Пример: «Покупатель (тип пользователя) должен иметь возможность отложить (действие) товар (объект) в список избранного (объект/обстоятельство)». «Менеджер по приему заказов должен иметь возможность выставлять счета От «лица продукта»: Продукт должен [иметь возможность] <действие> <объект/понятие/уточнение>. Например, «Система обработки заказов должна уведомлять (действие) администратора заказов при поступлении нового заказа «Допущение»: <Пользователь такой-то> не должен <действие> <объект> [объект/обстоятельство]. Пример: «Покупатель (тип пользователя) не должен подтверждать (действие) свой заказ (объект) через коллцентр (объект/обстоятельство)» «Характеристика объекта»: <Объект> должен иметь следующие характеристики: (перечень). Пример: «Заказi> (объект) должен иметь следующие характеристики: информацию о пользователе, сделавшим заказ, адрес доставки, список товаров.» Фоновые (не инициируемые пользователем) процессы: Необходимо <действие> <объект> <уточнение/обстоятельство>. Пример: «Необходимо выгружать (действие) заказы (объект) в ERP каждый час» … и так далее. Количество возможных формулировок неограничено

Все объекты и всех пользователей где-нибудь соберите в одном месте и дайте им определения. В примере выше объекты «товар» и «список избранного» должны быть описаны.

Услуги

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

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

Предложение на услуги должно идти отдельно от предложения на выполнение проектных работ.

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

• Порядок взаимодействия (как ставятся задачи, насколько ожидается быстрая реакция, какие каналы связи)


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


• Какие измеримые результаты (отчеты, документы, код, макеты, внешние аудит и прочее)


• Какие гарантии (имеют ли они финансовую ответственность, важно отличать «можем» и «должны»)


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

 

Формат документов

Для разработчика очень удобно, когда функциональные требования передаются как минимум в формате электронной таблицы, а прочие — нефункциональные, ограничения, цели, задачи, описание оформляются в виде документа Word или PDF. Электронные таблицы позволяют добавлять к требованиям вопросы и комментарии, статусы и трудозатраты, фильтровать и группировать требования. Да и если будет нужда, из электронной таблицы в формат Word переносить требования значительно проще, чем из неструктурированного текста в Excel.

В идеале формат таблицы с требованиями должен включать следующие колонки:

• Автор. Изначально везде вписано «заказчик». Если разработчик посчитает, что какие-то неявные требования указаны, он добавляет новые строки с автором «разработчик»


• Раздел. Удобно для фильтрации


• Подраздел. Удобно для фильтрации


• Уникальный номер требования. Удобно для формул Excel, типа СЧЁТ или СУММЕСЛИМН


• Текст требования. В свободном виде. Без картинок. Один абзац.


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

От подрядчика в идеале нужно ждать заполненную таблицу выше, а также саммари:

• Название пакета работ


• Оценка пакета работ в ч/ч. Разрабочик вправе разбить оценку на виды работ (см ниже). Например, отдельно выделив часы менеджера, аналитика, разработчика, тестировщика.


• Число требований, вошедших в пакет (для контроля, может быть 0). По желанию. Высчитывается автоматически через формулы Excel «СЧЁТ».

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

Что намеренно не вошло в данную статью и почему

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

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


• Способы визуализации бизнес-процессов и отношений между объектами: во многом схема красноречивее многих слов. Для описания бизнес-процессов и отношений между данными есть стандарты UML/Aris/IDEFx, BPMN, ERD, диаграммы последовтельностей и др.

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

Заключение

Итак, суммируя все выше,

• В RFP:
  
  • Формулируйте измеримые бизнес-цели, зачем делается эта разработка
  
  
  • Формулируйте измеримые задачи, которые нужно сделать для достижения цели
  
  
  • Выносите отдельно запрос на услуги (поддержка, хостинг, SEO)
  
  
  • Выносите отдельно запрос на работы (создание продукта, документа, обучение)
  
  
  • По требованиям:
    
    • Выделяйте отдельно требования к процессу разработки
    
    
    • Выделяйте отдельно требований к процессу управления проектом
    
    
    • Выделяйте отдельно функциональные и нефункциональные требования
    
    
    • Выделяйте отдельно ограничения
    
    
  
  
  • Продумайте, как вы будете сравнивать предложения
  
  


• Выбор подрядчика
  
  • По возможности разбейте на два запроса на предложения, (1) проектирование и (2) реализация
  
  
  • Исходите из предположения, что подрядчики на эти разные фазы могут быть разные (хоть это и не очень хорошо — но лучше это предполагать)
  
  
  • Организовывайте устные технические защиты (презентации) предложений
  
  
  • Требуйте в проектирование включить смету и план-график на случай, если будет выбран этот же подрядчик
  
  


• Формат документов: По возможности имейте функциональные требования в экселе, по одному на строку.


• Функциональные требования: Привлекайте для разработки функциональных требований профессиональных аналитиков, а если это невозможно, то старайтесь придерживаться правил атомарности, структурности, непротиворечивости, полноты, краткости. Опускайте банальности, выделяйте особенности.


• Определитесь для себя, какой способ работы с подрядчиком вам удобнее: Waterfall или Agile
  
  • Agile: Частые изменения, много ресерча, сложно сформулировать, что хотим, готовы сидеть рядом с программистами и непрерывно их корректировать
  
  
  • Waterfall: любим определенность, понятный проект, хорошая постановка, ясно, что делать, если будут существенные изменения, то не очень часто, хотим побольше переложить риски на подрядчика за сроки, качество и полноту
  
  

Алиев Рауф,

директор по e-commerce TEAMIDEA (разработка на SAP hybris)

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