Разработка расписания проекта. Продуктовые стратегии в IT

Размещено на http://www.allbest.ru/

Содержание

Разработка расписания проекта

Исходные данные для разработки расписания

Инструментарий и технологии для разработки расписания

Результаты разработки расписания

Технология разработки расписания

Разработка расписания проекта методом критического пути

Организация управления расписанием проекта

Исходная информация для процесса управления расписанием

Линия исполнения

Построение линии исполнения проекта

Диаграмма контрольных событий

Построение диаграммы контрольных событий

Продуктовые стратегии в IT

Программный продукт как товар

Особые свойства программных продуктов

Составляющие товарной политики для программного продукта

Программный продукт как услуга

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

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

Товарные стратегии для услуг, не связанных с разработкой программного обеспечения

Стратегия фокусирования при разработке программных продуктов и ИТ-услуг

Прототипирование программных продуктов

Сущность прототипирования

Основные виды прототипирования программных продуктов

Концепция притворного прототипирования (pretotyping)

А/В-тестирование

Учет эмоций потребителя при разработке программных продуктов и ИТ-услуг

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ



Разработка расписания проекта

Обязательным элементом планирования любых проектов является расписание работ. Расписание проекта - плановые даты для выполнения работ и плановые даты для наступления контрольных событий (вех) проекта.

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

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

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

Исходные данные для разработки расписания

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

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

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

Для разработки расписания рекомендуется использовать следующие инструменты и методы.

Диаграмма Гантта - диаграмма, которая использует горизонтальные полосы для представления операций проекта, показывает даты начала и завершения каждой операции и проекта относительно горизонтальной шкалы времени.

Рисунок 1.1. Пример диаграммы Гантта

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

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

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

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

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

Рисунок 1.2. Пример диаграммы по методу критического пути

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

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

? сбор исходной информации для построения диаграммы;

? построение сетевой диаграммы, отражающей взаимосвязь операций;

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

? выбор контрольных событий - событий, которые являются главными для продвижения проекта;

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

? нанесение контрольных событий на детальное расписание проекта ;

? проверка равномерности распределения контрольных событий по расписанию проекта.

Рисунок 1.3. Пример диаграммы контрольных событий

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

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

Инструментарий и технологии для разработки расписания

программный проект товарный потребитель

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

? Метод критического пути (СРМ - Critical Path Method) - вычисляет одиночные, детерминированные даты раннего и позднего начала для каждой работы на основе специальной последовательной сетевой логики и одиночной оценки продолжительности. Метод сфокусирован на вычислении резерва, чтобы определить, какие работы обладают наименьшей гибкостью в вопросах расписания. Основные алгоритмы метода часто используются в других математических методах исследования операций.

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

? Техника обзора и оценки проекта (PERT) - использует последовательную сетевую логику и средневзвешенные оценки продолжительности для вычисления продолжительности проекта. Хотя существуют и внешние различия, PERT отличается от метода критического пути тем, что использует величину из распределения (ожидаемое значение) вместо наиболее вероятной оценки, первоначально используемой в методе критического пути (рис. 3.5). Сам по себе PERT редко используется сегодня, хотя PERT - подобные оценки часто используются в вычислениях метода критического пути.

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

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

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

Имитация. Имитация описана в процессе «Оценка продолжительности работ».

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

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

Результаты разработки расписания

Результатами процесса разработки расписания являются:

? расписание проекта. Расписание проекта может быть разработано детально или укрупнено как расписание контрольных событий. Расписание может быть представлено в табличном виде или иметь графическое представление в виде сетевых диаграмм, столбиковых горизонтальных диаграмм или диаграмм контрольных событий;

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

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

? требования к ресурсам. Тип, количество и распределение по срокам. Могут определяться для всего проекта или отдельных рабочих тем;

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

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

? запрошенные изменения. В процессе разработки расписания могут появиться запрошенные изменения, которые обрабатываются в процессе общего управления изменениями;

? план управления проектом. План управления проектом обновляется с отражением всех одобренных изменений в способах управления расписанием проекта.

Информация, часто представляемая в качестве дополнительной, включает (но не ограничивается) следующее:

? потребности в ресурсах на период времени, часто в форме гистограмм ресурсов.

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

? запасы расписания или оценки риска расписания (процесс «Разработка методов реагирования на риск»).

