Сетевое планирование и управление: основные модели и методы
Менеджер проекта на этапе планирования часто сталкивается с ситуацией, когда одних структуры, плана по вехам и матрицы ответственности недостаточно для разработки календарного плана проекта. Такое возникает для весьма крупных проектных задач, где содержательную часть планируемых работ требуется осуществить наиболее рационально, снизив при этом расход временных ресурсов. На помощь проектному менеджеру может прийти сетевое планирование как инструментальное решение, реализуемое по стандартному оптимизационному алгоритму.
Метод сетевого моделирования
Сетевое планирование и управление получило активное развитие с 50-х годов прошлого века сначала в США, затем в других развитых странах и в СССР. Такие методы сетевого планирования, как CPM, PERT позволили существенно поднять «планку» проектного управления в направлении оптимизации временных и содержательных параметров графиков работ. Это дало возможность разрабатывать расписания проектных задач на основе более эффективной методологии сетевого моделирования, вобравшей в себя весь лучший опыт (схема методов календарного планирования приведена ниже). Сетевая диаграмма имеет различные названия, среди них:
- сетевой график;
- сетевая модель;
- сеть;
- граф сети;
- стрелочная диаграмма;
- PERT-диаграмма, и т.д.
Визуально сетевая модель проекта представляет собой графическую схему последовательного комплекса работ и связей между ними. Стоит заметить, что система планирования и управления проектом целостно отображается в графической форме состава операций, их временных протяженностей и взаимосвязанных событий. Основой метода построения модели служит раздел математики, именуемый теорией графов, сформировавшийся в начале 50-х – конце 60-х годов.
Методы календарного планирования и управления проектам
В модели сетевого планирования и управления под графом понимается геометрическая фигура, включающая бесконечное или конечное множество точек и линий, соединяющих между собой эти линии. Граничные точки графа называют его вершинами, а ориентированные в направлениях соединяющие их точки – ребрами или дугами. Сетевая модель в свой состав включает именно ориентированные графы.
Вид ориентированного графа
Разберем другие основные понятия сетевой модели проекта.
- Работа – часть производственного или проектного процесса, имеющая начало и окончание в форме количественно описываемого результата, требующая затрат времени и других ресурсов. Работа отражается на диаграмме в форме однонаправленной стрелочной линии. Формой работ мы можем считать операции, мероприятия и действия.
- Событие – факт завершения работ, результат которых необходим и достаточен для начала реализации следующих операций. Вид события на модели отражается в форме кружков, ромбиков (вехи) или других фигур, внутри которых помещается идентификационный номер события.
- Веха представляет собой работу с нулевой продолжительностью и обозначает важное, значимое событие в проекте (например, утверждение или подписание документа, акт окончания или начала проектного этапа и т.п.).
- Ожидание – это процедура, которая не потребляет никаких ресурсов, кроме затрат времени. Отображается как линия со стрелкой на конце с отметкой длительности и указанием наименования ожидания.
- Фиктивная работа или зависимость – вид технологической и организационной связи работ, не требует никаких усилий и ресурсов, в том числе затрат времени. На сетевой диаграмме показывается как пунктирная стрелка.
Варианты связей и отношение предшествования
Сетевые методы планирования строятся по моделям, в которых проект представляется как целостная совокупность взаимосвязанных работ. Данные модели во многом формируются типом и видом связей между операциями реализации проекта. С позиции типа различаются жесткие, мягкие и ресурсные связи. Видовое различие взаимосвязанности операций основано на отношения предшествования. Рассмотрим основные типы связи.
- Мягкие связи. Им соответствует особая, «дискреционная» логика, дающая «мягкую» основу для выбора операций к размещению на диаграмму, диктуемого технологией. В то время как технология длительный период развивалась на протяжении многих циклов, вырабатываются правила делового оборота, не требующие дополнительной фиксации и планирования. Это экономит время, место модели, стоимость и не требует дополнительного контроля со стороны PM. Поэтому менеджер проекта сам решает, нужна ему такая выделенная операция, или нет.
- Жесткие связи. Данный вид связей основан на технологической логике. Они предписывают выполнение конкретных действий строго после других, что сообразно с процессуальной логикой. Например, наладку оборудования можно осуществлять только после его монтажа. Тестирование недочетов технологии допустимо проводить, если сдача ее в опытную эксплуатацию произошла и т.д. Иными словами, принятая технология (неважно, в какой сфере она реализуется) жестко навязывает последовательность мероприятий и событий проекта, что и обуславливает соответствующий тип связи.
- Ресурсные связи. В условиях назначения на один ответственный ресурс нескольких задач возникает его перегруженность, что может привести к удорожанию проекта. За счет подведения под менее критичную задачу дополнительного ресурса этого можно избежать, и такие связи называются ресурсными.
В момент формирования расписания проекта сначала применяются жесткие, а затем – мягкие связи. Далее, по необходимости, некоторые мягкие связи подлежат сокращению. Благодаря этому может быть достигнуто некоторое сокращение общей длительности проекта. В условиях перегруженности некоторых ответственных ресурсов из-за параллельных работ допустимо разрешение возникших конфликтов введением ресурсных связей. Однако следует контролировать, чтобы новые связи не привели к значительным изменениям общего плана.
Сопряженные работы как некая последовательность проектной задачи связаны друг с другом. Назовем их операциями А и В. Введем понятие отношения предшествования, которое рассматривается как некое ограничение на сроки и общую продолжительность, так как операция В не может начаться до момента окончания операции А. Это означает, что В и А связаны отношением простого предшествования, при этом вовсе не обязательно, чтобы В начиналось одномоментно с окончанием А. Например, отделочные работы начинаются после возведения крыши дома, но это не означает, что выполняться они должны в тот же момент, когда наступит указанное событие.
Метод сетевой модели номер один
Сетевое планирование и управление (СПУ) предполагает два варианта построения сетевой диаграммы проекта: «ребро – работа» и «вершина – работа». При первом варианте отображения диаграммы реализуются метод критического пути и метод PERT. Метод имеет и иное название – «вершина – событие», что, по сути отражает другую сторону единого содержания. В англоязычной интерпретации данный вариант построения сетевой модели по аббревиатуре называют АоА (Activity on Arrow Diagramming). Доминирующее место в методе занимают события проекта. События различают трех видов:
- начальное событие;
- промежуточное событие;
- конечное событие.
Устройство проектной задачи таково, что в процессе ее реализации место есть только одному начальному и одному конечному событию. До начального события и после конечного события работы не выполняются. В момент конечного события проект считается завершенным. До наступления промежуточного события все входящие операции должны быть выполнены. Оно дает старт всем исходящим из него операциям. Фиктивные работы применяются после работ, если неизвестно, какая из них окажется последней.
Пример сетевой диаграммы метода «ребро – работа»
Сетевое планирование при построении сетевой диаграммы АоА руководствуется следующим набором основных правил.
- Проектные события подлежат последовательной нумерации. Номера присваиваются событиям без пропусков.
- Начального и конечного события должно быть только по одному.
- Работа не может планироваться и размещаться в направлении события проекта, имеющего меньший номер, чем у исходного события.
- Недопустима замкнутая последовательность операций, а линии стрелок размещаются в направлении слева-направо.
- Двойные связи между событиями недопустимы.
Алгоритм формирования диаграммы следующий.
- Разместить слева поля начальное событие.
- Найти в списке работы, не имеющие предшественников, и разместить их итоговые события на диаграмме правее начального события без указания номеров.
- Соединить стрелочными линиями работ начальное и только что размещенные события.
- Из состава работ, которых еще нет на диаграмме, выбрать работу, для которой предшественник уже размещен.
- Справа от предшествующего события вставить новое событие без номера и связать их выбранной работой.
- С учетом отношения предшествования соединить фиктивной работой начальное событие размещенной работы и событие, размещенное на сетевом графике.
- Вернуться к пункту 4, при условии, что не все работы размещены на диаграмме.
- Осуществить оптимизацию сетевого графика, объединяя некоторые события и сокращая ненужные фиктивные работы.
- Пронумеровать события с учетом правил, указанных выше.
Метод сетевой модели номер два
Вторым методом сетевого планирования, по праву завоевавшим популярность среди проект-менеджеров, является диаграмма, называемая «вершина – работа». В англоязычной версии модель сокращенно обозначается как AoN (Activity on Node). Метод отличается большей простой и наглядностью, предлагает узлами модели делать не события, а работы. При этом длина прямоугольников, обозначающих операции, может указывать на их длительность во времени. Отношения предшествования между ними оформляются прямыми или фигурными стрелками.
Такую диаграмму сформировать значительно проще, чем AoA. Тем не менее, алгоритм работы над ней очень похож. События на диаграмме не размещаются, но они предполагаются в завершении каждой работы. Помимо прочего, событиям все-таки уготовано место на сетевом графике, но в форме особых фактов, именуемых вехами. Веха – это особенное значимое событие проекта, и не каждая операция должна ею завершаться. Поэтому диаграмма может быть разгружена от несущественных событий, но отражать важные, ключевые моменты проектной реализации.
Пример сетевой диаграммы метода «вершина – работа»
Если воспользоваться возможностью вариации длины прямоугольников работ, превращая их в ленты, размер которых соответствует длительности реализации, то сетевой график превращается в диаграмму Ганта. Диаграмма вида AoN при этом становится похожей на АоА. В методе AoN отпадает необходимость в изображении фиктивных работ, требуемых в модели «ребро – работа» для своеобразной «упаковки» событий. Благодаря этому лишние, искусственные сущности исключаются из поля зрения менеджера проекта. Вехи в этом отношении являются более интересным решением, располагаясь, как и все работы, в узлах сетевого графика.
Работы перестают выполнять двойную функцию связующих события элементов и непосредственного обозначения выполняемых операций. Для метода AoN не требуется нумерации, что дает PM мобильность для свободного маневрирования числом мероприятий. И в этом кроется еще одно удобство метода «вершина – работа». В сетевой диаграмме должны быть учтены возможности применения различных связей предшествования. Их количество не столь велико, как может показаться на первый взгляд. Оно связано с вариантом связи предшествования и с эффектом отставания или опережения в отношении к примененной типовой связи. Все это мы рассмотрим в отдельном материале, посвященном практике сетевого планирования и управления.
В настоящей статье мы рассмотрели методы сетевого планирования и управления. В современной проектной практике отдается предпочтение методу AoN как более доступному и наглядному. Это не означает, что метод АоА плох, многие специалисты, освоив его, с успехом применяют. Обе модели приводят к одному и тому же результату, но с двух взаимосвязанных сторон: работ и событий. Проект-менеджер должен понимать суть и уметь применять каждый из представленных инструментов. Это связано с тем, что задача сетевого планирования состоит в поиске наиболее экономичных, ясных решений построения событийной и временной последовательности в условиях ограничений.
История управления проектами
В конце столетия Фредерик Тейлор (1856–1915 гг.) начал свои подробные исследования труда. Он применял при этом научные рассуждения, доказывая, что труд можно анализировать и улучшать, выделяя его элементарные составляющие. Он применял свои идеи к таким задачам на сталелитейных заводах, как засыпка песка и поднятие и перемещение деталей. До этого считалось, что единственный способ повысить производительность — это заставлять рабочих работать больше и дольше. В разрез с этим представлением Тейлор ввел понятие эффективной работы. Надпись на надгробии Тейлора в Филадельфии свидетельствует о важности его вклада в историю управления: «Отец научного управления».
Ученик Тейлора Генри Гант (1861–1919 гг.) очень подробно изучал последовательность операций при работе. Его исследование управления было сконцентрировано на кораблестроении во время Первой мировой войны. Диаграммы Ганта, включая отрезки задач и маркеры вех, показывают последовательность и продолжительность всех задач в процессе. Диаграммы Ганта оказались настолько полезным средством анализа для руководителей, что они практически не изменились за почти сто лет. Только в начале 1990-х гг. к отрезкам задач были впервые добавлены линии связей, которые отражают более точные зависимости между задачами.
Во время Второй мировой войны сложность правительственных и военных проектов, в также сокращение трудовых ресурсов привели к необходимости создания новых организационных структур. Были разработаны сложные сетевые диаграммы, которые назывались диаграммами PERT, и метод критического пути, которые предоставили руководителям возможность лучше контролировать очень сложные проекты с большим количеством инженерных работ (такие как создание боевых систем, требующее огромного числа задач и многочисленных операций в различные моменты времени).
В основе современных методов управления проектами лежат методики сетевого планирования, разработанные в конце 50-х годов в США. В 1956 г. М.Уолкер из фирмы «Дюпон», исследуя возможности более эффективного использования принадлежащей фирме вычислительной машины Univac, объединил свои усилия с Д.Келли из группы планирования капитального строительства фирмы «Ремингтон Рэнд». Они попытались использовать ЭВМ для составления планов-графиков крупных комплексов работ по модернизации заводов фирмы «Дюпон». В результате был создан рациональный и простой метод описания проекта с использованием ЭВМ. Первоначально он был назван методом Уолкера-Келли, а позже получил название Метода Критического Пути — МКП (или CPM — Critical Path Method).
Параллельно (1958г.) и независимо консалтинговой фирмой «Буз, Аллен энд Гамильтон» для реализации проекта разработки ракетной системы «Поларис» был разработан метод анализа и оценки (пересмотра) программ PERT (Program Evaluation and Review Technique). На его разработку, по заявлениям фирмы, ушло 15 лет, таким образом, начало работ относилось к 1943г.
Вскоре эти методы стали применяться в различных отраслях, так как руководители искали новые стратегии и средства управления, которые позволили бы справиться с ростом в условиях быстро меняющегося мира с ожесточенной конкуренцией. В начале 1960-х гг. компании стали применять к деловым операциям принципы общих теорий систем. Ричард Джонсон, Фремонт Каст и Джеймс Розенцвейг в своей книге Теория систем и управление ими представили современную компанию в виде человеческого организма — со скелетом, мускулами, кровеносной и нервной системой и т. д.
Идеи, сходные с идеями, положенными в основу системы PERT, были еще в 30-х годах предложены в советском капитальном строительстве (на строительстве Магнитогорского металлургического комбината), но в то время они не получили распространения и для них не были произведены необходимые математические разработки.
Однако это не означает, что в нашей стране идеи метода никого не интересовали. Благодаря усилиям С.П. Никанорова, в 60-е годы Министерство обороны в лице подведомственных институтов активно занялось разработками в этой области.
Если вспомнить, сколько стоил в то время вычислительный ресурс – становится понятным, что только крупные корпорации и правительства могли использовать эти методики.
С течением времени и удешевлением вычислительного ресурса, Системы управления проектами стали более распространенными.
Управление проектами продолжило свое развитие в последние десять лет. Возникли две значимые тенденции.
- Планирование «снизу вверх». В этой тенденции основной упор делается на простую структуру проекта, сокращение цикла проекта, эффективную совместную работу в группе, более глубокое вовлечение членов рабочей группы и принятие решений. Эта тенденция широко известна как динамичное управление проектами, и она включает связанные методики, такие как Scrum, Crystal, Extreme Programming, Unified Process и т. д.
- Планирование и анализ «сверху вниз». Эта тенденция характеризуется принятием решений в масштабе всего предприятия относительно портфеля проектов, который должна иметь организация, а также использованием технологий интеллектуального анализа данных для более понятного представления информации в портфеле.
Таким образом, основные вехи истории управления проектами.
30-50 годы – начало управления проектами:
- 1937г. – американским ученым Гуликом была осуществлена первая разработка по матричной организации для руководства и осуществления сложных проектов.
- 1956г. – компания «Дюпон де Немур» образовала группу для разработки методов и средств управления проектами.
- 1957г. – коллективом Remington Rand, возглавляемым Kelly и Walker, был разработан метод критического пути (CPM) с программной реализацией на ЭВМ UNIVAC.
- 1957-58 гг. – для программы Поларис (US Navy) была разработана и опробована система сетевого планирования PERT.
- 1959г. – комитетом Андерсона (NASA) был предложен системный подход к управлению проектом по стадиям его жизненного цикла, в котором особое внимание уделялось предпроектному анализу.
- Разработанные в 1956-58гг. методы и техника сетевого планирования дали мощный толчок развитию УП.
- Развитие УП в 50-е годы завершилось публикацией Gaddis в Harvard Business Review первой обобщающей статьи по управлению проектами.
60-е годы – развитие методов сетевого планирования:
- Развитие УП концентрируется почти исключительно на методах и средства PERT и CPM.
- Распространение сетевых методов УП в Европу и другие континенты.
- Появление матричной формы организации.
- Разрабатывается целостная система материально-технического обеспечения (1966)
- Появляется система GERT (1966), использующая новую генерацию сетевых моделей
- Создаются профессиональные организации управления проектами
- В Европе – Международная Ассоциация управления проектами (IPMA) – 1965г.
- В Северной Америке – Институт управления проектами (PMI) – 1969г.
70-е годы – развитие системного подхода к управлению проектами
- в УП учитывается «внешнее» окружение проектов.
- 1971г. — решаются проблемы руководителя проекта и команды проекта.
- 1977г. – разрабатываются методы управления конфликтами.
- 1977-79 гг. – разрабатываются организационные структуры УП.
- Создаются профессиональные организации УП:
- o В Австралии (AIPM)
- o В Азии (ENAA)
В 80-е годы – управление проектами сформировалось как сфера профессиональной деятельности
- В начале 80-х – высокий уровень неудач воплощения УП.
- Развиваются методы УП в строительстве с ориентацией на заказчика.
- В практику входят методы управления изменениями.
- Развивается управление качеством в проекте.
- Управление риском выделяется в самостоятельную дисциплину в сфере УП.
- В США публикуется первая версия коллективной работы института IPM – Project Management Body of Knowledge (Свод знаний по УП), в которой определены место, роль и структура методов и средств УП и их вклад в общее управление
В 90-е годы – новые направления и сферы приложения управления проектами:
- Начало трансферта знаний и опыта УП в развивающиеся страны.
- Осознание возможностей и полезности применения УП в нетрадиционных сферах.
- Осознание необходимости и практическое начало процессов глобализации, унификации и стандартизации в области УП.
- Начало разработки и использования в УП новых информационных технологий, в т.ч. сетевых.
- Разработка и ввод в действие программ сертификации менеджеров проекта.
- Разработка и ввод в действие международных (ISO 10006-10007) и национальных (APM, PMI, AI PM) стандартов по управлению проектами.
Сетевое планирование и управление в менеджменте (1) (Курсовая работа)
Российская Международная Академия Туризма
Курсовая работа
по дисциплине «Основы менеджмента»
на тему «Сетевое планирование и управление в менеджменте»
вариант № 9
студентки 206 группы
Бахтеевой Елены Маратовны.
Проверила
Еранцева Елена Михайловна.
г. Химки, микрорайон Сходня 2010 год
Содержание
Введение
Глава 1. Сетевого планирования и управления
1.1 Сущность сетевого планирования и область его использования
1.2 Элементы сетевой модели
1.3 Правила построения сетевой модели
Глава 2. Расчет параметров и оптимизация сетевой модели
2.1 Исходные данные для построения сетевой модели
2.3 Расчеты характеристик элементов сетевой модели
2.4 Оптимизация сетевой модели
Заключение
Список источников и литературы
Введение
Тема сетевого планирования и управления является актуальной, так как с помощью нее можно научиться строить сетевую модель и при необходимости, оптимизировать ее.
Предметом исследования курсовой работы является сетевое планирование и управление, а объектом — сетевая модель.
Целью курсовой работы является оптимизация сетевой модели, в соответствии с полученным вариантов №9.
Основными задачами данной курсовой работы являются:
теоретическое изучение сетевого планирования и у правления, определение его сущности, изучение основных элементов сетевой модели;
изучение правил построения модели;
расчеты всех параметров сетевой модели, полученной в варианте;
оптимизация сетевой модели.
Глава 1. Сетевого планирования и управления
Сущность сетевого планирования и область его использования
Сетевое планирование и управление (СПУ) – это комплекс графических и расчетных методов, организационных мероприятий, обеспечивающих моделирование, анализ и динамическую перестройку плана выполнения сложных проектов и разработок, например таких как: разработка туристской услуги, исследование системы управления организацией, маркетинговое исследование, разработка стратегий организации и др. Характерной особенностью таких проектов является то, что они состоят из ряда отдельных, элементных работ. Они обусловливают друг друга так, что выполнение некоторых работ не может быть начато раньше, чем завершены некоторые другие. Например, расчет цены услуги нельзя выполнить раньше, чем будет составлена калькуляция; реализация нового тура не может быть осуществлена, если еще не обучен персонал, и т. п.
Сетевое планирование и управление включает три основных этапа: структурное планирование, календарное планирование, оперативное управление.
Структурное сетевое планирование начинается с разбиения проекта на четко определенные операции, для которых определяется продолжительность и необходимые ресурсы. Затем строится сетевая модель (сетевой график), которая представляет взаимосвязи работ проекта. Это позволяет детально анализировать все работы и вносить улучшения в структуру проекта еще до начала его реализации.
Календарное сетевое планирование предусматривает определение моментов времени начала и окончания каждой работы и другие временные характеристики сетевого графика. Это позволяет, в частности, выявлять критические операции и пути сетевой модели, которым необходимо уделять особое внимание, чтобы закончить проект в директивный срок. Во время календарного планирования определяются все временные характеристики всех работ и событий с целью оптимизации сетевой модели, которая позволит улучшить эффективность использования какого-либо ресурса (трудовых ресурсов, времени, денежных средств и др.).
В ходе оперативного сетевого управления используются оптимизированный сетевой график и календарные сроки для составления периодических отчетов о ходе выполнения проекта. При этом модель может подвергаться оперативной корректировке, вследствие чего будет разрабатываться новые параметры остальной части сетевой модели.
Сетевая модель – это план выполнения некоторого комплекса взаимосвязанных работ, заданного в форме сети, графическое изображение которой называется сетевым графиком. Математический аппарат сетевых моделей базируется на теории графов.
Графом называется совокупность двух конечных множеств: – множества точек, которые называются вершинами, и множества связей между парами вершин, которые называются ребрами. Если рассматриваемые пары вершин являются упорядоченными, т. е. на каждом ребре задается направление, то граф называется ориентированным; в противном случае – неориентированным. Последовательность повторяющихся ребер, ведущая от некоторой вершины к другой, образует путь. Граф называется связным, если для любых двух его вершин существует путь, их соединяющий; в противном случае граф называется несвязным. В экономике и управлении чаще всего используется два вида графов: дерево и сеть.
Дерево представляет собой связный граф без циклов, имеющий исходную вершину (корень) и крайние вершины; пути от исходной вершины к крайним вершинам называются ветвями.
Сеть – это ориентированный конечный связный граф, имеющий начальную вершину (источник) и конечную вершину (сток). Таким образом, сетевая модель представляет собой граф вида «сеть».
Объектом управления в системах сетевого планирования и управления являются коллективы исполнителей, располагающие определенными ресурсами и выполняющие комплекс операций, который призван обеспечить достижение намеченной цели, например разработку новой услуги – исследование системы управления, реализацию комплекса управленческих процедур и операций для достижения стратегической организации и др.
1.2 Элементы сетевой модели
Элементами сетевой модели являются: работы, события, пути.
Работа – это либо любой активный трудовой процесс, требующий затрат времени и ресурсов и приводящий к достижению определенных результатов (событий), либо пассивный процесс («ожидание»), не требующий затрат труда, но занимающий время, либо, наконец, связь между какими-то результатами работ (событиями), называемая фиктивной работой. Обычно действительные работы в сетевом графике обозначаются сплошными стрелками, а фиктивные работы – пунктирными.
Событие – это итог проведенных работ, который дает начало для дальнейших (последующих) работ. Событие не имеет продолжительности во времени. Событие, за которым начинается данная работа, называется начальным для данной работы; оно обозначается символом i. Событие, которое наступает после выполнения данной работы, называется конечным для данной работы; оно обозначается символом j.
В каждой сети имеются два крайних события – исходное и завершающее. Исходным называется событие в сети, не имеющее предшествующих событий и отражающее начало выполнения всего комплекса работ. Оно обозначается символом I. Завершающим называется событие, которое не имеет последующих событий и показывает достижение конечной цели выполнения комплекса работ. Оно обозначается символом К. В одно и то же событие может входить и выходить из него несколько видов работ.
Путь – это любая последовательность работ в сетевом графике, в котором конечное событие каждой работы совпадает с начальным событием следующей за ней работы. Если известна продолжительность каждой работы tij, то для каждого пути может быть вычислена его общее время выполнения – длина, т. е. общая сумма продолжительности всех работ пути ТLi.
В сетевом графике следует различать несколько видов путей:
полный путь – путь от исходного события до завершающего;
полный путь с максимальной продолжительностью называется критическим путем Lкр;
путь, предшествующий данному событию, – путь от исходного события до данного;
путь, следующий за данным событием, – путь от данного события до завершающего;
путь между событиями i и j;
подкритический путь – полный путь, ближайший по длительности к критическому пути;
ненагруженный путь – полный путь, длительность которого значительно меньше длительности критического пути.
Методы управления проектами | WEEEK | Блог
Если ты откроешь практически любую статью о методах управления проектами, уверяю тебя, наткнёшься там на примерно один и тот же перечень «методов»:
- Waterfall,
- Agile,
- Scrum,
- Kanban,
- Lean,
- PRINCE2,
- Six Sigma и др.
Дело в том, что многие авторы путают тёплое с мягким, а именно — методы с методологиями, методиками, философскими концепциями и много чем ещё. Похоже, что они просто берут похожие слова, рассчитывая, что те являются синонимами. Возникает страшная путаница, из-за которой новичку в управлении проектами очень сложно разобраться в происходящем.
Важная теоретическая часть
Давай расставим все точки над «ё».
Метод — способ что-то сделать. Также называют техникой.
Методология — набор методов и принципов, подкреплённых теорией. Также называют моделью.
Методика — готовый алгоритм применения различных методов для достижения какой-то цели. Также называют фреймворком.
И вот если через призму этих определений, которые я склонен считать наиболее логичными и правильными, посмотреть на список «методов», приведённый выше, получается следующая картина:
Название | Чем является |
---|---|
Waterfall | методология |
Agile | методология (и философская концепция) |
Scrum | методика, построенная на методах Agile |
Kanban | метод Agile |
Lean | метод Agile (а ещё философская концепция) |
PRINCE2 | методика |
Six Sigma | методология, но касается она управления процессами, а не проектами |
Не совсем про методы, да? Скорее про методологии.
К слову, я считаю, что есть всего три методологии управления проектами:
- каскадная (водопадная, Waterfall) – задачи делаются последовательно, пока не завершится одна, нельзя начать другую;
- гибкая (итерационная, Agile) — работа над задачами ведётся параллельно, благодаря чему компания экономит ресурсы;
- гибридная — соответственно, смесь двух предыдущих методологий, которая берёт от них только лучшие элементы.
Все они состоят из множества методов, которые порой пересекаются. Но не все методы касаются управления проектами. Про остальные я ещё как-нибудь расскажу, но сейчас речь не о них.
7 методов управления проектами
Техник управления проектами очень-очень много. Я собрал, на мой взгляд, ключевые — которые работают вне зависимости от проекта.
Иерархическая структура работ (WBS)
Разбиваешь большие задачи на блоки более мелких и управляемых, которые тебе и команде будет проще понять и сделать. Короче, проводишь декомпозицию.
Скажем, если ты планируешь собрать себе велосипед с нуля, иерархическая структура работ может выглядеть следующим образом:
Метод поможет тебе оценить все задачи и понять, какие ресурсы нужны для достижения результата. Собственно, начинать декомпозицию лучше всего от обратного — сначала определись с желаемым результатом, а затем уже с задачами, которые для этого результата нужны.
Диаграмма Ганта
Один из самых старых и популярных методов управления проектами. До сих пор востребован и у новичков, и у опытных проджект-менеджеров. Всё благодаря отличной визуализации проекта — ты видишь:
- зависимость задач друг от друга;
- время, которое занимает каждая из них;
- то, как это время влияет на финальный дедлайн.
В принципе, диаграмму Ганта можно использовать для управления любыми проектами, но я бы не советовал сильно на ней фокусироваться. Это довольно жёсткий вариант планирования — при столкновении с реальностью любая такая диаграмма начинает разваливаться, потому что не бывает проектов, где всё идёт гладко.
Диаграмма Ганта — отличный способ оценить весь фронт работ и примерно прикинуть продолжительность, последовательность и зависимость задач друг от друга. Не более того.
Kanban
Очень популярный метод управления проектами, часть методологии Agile и методики Scrum. Его придумали в Toyota, чтобы оптимизировать рабочие процессы с помощью наглядной визуализации и активной работы над незавершёнными задачами.
Управление ведётся через специальную доску и набор стикеров-задач. Доска разделена на столбцы-этапы, которые проходит задача на пути к завершению. По умолчанию это:
- Входящие,
- К работе,
- В работе,
- Сделано.
Но с помощью столбцов можно описать любой рабочий процесс. Kanban особенно эффективен на простых проектах или в командах, практикующих многозадачность.
Работать по методу Kanban можно в WEEEK.
PERT (Program Evaluation and Review Technique)
Метод оценки, анализа, планирования и контроля работ по проекту. Разработан для ВМС США во времена Холодной войны, чтобы повысить эффективность работы над новыми технологиями.
Основа PERT — специальные диаграммы, сетевые графики. Каждая вершина — состояние проекта в той или иной момент времени. Связи между вершинами — проектные работы.
Среди прочего, PERT позволяет оценить время, которое потребуется твоей команде на каждую задачу, а также минимально необходимое время для выполнения проекта в целом.
Этот метод лучше всего подходит крупным и долгосрочным проектам с нестандартными задачами и сложными требованиями.
Метод критического пути (CPM)
Это метод планирования проектных работ, который часто используется вместе с PERT. Суть метода в определении самой длительной последовательности взаимосвязанных задач — так называемого «критического пути». Эти задачи называются критическими, потому что у них нет резерва времени — то есть любая проблема в одной из этих задач повлияет на сроки выполнения проекта в целом. Такие задачи требуют более пристального внимания и контроля.
Метод критического пути полезен на сложных проектах в областях, где сроки крайне важны — строительство, оборонка, разработка и т. п.
Метод критической цепи (CCPM)
Более продвинутый метод, основанный на методах PERT и CPM и, в каком-то смысле, противоположный им. Метод критической цепи не предполагает жёсткого планирования и жёсткой последовательности задач. Напротив — упор идёт на гибкость в распределении ресурсов и внимание к использованию времени.
CCPM, как и два предыдущих метода, эффективен на сложных проектах. А поскольку фокус этого метода на оптимизации времени и разумном распределении ресурсов, лучше всего он подойдёт проектам, где ресурсы ограничены.
Экстремальное управление проектами (XPM)
Примечательный метод управления, радикально отличающийся от всех вышеперечисленных. Если до этого я говорил о методах плюс-минус формальных, то XPM вообще не про то. XPM — это джаз, импровизация. Вместо чётких планов, правил и фаз, через которые должен пройти проект, здесь упор идёт на гибкость планирования и человеческий фактор.
В XPM настолько важная роль отводится людям, что и успех проекта определяют они, а не цифры. Например, если у команды есть ощущение, что проект движется в верном направлении, или они довольны своей жизнью во время работы над проектом, значит всё ОК.
Метод экстремального управления полезен на больших и сложных проектах с кучей неопределённых и непредсказуемых факторов.
Нельзя однозначно советовать те или иные методы управления проектами. Методы — это детали конструктора. И твоя задача, как менеджера проекта, собрать из деталей систему, которая подойдёт именно для этого проекта, именно здесь и сейчас.
УЛУЧШЕНИЕ ПРОЦЕССОВ ОБСЛУЖИВАНИЯ ПАССАЖИРОВ ВЫЛЕТАЮЩЕГО РЕЙСА НА ОСНОВЕ МЕТОДОВ УПРАВЛЕНИЯ ПРОЕКТАМИ | Кропивенцева
1. Богданов А.А., Зайцев Е.Н., Тецлав И.А. Управление коммерческой подготовкой воздушного судна в аэропорту // Вестник СПбГУ ГА. 2012. № 2(4). С. 91–100.
2. Сорокина Т.В., Кропивенцева С.А. Исследование путей сокращения длительности наземного обслуживания пассажиров внутрироссийского рейса // Сб. трудов Международной молодежной научной конференции «ХIII Королёвские чтения», г. Самара, 6–8 октября 2015. 2015. Т. 1. С. 186.
3. Радаева Ю.А., Кропивенцева С.А. Исследование мероприятий по повышению качества наземного обслуживания авиаперевозок в аэропорту // Сб. трудов Международной молодежной научной конференции с международным участием «ХIV Королёвские чтения», г. Самара, 3–5 октября 2017. 2017. Т. 1. С. 316.
4. Леоненков А.В. Решение задач оптимизации в среде MS Excel. СПб.: БХВ-Петербург, 2005. 704 с.
5. Новиков Д.А. Теория управления организационными системами. М.: МПСИ, 2005. 584 с.
6. Сетевые модели в управлении: сб. статей // под ред. Д.А. Новикова, О.П. Кузнецова, М.В. Губко. М.: Эгвес, 2011. 443 с.
7. Сесекин Н.А. Сетевое экономико-математическое моделирование оптимизации мелкосерийного производства на предприятии // Вестник ПГГПУ. Сер. № 3. Гуманитарные и общественные науки. 2016. № 1. С. 51–55.
8. Буценко Е.В., Шориков А.Ф. Реализация сетевого экономико-математического моделирования для процесса бизнес-планирования // Вестник УРФУ. Сер. Экономика и управление. 2015. Т. 14, № 6. С. 935–953. DOI: 10.15826/vestnik.2015.14.6.051
9. Ширшиков Б.Ф. Минимизация продолжительности возведения объектов на основе использования информационно-динамических сетевых моделей / А.М. Славин, В.С. Степанова, С.О. Михеев // Промышленное и гражданское строительство. 2016. № 2. С. 70–75.
10. Буценко Е.В. Метод критического пути как критерий оптимизации процесса бизнеспланирования // Известия ДВФУ. Экономика и управление. 2016. № 3. С. 40–50. DOI: 10.5281/zenodo.163476
11. Камышев А.И. Эффективность СМК. Ч. 3. Методы улучшения процессов // Методы менеджмента качества. 2013. № 12. С. 10–16.
12. Коникова Е.В. Система поддержки принятия решения при оперативном управлении наземным обеспечением авиаперевозок // Научный Вестник МГТУ ГА. 2007. № 118. С. 146–152.
7 лучших методологий управления проектами в 2021 году
Выполнение проекта — ответственная задача. Независимо от того, работаете ли вы в ИТ-компании или не в ИТ-компании, для этого вам понадобятся подходящие инструменты. И это начинается с вашей методологии управления проектами.
Без него невозможно оценить бюджет проекта, собрать команду, управлять ресурсами или эффективно распределить время. Вам понадобится подробный и четкий план.
Из этой статьи вы узнаете, что такое методологии управления проектами, а также их преимущества и недостатки.Вы также получите полезные советы о том, как претворить в жизнь свою методологию управления проектами и добиться результатов.
Методологии управления проектами: основы
Начнем с начала. Методологии управления проектами (PMM) — это набор правил, принципов и методов, который определяет:
- Как ваша команда должна работать над проектом
- Какие инструменты будет использовать ваша команда?
- Как проверить и оценить результат
Методологии управления проектами широко используются в IT-сфере, но не только.Вы можете использовать их в любой области, где требуется глубокий подход к проекту или деятельности. И разбейте их структуру по факторам, включая время , размер команды , бюджет проекта и его метрики качества .
У каждой методики есть свои преимущества и недостатки. Хотя список методологий PM кажется довольно длинным, вам не обязательно знать их все или следовать им в точности.
Но вам нужно потратить некоторое время на то, чтобы обдумать правила и инструменты вашего будущего проекта.Вы даже можете комбинировать различные методологии управления проектами, чтобы создать свой собственный способ лучше соответствовать вашему проекту.
Типы методологий управления проектами
Давайте взглянем на самые популярные и наиболее часто используемые методологии и примеры управления проектами.
Методологии управления ИТ-проектами
ИТ-проекты быстры, гибки и динамичны. Вот почему им требуется определенный набор методологий управления проектами. Эти методологии управления проектами помогают в разработке и доставке ИТ-продуктов.
Как вы могли заметить, ИТ-проекты часто характеризуются своей сложностью, связанной с бизнес-процессами, организационной структурой и рисками. Поэтому очень важно установить четкие цели, задачи и стратегии оценки.
Начиная новый проект, менеджеры ИТ-проектов могут смешивать несколько общих методологий или методологий управления ИТ. Такой подход делает такие проекты гибкими, позволяет командам быстро выпускать свои продукты и отслеживать отзывы пользователей о продукте.
Agile методология управления проектами гAgile-модель часто противопоставляется модели Waterfall, которая будет подробно рассмотрена ниже. В отличие от Waterfall, где ступени напоминают воду, стекающую с горы только в одном направлении, Agile использует итерацию . Это используется для исправления ошибок и гибкого анализа требований клиентов и методов разработки программного обеспечения.
Эта методология была создана в 2001 году в Юте, когда 17 разработчиков программного обеспечения собрались, чтобы обсудить свои подходы к разработке программного обеспечения помимо Waterfall.На этой конференции разработчики представили Agile Manifesto. Он содержит основные принципы Agile. Прочтите их и решите, может ли Agile работать на вас.
Основные принципы Agile
- Люди и взаимодействие важнее процессов и инструментов. : Люди имеют разные стили работы, и часто гораздо проще решить некоторые проблемы быстро в сотрудничестве, чем следовать предписанным процедурам.
- Рабочее программное обеспечение важнее исчерпывающей документации. : Для Agile гораздо важнее, чтобы ваш продукт работал, а не хорошо разработанная документация.
- Сотрудничество с клиентами при заключении контрактов : Клиенты должны принимать активное участие в разработке продукта и выдвигать предложения по его улучшению.
- Реагирование на изменение в соответствии с планом : Это означает, что измененные требования к продукту намного важнее, чем спецификации продукта, согласованные в начале. Заказчик лучше знает, какой продукт ему нужен, поэтому он выбирает его качества и особенности.
Элементы гибкой методологии управления проектами
- Изменение приветствуется. : Это означает, что заказчики, команда и менеджеры проектов готовы к внесению изменений в исходный проект, которые будут обсуждаться и внедряться в продукт вместе с развертыванием проекта.
- Поэтапная разработка : Продукт улучшается после каждой итерации и развивается постепенно. Итерация означает, что каждый компонент продукта обсуждается, создается, проверяется и реализуется с максимально успешным завершением проекта.
- Частые выпуски и отзывы : Чтобы оправдать ожидания клиентов, разрабатываемое программное обеспечение подвергается коротким циклам поэтапной разработки. После каждой итерации команда представляет результат своего продукта для обратной связи с клиентами.
- Участие клиента в разработке продукта : Клиент предоставляет обратную связь и предлагает модификации продукта в составе проектной группы.
Отслеживайте время прямо там, где происходит работа
Оценивайте задачи, устанавливайте бюджеты, сохраняйте время и
настраивайте отчеты — все это в вашем инструменте управления проектом
.Простой!
Скрам против Канбан
Scrum и Kanban — две из самых популярных методологий управления проектами Agile. Давайте разберем их.
Источник изображения: Medium.comКоманды Scrum обязуются поставлять работающее программное обеспечение через определенные интервалы, называемые спринтами . Их цель — создать циклы обучения для быстрого сбора и интеграции отзывов клиентов. Скрам-команды берут на себя определенные роли, создают особые артефакты и проводят регулярные церемонии, чтобы все двигалось вперед.
Канбан предназначен для визуализации вашей работы, ограничения незавершенной работы и повышения эффективности (или потока). Канбан-команды сосредоточены на сокращении времени, необходимого для прохождения проекта (или пользовательской истории) от начала до конца. Они делают это, используя доску канбан и постоянно улучшая рабочий процесс.
Канбан идеально подходит для предприятий, которые готовы быстро добиваться результатов. Между тем, они тратят свои ресурсы на частое исправление, улучшение продуктов и тесное сотрудничество со своими клиентами.
Преимущества и недостатки
- Быстрая реализация на следующей итерации после обсуждения с клиентом
- Минимизация ресурсов из-за частого согласования дальнейших шагов
- Продукт и команды гибкие и адаптируемые
- Усилия больше сосредоточены на разработке продукта
- Быстрое обнаружение дефектов и раннее тестирование продукта
- Результат более удовлетворительного продукта благодаря участию клиентов в разработке продукта
- Быстрая и частая обратная связь
- Интенсивное сотрудничество и общение внутри команды.
- Не все готовы принять Agile. Некоторым компаниям придется столкнуться с обновлением всей структуры компании, чтобы внедрить Agile. Например, им нужно будет изменить рабочий процесс, обучить сотрудников и провести переговоры с текущими клиентами.
- Чтобы добиться результатов, вы должны знать, как это реализовать. Это означает, что вам и вашим сотрудникам потребуется дополнительное обучение.
Гибкие инструменты
Вы хорошо понимаете, что такое Scrum и Kanban? Большой.Когда вы будете довольны фреймворком Scrum, пора найти инструмент Scrum, который вам пригодится. То же самое и с Канбаном. Программное обеспечение Jira поддерживает рабочие процессы как Scrum, так и Kanban, и его можно безупречно интегрировать с приложениями для отслеживания времени.
Как лучше отслеживать время в JIRA. Методология управления проектом водопадаМетод водопада — одна из первых методологий, созданных для управления разработкой программного обеспечения. По сути, если вы возьмете традиционный подход к управлению проектами и примените его к сфере ИТ, вы получите модель водопада.
Впервые он был представлен Гербертом Д. Бенингтоном на Симпозиуме по передовым методам программирования для цифровых компьютеров в 1956 году.
Он называется «Водопад», так как его ступени напоминают стекающую с горы воду, как настоящий водопад.
Чтобы применить методологию водопада, выполните следующие действия.
1) Установка требований
- Определение потребностей бизнеса
2) Создание документации
- Создание бизнес-требований и спецификаций
- Разработка архитектуры разработки программного обеспечения
- Выбор технологии разработки программного обеспечения
3) Разработка продукта
4) Зондирование и тестирование продукта
- Разработчики программного обеспечения проводят юнит-тесты
- QA-инженеры тестируют программный продукт
5) Выпуск и сопровождение продукта
- Выпуск вашего продукта
- Оказание необходимой поддержки пользователям
Для эффективного управления проектами лучше всего использовать инструменты цифрового управления проектами и полезные интеграции.Они помогут вам собрать все задачи в одном месте и оценить ваш вклад в проект.
Достоинства и недостатки- Стабильная и хорошо проработанная документация от начала до конца проекта.
- Более доступное обучение новичков, которые могут изучить проект по разработанным документам.
- Лучшее планирование времени для членов команды, так как обязанности ясны, а работа расписана.
- Клиенты имеют полное представление о продукте, который они получат на стадии выпуска.Прозрачное расходование бюджета, отслеживаемое рабочее время каждого сотрудника.
- По проекту легко оценить и измерить прогресс.
- Качественный продукт благодаря подробной документации и выделенному времени на тестирование.
- После того, как вы закончили этап в модели Waterfall, почти невозможно вернуться и исправить недостатки. В результате этап планирования несет ответственность за весь проект.
- Поскольку отката нет, все допущенные ошибки переносятся на следующий этап с небольшими шансами на их исправление, что приводит к падению качества продукта.
- Если вы опоздали на одном из этапов своего проекта, крайний срок проекта переносится на другие даты.
- QA-тестирование начинается слишком поздно, когда код готов, и исправление ошибок мало что дает.
- Если проект задерживается, некоторые компании пытаются сократить время на этапе тестирования, что приводит к ошибкам и системным сбоям в продукте.
- Слишком медленно в реализации. К моменту выпуска требования клиента могут измениться в связи с потребностями бизнеса, и конечный продукт может стать неактуальным.
- Модель Waterfall не допускает никаких непредвиденных проблем, а это означает, что ваша команда может столкнуться с ними во время проекта.
Методология Waterfall лучше всего подходит для небольших проектов по аутсорсингу или простых проектов разработки программного обеспечения, в которых не ожидается незначительных изменений или применяются бюджетные ограничения. Требования к продукту меняются реже, чем в аутсорсинговых компаниях, и риски ниже.
Помимо управления проектами, небольшие компании могут столкнуться с такими трудностями, как оценка рабочего времени сотрудников, расчет сверхурочной оплаты или выписывание счетов-фактур, которые должны соответствовать графику выполнения проекта.
Общие методики управления проектамиОбщие методики управления проектами подходят для широкого круга проектов. Вы можете реализовать их как для малых, так и для крупных мероприятий. И даже с разным бюджетом и разным количеством участников в команде.
Основное различие между этими методологиями управления ИТ-проектами заключается в том, что их можно использовать в различных областях, таких как строительство, государственное управление, финансовый сектор и т. Д.
Давайте взглянем на некоторые из них.
Метод критического пути (CPM)
Метод критического пути был разработан для крупномасштабных многоцелевых проектов компанией El DuPont de Nemours в конце 50-х годов.
В его основе лежит математический алгоритм, который помогает определить критический путь в вашем проекте.
Critical Path Основная особенность критического пути — это способ расчета минимальной возможной продолжительности проекта путем выстраивания самой длинной последовательности зависимых задач, необходимых для завершения проекта.
CPM широко используется с 1958 года, когда он впервые был успешно использован при строительстве химического завода. Это делает планирование времени и задач приоритетом, помогая вам не отставать от сроков при выполнении сложных задач.
Источник изображения: Workep.com Для реализации метода CPM необходимо выполнить следующие шаги1) Соберите и систематизируйте свои задачи
- Составление списка ваших задач
- Присвоение каждой задаче имени или шорткода
- Определение продолжительности и срока выполнения каждой задачи
2) Поток задач заказа
- Логическое построение задач
- Определение зависимостей ваших задач
3) Создайте схему сети
- Визуализация вашей цепочки задач с помощью сетевой диаграммы
- Связывание задач в график
4) Назначьте время
- Определение времени, необходимого для выполнения каждой задачи в проекте
5) Определите критический путь
- Нахождение на диаграмме самой длинной последовательности задач проекта.
Пояснение видео
Вначале вам придется полагаться на свой предыдущий опыт для выполнения задач и добавлять приблизительное время для каждой задачи. После этого возьмите в привычку отслеживать свое время для каждой задачи. Таким образом, вы сможете более точно оценивать свое время в будущем.
Чтобы рассчитать время для каждой задачи и легко расставить приоритеты, лучше всего использовать приложение для отслеживания времени. Это поможет вам точно отслеживать и оценивать время, затрачиваемое на ваш проект.
Достоинства и недостатки- CPM лучше всего подходит для крупных проектов с большим количеством людей и ресурсов. Он помогает не только организовывать, но и отслеживать завершение проекта на каждом этапе его развития.
- С помощью CPM вы можете легко отслеживать узкие места проекта и переориентировать свои ресурсы для своевременного выполнения задач проекта.
- Если вы столкнетесь с длительной задержкой при выполнении какой-либо задачи вашего проекта, вам придется перенести срок всего проекта на более поздний срок.
Средний и крупный бизнес, реализующий амбициозные проекты.
Методология построения сетевых диаграммPERT
Метод анализа оценки программы (PERT) аналогичен методу CPM. Он также был разработан примерно в то же время. Эта методика была разработана для ВМС США в 1958 году и реализована в ракетной программе подводных лодок.
Для сети критического пути необходимо использовать детерминированный подход к оценке.Т.е. в цене за тысячу показов вы не можете учесть разницу во времени выполнения. В PERT вы создаете древовидные временные рамки для каждой задачи, чтобы лучше оценивать свои риски.
Сеть PERT признает, что будет временное отклонение из-за неопределенности, и поэтому использует вероятностный подход к оценке для каждого вида деятельности.
Для оценки активности используйте следующую формулу:
Ожидаемое время = (Оптимистичный + 4 x Наиболее вероятный + Пессимистичный) / 6
Вместе методы PERT и Critical Path оказали наибольшее влияние на сферу управления проектами со времен диаграммы Ганта.
Для успешного внедрения техники PERT необходимо выполнить следующие шаги.
1) Систематизируйте свои задачи
- Записывайте все задачи, которые вам нужно выполнить
- Определение шагов, которые необходимо предпринять для выполнения каждой задачи
2) Закажите свои задачи
- Анализируем ваши задачи, если вы упускаете какие-либо шаги
- Расстановка приоритетов по срокам и длине
3) Построить диаграмму
- Визуальное связывание задач на диаграмме, показывая переход между фазами
- Некоторые задачи можно выполнять параллельно, чтобы перейти к следующей
4) Распределите время для каждой задачи
- Оценка трех возможных сценариев для каждой задачи:
Оптимистическое время — наименьшее время, необходимое для выполнения задачи
Вероятное время — вы с высокой вероятностью выполните задачу за это время
Пессимистическое время — наибольшее время, необходимое для выполнения задачи. Выполни свою задачу
- Расчет ожидаемого времени (ET) по формуле
5) Расчет критического пути
- Определение самого длинного пути на диаграмме
- Расчет времени всех задач на самом длинном пути (СУММИРОВАТЬ)
Чтобы согласовать свои задачи и более точно оценить их время, вы можете использовать простые приемы, например, технику блокировки по времени.
Преимущества и недостатки
- С помощью PERT легко оценить и проанализировать время и ресурсы, необходимые для проекта.
- Вы можете управлять и отслеживать свою команду и должностных лиц, бюджет и другие ресурсы на любом этапе развития проекта.
- С помощью этого метода вы можете выполнить анализ «что, если», выделяя вероятности и минимизируя возможные потери.
- PERT требует хороших навыков оценки и анализа.В противном случае ваши расчеты могут быть субъективными и не отражать реальных затрат и времени на проект.
- Он ориентирован на время и менее гибок с бюджетом и техническими аспектами проекта.
- Этот метод требует тщательной подготовки и глубокого анализа документации и экспертных заключений перед планированием задач.
Кому подходит
Средние и крупные компании с устойчивой базой экспертов и ресурсов, которые реализуют крупные и сложные проекты.
PRINCE2 Методология управления проектами
PRojects IN Controlled Environments (PRINCE2) — одна из самых популярных методологий управления государственными проектами. Он был разработан в Великобритании и зарекомендовал себя в самых непредсказуемых условиях. Вот почему такие страны, как США, Германия, Испания, Южная Африка и другие, широко используют этот стиль в государственном управлении и для ведения прибыльного бизнеса.
PRINCE2 помогает эффективно организовать все этапы и мероприятия проекта.Он помогает организовать и подробно проанализировать каждый этап проекта и решить наиболее распространенные проблемы, с которыми сталкиваются предприятия при постановке сложных задач.
Prince2 ценит ожидания всех сторон, участвующих в проекте:
- Заказчик ожидает результатов и выгод от проекта.
- Подрядчик прогнозирует методологии выполнения проекта и возможные проблемы.
- И заказчик, и подрядчик должны предсказать мнений конечных пользователей о продукте в будущем.
Исходя из участия трех сторон, существует 7 основных принципов, которым необходимо следовать при выполнении проекта:
- Осуществимость . Есть ли причина продолжать проект (например, у вас есть заказчик и существенная выгода)?
- Учимся на ошибках . Составьте список неудачных решений, чтобы проанализировать их и избежать в будущих проектах.
- Четкое распределение ролей. Каждый участник проекта должен знать, что ему делать и за что он отвечает.Как руководитель проекта вы можете делегировать задачи. Все работы должны быть выполнены и представлены ответственными лицами.
- В стадии управления. Разделите проект на отдельные этапы, которые легко контролировать и оценивать.
- Ориентация на продукт. Оценивайте качество продукта на каждом этапе разработки проекта.
- Гибкость. Если процесс слишком длинный для выполнения, но не критичен, вам необходимо его упростить. Например, если на создание отчета по результатам уходит много времени.Можно ли сообщить устно или отправить быстрое электронное письмо?
Этапы PRINCE2
1) Создайте команду проекта
- В вашу команду должны входить: заказчик, исполнительный директор и менеджер по ориентации пользователей
- Составление краткого описания проекта и подхода к проекту
- После определения внутреннего документа перейти к следующему этапу
2) Инициировать проект
- Подробное описание дальнейших планов проекта, методов контроля и возможных рисков.
- Поскольку у вас есть представление обо всех процедурах и рабочем процессе по проекту, переходите к следующему этапу.
3) Директ проекта
- Изучение направления проекта и определение конечной даты проекта.
4) Контроль этапов проекта
- Руководитель проекта анализирует текущие работы
- PM вносит изменения по мере необходимости, обрабатывает возникающие проблемы и отчитывается по насущным вопросам перед командой проекта.
5) Управляйте своей командой
- Руководитель проекта делегирует задачи
- PM контролирует выполнение работ по графику
6) Управление этапами проекта
- Если проект столкнулся с серьезными проблемами, команда должна быть повторно оценена и обновлена.
- Ваша команда должна проанализировать опыт, а в проекте появились недочеты
7) Закройте проект
- Подготовить итоговый отчет
- Оценка качества продукции конечными потребителями
- Анализ мнений конечных пользователей о продукте.
Пояснение видео
Для удобного отслеживания работы каждого участника в проекте можно использовать простые инструменты управления проектами. Это поможет вам отслеживать проект и его участников.
Преимущества и недостатки
- В основе надежной методологии управления проектами. Понятное управление проектом и командой. Каждый участник проекта знает свои обязанности и ответственность.
- Менеджер проекта берет на себя роль советника, а не консультанта, и вмешивается в процесс только тогда, когда рабочий процесс начинает выходить из-под контроля.
- Команда проекта представляет интересы бизнеса, пользователей и подрядчиков, обеспечивая взвешенное решение.
- PRINCE2 создан для крупномасштабных проектов и обеспечивает успешную реализацию проекта, подтвержденную многими предприятиями и странами.
- PRINCE2 применяется для широкого спектра проектов, начиная от строительства и заканчивая ИТ-сферой.
- Не применимо к небольшим гибким проектам с нестабильными требованиями. Ведь команда не справится с количеством отчетов и отслеживанием ошибок.
- Новички в управлении проектами могут не установить все этапы и процессы PRINCE2 правильно и вовремя. Эта методика требует дополнительного обучения. Некоторые руководители проектов замечают, что PRINCE2 не включает управление конфликтами. Это означает, что им необходимо искать дополнительные практики по построению команды, чтобы включить их в управление проектом.
Кому подходит
Крупные компании или государственные проекты с большим количеством процессов и людей, вовлеченных в проект.
Традиционный подход к управлению проектамиТрадиционное управление проектами было впервые описано в 1950-х годах. Однако интуитивно это использовалось веками. Это базовый формат, на котором построены другие методологии.
Основные этапы традиционного управления проектами включают :1) Инициирование
- Постановка целей и задач проекта
- Оценка возможных рисков
2) Планирование
- Идентификация деятельности и ее продолжительность
- Мобилизация ресурсов
- Документирование разработки
3) Исполнение
- Создание проектной команды
- Организация и обмен информацией
- Выполнение проекта
- Оценка качества проекта
- Планирование работ
4) Мониторинг
- Контроль объема проекта, бюджета проекта и качества проекта
- Отчетность о проделанной работе
- Ревизия проекта
Строго говоря, это не методология, а набор приемов, таких как WBS (иерархическая структура работ), разделение проекта на фазы, диаграммы Ганта и т. Д.
Диаграмма Ганта визуализирует график проекта и показывает его продолжительность. Он может включать текущие цели и работу членов команды.
Достоинства и недостатки- Традиционная методология управления проектами может использоваться для широкого спектра проектов с разным размером, бюджетом и различным количеством членов команды.
- Традиционное управление проектами требует выполнения каждого шага по порядку.Но в сложных проектах с широким кругом задач это не всегда возможно или разумно. Поскольку они потребуют более частого контроля, менее проработанной документации и формирования команды еще до начала планирования.
Идеально подходит как для фрилансеров, так и для крупных компаний. Но одно предупреждение. Этот не для сложных проектов. Так что будьте проще.
Как выбрать методологию:
ЗаключениеМетодологии управления проектами необходимы для планирования проекта.Вы должны использовать их с самого начала при разработке своего проекта. Не делайте этого, и он может выйти из строя еще до того, как вы нажмете кнопку «Старт».
Успех означает выбор методологии, которая на 100% подходит вашему проекту. Но помните, что можно смешивать несколько методов вместе или применять их лучшие практики в своем проекте, не подписываясь только на один.
У каждого есть свои преимущества и недостатки. Примите их во внимание при выборе лучшей методологии для вашего проекта.
И последнее! Оценивая источники для вашего проекта, всегда помните, что время — самый ценный ваш актив.Используйте приложения для учета рабочего времени, чтобы управлять временем своего проекта и рабочим временем своей команды, и вы обнаружите, что управление проектами становится второстепенным.
Учет времени в управлении проектами с EverhourЕсли вы — девелоперская или консалтинговая фирма, вы всегда знаете своих клиентов о двух вещах, прежде чем подписывать какой-либо контракт — сколько это будет стоить и сколько времени это займет.
Задача для вас и вашей команды — оставаться в рамках согласованных оценок. Это означает, что все должно оставаться прозрачным на протяжении всего цикла разработки.
В Everhour мы помогаем вам отслеживать время и получать результаты независимо от того, какую методологию управления проектами вы выберете. Вы сможете:
- Отслеживайте свое рабочее время по сравнению с проектными часами
- Следите за эффективностью сотрудников в ваших проектах
- Смета затрат по каждому проекту
- Планируйте ресурсы для каждого проекта
- Создание отчетов по проекту
- Рассчитайте оплату сверхурочных для ваших сотрудников
- Подсчитать оплачиваемое и не подлежащее оплате рабочее время
- Составьте счета для ваших клиентов
- Интегрируйте учет рабочего времени в свои ежедневные приложения
20 лучших методологий управления проектами
При правильной методологии управления проектами офисы управления проектами (PMO) могут помочь своим организациям в улучшении бизнес-результатов, но для этого требуется нечто большее, чем признание приоритетов организации.Для большинства компаний недавние внешние факторы, такие как COVID-19, и сбои в отрасли, вызванные темпами цифровых изменений, изменили цели и приоритеты компании, что привело к необходимости переоценки того, могут ли применяемые методологии проектов эффективно и действенно достигать результатов. новые бизнес-цели при одновременном снижении рисков
При таком большом количестве различных — а в некоторых случаях частично совпадающих — подходах к управлению сложностями любого конкретного проекта, как вы можете узнать, какая методология управления проектами лучше всего? Здесь мы опишем наиболее популярные методологии управления проектами (PMM) на практике сегодня, сравнив их направленность и принципы.
Топ-20 методологий управления проектамиПри рассмотрении этих методологий управления проектами важно отметить, что не всегда существует единое решение для всех случаев, даже в пределах одной организации. В следующей таблице представлен краткий снимок основных 20 наиболее популярных методологий управления проектами с указанием преимуществ и недостатков каждой из них, более широко определенных ниже.
Методология | Фокус |
---|---|
Водопад | Линейный, последовательный подход к разработке |
Гибкий | Постоянное совершенствование и повышение качества |
Водопад и гибкий гибрид | Сочетает в себе лучшее из «водопада» для планирования и гибкости для выполнения |
Метод критического пути (CPM) | Максимизация проектной деятельности и поиск кратчайшего пути (временной шкалы) к задаче и успеху проекта |
Управление проектами критической цепочки (CCPM) | Оптимизация использования ресурсов |
Шесть сигм | Устранение отходов и улучшение процессов и прибыльности |
Схватка | Высокое качество |
Бережливое развитие (LD) | Сокращение отходов при максимальном увеличении производительности и увеличении стоимости для заинтересованных сторон |
Lean Six Sigma | Ориентация на клиента |
Скрамбан | Сокращение отходов, времени выполнения заказов и производственного цикла при предоставлении более качественных продуктов и услуг |
Канбан | Ориентация на клиента, способствующая постоянному сотрудничеству и непрерывному обучению |
Методология цепочки событий | Выявление, анализ и управление любыми потенциальными рисками как можно раньше в жизненном цикле проекта |
Экстремальное программирование (XP) | Повышение качества и скорости отклика программного обеспечения по мере изменения потребностей заинтересованных сторон |
Кристалл | Улучшение результатов проекта за счет сосредоточения усилий на людях в проектах |
Разработка на основе функций (FDD) | Устранение сложностей, которые могут возникнуть в крупных проектах, путем разработки быстрых, повторяемых процессов |
Метод разработки динамических систем (DSDM) | Согласование проектов со стратегическими целями компании |
Адаптивная разработка программного обеспечения (ASD) | Помощь командам стать более гибкими при работе с изменениями |
Быстрая разработка приложений (RAD) | Ориентация на вводимые пользователем данные на основе результатов тестирования и на то, насколько хорошо продукт работает по сравнению с намеченными целями |
Рациональный унифицированный процесс (RUP) | Упрощение разработки продукта при одновременном снижении рисков |
Спираль | Предоставление модели процессов с учетом рисков для более эффективной разработки продукта |
Waterfall
Waterfall признан традиционной последовательной методологией и на протяжении многих лет является основной методологией управления проектами.Он используется во многих отраслях, но чаще всего при разработке программного обеспечения. Он включает статические этапы (анализ требований, проектирование, тестирование, внедрение и сопровождение), которые выполняются в определенном линейном порядке.
Waterfall позволяет усилить контроль на каждой фазе. Он предлагает более формальную стадию планирования, которая может увеличить шансы на предварительное выполнение всех требований проекта. Это снижает потерю любой ключевой информации и требований на начальных этапах. Одним из недостатков является то, что водопад может быть очень негибким, если масштаб проекта изменится после того, как он уже запущен.
Agile
Agile использует совершенно другой подход к управлению проектами. Первоначально он был разработан для проектов, требующих значительной гибкости и скорости, и ориентирован на постоянное совершенствование для предоставления более качественных решений. Для этого Agile состоит из коротких циклов доставки, также называемых «спринтами». Agile может лучше всего подходить для проектов, требующих меньшего контроля и большего взаимодействия в режиме реального времени в рамках самомотивированной команды.
Как методология управления проектами, гибкая разработка является высоко интерактивной, что позволяет быстро вносить изменения в течение всего проекта.Он обычно используется в проектах разработки программного обеспечения в значительной степени потому, что упрощает быстрое выявление проблем и внесение изменений на ранних этапах процесса разработки, вместо того, чтобы ждать завершения тестирования. Agile предлагает повторяемые процессы, снижает риск, обеспечивает немедленную обратную связь, обеспечивает быстрое выполнение работ и снижает сложность. Недостатки Agile включают большее количество времени, необходимое заинтересованным сторонам при прохождении каждой итерации, и потенциально меньший объем документации по сравнению с водопадом.
Водопад и гибкий гибрид
В то время как многие команды будут отдавать предпочтение либо водопаду, либо гибкости, преимущества обоих подходов могут создать аргумент в пользу решения с гибридной методологией управления проектами, в котором этап планирования и требований выполняется в рамках каскадного подхода и этапы проектирования, разработки, внедрения и оценки следуют гибкой методологии.
Метод критического пути (CPM)
CPM — это пошаговая методология, используемая для проектов с взаимозависимыми действиями.Он ориентирован на максимизацию деятельности по проекту и поиск кратчайшего пути (временной шкалы) к задаче и успеху проекта с использованием иерархической структуры работ (WBS) и временной шкалы для завершения, а также зависимостей, этапов и результатов. Он выделяет критические и некритические действия, вычисляя «наибольшее» (на критическом пути) и «кратчайшее» (плавающее) время для выполнения задач, чтобы определить, какие действия являются критическими, а какие нет. Одним из недостатков CPM является то, что некоторые команды не всегда могут распознать критический путь, особенно в более крупных и сложных проектах.
Управление проектами критической цепочки (CCPM)
CCPM отличается от CPM тем, что фокусируется на использовании ресурсов в рамках проекта, а не на действиях проекта. Для решения потенциальных проблем с ресурсами встроены буферы, чтобы гарантировать своевременное выполнение проектов и безопасность. Это требует, чтобы все были в курсе критической цепочки и усилий, чтобы заручиться поддержкой этой методологии со стороны всех заинтересованных сторон.
Six Sigma
Six Sigma изначально была разработана Motorola для устранения потерь и улучшения процессов и прибылей.Он основан на данных и состоит из трех ключевых компонентов:
- DMAIC: определение, измерение, анализ, улучшение и управление
- DMADV: определение, измерение, анализ, проектирование и проверка
- DFSS: Design for Six Sigma, который может включать в себя предыдущие опции, а также другие, такие как IDOV (идентификация, проектирование, оптимизация и проверка).
Шесть сигм иногда обсуждают как методологию в сообществе управления проектами. Эта методология добавляет некоторую потенциальную жесткость, которая может подавить творчество или задержать выполнение проекта.
Scrum
Названный в честь игрового процесса в регби, Scrum является частью гибкой структуры и также является интерактивным по своей природе. «Скрамы» или «30-дневные спринты» используются для определения приоритетных задач. Мастер Scrum используется для облегчения вместо менеджера проекта. Небольшие команды могут быть собраны, чтобы сосредоточиться на конкретных задачах независимо, а затем встретиться с мастером Scrum, чтобы оценить прогресс или результаты и изменить приоритеты невыполненных задач. У более крупных команд могут возникнуть проблемы с адаптацией к Scrum, и он может потерпеть неудачу или стать предметом сползания, особенно если все члены команды не полностью вовлечены и привержены.Чтобы избежать дублирования и путаницы, необходимо четко определить роли.
Lean development (LD)
Первоначально разработанный Toyota, Lean был разработан, чтобы сосредоточиться на сокращении отходов при максимальном увеличении производительности и увеличении ценности для заинтересованных сторон. Хотя бережливое производство зародилось в обрабатывающей промышленности, сегодня оно применяется в различных отраслях, поскольку его направленность не является отраслевой. Lean следует семи ключевым принципам: сокращать отходы, повышать качество, делиться знаниями с другими, оставаться в состоянии непрерывного улучшения, более быстрое выполнение работ, устранение разрозненности и поддержание атмосферы уважения.Lean полагается на полную приверженность заинтересованных сторон, что может быть проблематичным, если заинтересованные стороны не хотят меняться или боятся изменений. Это может привести к несоответствиям в доставке.
Lean Six Sigma
Этот гибрид бережливого производства и шести сигм ориентирован на клиента с целью повышения эффективности и результативности бизнеса за счет определения и понимания того, как выполняется работа (поток создания ценности). Lean Six Sigma стремится улучшить процессы, удалить ненужные отходы и уменьшить количество дефектов, но для компаний это может быть дорогостоящим и затратным по времени.
Канбан
Канбан ориентирован на постоянное сотрудничество и способствует созданию атмосферы непрерывного обучения и совершенствования. Он использует наглядные доски и карточки, чтобы помочь командам увидеть выполненные, выполняемые и невыполненные задачи. Все действия основаны на способности визуализировать ежедневные задачи, тщательно сбалансировать незавершенную работу и управлять невыполненными работами. Однако перегруженные или устаревшие платы могут создать путаницу или привести к отказу.
Scrumban
Scrumban предоставляет группам разработки продуктов и поддержки лучшие функции Scrum и Kanban.Комбинируя вытягивающую систему Канбана и приоритизацию невыполненных работ и короткие циклы Scrum, команды могут не только быстро и эффективно выполнять работу, но и улучшать процессы, обнаруживая слабые места. Используя преимущества обеих структур, команды в конечном итоге сокращают отходы, сокращают время выполнения заказа, время выполнения работ и предоставляют более качественные продукты и услуги. Успех Scrumban, ориентированного на более крупные команды, зависит от стабильного предложения продуктов или компонентов, а командные роли должны быть четко определены.
Методология цепочки событий (ECM)
В качестве дополнительной опции к CPM или CCPM, ECM ориентирован на выявление, анализ и управление любыми потенциальными рисками в начале проекта. Цель состоит в том, чтобы определить вероятность того, что риск станет реальностью, когда он может случиться и какое влияние может оказать на проект. ECM руководствуется шестью основными принципами: определение цепочки событий, определение их сроков и статуса, определение критических событий, составление карты или диаграмма цепочки событий, мониторинг производительности цепочки событий и количественная оценка воздействия.Некоторые команды могут не осознавать, что событие может вызвать возможность, а не просто потенциальную проблему.
Экстремальное программирование (XP)
Эта методология предназначена для улучшения качества и функциональности программного обеспечения по мере изменения потребностей заинтересованных сторон. XP использует короткие циклы разработки и требует постоянного сотрудничества из-за частых выпусков. Преимущества: XP может творить чудеса с производительностью для проектной группы, которой требуется высокий уровень производства. Команды держатся в тонусе и находят опыт менее целенаправленным и структурированным.
Crystal
Как гибкий подход, Crystal был разработан IBM как способ улучшить результаты проекта за счет сосредоточения усилий на человеческой стороне проекта. В частности, основное внимание уделяется навыкам, способностям и сотрудничеству членов команды. Кристалл основан на двух основных убеждениях.
- Команды, вероятно, определят и разработают улучшения рабочего процесса
- Проекты уникальны, поэтому более вероятно, что проектные группы лучше всего подходят для определения того, как выполнять работу более эффективно.
Crystal может не подходить для некоторых удаленных команд из-за необходимости тесного и частого общения и мозгового штурма.
Разработка на основе функций (FDD)
Разработанный для крупномасштабных проектов, но применимый к проектам любого размера, FDD помогает устранить некоторые сложности, которые могут возникнуть в крупных проектах, путем разработки быстрых, повторяемых процессов, которые могут быть выполнены в меньших масштабах. промежутки времени различными командами в организации. Этот подход следует некоторым ключевым процессам, которые включают разработку общей модели, составление списка функций, планирование на основе каждой из идентифицированных функций, проектирование функций и построение функций.FDD может не работать лучше всего для небольших команд, и ограниченная письменная документация заинтересованных сторон может стать проблемой.
Метод динамической разработки систем (DSDM)
Разработанный как способ согласования со стратегическими целями компании, DSDM ориентирован на предоставление проверенных бизнес-преимуществ. Этот подход основан на восьми ключевых принципах:
- Необходимость сосредоточиться на бизнес-требованиях
- Своевременная доставка
- Сотрудничество необходимо
- Качество как главный приоритет
- Построение поэтапно на твердых опорах
- Использование итеративного подхода к разработке
- Четкое и постоянное общение
- Сохранение контроля
Дорогостоящая реализация с использованием DSDM делает его менее подходящим для малых предприятий.
Адаптивная разработка программного обеспечения (ASD)
Этот подход помогает командам стать более гибкими при работе с изменениями. Командам рекомендуется оставаться в состоянии непрерывного обучения, чтобы улучшить развитие. РАС состоит из трех этапов: предположений, сотрудничества и обучения. ASD требует значительных ресурсов и более высоких затрат, что делает его более подходящим для крупных организаций.
Быстрая разработка приложений (RAD)
9 самых популярных методологий управления проектами, которые стали проще
Как выбрать правильную методологию управления проектами
Выбор правильной методологии важен, потому что она определяет то, как мы работаем.Он предоставляет структуры, которые могут вести нас к успеху или неудаче проекта. А поскольку вы уже знаете, что не существует универсального метода, подходящего для всех типов, размеров и отраслей бизнеса, важно, чтобы вы потратили некоторое время и усилия на выбор правильной методологии управления проектами для вашего контекста.
Вот несколько шагов, чтобы решить, какую методологию управления проектами использовать в вашем проекте:
1. Рассмотрите факторы вашего проекта по их простоте или сложности.
Это включает в себя сам проект, а также клиента, наши доступные ресурсы и ограничения проекта (включая аппетит к изменениям и риску), сроки, инструменты и людей. Перечислите эти факторы и обозначьте их в соответствии с их простотой или сложностью.
2. Определите жесткость или гибкость вашей рабочей среды.
Если вы работаете в динамичной среде, где есть стремление к развитию и изменениям, вам может подойти методология Agile.Если вы работаете в рамках очень жестких требований, сроков и бюджета, вам может быть лучше использовать водопадный подход. Наряду с рассмотрением вашей гибкости обратите внимание на свои ограничения и риски. Как вы можете внедрить процессы, которые минимизируют ваши ключевые риски и помогают вашим командам точно вписать свои проекты в рамки ваших организационных ограничений?
Независимо от того, занимаетесь ли вы более гибкой стороной (представьте себе проворную дизайн-студию с небольшой командой, где большинство членов команды носят несколько головных уборов) или более жесткой стороной (подумайте о внутреннем агентстве, где деятельность должна соответствовать большому количеству внутренние правила) сейчас также хорошее время, чтобы спросить себя, должна ли ваша организация оставаться такой же жесткой или гибкой.Вы можете выбрать методологию или гибридную методологию, которая подтолкнет вашу организацию в том направлении, в котором вы хотите двигаться, — просто будьте осторожны, выбирая методы, которые действительно реалистичны для реализации вашими командами в том виде, в каком они есть в настоящее время.
3. Подумайте, что приносит наибольшую пользу.
Спросите, что приносит наибольшую пользу клиенту (или заинтересованной стороне, или конечному пользователю). Составьте список их потребностей и используйте его, чтобы выбрать способ работы, который лучше всего отвечает этим потребностям.
Например, если ваши клиенты обычно делают постоянные запросы и ожидают постоянных обновлений и изменений, то итеративная методология с короткими циклами поможет клиенту почувствовать, что они получают большую ценность.Использование этой методологии поможет вам повысить ценность и поддерживать позитивные отношения с клиентами.
4. Используйте свои организационные цели.
Используйте цели или задачи проекта, которые вы уже создали как команда или организация, чтобы руководствоваться при выборе методологии проекта. Ясно, что ваши методы должны быть средством достижения ваших целей — лучший метод — это тот, который направляет вас непосредственно к вашим стратегическим целям с наибольшей выгодой и наименьшим негативным воздействием.
5. Перечислите свои организационные и командные ценности.
Наконец, что важно, глубоко погрузитесь в свои ценности. В конце концов, методики разрабатываются людьми — людьми с привычками, мнениями и ценностями. Вместо того, чтобы использовать трендовую методологию и бросать ее своим людям, используйте способы их мышления, взаимоотношений и работы, чтобы разработать методологию, которая будет вам естественна.
Ценности вашей организации и команды могут придать форму действительно устойчивой методологии, которая в меньшей степени является теоретическим стандартом (которого вы никогда не встретите на самом деле), а в большей степени способом систематического воплощения жизненных, дыхательных процессов, которые легче поддерживать в долгосрочной перспективе.
Помните, что нет методологии лучше, чем другие. Все зависит от того, насколько хорошо он соответствует целям и ценностям организации, от ограничений, с которыми приходится иметь дело команде проекта, потребностей заинтересованных сторон, связанных с этим рисков, а также от размера, стоимости и сложности проекта.
Какая лучшая методология для цифровых агентств?
Короткий ответ?
Это зависит от обстоятельств. Нет правильного или неправильного. Это зависит от вашего клиента, вашей команды и проекта. Вот подробное описание некоторых распространенных методологий и того, какие преимущества и проблемы они приносят.
У меня есть целая статья, посвященная дебатам Agile vs. Waterfall, но ниже я резюмирую несколько основных моментов, которые следует учитывать при размышлениях о лучшем подходе для цифровых агентств.
Плюсы и минусы Waterfall в цифровых агентствах
Практически всегда, когда в агентстве поднимают голову над парапетом и предполагают, что метод Waterfall может быть хорошим подходом для проекта, равносильно рисованию большой мишени на себе. Waterfall — это то, что не хочет слышать ни один клиент или команда — мы все хотим, чтобы нас считали передовыми, а Waterfall определенно не крутой.
Мало того, что это не круто, но Waterfall сложен, потому что требует тщательного предварительного планирования проекта до того, как будет выполнена какая-либо работа, создающая ценность. Иногда планирование необходимо, потому что клиенты должны утверждать стоимость, сроки и объем. Но клиенты обычно не хотят платить за планирование, и даже в тех случаях, когда агентства успешно переводят клиентов с Waterfall на более гибкие контракты, что произойдет, если ваше планирование не на должном уровне?
По правде говоря, в цифровом мире нам постоянно сложно делать точные оценки.Обычно мы работаем с новыми технологиями, над неопределенными проектами. Часто, как только вы начинаете свой проект, ваш план уже устарел. Таким образом, хотя клиентам нравится предсказуемость результатов, бюджета и сроков, водопадный подход по своей сути негибкий.
Так что насчет вкуса Agile?
Плюсы и минусы Agile в цифровых агентствах
Между агентствами и клиентами, как правило, довольно плавное понимание Agile-метода.
Agile широко хвалят за то, что он «не является водопадом», и его часто неправильно понимают как «делать больше, с меньшими затратами, быстрее и дешевле, чем когда-либо прежде».
Почему бы вам этого не захотеть?
Клиентам, как правило, нравится идея Agile из-за ее очевидной гибкости для поворота проекта, предоставляя им больше возможностей постоянно менять свое мнение на протяжении всего проекта.
Они часто думают, что это означает, что они выполнят больше работы за меньшие деньги или что им никогда не придется принимать окончательное решение по чему-либо, потому что они могут изменить свое мнение вплоть до последней минуты.
Отчасти это правда, но не вся история.По правде говоря, Agile может быть лучше, но Agile не бывает дешевым и легким.
Уловка и остальная часть истории в том, что такой уровень гибкости стоит дорого. Да, вы можете передумать, но это отнимает время, а время стоит денег.
Другая проблема заключается в том, что для того, чтобы быть успешными и по-настоящему гибкими, клиенты должны быть доступны и иметь возможность принимать решения (что редко бывает в иерархических организациях и организациях, ориентированных на совет директоров). Им необходимо оперативно предоставлять обратную связь и расставлять приоритеты, чтобы проект продолжал развиваться, что часто бывает очень непросто.
Основные факты о лучшей методологии агентства
По сути, агентства хотят получать деньги за свою работу, а клиенты хотят, чтобы агентства делали свою работу наилучшим образом, правильно, с первого раза. Должна быть какая-то золотая середина.
Во многом все сводится к доверию. Действительно ли клиенты верят, что агентство приносит пользу, и готовы ли они платить за неудачи на пути к успеху?
Делать больше с меньшими затратами и устранять потери — отличный принцип бережливого производства, но проблема с этим подходом заключается в том, чтобы общаться с клиентами для поддержания отношений.Клиенты могут стать причиной больших потерь, и без по-настоящему встроенного, доверчивого клиента, который дает реальную власть принимать решения, никакая методология Agile-проекта не может исправить этот недостаток в отношениях.
Но там, где есть доверие и желание экспериментировать, происходит волшебство. От наших клиентов требуется зрелость, чтобы понять, что мы не можем точно определить, что и когда они получат, но, обладая некоторым здоровым доверием, мы будем работать вместе, чтобы делать все, что в наших силах.
Обзоры 9 наиболее популярных методологий управления проектами
Ниже я составил список методологий управления проектами, в котором описаны наиболее популярные подходы к управлению проектами.В каждом разделе есть ссылки, чтобы узнать больше о каждом подходе.
Сети проектов
Сеть проекта (или сеть деятельности проекта ) представляет собой графическое изображение (очень похожее на блок-схему), которое показывает последовательность, в которой должны быть выполнены оконечные элементы проекта . Каждый конечный элемент представляет действие , которое относится к рабочему пакету на самом низком уровне иерархической структуры работы (WBS).Однако, в то время как WBS не пытается идентифицировать последовательность событий или продолжительность какой-либо деятельности, сеть проекта стремится идентифицировать последовательность, в которой происходят действия, и другие действия (если таковые имеются), от которых зависит конкретное действие. Существует ряд методов, используемых для создания сети проектной деятельности. Некоторые из наиболее часто используемых методов включают диаграммы Ганта , Управление критическим путем (CPM) и метод оценки и анализа проекта (PERT).В некоторых методах каждый конечный элемент (или действие) представлен узлом на графе, в то время как в других он представлен ребром (линией, соединяющей два узла). Каждый оконечный элемент должен находиться только на одном пути в сети. Пример сетевой диаграммы деятельности проекта показан ниже.
Общая сетевая диаграмма проектной деятельности
Сетевая диаграмма действий помогает определить наиболее логичную последовательность событий для проекта и обеспечивает основу для реалистичного расписания проекта.Это позволит вам рассчитать общее количество времени, необходимого для проекта, определить порядок, в котором задачи должны быть выполнены, и выделить те задачи, которые являются критическими для графика проекта. Когда WBS будет завершен, у вас будет список действий на различных уровнях декомпозиции, которые должны быть выполнены для достижения целей проекта. Теперь вы можете определить зависимости задач и продолжительность каждой задачи, чтобы можно было составить расписание. Теперь доступно программное обеспечение для управления проектами, которое будет выполнять планирование за вас, рассчитывать общее время, необходимое для завершения проекта, и определять критический путь графика .Все, что вам нужно сделать, это ввести продолжительность каждой задачи и определить любые зависимости задач. Программа будет создавать диаграммы сетевой активности и диаграммы Ганта на основе предоставленной вами информации.
Хотя в наши дни программное обеспечение для управления проектами легко доступно, полезно понимать процесс создания сетевой диаграммы активности. Следующие шаги можно использовать для выполнения процесса вручную:
- Составьте список всех задач, которые необходимо выполнить (это рабочие пакеты, определенные в результате создания иерархической структуры работ), и напишите название каждой задачи на небольшой карточке или бумаге (предположим, что мы будет использовать заметки Post-it , которые идеально подходят для этой цели).
- Решите, какая задача должна быть выполнена в первую очередь (назовите ее Задача 1 ), и поместите ее на левой стороне большой рабочей поверхности (для целей этого упражнения я предполагаю, что мы будем использовать доску ) .
- Найдите любые другие задачи, которые можно выполнять одновременно, и разместите их над или под Задачей 1 на доске. Определите эти задачи (если есть) как Задача 2 , Задача 3 . . . и так далее.
- Решите, какой будет следующая задача ( Задача № ), и поместите ее справа от Задачи 1 . Опять же, найдите любые другие задачи, которые можно выполнять одновременно, и поместите их выше или ниже Задача № . Продолжайте нумеровать каждую задачу, помещая ее на доску.
- Повторяйте процесс до тех пор, пока все задачи не будут расположены последовательно и параллельно, и убедитесь, что каждой задаче присвоен номер.
- Нарисуйте стрелку от каждой задачи к следующей за ней.
- Оцените время, необходимое для каждой задачи, и запишите его на стикер (используйте одну и ту же единицу времени для каждой задачи, то есть часы, дни или недели).
- Найдите критический путь. Это путь связанных действий, который, если сложить длительность всех задач в нем, потребует больше всего времени для завершения.
Критический путь сообщает вам, сколько времени потребуется для завершения всего проекта (на основе текущей информации).Следовательно, задачи на критическом пути должны контролироваться более внимательно, чем задачи, не относящиеся к критическому пути, потому что любые задержки в одной из этих задач вызовут увеличение длины критического пути (другими словами, время, необходимое для завершения проект будет увеличиваться). Одним из способов сокращения общей продолжительности проекта, конечно же, является ускорение выполнения одной или нескольких задач на критическом пути — если это возможно. Для других путей в сети каждая задача будет иметь некоторый резерв в том смысле, что она может быть отложена до определенного момента, потому что она не находится на критическом пути.Однако имейте в виду, что если одна или несколько задач на других путях будут значительно задержаны, затронутый путь может приобрести общую длительность, превышающую продолжительность критического пути. Следовательно, он по определению станет новым критическим путем.
Диаграммы Ганта, PERT и CPM — все это полезные методы, которые предоставляют информацию о графиках проекта в графическом виде, но они не говорят вам всего. Например, они не сообщают вам, какие ресурсы требуются для выполнения конкретной задачи.Диаграммы сети активности — это снимки состояния проекта в определенное время. Их необходимо будет обновить по мере изменения обстоятельств. Если задача занимает больше времени, чем ожидалось, это может повлиять на общий график проекта. То же самое и с задачами, которые выполняются досрочно. Влияние на ресурсы не будет очевидным при просмотре одной только сетевой диаграммы, и необходимо использовать другие инструменты и методы, чтобы определить, где будут возникать пики и спады с точки зрения спроса на критически важные ресурсы проекта.
3 бесплатных инструмента для создания сетевых диаграмм
Управление проектами хорошо умеет делать сложное простым или, по крайней мере, управляемым. Конечно, существует множество различных способов достижения этой цели, многие из которых используются в течение жизненного цикла проекта.
Сетевая диаграмма проекта — это один из таких инструментов, который помогает упростить сложный план проекта, позволяя руководителю проекта увидеть общую картину проекта. Важно иметь обзор любого проекта, видеть, когда он начинается и когда заканчивается, а также быстро отмечать все действия и то, как они работают вместе.Методы планирования и составления графиков проектов, такие как метод критического пути (CPM) и метод оценки и анализа программ (PERT), используют сетевые диаграммы для достижения такой ясности для своих проектов.
Но некоторые могут избегать проектирования сетевых диаграмм, думая о них как о тех плотных схемах, которые изображают узлы и соединения в компьютерной сети. Это было бы ошибкой. Руководителям проектов нужны инструменты, и сетевая диаграмма проекта — отличная.
Что такое сетевая диаграмма в управлении проектами?
Сетевая диаграмма проекта — это визуальное представление рабочего процесса проекта.Сетевая диаграмма — это диаграмма, заполненная полями, в которых указаны задачи и обязанности, а затем стрелки, отображающие расписание и последовательность, в которой работа должна быть завершена. Таким образом, сетевая диаграмма проекта — это способ визуально проследить за продвижением каждой фазы жизненного цикла проекта до его завершения.
Руководители проектов используют сетевую диаграмму для отслеживания проекта, позволяя им видеть прогресс каждого действия. Затем они могут поделиться своим статусом с остальной частью команды управления проектом.Это особенно полезно для тех, кто лучше понимает информацию, передаваемую визуально. Для этих членов команды сетевые диаграммы проекта помогут в выполнении их задач и увеличат продуктивность проекта.
Другой аспект сетевой диаграммы состоит в том, что она буквально иллюстрирует объем проекта. Это связано с тем, что на сетевой диаграмме проекта собраны все действия, этапы и результаты, определенные в структурной декомпозиции работ проекта. Метод критического пути (CPM) и метод оценки и анализа программ (PERT) являются хорошими примерами того, как использовать сетевые диаграммы в управлении проектами.Руководители проектов используют эти методы для оценки продолжительности проекта и создания графика проекта.
Типы сетевых схем проекта: ADM и PDM
Сетевые диаграммы расписания проекта можно разделить на два типа: метод стрелочной диаграммы (ADM) и метод диаграммы приоритета (PDM).
Как и ожидалось, метод стрелочной диаграммы или действие на сетевой диаграмме со стрелками использует стрелки для представления деятельности проекта, причем конец стрелки является его началом, а точка — концом.Длина стрелки — это продолжительность действия. Стрелки соединяют узлы или прямоугольники, которые последовательно являются символами вехи начала и конца деятельности.
В методе диаграммы приоритета или активности на сетевой диаграмме узла каждый узел или блок является действием. Есть стрелки, но в данном случае они обозначают взаимосвязь между действиями. Это отношение может быть одним из следующих:
- От конца до начала: Это означает, что действие не может начаться, пока не завершится его предшественник.
- От начала до начала: Используйте это, когда два действия могут начаться одновременно.
- От конца до конца: Используйте это, когда действия должны завершаться вместе.
- От начала до конца: Используйте это, когда одно действие не может завершиться, пока не начнется другое.
Преимущества и ограничения сетевых схем проекта
Теперь, когда вы знаете, что такое сетевая диаграмма расписания проекта, давайте более критически рассмотрим плюсы и минусы.
Плюсы проектных сетевых схем
С точки зрения профессионалов, сетевые диаграммы — это благо при планировании проекта. Методика собирает все необходимые задачи, которые нужны для успешного завершения проекта. Это внимание к деталям перед запуском проекта поможет определить действия критического пути и то, где может существовать float или время, в течение которого задача может быть отложена.
Создание сетевой диаграммы проекта также является отличным способом составить график проекта, а размещение всех мероприятий на одной диаграмме упрощает заказ материальных ресурсов и оборудования, необходимых для их выполнения.Это описание ресурсов поможет с потоком денежных средств и подбором нужной команды.
Кроме того, наличие задач на сетевой диаграмме проекта и возможность видеть, где они зависят от других действий, могут помочь решить проблемы по мере их возникновения в ходе проекта.
Минусы сетевых схем проекта
Есть и ограничения. Создание сетевой диаграммы проекта требует времени и денег. Кроме того, схема сети, в зависимости от проекта, может быть слишком сложной и трудноразличимой визуально.Это противоречит одной из его основных целей.
Конечно, при его создании могут быть ошибки или другие неизвестные факторы, которые могут повлиять на это за пределами собранных данных; все это может ввести в заблуждение и потенциально нанести ущерб вашему проекту. Использование программного обеспечения для построения сетевых диаграмм не гарантирует, что сетевая диаграмма точно представляет график вашего проекта, если последовательности действий не обозначены правильно.
Некоторые не верят в необходимость сетевой диаграммы, в то, что существуют другие инструменты, которые охватывают те же вопросы.Например, есть диаграмма Ганта, которая также является графическим представлением временной шкалы проекта с задачами, продолжительностью и зависимостями. Но диаграмма Ганта также может распределять ресурсы, обновлять статус проекта и отслеживать задачи и время.
Онлайн-диаграмма Гантана сайте ProjectManager.com. Рекомендации по построению сетевых диаграмм проекта
.Чтобы воспользоваться преимуществами и избежать недостатков сетевых диаграмм проекта, полезно знать, что работает. Например, сетевая диаграмма — это визуальный язык, и, как любой коммуникативный метод, он требует использования общих и понятных всем символов.
Как нарисовать сетевую диаграмму в управлении проектами?
Сначала вам нужно понять хронологический порядок, в котором должны выполняться действия, и определить начальную и конечную точку сетевой диаграммы. При построении диаграммы используйте стрелки, идущие слева направо. Так люди читают на Западе, и диаграмма должна интуитивно следовать этому образцу.
Вам нужно, чтобы диаграмма была как можно более четкой и легко читаемой. Это означает, что не загромождайте страницу пересекающимися стрелками.Фактически, любые стрелки, которые вы используете для указания направления, должны быть прямыми. Но продолжительность стрелки не должна определяться ее длиной.
Сделайте приблизительный набросок диаграммы
На более простом уровне, начните с сетевой диаграммы вашего проекта, начертил ее сначала. Затем вы можете стирать и перемещать элементы, пока не создадите наиболее эффективную схему сети.
Как только вы закончите дизайн, подумайте о шрифте. Различные шрифты могут выделить части диаграммы и облегчить ее чтение.Легенда или ключ в углу также помогут читателю понять.
Определите действия для вашего проекта Сетевая диаграмма
Еще один совет, прежде чем вы даже приложите карандаш к бумаге, — это организовать свои задачи. Вы же не хотите начинать диаграмму и понимать, что упустили некоторые важные действия. Также существуют зависимости задач, при которых задачи не могут начинаться или завершаться, пока не начнется или не закончится другое действие. Определите их тоже и разбейте проект на фазы. После этого вы готовы приступить к созданию сетевой диаграммы проекта.
Бесплатные инструменты для построения сетевых диаграмм
Есть только один способ узнать, подходит ли вам сетевая диаграмма проекта: попробовать. К счастью, есть много бесплатных инструментов для создания сетевой диаграммы в Интернете. Мы выбрали три наших фаворита, чтобы вы могли надеть их и покататься.
Google Draw
У Google есть инструмент для всего, что вы делаете, поэтому само собой разумеется, что у них есть инструмент для сетевых диаграмм. Google Draw полностью бесплатен (вам даже не нужно вводить кредитную карту).Он может помочь вам создавать блок-схемы, диаграммы UML, отношения сущностей, макеты и, конечно же, сетевые диаграммы проекта.
Данные хранятся на Google Диске, но также могут хранить данные в Dropbox и OneDrive. Google draw может импортировать файлы из множества различных форматов, имеет 27 языков, и им легко делиться. Это быстро и поддерживает совместную работу в режиме реального времени при подключении к учетной записи Google.
С другой стороны, не так много шаблонов и форм на выбор. Если у вас нет опыта в дизайне, вам может быть непросто научиться чему-то новому.Эта платформа лучше всего подходит, если вы хотите сотрудничать с другими функциями Google и только время от времени составлять сетевые диаграммы.
Диаметр
Dia — это инструмент для построения сетевых диаграмм с открытым исходным кодом, который можно использовать для создания сетевых диаграмм. Его довольно легко изучить, и он может создавать базовые сетевые диаграммы расписания проекта. Dia сохраняет документы в формате XML, которые автоматически уменьшаются для экономии места. Он доступен для Linux, Mac и Windows.
Dia является бесплатным и представляет собой хороший вариант начального уровня для людей, желающих познакомиться с созданием сетевых диаграмм, а также диаграмм UML и блок-схем.
Программное обеспечение имеет удобный пользовательский интерфейс, который помогает пользователям, а также его легко и быстро установить из-за небольшого размера файла. Однако программное обеспечение не имеет визуальной привлекательности. Это слишком просто, и некоторые критиковали его как уродливое из-за его черно-белого дизайна, который можно улучшить с помощью цвета.
Gliffy
Хотя Gliffy бесплатен, бесплатная версия очень ограничена. Если вам это нравится, вы, вероятно, захотите заплатить за полную версию с оплатой подписки.Стоимость является многоуровневой: 14,85 долларов США каждые три месяца для одного пользователя, который может создавать 200 диаграмм, но ни одна из них не интегрируется с Google Диском. Бизнес-аккаунт для одного пользователя стоит 29,85 доллара на три месяца, включая неограниченное количество диаграмм, но он по-прежнему не интегрируется с Google Диском. Для этого вам понадобится пакет бизнес-команды, который стоит 59,88 доллара в год. Тот факт, что диаграммы просты в создании и совместной работе, вероятно, поможет при переходе от бесплатного к платному.
Gliffy — это веб-приложение, которое не подходит для создания дополнительных технических схем.Однако это бесплатное программное обеспечение для построения сетевых диаграмм, которое является хорошим первым шагом в построении сетевых диаграмм.
Диаграммыоживают с ProjectManager.com
Сетевая диаграмма проекта — хорошее начало, но для контроля фазы выполнения вам понадобится нечто большее, чем диаграмма. Лучше выполнять свой проект с помощью инструмента, предлагающего полный спектр услуг. ProjectManager.com — это облачное программное обеспечение для управления проектами, которое выводит рабочий процесс на новый уровень.
ProjectManager.com предоставляет вам инструменты для превращения сетевой диаграммы вашего проекта в полноценный проект с диаграммами Ганта, которые позволяют вам определять критический путь, назначать задачи членам вашей команды и добавлять продолжительность и сроки выполнения.Вы можете избежать узких мест в рабочем процессе, связав задачи, которые зависят друг от друга. Разбивайте проекты на этапы, чтобы в дальнейшем сделать большие этапы проекта более удобоваримыми.
Планируйте целые проекты с помощью онлайн-диаграммы Ганта ProjectManager.com — Попробовать бесплатноЕсть даже инструмент ресурсов, который показывает, какие члены команды задействованы в недостаточной или избыточной мере, чтобы обеспечить сбалансированную рабочую нагрузку. Это обеспечивает бесперебойную работу и предотвращает дорогостоящее перераспределение ресурсов или несоблюдение сроков.
Визуализируйте рабочие процессы с помощью динамических плат
Рабочий процесс дополнительно управляется с помощью представления проекта канбан. Просто переключитесь на вид доски, и все на вашем графике Ганта теперь отобразится на доске канбан. Рабочий процесс представлен настраиваемыми столбцами, которые указывают, где находится каждая задача в проекте.
Создавайте визуальные рабочие процессы с помощью наших совместных канбан-досок.Каждая задача представляет собой карточку, которую можно перетаскивать из столбца в столбец, что обеспечивает прозрачность процесса и позволяет группам сосредоточиться только на задачах, которые они могут выполнить.Когда члены команды обновляют свой статус, эти данные мгновенно отражаются во всем программном обеспечении. Автоматические уведомления по электронной почте информируют команды о внесении изменений или приближении сроков.
ProjectManager.com предоставляет менеджерам проектов и командам инструменты, необходимые для управления рабочим процессом, знания своих обязанностей и соблюдения графика.
(Этот пост был обновлен в сентябре 2020 г.)
После того, как вы познакомились с бесплатными приложениями для построения схем сети и почувствовали, как они работают, взгляните на ProjectManager.com, облачное программное обеспечение для управления проектами. Наша онлайн-диаграмма Ганта делает многое из того, что может делать сетевая диаграмма, но также всегда для совместной работы в режиме реального времени, создания отчетов о состоянии, и ее легко изменить по мере изменения проекта. Попробуйте бесплатную 30-дневную пробную версию.
Как использовать сетевые диаграммы в управлении проектами
Этот пост был первоначально опубликован 6 сентября 2019 г. и последний раз обновлялся 25 июля 2020 г.
Что касается проектов, то чем они крупнее, тем сложнее становится процесс управления.Есть задачи, которые нужно спланировать, графики, которые нужно организовать, и зависимости, которыми нужно манипулировать. Короче говоря, горстка. Здесь пригодится подход к управлению проектами сетевой диаграммы.
Когда думают о сетевых диаграммах, большинство людей думают о чем-то, что изображает телекоммуникационную сеть. Но вместо того, чтобы иллюстрировать физическую сеть серверов и брандмауэров, они также могут изобразить, как одна задача в проекте соединяется с другой задачей — что невероятно полезно для менеджеров.
Исследования показывают, что визуальное представление информации может помочь улучшить понимание и улучшить удержание, что особенно полезно при работе с большим количеством данных.Поскольку сетевые диаграммы показывают все задачи и зависимости за один раз, они могут помочь руководителям проектов оценивать задания, принимать более обоснованные решения, а также более эффективно отслеживать и управлять прогрессом.
Какие бывают типы сетевых схем?
Существует множество различных типов сетевых диаграмм, но это касается управления проектами. Но вам нужно знать только два: метод стрелочной диаграммы (ADM) и метод диаграммы приоритета (PDM). Если вы с ними знакомы, вы сможете составить шаблон сетевой диаграммы для своей собственной системы.
Метод стрелочных диаграмм (ADM)
ADM делает то, что написано на банке: он использует стрелки для обозначения различных действий. Прелесть этого варианта в том, что он невероятно интуитивно понятен. Конец стрелки выходит из прямоугольника (иногда называемого «i-узлом»), который представляет собой начальную точку задачи. Головка стрелки указывает на другой прямоугольник (иногда называемый «j-узлом»), который представляет конечную или конечную точку. Длина самой стрелки обозначает количество времени, затраченного на действие (длинная стрелка = длинная задача, короткая стрелка = небольшая задача).
Отношения между узлами могут быть только «от начала до конца» (SF), хотя иногда для демонстрации зависимостей используются «фиктивные действия». Обычно они используются в ситуации «от финиша до старта» (FS). Если использовать аналогию: глазирование торта (задание C) не может начаться, пока торт не будет приготовлен (задание A) и не будет приготовлена смесь для глазури (задание B). Таким образом, обледенение связано с двумя другими видами деятельности (A и B), но не связано друг с другом. В этом случае вам нужно нарисовать фиктивную активность между A и B.Этот манекен показывает, что вам нужно заполнить A и B, чтобы заполнить C.
Плюсы: Этот тип диаграмм прост в создании и понимании, без формального обучения.
Минусы: Невозможно включить время опережения и запаздывания без добавления новых элементов в диаграмму. Это означает, что для многих руководителей проектов это немного упрощено.
Метод диаграммы приоритетов (PDM)
Метод PDM похож на расширенную версию ADM.У вас еще есть ящики и стрелы. Но вместо стрелок, представляющих ограничительную взаимосвязь «от начала до конца», они иллюстрируют четыре возможных взаимосвязи, в том числе:
- От конца до начала (FS): Это наиболее распространенный тип взаимосвязи. Это происходит, когда одна задача не может начаться, пока вы не выполните другую. Например, вы не можете заморозить торт, пока не испечете его.
- От начала до конца (SF): Это относится к ситуации, когда одна задача не может начаться, пока не начнется другая.Например, внедрение новой системы программного обеспечения для управления проектами должно начаться до того, как вы сможете отключить старую систему.
- Start-to-start (SS): Это относится к ситуации, когда вторая задача может начаться только после начала первой задачи. Оба действия можно начинать одновременно, хотя их необязательно начинать в одно и то же время. Возвращаясь к аналогии с пирогом, чтобы максимально эффективно использовать свое время, вы захотите использовать время, когда торт находится в духовке, для чего-нибудь полезного, например, для приготовления глазури.Итак, в данном случае «испечь пирог» и «сделать глазурь» — это отношения «от начала до конца».
- Finish-to-finish (FF): Это относится к ситуации, когда завершение одной задачи зависит от завершения другой задачи. Вторая задача может быть завершена одновременно или в любое время после завершения первой задачи. Если снова использовать аналогию с тортом, предположим, что свечи — это последний штрих к украшению вашего торта. Перед тем, как выполнить это задание, вам необходимо доставить товар. В этом случае отделка украшения зависит от того, как закончить доставку.
Этот метод полезен для отслеживания времени выполнения (количество времени, которое у вас есть, чтобы закончить что-то, прежде чем оно повлияет на следующую задачу) и времени задержки (время задержки) рядом со стрелками. Это дает руководителю проекта более четкое представление о расписании и объеме, что помогает при составлении отчетов и управлении командой.
Плюсов: Вы можете более точно оценивать время и принимать более обоснованные решения на основе более глубокого знания каждой зависимости. Это означает, что вы можете вносить коррективы, не сбивая проект с пути.А если кто-то попросит вас обосновать свои оценки, у вас будет подробное логическое представление о вашем графике.
Вы также можете использовать этот тип диаграммы, чтобы обнаружить возможности для оптимизации как во время проекта, так и после него. Просмотрите схему на посмертном собрании как инструмент обучения для лучшего управления проектами.
Минусы: Понятно, что создание этого типа диаграммы занимает больше времени, чем метод простой стрелки, но, как вы, наверное, догадались, дополнительное время, которое требуется, более чем окупается в долгосрочной перспективе, потому что у вас есть более точные и подробные информация для работы.
Заключительные мысли
Каким бы ни был ваш проект, создание сетевой диаграммы может значительно облегчить понимание взаимосвязей между задачами.
Инвестиции в качественный инструмент построения диаграмм, который поможет вам создавать ваши сетевые диаграммы, является обязательным: вы не только сможете быстро чертить их с помощью готовых шаблонов и фигур, но и сможете делиться ими с вашей команде легко, особенно если вы выбираете облачное решение. Как и задачи на сетевой диаграмме, ваша роль не существует изолированно; чем больше вы сотрудничаете со своей командой, тем больше у вас шансов сделать все правильно с первого раза.
Совместная работа над идеями для согласования видения вашей команды в CacooДжорджина Гатри Джорджина — перемещенная британка, в настоящее время работающая во Франции копирайтером-фрилансером. Прежде чем переехать в более солнечный климат, она работала писателем в агентстве B2B в Бристоле, Англия, где она также родилась. В свободное время любит старые фильмы и готовит (плохо).
Методы сетевого анализа — ManagementMania.com
Что Методы сетевого анализа
Методы сетевого анализа — это группа специальных аналитических методов, которые используются в случае, когда необходимо проанализировать и оптимизировать сеть взаимосвязанных и связанных элементов, которые имеют некоторую связь между собой.Методы сетевого анализа — это группа специальных аналитических методов (см. Аналитические методы), которые используются в случаях, когда необходимо проанализировать и оптимизировать сеть взаимосвязанных и связанных элементов, которые имеют некоторую связь друг с другом.
Для чего нужны методы сетевого анализа?
Методы сетевого анализа используются в управлении проектами, где элементы являются ключевыми действиями проекта во взаимном временном отношении. Другая возможность их использования — в области логистики и транспорта, где элементы представляют собой центр, а зависимости являются пространственными (также в переносном смысле временными). Методы сетевого анализа сосредоточены на вычислении критического пути или оптимизации между элементами.В число основных методов сетевого анализа входят:
Методы сетевого анализа связаны с концепцией сетевой диаграммы , которая представляет собой представление проекта в виде диаграммы, которая выражает различные связи между действиями проекта. Сетевые диаграммы и методы сетевого анализа основаны на теории графов.
В управлении проектами используются сетевые диаграммы как с рейтингом ребер (определенные), где края графа представляют действия проекта и узлы их связи (или события между действиями), так и графы с узловыми рейтингами (определенные), где узлы графа представляют действия, а ребра представляют отношения между ними.
Связанные термины и методы:
Связанное поле управления:
Метод GERT (метод графической оценки и анализа)
Теория графов
Схема сети
Метод MPM Метод Metra Potential
предыдущий следующий .
Добавить комментарий