Методи керування проектами

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

- требования заказчика не выполняются,

- проект не вложился в стоимость,

- проект не вложился в заданные сроки,

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

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

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

- планирование проекта и составление графиков работ выполнения проекта,

- управление проектными работами и командой исполнителей,

- управление рисками,

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

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

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

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

- этот продукт не материален, его нельзя увидеть в процессе конструирования (как это имеет место, например, при строительстве здания) и повлиять на его реализацию более оперативно;

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

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

- элементной базы и языков программирования.

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

Накопленный опыт в создании технических проектов был систематизирован (в институте управления проектами в США) и разработано ядро знаний - РМВОК (Project Management Body of Knowledge [2]. В нем малыми проектами считаются проекты, содержащие 100 работ и 15 исполнителей, средними - 500 работ и 50 исполнителей и большими - 1000 работ и 100 исполнителей.

Методы управления программным проектом

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

57. Метод критичного шляху для керування проектом

Метод критического пути СРМ

Оснополагающим моментом создания этого метода является исследование возможности эффективного использования вычислительной машины Univac на фирме "Dupon" при планировании и создании планов-графиков больших комплексов работ по модернизации заводов этой фирмы. В результате был создан рациональный и простой метод (Уолкера - Келли) управления проектом с использованием ЭВМ, который был назван CPM (Critical Path Method) методом критического пути.

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

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

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

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

58. Метод аналізу та оцінки PERT

Метод анализа и оценки PERT

Параллельно с разработкой CPM, в военно-морских силах США был создан (фирма "Буз, Аллен & Гамильтон") метод анализа и оценки программ PERT (Program Evaluation and Review Technique) для реализации проекта разработки ракетной системы "Polaris", объединяющей около 3800 подрядчиков с числом операций более 60 тыс. [6].

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

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

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

В этом методе возможное время выполнения операций оценивается с помощью трех оценок:

- оптимистичной (О),

- пессимистической (P),

- вероятностной (B).

А далее вычисляется по формуле: (О+4В+П)/6, c указанием его на сетевом графике.

Для уменьшения провалов проектов используются и другие аналитические методы и усовершенствованные языки разработки систем. Как показывает опыт, "продвинутые" технологии решают вопросы успешного создания проекта с учетом факторов, которые уменьшают его провал [3]:

1. Проект начинать с правильного шага.

2. Поддержка темпа работы.

3. Обеспечение прогресса и правильных решений.

4. Посмертный анализ завершенного проекта.

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

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

2). Поддержка темпа работы состоит в:

- уменьшении текучести кадров;

- контроле качества выполняемых работ;

- управлении процессом разработки, а не людьми.

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

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

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

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

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

Дата добавления: 2015-05-08