? план управления расписанием. План управления расписанием определяет, как будут управляться изменения в расписании. Он может быть формальным или неформальным, высоко детализованным или общим в зависимости от нужд проекта. План управления расписанием является составным элементом плана проекта (процесс «Создание (разработка) плана проекта»).

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

Технология разработки расписания

При разработке расписания рекомендуется соблюдать следующую последовательность работ:

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

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

3) определить длительность каждой операции;

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

5) рассчитать с помощью обратного прохода позднее расписание для каждой операции;

6) вычислить временной резерв для каждой операции;

7) определить критический путь ;

8) сравнить дату предполагаемого завершения проекта с датой завершения проекта по обязательству;

9) подкорректировать расписание или дату завершения проекта по обязательству, если завершение проекта по расписанию предполагается раньше этой даты;

10) определить ограничения на ресурсы;

11) откорректировать расписание в соответствии с ограничениями на ресурсы;

12) проверить, не планируется ли завершение проекта по откорректированному расписанию раньше даты обязательства;

13) согласовать расписание.

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

Рисунок 1.4. Шаблон последовательного формирования расписания проекта

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

Типы взаимосвязей:

? Финиш - старт . Эта взаимосвязь означает, что предшествующая операция должна закончиться до того, как последующая операция может начаться.

? Финиш-финиш. означает, что операция должна закончиться до того, как может закончиться последующая операция. Это не значит, что последующая операция должна закончиться одновременно с предшествующей операцией. Последующая операция может закончиться позже, но не раньше, чем предшествующая операция.

? Старт - старт. означает, что предшествующая операция должна начаться до того, как может начаться последующая операция.

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

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

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

Разработка расписания проекта методом критического пути

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

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

? Определить длительность каждой операции. Длительность каждой операции определялась в рамках процессов оценки трудоемкости и определения длительности операций.

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

? Рассчитать с помощью прямого прохода (forward pass) раннее расписание (early schedule): ранний старт (ES) и ранний финиш (EF) для каждой операции.

При расчете раннего расписания для операций требуется придерживаться нескольких правил составления расписаний (scheduling conventions). Данные правила приняты сообществом по составлению расписаний (scheduling community). В расписании старт первой операции всегда назначается на дату старта проекта. Эта дата является входом плана проекта. Первая дата старта является стартом проекта. Дата раннего финиша - это дата раннего старта плюс длительность операции. При этом применяется следующее правило. Считается, что каждая операция начинается в момент начала того периода, в который она стартует, и оканчивается в момент завершения периода, в который она завершается. Это означает, что если длительность операции составляет один день и если она начинается первого января, то заканчивается данная операция также первого января. В соответствии с данным правилом ранний финиш любой операции равен раннему старту плюс длительность минус один. Таким образом, операция 1 начинается в день 1 и заканчивается в день 15. Следующая операция должна начаться в следующий доступный временной период: поскольку операция 1 заканчивается в день 15, операция 2 должна начаться в день 16, а закончиться в день 20. Операции 3 и 4 представляют следующую проблему. Эти операции зависят от операции 2, т. е. операция 2 должна окончиться перед их стартом. Очевидно, что датой раннего старта обеих операций будет день 21.

? Рассчитать с помощью обратного прохода (backward pass) позднее расписание (late schedule) для каждой операции.

Для выполнения обратного прохода необходимо начинать с последней операции, которая была выполнена в раннем расписании. Логическим обоснованием этого является следующее: если раннее расписание определяет самую раннюю дату завершения проекта, то в обратном проходе мы ищем для всех операций самые поздние даты их выполнения, при которых проект мог бы быть полностью выполнен. Мы начинаем с наиболее поздней из дат раннего финиша, соответствующей завершению последней операции. Это время позднего финиша (LF). Для получения времени позднего старта (LS) из времени позднего финиша вычитается длительность. Даты позднего расписания (поздний старт и поздний финиш) для операции 11 будут соответственно днями 90 и 94. Поскольку дата позднего старта операции 11 - день 90, операции 10 и 3 должны быть окончены не позднее дня 89. Это будет датой позднего финиша для обеих операций. Таков самый поздний срок завершения данных операций для того, чтобы обеспечить завершение проекта в день 94 и дату позднего старта операции 11. Для получения дат позднего старта для каждой операции вычитаются их длительность. При рассмотрении операции 2 надо быть очень внимательными в выборе даты позднего финиша, которая также согласуется с датами позднего старта операций 3, 4 и 6. Поскольку датами позднего старта операций 3, 4 и 6 являются дни 86, 53 и 21, соответственно, датой позднего финиша операции 2 является день 20.

