Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Обучение от Mail.Ru Group.
Онлайн-университет
для программистов с
гарантией трудоустройства.
Набор открыт!
2003 г

Теория для победителя

Эрнст Долгий
«Экспресс-Электроника»

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

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

Как правило, под термином «проект» подразумевается ограниченный во времени организационный стратегический план для создания уникального продукта или услуги, который может выполняться как одним человеком, так и коллективом. Данное определение проекта ничего не говорит о длительности выполнения работ – оно может варьироваться в самых широких пределах. Неизменным остается лишь конечная цель проекта – получение прибыли или некоего стратегического результата, а также инструмент оптимизации хода выполнения работ – Project Management. Последний подразумевает использование определенных знаний, умений, средств и методов для достижения поставленных целей.

Приведенное определение, позаимствованное из руководства по основам управления проектами (A Guide to the Project Management Body of Knowledge), созданного Project Management Institute, к сожалению, не отражает тех трудностей, с которыми приходится сталкиваться большинству компаний при реализации даже относительно несложных проектов. На наш взгляд, все они связаны с отсутствием у исполнителей современных знаний в области оптимального ведения проекта, а также неумения создать или организовать по-настоящему действенную функциональную команду. И если первая проблема решается достаточно просто – обучением имеющегося персонала или наймом квалифицированного, то решение второй куда сложнее. Дело в том, что принцип формирования команды, принятый в нашем обществе, не правилен, и преодоление стереотипов, связанных с ним, вызывает непонимание у руководства большинства компаний. Иногда дело доходит до саботажа в рядах менеджеров верхнего уровня (не являющихся владельцами компании). Не стоит забывать и об особенностях национального менталитета. К слову, они почему-то полностью нивелируют преимущества использования средств ускоренной разработки программных продуктов, зарекомендовавших себя с наилучшей стороны в западных компаниях.

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

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

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

В то же время диаграммы Гантта имеют ряд недостатков. Например, с их помощью довольно сложно планировать многовариантные взаимосвязанные цепочки работ (в строительных, военных, государственных проектах и на производстве). Для таких задач в военном ведомстве США в 1950-е годы были предложены методы сетевого планирования, или методы выбора «критического пути». Кроме того, диаграммы Гантта удобно применять только для одного критического ресурса — времени. При необходимости учитывать еще несколько ресурсов, например технологическую оснастку, диаграммы Гантта надо воспринимать как объемные, приобретающие ряд измерений по числу учитываемых ресурсов. Это имеет смысл для визуальной интерпретации планов, но затрудняет их анализ. Для управления ходом проекта используются более мощные средства – CPM, PERT и некоторые другие. Ниже дается их описание.

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

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

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

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

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

Для задач, связанных с интеллектуальным трудом и другими вопросами, в которых стоимость оптимизируемого параметра не известна наверняка, используется метод PERT-анализа (Program Evaluation Review Technique). Он был разработан сотрудниками Военно-морского флота США в 1957 году для обеспечения создания ракеты «Поларис». Применяя PERT-анализ, они попытались сымитировать график выполнения работ по созданию ракеты путем построения логической сети взаимозависимых последовательных событий. На начальной стадии PERT-представление было сфокусировано на контроле временных характеристик графика и прогнозировании вероятности успешного завершения программы. Но прежде чем PERT-представление было окончательно принято руководителями программ в промышленности, Военно-воздушные силы США внесли дополнение в методику, добавив к логической сети функцию ресурсной оценки. Таким образом, в 1962 году появилась PERT/Cost-методика (PERT-анализ с целью стоимостного прогнозирования), в то время как первоначально PERT-анализ был известен под названием PERT/Time (PERT-анализ для определения времени реализации проекта).

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

Типичный период времени, применяемый в PERT — одна неделя, но при необходимости может использоваться и любой другой промежуток. Для каждого действия указывают три оценки его длительности — оптимистическая (О), наиболее вероятная (В) и пессимистическая (П). Ожидаемое время продолжительности каждого действия может быть приблизительно оценено как (О + 4В + П)/6. Это расчетное время и указывается на сетевом графике.

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

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

Позже, для получения еще более точных оценок, стали использовать некоторые специальные математические методы, например «рулетка случайных чисел Монте-Карло» или методы статистического моделирования. Хотя первые методики используются и по сей день. Так, работы Гарри Гантта легли в основу научных дисциплин, возникших в середине ХХ века, — промышленной инженерии, занимающейся управлением и организацией производства, а также исследования операций. С исследованием операций связаны работы по применению математических методов формализации человеческой деятельности, в том числе в производстве и планировании. Разработаны многие статистические и оптимизационные алгоритмы планирования, используемые в современных системах. Например, в SAP R/3 для прогнозирования потребностей в продукции (функция Forecast) с учетом информации о фактическом спросе за предыдущие периоды, применяются статистические и эвристические методы (расчеты сезонных колебаний спроса, расчеты по трендам). Еще один пример — методы оперативного планирования (функция Scheduling), подсистемы планирования производства SAP R/3, в которых использованы алгоритмы расчета даты выполнения заказа, сокращения длительности производственного цикла, минимизации переналадок оборудования и прочие.

Новости мира IT:

Архив новостей

Последние комментарии:

Релиз ядра Linux 4.14  (9)
Среда 22.11, 19:04
Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...