Архитектура на практике: Часть 3. Десять советов по написанию качественных предложений по ИТ-проектам

Как существуют методики разработки программного обеспечения, так есть и методики написания предложений по ИТ-проектам, которые увеличивают ваши шансы на успех. В новой статье серии Архитектура на практике архитектор ПО компании IBM Тилак Митра ставит себя на место руководителя ИТ-проекта и ищет путь к написанию качественных проектных предложений.

Тилак Митра, ведущий ИТ-архитектор, IBM

Tilak MitraТилак Митра (Tilak Mitra) работает в компании IBM в качестве ведущего ИТ-архитектора. Он специализируется на сервис-ориентированных архитектурах (SOA) и помогает разрабатывать стратегию и направление развития SOA-бизнеса IBM. Он также консультирует клиентов по SOA, помогая им применять SOA для трансформации SOA-бизнеса, особенно в условиях сложных и крупномасштабных корпоративных архитектур. Он живет на солнечном юге штата Флориды и свое свободное время зачастую посвящает игре в крикет и настольный теннис. Тилак получил степень бакалавра по физике в Президентском колледже (Presidency College) г. Калькутта, Индия, а затем получил совмещенную степень бакалавра и магистра по электротехнике в Индийском научном институте (Indian Institute of Science) г. Бангалор. Можете читать его блог или переписываться с ним по адресу: tmitra@us.ibm.com.



13.05.2011

Введение: Что предшествует написанию ИТ-проекта

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

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

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


Составление плана предложения

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

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


Финансирование и выделение средств

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

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

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

Еще один очень важный аспект составления бюджета - оценка того, сколько средств можно потратить при разработке проектного предложения, и его коммерческого потенциала. У всех консалтинговых компаний свой подход к реализации коммерческих возможностей, и каждая по-своему определяет, сколько можно потратить на проектное предложение, даже если оно не приведет к заключению контракта. Инвестиции в коммерческие возможности для группы по разработке проектного предложения обычно высчитываются как определенный процент от цены, которая будет выставлена клиенту. В некоторых компаниях даже выделяют на проектные предложения специальный бюджет, опять-таки для определения минимальных расходов по реализации коммерческих возможностей. Например, если вся стоимость возможности оценивается в 2 миллиона долларов, а объем средств, выделяемых консалтинговой компанией на реализацию коммерческих возможностей составляет 3%, то объем финансирования данного предложения составит 60 000 долларов. При типичной для большинства компаний стратегии продаж также отводят 15% бюджета на амортизацию, что в этом случае составит 9 000 долларов. Определение этой части бюджета для проектного предложения очень важно, поскольку оно указывает, какую часть бюджета можно использовать для подбора группы составителей предложения, и сколько времени они могут потратить на предложение, даже если оно и не выльется в контракт. Затем эту информацию используют при выполнении следующего шага в этом процессе -- подборе членов группы..


Подбор команды

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

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

  1. Менеджер по проектному предложению (руководитель проекта) -- Осуществляет общее руководство разработкой проектного предложением и, в частности, другими его менеджерами.
  2. Технический руководитель -- Руководит реализацией технических решений. Распределяет кадровые ресурсы (например, на архитектуру приложений, на интеграцию, на инфраструктуру и т.д.).
  3. Руководитель по ценообразованию -- Помогает определить окончательную цену предлагаемого решения. Это решение может включать консультационные услуги, оборудование или ПО. Все эти составные части цены включаются в окончательное предложение. Руководитель по ценообразованию также определяет расходы на уплату налогов.
  4. Руководитель по качеству и рискам -- Занимается оценкой обеспечения качества предложения. Он отвечает за своевременное обнаружение рисков при создании проектного предложения и планирует меры по их снижению. Хорошо, если этот человек также является предметным специалистом, тогда он сможет оценить обоснованность, полноту и реализуемость предложенного технического решения. Без его одобрения нельзя представлять окончательное предложение заказчику..
  5. Администратор по кадрам -- Помогает определить кадры, которые обеспечат выполнение плана предложения. В сложных проектах для подбора команды по проекту может потребоваться глобальная модель обеспечения , поскольку нужные кадры базируются в разных географических территориях (в случае распределенной структуры филиалов). Администратор по кадрам направляет и координирует деятельность международных команд.
  6. Рецензенты предложения -- Проводят всестороннюю оценку предложения, его полноту, цельность и качество. В их числе могут быть как уже названные специалисты, так и другие.

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