Рисунок 1.5. Операции проекта

? Вычислить временной резерв (float) для каждой операции.

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

? Определить критический путь (critical path).

Критический путь (critical path) - это последовательность операций, имеющих нулевой временной резерв (zero float). Операции с нулевым временным резервом - это операции, задержка которых обязательно влечет за собой задержку окончания всего проекта. Операции такого типа необходимо жестко контролировать, чтобы обеспечить завершение работы над проектом в установленное время. И наоборот, операции, которые не лежат на критическом пути и имеют ненулевой временной резерв, необязательно контролировать так жестко. К тому же, важно знать, выполнение каких операций проекта может быть задержано без изменения даты завершения проекта. Ресурсы операций, имеющих резерв времени, при необходимости могут быть использованы для выполнения обхода (workaround).

? Определить, не состоится ли предполагаемое завершение проекта раньше даты обязательства (promise date).

После того как было определено расписание самого раннего окончания проекта, следует произвести проверку на реальных данных. Расписание должно определять дату окончания проекта, более раннюю, чем дата обязательства (promise date), которая могла быть уже сообщена участникам проекта. Если это не так, надо бить тревогу. Составленное расписание пока еще не включает задержки, которые могут произойти в случае отсутствия необходимых ресурсов. Расписание не дополнено резервами на случай известных или неизвестных рисков. Также не были учтены обычные отклонения, которые будут возникать между предварительно определенной и действительной длительностью операций проекта.

? Подкорректировать расписание или дату обязательства.

Затем надо отрегулировать расписание или дату обязательства. Возможны две ситуации: расписание с датой обязательства более ранней, чем предварительно определенная дата, и расписание с датой обязательства более поздней, чем предварительно определенная дата. Если предварительная дата расписания является более поздней, чем обязательства, то необходимо применять сжатие (crashing) или быстрый проход (tracking).

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

? Запросить ресурсы и определить ограничения на ресурсы.

? Отрегулировать расписание в соответствии с ограничениями на ресурсы.

? Определить, не состоится ли предполагаемое завершение проекта раньше даты обязательства.

? Подкорректировать расписание или дату обязательства.

? Получить одобрение расписания (согласовать расписание).

Организация управления расписанием проекта

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

Исходная информация для процесса управления расписанием

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

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

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



Рисунок 1.6. Шаблон формы отчета о прогрессе проекта

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

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

Анализ отклонений. Ключевой функцией управления расписанием является проведение анализа отклонений по срокам. Сравнение директивных дат начала и выполнения с фактическими/прогнозируемыми дает информацию для осуществления корректирующих действий в случае задержки.

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

Линия исполнения

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

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

Построение линии исполнения проекта

1) Подготовка информации для построения линии исполнения: базовое расписание в формате диаграммы Гантта, отчеты о ходе выполнения проекта, запросы на внесенные изменения, которые могут влиять на дату завершения проекта.

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

a) Каково отклонение фактического расписания от базового?

b) Какие проблемы вызывают отклонения?

c) Какие новые риски могут возникнуть и как они могут повлиять на дату завершения операции?

d) Каков текущий тренд выполнения проекта?

e) Какие действия наметил владелец операции для предотвращения срыва сроков выполнения операции?

Шаг 2 может быть пропущен, если существует отлаженная система сбора реальной информации о ходе выполнения проекта.

3) Проведение совещания о ходе выполнения проекта. Совещания следует проводить регулярно (раз в месяц или раз в неделю, в зависимости от продолжительности проекта).

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

Рисунок 1.7. Пример линии исполнения проекта

5) Рисование линии исполнения.

a) Взять базовое расписание проекта и отметить на календаре (в шапке базового расписания) дату проведения совещания - статусную или отчетную.

b) От этой даты рисовать вниз вертикальную линию до пересечения со строкой первой операции

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

Таким образом, линия исполнения позволяет регулярно контролировать и корректировать выполнение базового расписания проекта.

Диаграмма контрольных событий

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



Рисунок 1.8. Пример диаграммы прогнозирования контрольных событий

Построение диаграммы контрольных событий

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

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

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

