Библиотека Интернет Индустрии I2R.ru

Пожалуй самым главным источником недоразумений и проблем, возникающих между клиентами и компаниями-разработчиками, является плохо составленная Request for Proposal (дословно: заявка на получение предложений - далее используется термин "заявка").

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

Большая часть проблемы связана с тем, что трудно выразить на бумаге все подробности и возможности проекта по разработке Web-узла, когда нет еще самой идеи того, что вам нужно и как это все вместе будет работать. Кроме того, разработка Web-узлов - сравнительно новый вид деятельности и потому не удивительно, что большинство клиентов не имеют большого опыта в написании заявок на разработку Интернет-проектов. Заказ на постройку моста или установку сети - сильно отличается от заказа на разработку Web-проекта.

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

Ну а что же делать? Я предлагаю воспользоваться двухэтапным процессом составления заявки. На первом этапе вы проводите обзор претендентов после чего составляете краткий список компаний, которым будет разослана ваша заявка, когда вы ее составите. Смысл заключается в том, чтобы найти 3 - 4 компании-разработчика, которые по вашему мнению подходят для проекта даже несмотря на то, что они пока еще никаких цифр не представили. Для этого вам необходимо подготовить предварительный документ, который большинство разработчиков, заинтересованных в работе с вами, будут использовать в качестве отправной точки при переговорах.

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

Опишите вашу компанию и вашу продукцию, дайте хоть немного информации о времени, за которое надо выполнить проект и опишите, какие ресурсы вы готовы выделить на него.

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

Количество участников отбора следует свести к 3-ем, максимум к 4-ем компаниям. Если на проект планируется потратить много денег - выделите по 1000 долларов каждой компании-финалисту, чтобы покрыть их расходы по подготовке окончательного варианта своих предложений. Это может показаться выбрасыванием денег на ветер, но поставьте себя на место конкурсантов. Хорошо подготовленное предложение для большого проекта может потребовать большого количества времени и ресурсов. Лишь малая толика предложений кончается ничем. Очень часто появляются слухи, что та или иная компания, сделавшая заявку, уже имеет своего разработчика-любимчика, и просто желает получить предложения от конкурентов для сравнения или для давления на своего фаворита. Если это так, то вряд ли можно ожидать хорошего, тщательного продуманного предложения от конкурсантов в такой ситуации. Оплата подготовки предложения гарантирует, что лучшие компании-разработчики могут уделить время на подготовку своего лучшего предложения.

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

Предложения должны содержать следующие разделы:

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

Можно задать еще кучу вопросов, но помните, что ваша задача - выбрать ту компанию, которой вы доверяете. Во время разработки вы можете допустить ошибки, и они могут допустить ошибки, вы опоздаете с доставкой материала, и они могут опоздать. Вам необходимо выбрать компанию, которая будет прощать вам ваши грехи, а вы - их. Можно конечно попытаться, но включить в заявку или в ответ на нее абсолютно ВСЕ - невозможно. Предложение-ответ должен содержать описание того, как вы будете работать вместе. Все клиенты почти всегда вначале обещают, что предоставят все, что необходимо для проекта в виде маленькой кучки, и вы можете подумать, что и у вас также получится. ЭТОГО НИКОГДА НЕ БЫВАЕТ! Именно клиент первым с доставкой и запаздывает. В вашей заявке должно быть написано, что должно произойти, когда происходит задержка с вашей или их стороны.

Убедитесь, что в вашей заявке имеется график рассмотрения ответов и процесса производства. Например:

• 10 марта - Разослан "заказ-заявка"
• 20 марта - крайний срок получения ответов
• 22 марта - составлен краткий список участников отбора
• 30 марта - разослан "заказ-заяка" участникам из краткого списка
• 15 апреля - крайний срок получения ответов на "заказ-заявку"
• 20 апреля - уведомление победителя о принятии его предложения
• 22 апреля - выписан заказ-наряд на выполнение работ по проекту
• 24 апреля - общее первое собрание по проекту
• 30 мая - начало разработки проекта
• 30 июля - узел публикуется в сети

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

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

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

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

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

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