Управление документами

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

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

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

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

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

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

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


Разработка технического решения

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

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

Технический руководитель должен обладать опытом для оценки конкретных умений, которые потребуются для решения в целом. Это зависит от характера требуемого решения. Некоторые предложения связаны с обновлением оборудования, другие - с переносом комплекса приложений в новую программную среду, иногда нужно создать оригинальное приложение на заказ, с конкретным набором свойств для реализации бизнес-требований. Технический руководитель может назначить архитектора приложений, если нужно полностью разработать ПО, или поручить работу архитектору инфраструктуры, если предложение посвящено обновлению оборудования, например, переходу с Sun Sparc на IBM pSeries. Часто предложение включает несколько аспектов, то есть клиент нуждается и в рекомендациях по ПО, и в консультационных услугах по разработке комплексного приложения. В таких случаях техническому руководителю может потребоваться и архитектор приложений, и специалист по конкретной продукции.

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

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

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

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

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

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

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

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


Кадровые ресурсы

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

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

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

  • Время, нужное для завершения каждой фазы проекта, и график проекта в целом, с установленными границами этапов
  • Общий бюджет проекта

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

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

Для администратора по кадрам интересные возможности подбора кадров имеют территориально распределенные транснациональные компании. Международные команды становятся все более распространенными в ситуациях, когда цена предложения превосходит сумму, которую, по расчетам инициатора предложения, заложил в свой бюджет сам клиент. Расходы на оплату труда в разных странах сильно различаются. Кадры можно найти в странах, где оплата ниже, и это снизит расходы. Такую модель часто называют моделью смешанных ставок (blended rate), при ее использовании стоимость ресурсов складывается из разной стоимости рабочей силы в разных странах. Модель смешанных ставок очень распространена в крупных территориально распределенных организациях.

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

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


Контроль качества

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

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

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

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

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


Оценка стоимости предложения

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

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

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

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

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

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

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


Правила и условия, предпосылки

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

Правила и условия (terms and conditions, распространена аббревиатура Ts & Cs), обычно относятся к юридическим аспектам контракта. В предложении следует четко прописать правила и условия, а также юридические обязательства, которые возникают после подписания контракта. Следует подробно прописать условия, при которых контракт может быть аннулирован обеими сторонами, заказчиком или продавцом. В большинстве случаев стандартный шаблон Ts & Cs готовит юридический отдел вашей компании, но его надо отредактировать, включив в предложение конкретные имена, сроки и детали проекта.

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

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

  1. Участие заинтересованной стороны в принятии управленческих решений по проекту.
  2. Выделение специально назначенного сотрудника клиентской фирмы для получения запросов и выдачи пояснений.
  3. Наличие организационной структуры, которая позволяющей эскалировать и оперативно решать вопросы.
  4. Своевременный отклик клиента на сдачу этапов проекта.
  5. Своевременное рассмотрение и визирование деловых и технических решений до начала их реализации.
  6. Выделение достаточных кадровых ресурсов со стороны клиента для завершения проекта в заданные сроки.
  7. Офисные площади и оборудование для ежедневной работы консультантов поставщика.

Это не полный список, предпосылки могут меняться от предложения к предложению.


Завершение проектного предложения

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

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


Резюме: Работа на положительный результат

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

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

Благодарности

Автор благодарит свою коллегу Санграви Випулаком (Вики), которая не раз и не два читала эту статью в процессе ее написания. Если бы не ее опыт и проницательный ум, автор упустил бы очень многие детали в разработке выбранной темы. (Вики, спасибо!!!) От всей души благодарю также Протика Мукхерджи, помощь которого стала залогом успешного написания статьи. И наконец, огромное спасибо Санкару Сингхе, другу и коллеге, ведь благодаря его критическому уму которого объяснения многих понятий и действий стали значительно точнее.

Ресурсы

Научиться

Получить продукты и технологии

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=658565
ArticleTitle=Архитектура на практике: Часть 3. Десять советов по написанию качественных предложений по ИТ-проектам
publish-date=05132011