Продуктовые стратегии в IT

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

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

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

Программный продукт как товар. Особые свойства программных продуктов

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

? нематериальность;

? идемпотентность;

? наличие института защиты авторских прав.

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

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

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

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

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

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

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

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

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

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

Составляющие товарной политики для программного продукта

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

? какие классы программ компания разрабатывает и предлагает рынку;

? для каких покупателей и сегмента (B2B/B2C) они предназначены;

? какими функциональными характеристиками они наделены, какие потребности покупателя могут удовлетворить и какие проблемы решают;

? какие технические требования предъявляют к аппаратному обеспечению и т. П.

Обычно продуктовые компании концентрируются на весьма узком продуктовом сегменте, так как это позволяет наилучшим образом проанализировать рынок, оценить возможности применения и разработать качественные программные продукты. Так, например, белорусская компания Viaden Media предлагает рынку два основных класса продуктов: азартные онлайн-игры и приложения для таких мобильных устройств, как iPhone/iPod Touch, iPad и Android63.

Важным вопросом для ИТ-продуктов является политика версий: следует ли выпускать программный продукт в одной версии или предлагать рынку несколько (в последнем случае наиболее традиционны Home, Professional и Enterprise Editions).

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

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

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

Программный продукт как услуга

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

Software as a service (SaaS) - предоставление программного обеспечения в качестве услуги - это модель предложения программного обеспечения потребителю, при которой поставщик разрабатывает интернет-приложение, размещает его в сети и управляет им (самостоятельно либо через третьих лиц), предоставляя потребителю возможность использования услуг поставщика программного обеспечения посредством предоставления доступа к программному обеспечению через Интернет.

SaaS - это современная альтернатива установке ПО на оборудовании заказчика, которая имеет следующие отличия от традиционного подхода:

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

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

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

Преимущества SaaS-модели:

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

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

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

4. Отсутствие затрат на развитие соответствующей ИТ-инфраструктуры при получении доступа к использованию возможностей мощных серверных центров.

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

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

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

? освоенные языки программирования (С#, Java, JavaScript, HTML, XML, JSP, PHP и др.);

? операционные системы (MS Windows, Linux, Palm OS, Android и др.);

? технологические платформы (.NET, J2ME, SAP и др.);

? базы данных (Oracle, MySQL и др.);

? CASE-средства проектирования (UML, IBM Rational Rose и др.).

При этом здесь могут существовать разные «ассортиментные» стратегии. Например, такие лидеры офшорного программирования, как EPAM Systems и SamSolutions, предлагают очень широкий перечень технологических компетенций, а у компании «КактусСофт» - «четкий фокус на разработке под мобильные платформы и использовании решений от Microsoft», как было сказано на ее официальном сайте ранее, а в настоящее время она позиционируется как «компания, осуществляющая полный цикл разработки программного обеспечения на заказ».

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

«Дженерейшн-Пи Консалтинг» специализируется на проектах исключительно в сфере туризма. А самая крупная отечественная аутсорсинговая компания EPAM Systems (ИООО «ЭПАМ Системз») специализируется на ИТ-услугах в пяти основных сферах: поставщики информационных систем и технологий, банки и финансовое обслуживание, бизнес-информация и масс-медиа, туризм и гостиничный бизнес, розничная торговля.

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

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

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

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

Услуги по внедрению программного обеспечения может оказывать как сам разработчик, так и компании, интегрирующие уже готовые программные продукты других фирм-производителей для автоматизации бизнес-процессов конкретного заказчика - так называемые системные интеграторы. В качестве примера здесь можно привести множество белорусских компаний, осуществляющих внедрение популярного специализированного программного обеспечения для бухгалтерского учета от российского разработчика ЗАО «1С». Другим примером выступают компании ИООО «ЭПАМ Системз» и ЗАО «Итранзишн», в которых сформированы целые отделы, занимающиеся внедрением ERP-систем всемирно известного вендора «SAP». Можно упомянуть и белорусскую компанию «КомплИт», занимающуюся внедрением CRM-систем от украинского разработчика «Terrasoft».

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

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

Товарные стратегии для услуг, не связанных с разработкой программного обеспечения

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

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

? объем предоставляемого дискового пространства;

? доступные доменные зоны;

? предлагаемые операционные системы для серверного оборудования (Windows, Linux);

...