Вести проект без методологии — это всё равно, что плыть через океан без карты или компаса: риски высоки, а вероятность успеха низкая. Методологии не только обеспечивают основу для планирования и успешного выполнения проектов, но и улучшают коммуникацию, помогают управлять рисками, облегчают решение проблем.
Все основные методологии, которыми мы пользуемся сегодня, сформировались в течение последних ста лет. У каждой — своя логика и подход к планированию. Некоторые методики развились на основе более ранних, а часть скорее выступает в качестве фреймворков к той или иной методологии.
Разберёмся, стоит ли следовать какому-то отдельному подходу или настало время гибридных методологий управления проектами. В этой статье — первой части — рассмотрим ключевые методики и фреймворки, которые возникли в основном в XX веке и широко используются при ведении проектов, особенно цифровых. А в следующей статье поговорим о том, какие из методологий управления проектами стали широко использоваться в миксе.
Алина Голава
Solution Consulting Director (управление presale-процессами) в компании Mercaux
В материале
Несмотря на то, что человечество долго не идентифицировало свои цели и задачи при помощи термина «проект» и не стремилось формализовать методологию управления, история управления проектами стара, как сама цивилизация. Возьмём, к примеру, известные египетские пирамиды Гизы, построенные в 2 500 годах до н.э. Их строительство, продолжавшееся около 20 лет, требовало тщательного планирования, координации и огромного управления трудом. Иероглифы позволяют предположить, что египтяне разбили масштабное предприятие на более мелкие, управляемые части — намёк на поэтапный современный подход к управлению проектами.
В древние времена без формальных методологий результат определялся обычно волей конкретного правителя, а не стратегическим планом или графиком. С приходом промышленной революции в XVIII веке начали формироваться признаки структурированного управления проектами, которое с тех пор постоянно развивается, чтобы соответствовать потребностям меняющегося бизнес-ландшафта.
И в XX веке, отмеченном быстрым технологическим прогрессом и повышением сложности проектов, стали укореняться методологии структурированного управления проектами, доставшиеся нам в наследство от промышленного производства и времён разработки первого широко применяемого программного обеспечения.
Приводим краткий обзор эволюции ключевых методик управления проектами в IT и digital-сфере. Рассмотрим, как работают методологии, их преимущества и ограничения, для каких проектов подходят лучше всего.
Названная в честь своего создателя Генри Ганта, диаграмма Ганта была одним из первых инструментов управления проектами. Инженер-механик и консультант по вопросам управления Гант представил линейчатую диаграмму как визуальный инструмент для планирования задач во времени.
Диаграмма Ганта не является полноценной методикой, но с неё начался процесс формализации методов и инструментов. Более того, она остаётся одним из наиболее популярных методов визуализации проекта.
Что из себя представляет и как работает: это диаграмма, где по вертикали в последовательном порядке располагаются блоки: этапы, задачи и подзадачи, — а по горизонтали отображается временная шкала и для каждого из блоков на этой шкале отображаются периоды выполнения этих задач. Это удобный способ показать, какая работа запланирована на определённый день.
Как выглядит диаграмма Ганта. Иллюстрация автора
Идеально для: проектов малого и среднего размера с чёткими задачами с установленной последовательностью и фиксированными сроками. Обычно используется в разработке программного обеспечения и продуктов, в исследовательских проектах, в планировании мероприятий.
Когда использовать: когда нужен простой и наглядный способ планирования и отслеживания хода выполнения отдельных задач с течением времени. Является базовым инструментом проектного управления.
Преимущества: легко создать и интерпретировать за счёт использования визуальной временной шкалы, позволяет подсветить критические этапы и их последовательность.
Ограничения: не подходит для сложных, особенно кросс-функциональных проектов, так как плохо показывает зависимости между задачами. Диаграмма может стать громоздкой при слишком большом количестве задач, что затруднит работу с документацией. Помимо этого, диаграмма не предусматривает отображение сведений о задаче: описание, как задачи будут выполняться или их сложность.
Ключевые элементы: задачи, последовательность, даты начала и окончания, продолжительность задачи, ход выполнения, временная шкала.
Философию Lean (от англ. lean production — бережливое, экономичное производство) разработали Тайичи Оно и Эйдзи Тойода из Toyota. Методика стала известна в 1940-х годах как способ оптимизации производства: создание максимальной ценности при минимизации усилий компании и производственных отходов.
В основе Lean лежит концепция непрерывного совершенствования «кайдзен», цель которой устранить все потери в процессе создания ценности.
Что из себя представляет и как работает:
Будучи философией, Lean сама по себе не предлагает конкретных инструментов визуализации или управления. Суть Lean — в концептуальном подходе к исследованию ценности продукта и созданию стратегии улучшений.
В результате вокруг философии бережливого производства сформировались такие инструменты анализа и управления, как:
Идеально для: производственных сред, но может применяться к любому чёткому рабочему процессу при стремлении свести к минимуму потери, повысить эффективность и максимизировать ценность для клиента.
Когда использовать: когда нужно сократить потери и неэффективность для создания оптимизированного процесса.
Преимущества: помогает выявлять и устранять потери, оптимизируя процессы и сокращая количество отходов. В итоге Lean помогает значительно повысить эффективность работы.
Ограничения: требуется участие всей организации. Особенно методология Lean требует твёрдой приверженности со стороны руководства, без которого эта сложная концепция легко теряет свой импульс. Её может быть сложно правильно внедрить из-за необходимости перестраивать процессы, которые могут затрагивать почти всю компанию по цепочке создания ценности.
Помимо этого, рядовые сотрудники могут воспринять внедрение практики Lean скорее как сокращение затрат вместо системной работы над ошибками, что приведёт к недостатку взаимопонимания между сотрудниками и менеджментом компании. Например, можно столкнуться с сопротивлением со стороны сотрудников, привыкших к старым методам работы или опасающихся, что за сокращением затрат стоит кадровая оптимизация, урезание расходов и другое.
Ключевые элементы: ценность — понимание того, что ценит клиент, карта потока создания продукта, анализ временных, финансовых, рабочих и других потерь, Kanban, TPM, JIT.
Самое главное — совершенство, ведь бережливое производство — это непрекращающееся движение к совершенству с постоянными усилиями по устранению потерь и повышению эффективности.
Первоначально разработана компанией Toyota в 1940-х годах как система для улучшения и поддержания высокого уровня производства. Позволяет управлять выполнением задач на разных этапах производственного процесса, необходимого для гибкого внедрения принципов бережливого производства (Lean).
Подход позволяет визуально разделять работу и оптимизировать загрузку команды. Активно используется в проектных командах для управления потоком задач. Лежит в основе популярных программ для управления задачами, например Trello и Jira.
Что из себя представляет и как работает: метод предусматривает составление бэклога — списка задач, который формируется на основе всех задач к выполнению. Задачи из бэклога сортируются, приоритизируются по важности и ценности внедрения, оцениваются по трудозатратам. Далее вся работа визуализируется в виде стадий, например «Сделать», «В процессе», «Готово».
Для каждой стадии существует конечный набор задач и подзадач, которые отображаются на карточках. Задачи-карточки разделяются между участниками команды на специализированной канбан-доске и перемещаются между стадиями по мере их выполнения в соответствии с заранее утверждёнными правилами. Например, задачу можно переносить на этап «В разработке», если только она сформулирована в виде пользовательской истории, составленной по определённым критериям.
В Канбане нет привычного многим спринта, когда команда концентрируется только на текущей работе и по завершении рабочей задачи команда забирает следующую задачу с верха бэклога.
Помимо чётких критериев перехода задачи от стадии к стадии, Канбан подразумевает ограничение количества задач, находящихся на каждой из стадий в процессе выполнения. Это позволяет фокусироваться в первую очередь на закрытии задач — а не на оставлении задачи на какой-то стадии — и избежать неэффективности многозадачности и переключения между контекстами различных задач.
Ограничения задач в статусе «В процессе» позволяют легче увидеть, где объём работы накапливается, что позволяет командам выявлять и устранять узкие места в рабочем процессе. Помимо этого, Канбан предусматривает регулярные встречи, где участники коротко делятся обратной связью по задачам и процессам.
Пример канбан-доски. Иллюстрация автора
Идеально для: команд с постоянным потоком входящей работы с разным приоритетом, например IT-операций и групп поддержки. Канбан универсален и может применяться ко многим видам работы, включая производство, разработку программного обеспечения и другую творческую и интеллектуальную работу.
Когда использовать: когда нужно улучшить процесс управления потоком задач, визуально разделить обязанности, чётко ограничить объём выполняемой за определённый промежуток времени работы.
Преимущества: наглядность, гибкость и уменьшение перегрузки за счёт:
Ограничения: для эффективной работы командам следует придерживаться лимитов количества задач, находящихся в статусе «В процессе». Это требует дисциплины и может быть сложно выполнять, особенно при возникновении срочных задач.
Помимо этого, работа по Канбан менее предсказуема с точки зрения производительности, так как команда работает в непрерывном темпе, без планирования задач по времени. Из-за этого оценка сроков выполнения задач может быть более сложной по сравнению с такими методологиями, как Scrum.
Ключевые элементы: канбан-доски и канбан-карточки, чёткие цели, приоритеты и сроки, циклы задач, командная работа, система pull, где члены команды самостоятельно берут задачи из бэклога по мере выполнения текущих задач.
Critical Path Method (CPM) — метод критического пути — разработали в середине 1950-х годов Морган Р. Уокер из DuPont и Джеймс Э. Келли-младший из Remington Rand для сложных проектов с большим количеством взаимозависимых действий.
Одновременно с этим для ракетного проекта Polaris с аналогичными сложностями планирования консалтинговая компания «Буз, Ален и Гамильтон» создала очень похожую методологию, известную как метод оценки и анализа проектов — Program Evaluation Review Technique (PERT).
Оба метода похожим образом выделяют последовательность действий и вычисляют ожидаемую продолжительность проекта или отдельного процесса. PERT практически всегда используется в сочетании с CPM. Оба отображаются в виде сетевой диаграммы, отображающей элементы времени.
Что из себя представляет и как работает
Подразумевает детальный анализ проекта, который:
В итоге формируется так называемый критический путь — самая длинная последовательность задач, в которой к каждой следующей задаче нельзя приступить, не закончив предыдущую, и от которой зависит весь проект. В случае изменения длительности задач изменяются сроки всего проекта.
На основе этой информации создаётся модель проекта с сетевой диаграммой, которая иллюстрирует порядок задач.
Метод подразумевает наличие чётких задач и работает в предположении, что продолжительность каждой задачи известна и постоянна.
К примеру, вёрстку сайта нельзя начать, пока не готов дизайн, а его нельзя сделать без черновика, который не собрать, пока не сформируется понимание основных сценариев и опций. Это и есть критический путь, задачам в рамках которого следует уделить повышенное внимание для получения нужного результата.
Чтобы внедрить PERT, руководители проектов сначала определяют:
Эту информацию используют для создания сетевой диаграммы, показывающей последовательность задач, — тот же самый блок работ, как в методе CPM.
Уникальный аспект PERT — использование «оптимистичных», «пессимистичных» и «наиболее вероятных» оценок времени для каждой задачи с учётом неопределённости и риска. Используя эти три оценки, рассчитывают график проекта.
Объединённая диаграмма CPM-PERT для проекта по разработке устройства. Иллюстрация автора
Идеально для
Комплексных проектов, особенно в области строительства и производственной промышленности.
Проектов исследований и разработки, строительных проектов, планирования крупных мероприятий.
Для IT-проектов оба метода — CPM и PERT — нужно применять с осторожностью, так как они подразумевают, что все задачи и их продолжительность заранее известны. Однако разработка ПО может включать в себя задачи, точные сроки по которым неизвестны или по ходу проекта в требования могут быть внесены изменения, которые могут повлиять на последовательность действий и их продолжительность.
Тем не менее, и CPM, и PERT можно использовать для анализа проекта и идентификации критических этапов, без которых проект не реализуется в оговоренные сроки.
Когда использовать
CPM эффективен для планирования и выявления критических задач, которые могут задержать весь проект, если они не будут выполнены вовремя.
Это полезно, когда требуется заранее распределить ресурсы так, чтобы вовремя выполнить все задачи в цепочке.
PERT идеально подходит для больших и сложных проектов с высокой степенью неопределённости по времени выполнения задач, особенно когда последовательность проекта включает в себя взаимозависимые действия.
Преимущества
Как и CPM, PERT определяет критический путь проекта, что помогает выполнять основные задачи в соответствии с графиком.
Сильная сторона PERT — включение неопределённости и рисков в оценку сроков проекта с тремя возможными временными сценариями.
Ограничения
Не подходит для проектов с высокой степенью неопределённости, так как метод основан на фиксированных оценках времени для каждого вида деятельности, что усложняет возможность его использования, например, в разработке софта.
Может быть сложным в реализации, особенно для крупных проектов. CPM фокусируется в первую очередь на времени и игнорирует другие важные факторы, такие как оптимизация затрат и ресурсов.
Построение диаграммы PERT может быть сложным и трудоёмким процессом, особенно для крупных проектов с большим количеством задач.
В таких случаях можно заменить дни неделями или месяцами и разделить действия на более крупные группы, сосредоточившись на больших практических задачах, чтобы не запутаться в графических элементах диаграммы.
Эффективность PERT зависит от точных оценок времени, поэтому стоит убедиться, что специалист-оценщик обладает всей необходимой информацией.
Ключевые элементы
Список критических и некритических задач и их взаимозависимости, продолжительность, сетевая диаграмма проекта.
Список критических и некритических задач и их взаимозависимости, продолжительность согласно оптимистичному, реалистичному и пессимистическому сценариям, формула PERT, сетевая диаграмма проекта.
Термин «Waterfall» для обозначения каскадной методологии управления проектами ввёл в 1970 году американский учёный Уинстон Ройс.
Модель водопада представляет собой линейный — каскадный — подход к управлению проектами, где каждый этап проекта перетекает в следующий, неуклонно стекая вниз, как водопад. Waterfall — стандартный и широко распространённый из классических методов управления проектами на сегодняшний день.
Что из себя представляет и как работает: все требования собираются до начала работ в виде неизменяемого списка, на основании которого формируется перечень задач, выстраиваемых в соответствии с требованиями и этапами.
Методология выделяет следующие этапы:
Эти этапы идут последовательно и взаимосвязаны друг с другом. Закончен один — команда переходит к следующему, при этом пропуск отдельного этапа и возврат на предыдущие стадии не предусмотрен, что обеспечивает поступательное выполнение работ и контроль над всем процессом разработки проекта.
Участие заказчика в промежуточных точках не подразумевается. Результат проекта виден только в самом его конце.
Идеально для: проектов с определёнными и неизменными требованиями, в основном таких как разработка программного обеспечения или в таких отраслях, как строительство и производство, где модель водопада часто используют из-за высокой стоимости внесения изменений в конструкцию на более поздних этапах.
Когда использовать: когда результат проекта ясен, когда нужен структурированный подход, есть желание спланировать всё с самого начала, когда не готовы к отклонениям от заданного результата.
Преимущества:
Ограничения: недостаточная гибкость для изменений и пересмотров — не подходит для проектов с неопределёнными или меняющимися требованиями.
Применима, только когда заказчик чётко знает, что он хочет получить. В противном случае есть высокий уровень риска получить не тот результат, так как в ходе формирования ТЗ что-то может быть упущено.
Также можно выделить в качестве недостатков позднее тестирование — из-за чего ошибки и проблемы могут стать очевидными, когда будет проделан значительный объём работы, — и мотивационные риски для сотрудников, вовлечённых в разработку крупного сложного проекта, — итоговый продукт они увидят только в самом конце.
Ключевые элементы: последовательные этапы — требования, проектирование, реализация, проверка, техническое обслуживание, визуализация через диаграмму Ганта, техническое задание, проектная документация, чёткая процедура перехода с этапа на этап (project handoff).
Основателями методологии Scrum считают японских учёных Хиротаку Такеути и Икуджиро Нонака. В 1986 году во время наблюдения за компаниями-инноваторами — Fuji-Xerox, Honda и Canon — они заметили, что более эффективны те команды, в которых несколько разнопрофильных специалистов одновременно работают над задачей. А традиционный подход, в котором задача поэтапно переходит от одного специалиста к другому, проигрывает по результатам.
Однако в том виде, в которым мы его знаем, Scrum-метод сформулировали спустя почти 10 лет программисты Кен Швабер и Джефф Сазерленд. Также спустя ещё некоторое время они участвовали в разработке манифеста метода Agile, о котором расскажем ниже.
Особенность Scrum заключается в командном подходе и нестандартном распределении обязанностей внутри коллектива. В процесс плотно вовлечены не только участники проекта, но и бизнес-заказчики, которых привлекают к созданию продукта чаще, чем при других подходах, и делают это преимущественно в формате личного общения, а не через документацию.
Это простая для понимания и сложная в освоении методология помогает командам работать над проектами с высокой долей неопределённости или необходимостью гибко менять приоритеты и результаты каждой итерации.
Что из себя представляет и как работает: для применения подхода Scrum выделяют роли:
На старте создаётся и приоритизируется список всех требований к задаче ― бэклог. Далее задачи оцениваются командой на предмет сложности и затратности временных ресурсов.
Затем участники, скрам-мастер и владелец продукта проводят скрам-собрание, на котором они планируют спринт — определённое время для выполнения части заданий продолжительностью от недели до месяца. В течение спринта на скрам-доске с 4–5 колонками — к примеру, «Бэклог», «Спринт», «В процессе», «На ревью», «Сделано» — распределяются стикеры с заданиями, которые в процессе работы поочерёдно перемещаются из одной колонки в другую (практика Канбан).
Каждый день участники подключаются на короткие встречи и рассказывают, что сделали, что будут делать и есть ли какие-то сложности. По завершении спринта проводится его ревью, а по завершении задачи — ретро всего процесса выполнения, на котором обсуждают, что команда делала хорошо, что можно сделать лучше и что можно улучшить прямо сейчас.
Как может выглядеть скрам-доска. Иллюстрация автора
Идеально для: сложных, быстро меняющихся проектов с неясными долгосрочными целями. Часто используется в разработке программного обеспечения, но может применяться и в других областях.
Когда использовать: Scrum способствует командному сотрудничеству, прозрачности и быстрой разработке высококачественных продуктов, особенно когда ожидается, что цели и задачи могут меняться на протяжении всего процесса разработки.
Преимущества: очень гибкий, позволяет вносить изменения и корректировки практически на ходу. Владелец продукта обладает достаточным количеством информации и полномочий, чтобы оперативно принимать любые решения, например о смене приоритетов.
Ограничения: при неправильном управлении может произойти расползание масштаба (scope creep).
Не подходит для проектов с неизменными требованиями. Ограничивает команду 5–9 участниками, из-за чего опытный скрам-мастер может управлять сразу несколькими командами.
Ключевые элементы: спринты, скрам-мастер, владелец продукта, бэклог, скрам-встречи, спринты, скрам-доски, стендапы (ежедневные собрания), обзор спринта, ретро-ревью проекта.
курс
Agile: от основ
PRINCE2 (PRojects IN Controlled Environments, или Проекты в контролируемой среде) — вторая редакция более раннего метода PRINCE, который в 1989 году разработало Центральное агентство по компьютерам и телекоммуникациям (CCTA) Великобритании в качестве стандарта для управления IT-проектами.
Основная цель этого стандарта ― предоставить проектную среду и структуру для управления проектами любого масштаба и типа. Под проектной средой подразумеваются условия, необходимые для воплощения проекта в жизнь.
Стандарт требует подробной документации каждой стадии проекта, что делает PRINCE2 подходящим методом для проектов, где важен контроль.
Что из себя представляет и как работает
Методология PRINCE2 основывается на:
Принципы, темы и процессы в PRINCE2 взаимосвязаны и взаимодействуют друг с другом. Принципы формируют общую основу для управления проектом. Темы помогают обеспечить управление важными аспектами проекта в соответствии с этими принципами. Процессы, в свою очередь, обеспечивают применение этих принципов и тем в конкретных действиях на протяжении всего проекта.
Структура методологии PRINCE2.
Рассмотрим подробнее процессы, темы и принципы.
Согласно методологии PRINCE2, проект проходит через 7 процессов — наборов операций, направленных на достижение конкретной цели:
Для успешного прохождения обозначенных выше процессов проектная команда должна проработать 7 направлений — областей знаний:
Методология PRINCE2 требует реализовывать проект в соответствии с 7 фундаментальными принципами:
Вот как с помощью PRINCE2 можно реализовать проект разработки ПО ↓
1. Подготовка проекта
Ясно определяем цели проекта. Для примера возьмём создание функциональной удобной и надёжной мобильной кассы, которая ускорит оплату в магазинах и улучшит опыт покупателей.
Формируем список ключевых участников проекта, включая разработчиков, дизайнеров, менеджеров магазина, представителей клиентов.
2. Разработка бизнес-кейса
Аргументированно объясняем, почему этот проект стоит реализовать. Бизнес-кейс может включать прогнозирование увеличения продаж, улучшения удовлетворённости клиентов или повышения эффективности работы сотрудников магазина.
3. Планирование
Определяем ключевые этапы проекта, их сроки, ресурсы и ответственных. Может включать в себя разработку требований, дизайн, разработку, тестирование, запуск и пост-запускное обслуживание мобильной кассы.
4. Инициация проекта
После выполнения и утверждения стейкхолдерами подготовительных работ начинаем реализацию проекта.
5. Управление стадиями
Разрабатываем и реализуем план для каждого этапа проекта. После завершения каждого этапа проводим проверку его результатов и при необходимости адаптируем планы для следующего этапа.
6. Контроль этапов
На протяжении каждого этапа проекта регулярно проверяем ход выполнения работ, управляем рисками и проблемами, убеждаемся, что проект продвигается в соответствии с планом.
7. Завершение проекта
Оцениваем результаты проекты, сравниваем их с ожидаемыми выгодами из бизнес-кейса и проводим анализ опыта, полученного в процессе работы над проектом, чтобы использовать его в будущих проектах.
Идеально для: больших и сложных проектов, особенно в государственном секторе и IT.
Когда использовать: когда проект сложный и требует высокого уровня контроля и организации.
Преимущества: хорошо структурированный, широко признанный. Формируются определённая структура команды проекта и зоны ответственности каждого участника. Методология требует детальной документации для успешной разработки продукта, гарантирует грамотное управление рисками, подходит для проектов в любой области.
Ограничения: может быть бюрократическим и негибким подходом, а также излишним для небольших проектов. Нет рекомендаций по конкретным инструментам для менеджеров, таких как диаграмма Ганта или канбан-карточки.
Ключевые элементы: бизнес-обоснование, определённая организационная структура команды управления проектом, подход к управлению рисками, подробная документация, управление по исключениям.
Родом из мира разработки программного обеспечения, Agile является ответом на ограничения модели Waterfall. Манифест Agile написали 17 разработчиков, включая Джеффа Сазерленда и Кена Швабера, которые сформировали Scrum-метод. В манифесте создатели предлагают универсальный набор принципов, ведущих к улучшению процессов разработки проектов для любого направления деятельности и размера команды.
Что из себя представляет и как работает: методология Agile хорошо подходит для проектов, в которых некоторые детали с самого начала непонятны. Фокус на гибкости, сотрудничестве, удовлетворённости клиентов и высокое качество результатов.
Вместо линейного последовательного процесса проектирования в Agile используется итеративный подход и допускается смещение приоритетов от итерации к итерации. Работа разбивается на небольшие управляемые блоки — пользовательские истории — и выполняется короткими фазами продолжительностью 1–4 недели — спринтами.
При принятии решений Agile способствует частому общению и постоянной обратной связи с участием всех заинтересованных сторон — от членов команды до клиентов. Ежедневные стендапы проводятся для обсуждения прогресса и препятствий.
В основе Agile лежат 4 основные концепции, которые влияют на принцип и подход к управлению проектом:
Идеально для: проектов разработки программного обеспечения или любого проекта с частыми изменениями и итерациями. Отлично подходит для проектов, где решающее значение имеют отзывы клиентов и постоянная перестройка и совершенствование на их основе.
Когда использовать: когда нужна гибкость и адаптируемость, особенно в быстро меняющихся условиях с неопределёнными или меняющимися требованиями. Или когда быстрое развитие технологий приводит к изменению требований.
Преимущества: очень гибкий и адаптируемый метод, позволяет сонастраиваться с целями и потребностями клиентов в течение всего цикла проекта.
Ограничения: менее предсказуем, требует плотного участия заказчика и команды на протяжении всего проекта. Может привести к расползанию масштаба (scope creep).
Ключевые элементы: итеративная разработка, самоорганизующиеся команды, сотрудничество с клиентами, постоянная обратная связь.
Чем различаются Scrum и Agile
Agile — это широкая философия, подход к управлению проектами, набор принципов и ценностей, общих для нескольких методологий, фреймворков и практик.
Scrum — методология, которая подпадает под философию Agile, хотя и появилась раньше неё.
Другими словами, Scrum — это разновидность Agile, но Agile — это не обязательно Scrum.
Методы управления проектами, появившиеся ещё в 1950-е годы, представили нам концепции последовательности действий, планирования и распределения ресурсов. Однако именно разработка модели Waterfall позволила значительно шагнуть вперёд и стала одной из первых методологий управления проектами, основанных на процессах.
При этом жёсткость модели водопада — её же основной недостаток при адаптации к изменениям в ходе реализации проектов. Этот недостаток особенно заметен в проектах по разработке программного обеспечения, где потребности конечных пользователей могут быстро меняться.
В ответ на это в начале XXI века возникла методология Agile, в которой упор делается на гибкость, сотрудничество с клиентами и способность реагировать на изменения. Правда, хотя Agile-подход и произвёл революцию в управлении программными проектами, он также показал, что разные проекты требуют разных подходов к управлению, заложив основу для разработки гибридных методологий.
Читать также
Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши
Алина Голава
Solution Consulting Director (управление presale-процессами) в компании Mercaux
The post
Все основные методологии, которыми мы пользуемся сегодня, сформировались в течение последних ста лет. У каждой — своя логика и подход к планированию. Некоторые методики развились на основе более ранних, а часть скорее выступает в качестве фреймворков к той или иной методологии.
Разберёмся, стоит ли следовать какому-то отдельному подходу или настало время гибридных методологий управления проектами. В этой статье — первой части — рассмотрим ключевые методики и фреймворки, которые возникли в основном в XX веке и широко используются при ведении проектов, особенно цифровых. А в следующей статье поговорим о том, какие из методологий управления проектами стали широко использоваться в миксе.
Алина Голава
Solution Consulting Director (управление presale-процессами) в компании Mercaux
В материале
You do not have permission to view link please Вход or Регистрация
You do not have permission to view link please Вход or Регистрация
You do not have permission to view link please Вход or Регистрация
You do not have permission to view link please Вход or Регистрация
You do not have permission to view link please Вход or Регистрация
You do not have permission to view link please Вход or Регистрация
You do not have permission to view link please Вход or Регистрация
You do not have permission to view link please Вход or Регистрация
-
You do not have permission to view link please Вход or Регистрация
You do not have permission to view link please Вход or Регистрация
Несмотря на то, что человечество долго не идентифицировало свои цели и задачи при помощи термина «проект» и не стремилось формализовать методологию управления, история управления проектами стара, как сама цивилизация. Возьмём, к примеру, известные египетские пирамиды Гизы, построенные в 2 500 годах до н.э. Их строительство, продолжавшееся около 20 лет, требовало тщательного планирования, координации и огромного управления трудом. Иероглифы позволяют предположить, что египтяне разбили масштабное предприятие на более мелкие, управляемые части — намёк на поэтапный современный подход к управлению проектами.
В древние времена без формальных методологий результат определялся обычно волей конкретного правителя, а не стратегическим планом или графиком. С приходом промышленной революции в XVIII веке начали формироваться признаки структурированного управления проектами, которое с тех пор постоянно развивается, чтобы соответствовать потребностям меняющегося бизнес-ландшафта.
И в XX веке, отмеченном быстрым технологическим прогрессом и повышением сложности проектов, стали укореняться методологии структурированного управления проектами, доставшиеся нам в наследство от промышленного производства и времён разработки первого широко применяемого программного обеспечения.
Приводим краткий обзор эволюции ключевых методик управления проектами в IT и digital-сфере. Рассмотрим, как работают методологии, их преимущества и ограничения, для каких проектов подходят лучше всего.
Диаграмма Ганта (1910-е годы)
Названная в честь своего создателя Генри Ганта, диаграмма Ганта была одним из первых инструментов управления проектами. Инженер-механик и консультант по вопросам управления Гант представил линейчатую диаграмму как визуальный инструмент для планирования задач во времени.
Диаграмма Ганта не является полноценной методикой, но с неё начался процесс формализации методов и инструментов. Более того, она остаётся одним из наиболее популярных методов визуализации проекта.
Что из себя представляет и как работает: это диаграмма, где по вертикали в последовательном порядке располагаются блоки: этапы, задачи и подзадачи, — а по горизонтали отображается временная шкала и для каждого из блоков на этой шкале отображаются периоды выполнения этих задач. Это удобный способ показать, какая работа запланирована на определённый день.
Как выглядит диаграмма Ганта. Иллюстрация автора
Идеально для: проектов малого и среднего размера с чёткими задачами с установленной последовательностью и фиксированными сроками. Обычно используется в разработке программного обеспечения и продуктов, в исследовательских проектах, в планировании мероприятий.
Когда использовать: когда нужен простой и наглядный способ планирования и отслеживания хода выполнения отдельных задач с течением времени. Является базовым инструментом проектного управления.
Преимущества: легко создать и интерпретировать за счёт использования визуальной временной шкалы, позволяет подсветить критические этапы и их последовательность.
Ограничения: не подходит для сложных, особенно кросс-функциональных проектов, так как плохо показывает зависимости между задачами. Диаграмма может стать громоздкой при слишком большом количестве задач, что затруднит работу с документацией. Помимо этого, диаграмма не предусматривает отображение сведений о задаче: описание, как задачи будут выполняться или их сложность.
Ключевые элементы: задачи, последовательность, даты начала и окончания, продолжительность задачи, ход выполнения, временная шкала.
Lean / Бережливое производство (1940-е годы)
Философию Lean (от англ. lean production — бережливое, экономичное производство) разработали Тайичи Оно и Эйдзи Тойода из Toyota. Методика стала известна в 1940-х годах как способ оптимизации производства: создание максимальной ценности при минимизации усилий компании и производственных отходов.
В основе Lean лежит концепция непрерывного совершенствования «кайдзен», цель которой устранить все потери в процессе создания ценности.
Что из себя представляет и как работает:
- подробное исследование создания продукта и его ценности;
- поиск и устранение точек потерь — временных, финансовых, ресурсных, рабочих ресурсов — из-за излишних перемещений, проверок, перепроизводства, дефектов и не только;
- постоянное совершенствование процесса;
- поддержка инициатив, исходящих по принципу «снизу-вверх», когда сотрудники на местах являются источником запроса на изменения.
Будучи философией, Lean сама по себе не предлагает конкретных инструментов визуализации или управления. Суть Lean — в концептуальном подходе к исследованию ценности продукта и созданию стратегии улучшений.
В результате вокруг философии бережливого производства сформировались такие инструменты анализа и управления, как:
- Kanban;
- система 5S: сэири, сэитон, сэисо, сэикэцу, сицукэ → сортировка, соблюдение порядка, содержание в чистоте, стандартизация, постоянное совершенствование — принципы создания комфортного и эффективного рабочего места;
- система TPM (Total Productive Maintenance) — поддержание оборудования в отличном состоянии за счёт регулярной профилактики;
- система JIT (Just In Time) — «точно в срок», при которой все компоненты поступают в тот момент, когда они нужны на конкретном этапе производства.
Идеально для: производственных сред, но может применяться к любому чёткому рабочему процессу при стремлении свести к минимуму потери, повысить эффективность и максимизировать ценность для клиента.
Когда использовать: когда нужно сократить потери и неэффективность для создания оптимизированного процесса.
Преимущества: помогает выявлять и устранять потери, оптимизируя процессы и сокращая количество отходов. В итоге Lean помогает значительно повысить эффективность работы.
Ограничения: требуется участие всей организации. Особенно методология Lean требует твёрдой приверженности со стороны руководства, без которого эта сложная концепция легко теряет свой импульс. Её может быть сложно правильно внедрить из-за необходимости перестраивать процессы, которые могут затрагивать почти всю компанию по цепочке создания ценности.
Помимо этого, рядовые сотрудники могут воспринять внедрение практики Lean скорее как сокращение затрат вместо системной работы над ошибками, что приведёт к недостатку взаимопонимания между сотрудниками и менеджментом компании. Например, можно столкнуться с сопротивлением со стороны сотрудников, привыкших к старым методам работы или опасающихся, что за сокращением затрат стоит кадровая оптимизация, урезание расходов и другое.
Ключевые элементы: ценность — понимание того, что ценит клиент, карта потока создания продукта, анализ временных, финансовых, рабочих и других потерь, Kanban, TPM, JIT.
Самое главное — совершенство, ведь бережливое производство — это непрекращающееся движение к совершенству с постоянными усилиями по устранению потерь и повышению эффективности.
Kanban / Канбан (1940-е годы)
Первоначально разработана компанией Toyota в 1940-х годах как система для улучшения и поддержания высокого уровня производства. Позволяет управлять выполнением задач на разных этапах производственного процесса, необходимого для гибкого внедрения принципов бережливого производства (Lean).
Подход позволяет визуально разделять работу и оптимизировать загрузку команды. Активно используется в проектных командах для управления потоком задач. Лежит в основе популярных программ для управления задачами, например Trello и Jira.
Что из себя представляет и как работает: метод предусматривает составление бэклога — списка задач, который формируется на основе всех задач к выполнению. Задачи из бэклога сортируются, приоритизируются по важности и ценности внедрения, оцениваются по трудозатратам. Далее вся работа визуализируется в виде стадий, например «Сделать», «В процессе», «Готово».
Для каждой стадии существует конечный набор задач и подзадач, которые отображаются на карточках. Задачи-карточки разделяются между участниками команды на специализированной канбан-доске и перемещаются между стадиями по мере их выполнения в соответствии с заранее утверждёнными правилами. Например, задачу можно переносить на этап «В разработке», если только она сформулирована в виде пользовательской истории, составленной по определённым критериям.
В Канбане нет привычного многим спринта, когда команда концентрируется только на текущей работе и по завершении рабочей задачи команда забирает следующую задачу с верха бэклога.
Помимо чётких критериев перехода задачи от стадии к стадии, Канбан подразумевает ограничение количества задач, находящихся на каждой из стадий в процессе выполнения. Это позволяет фокусироваться в первую очередь на закрытии задач — а не на оставлении задачи на какой-то стадии — и избежать неэффективности многозадачности и переключения между контекстами различных задач.
Ограничения задач в статусе «В процессе» позволяют легче увидеть, где объём работы накапливается, что позволяет командам выявлять и устранять узкие места в рабочем процессе. Помимо этого, Канбан предусматривает регулярные встречи, где участники коротко делятся обратной связью по задачам и процессам.
Пример канбан-доски. Иллюстрация автора
Идеально для: команд с постоянным потоком входящей работы с разным приоритетом, например IT-операций и групп поддержки. Канбан универсален и может применяться ко многим видам работы, включая производство, разработку программного обеспечения и другую творческую и интеллектуальную работу.
Когда использовать: когда нужно улучшить процесс управления потоком задач, визуально разделить обязанности, чётко ограничить объём выполняемой за определённый промежуток времени работы.
Преимущества: наглядность, гибкость и уменьшение перегрузки за счёт:
- ясного визуального обзора текущего состояния работы;
- отсутствия строгого планирования и необходимости составления графиков при возможной быстрой смене приоритетов;
- ограничения задач в работе — это стимулирует команды доделывать задачи.
Ограничения: для эффективной работы командам следует придерживаться лимитов количества задач, находящихся в статусе «В процессе». Это требует дисциплины и может быть сложно выполнять, особенно при возникновении срочных задач.
Помимо этого, работа по Канбан менее предсказуема с точки зрения производительности, так как команда работает в непрерывном темпе, без планирования задач по времени. Из-за этого оценка сроков выполнения задач может быть более сложной по сравнению с такими методологиями, как Scrum.
Ключевые элементы: канбан-доски и канбан-карточки, чёткие цели, приоритеты и сроки, циклы задач, командная работа, система pull, где члены команды самостоятельно берут задачи из бэклога по мере выполнения текущих задач.
и
. Метод критического пути (CPM) и метод оценки и анализа проектов (PERT) — 1950-е годы
Critical Path Method (CPM) — метод критического пути — разработали в середине 1950-х годов Морган Р. Уокер из DuPont и Джеймс Э. Келли-младший из Remington Rand для сложных проектов с большим количеством взаимозависимых действий.
Одновременно с этим для ракетного проекта Polaris с аналогичными сложностями планирования консалтинговая компания «Буз, Ален и Гамильтон» создала очень похожую методологию, известную как метод оценки и анализа проектов — Program Evaluation Review Technique (PERT).
Оба метода похожим образом выделяют последовательность действий и вычисляют ожидаемую продолжительность проекта или отдельного процесса. PERT практически всегда используется в сочетании с CPM. Оба отображаются в виде сетевой диаграммы, отображающей элементы времени.
CPM
PERT
Что из себя представляет и как работает
Подразумевает детальный анализ проекта, который:
- определяет критические и некритические задачи,
- устанавливает продолжительность каждой задачи,
- выявляет взаимозависимость между задачами.
В итоге формируется так называемый критический путь — самая длинная последовательность задач, в которой к каждой следующей задаче нельзя приступить, не закончив предыдущую, и от которой зависит весь проект. В случае изменения длительности задач изменяются сроки всего проекта.
На основе этой информации создаётся модель проекта с сетевой диаграммой, которая иллюстрирует порядок задач.
Метод подразумевает наличие чётких задач и работает в предположении, что продолжительность каждой задачи известна и постоянна.
К примеру, вёрстку сайта нельзя начать, пока не готов дизайн, а его нельзя сделать без черновика, который не собрать, пока не сформируется понимание основных сценариев и опций. Это и есть критический путь, задачам в рамках которого следует уделить повышенное внимание для получения нужного результата.
Чтобы внедрить PERT, руководители проектов сначала определяют:
- все действия, необходимые для реализации проекта,
- последовательность этих действий, в том числе задачи, которые зависят от завершения других.
Эту информацию используют для создания сетевой диаграммы, показывающей последовательность задач, — тот же самый блок работ, как в методе CPM.
Уникальный аспект PERT — использование «оптимистичных», «пессимистичных» и «наиболее вероятных» оценок времени для каждой задачи с учётом неопределённости и риска. Используя эти три оценки, рассчитывают график проекта.
Объединённая диаграмма CPM-PERT для проекта по разработке устройства. Иллюстрация автора
Идеально для
Комплексных проектов, особенно в области строительства и производственной промышленности.
Проектов исследований и разработки, строительных проектов, планирования крупных мероприятий.
Для IT-проектов оба метода — CPM и PERT — нужно применять с осторожностью, так как они подразумевают, что все задачи и их продолжительность заранее известны. Однако разработка ПО может включать в себя задачи, точные сроки по которым неизвестны или по ходу проекта в требования могут быть внесены изменения, которые могут повлиять на последовательность действий и их продолжительность.
Тем не менее, и CPM, и PERT можно использовать для анализа проекта и идентификации критических этапов, без которых проект не реализуется в оговоренные сроки.
Когда использовать
CPM эффективен для планирования и выявления критических задач, которые могут задержать весь проект, если они не будут выполнены вовремя.
Это полезно, когда требуется заранее распределить ресурсы так, чтобы вовремя выполнить все задачи в цепочке.
PERT идеально подходит для больших и сложных проектов с высокой степенью неопределённости по времени выполнения задач, особенно когда последовательность проекта включает в себя взаимозависимые действия.
Преимущества
- Улучшенное планирование: CPM выявляет чёткую последовательность действий, упрощая планирование и координацию задач.
- Идентификация критических задач: выделяя критический путь, CPM помогает гарантировать, что важные задачи не будут отложены.
- Эффективность: определяя некритические задачи, можно гибко корректировать время их выполнения.
- Предсказуемость: прогнозируется время завершения проекта, можно точнее управлять ожиданиями.
Как и CPM, PERT определяет критический путь проекта, что помогает выполнять основные задачи в соответствии с графиком.
Сильная сторона PERT — включение неопределённости и рисков в оценку сроков проекта с тремя возможными временными сценариями.
Ограничения
Не подходит для проектов с высокой степенью неопределённости, так как метод основан на фиксированных оценках времени для каждого вида деятельности, что усложняет возможность его использования, например, в разработке софта.
Может быть сложным в реализации, особенно для крупных проектов. CPM фокусируется в первую очередь на времени и игнорирует другие важные факторы, такие как оптимизация затрат и ресурсов.
Построение диаграммы PERT может быть сложным и трудоёмким процессом, особенно для крупных проектов с большим количеством задач.
В таких случаях можно заменить дни неделями или месяцами и разделить действия на более крупные группы, сосредоточившись на больших практических задачах, чтобы не запутаться в графических элементах диаграммы.
Эффективность PERT зависит от точных оценок времени, поэтому стоит убедиться, что специалист-оценщик обладает всей необходимой информацией.
Ключевые элементы
Список критических и некритических задач и их взаимозависимости, продолжительность, сетевая диаграмма проекта.
Список критических и некритических задач и их взаимозависимости, продолжительность согласно оптимистичному, реалистичному и пессимистическому сценариям, формула PERT, сетевая диаграмма проекта.
Waterfall / Модель водопада (1970-е годы)
Термин «Waterfall» для обозначения каскадной методологии управления проектами ввёл в 1970 году американский учёный Уинстон Ройс.
Модель водопада представляет собой линейный — каскадный — подход к управлению проектами, где каждый этап проекта перетекает в следующий, неуклонно стекая вниз, как водопад. Waterfall — стандартный и широко распространённый из классических методов управления проектами на сегодняшний день.
Что из себя представляет и как работает: все требования собираются до начала работ в виде неизменяемого списка, на основании которого формируется перечень задач, выстраиваемых в соответствии с требованиями и этапами.
Методология выделяет следующие этапы:
- Формирование концепции.
- Сбор информации.
- Анализ требований.
- Дизайн или визуализация концепта — например, верхнеуровневая визуализация продукта или визуализация пользовательского пути.
- Разработка.
- Тестирование.
- Внедрение.
- Обслуживание.
Эти этапы идут последовательно и взаимосвязаны друг с другом. Закончен один — команда переходит к следующему, при этом пропуск отдельного этапа и возврат на предыдущие стадии не предусмотрен, что обеспечивает поступательное выполнение работ и контроль над всем процессом разработки проекта.
Участие заказчика в промежуточных точках не подразумевается. Результат проекта виден только в самом его конце.
Идеально для: проектов с определёнными и неизменными требованиями, в основном таких как разработка программного обеспечения или в таких отраслях, как строительство и производство, где модель водопада часто используют из-за высокой стоимости внесения изменений в конструкцию на более поздних этапах.
Когда использовать: когда результат проекта ясен, когда нужен структурированный подход, есть желание спланировать всё с самого начала, когда не готовы к отклонениям от заданного результата.
Преимущества:
- Последовательный характер методологии Waterfall — она проста для понимания и использования.
- Фиксированная структура.
- Понятные сроки.
- Чёткое ТЗ.
- Подробная согласованная документация.
- Нет необходимости вовлекать заказчика на промежуточных этапах проекта.
- Конечный объём работы.
- Понимание требуемых ресурсов.
Ограничения: недостаточная гибкость для изменений и пересмотров — не подходит для проектов с неопределёнными или меняющимися требованиями.
Применима, только когда заказчик чётко знает, что он хочет получить. В противном случае есть высокий уровень риска получить не тот результат, так как в ходе формирования ТЗ что-то может быть упущено.
Также можно выделить в качестве недостатков позднее тестирование — из-за чего ошибки и проблемы могут стать очевидными, когда будет проделан значительный объём работы, — и мотивационные риски для сотрудников, вовлечённых в разработку крупного сложного проекта, — итоговый продукт они увидят только в самом конце.
Ключевые элементы: последовательные этапы — требования, проектирование, реализация, проверка, техническое обслуживание, визуализация через диаграмму Ганта, техническое задание, проектная документация, чёткая процедура перехода с этапа на этап (project handoff).
Scrum / Скрам (1986)
Основателями методологии Scrum считают японских учёных Хиротаку Такеути и Икуджиро Нонака. В 1986 году во время наблюдения за компаниями-инноваторами — Fuji-Xerox, Honda и Canon — они заметили, что более эффективны те команды, в которых несколько разнопрофильных специалистов одновременно работают над задачей. А традиционный подход, в котором задача поэтапно переходит от одного специалиста к другому, проигрывает по результатам.
Однако в том виде, в которым мы его знаем, Scrum-метод сформулировали спустя почти 10 лет программисты Кен Швабер и Джефф Сазерленд. Также спустя ещё некоторое время они участвовали в разработке манифеста метода Agile, о котором расскажем ниже.
Особенность Scrum заключается в командном подходе и нестандартном распределении обязанностей внутри коллектива. В процесс плотно вовлечены не только участники проекта, но и бизнес-заказчики, которых привлекают к созданию продукта чаще, чем при других подходах, и делают это преимущественно в формате личного общения, а не через документацию.
Это простая для понимания и сложная в освоении методология помогает командам работать над проектами с высокой долей неопределённости или необходимостью гибко менять приоритеты и результаты каждой итерации.
Что из себя представляет и как работает: для применения подхода Scrum выделяют роли:
- владелец продукта ― отвечает за список требований к продукту и за результат работы команды, является основным стейкхолдером для команды разработки, так как совмещает функции спонсора, менеджера продукта и руководителя проекта;
- скрам-мастер ― организует процесс и знает, как следить за ходом его реализации;
- команда ― формируется из специалистов с различными компетенциями — до 9 человек; считается, что в командах, насчитывающих более 9 участников, будут возникать сложности с координацией и взаимодействием.
На старте создаётся и приоритизируется список всех требований к задаче ― бэклог. Далее задачи оцениваются командой на предмет сложности и затратности временных ресурсов.
Затем участники, скрам-мастер и владелец продукта проводят скрам-собрание, на котором они планируют спринт — определённое время для выполнения части заданий продолжительностью от недели до месяца. В течение спринта на скрам-доске с 4–5 колонками — к примеру, «Бэклог», «Спринт», «В процессе», «На ревью», «Сделано» — распределяются стикеры с заданиями, которые в процессе работы поочерёдно перемещаются из одной колонки в другую (практика Канбан).
Каждый день участники подключаются на короткие встречи и рассказывают, что сделали, что будут делать и есть ли какие-то сложности. По завершении спринта проводится его ревью, а по завершении задачи — ретро всего процесса выполнения, на котором обсуждают, что команда делала хорошо, что можно сделать лучше и что можно улучшить прямо сейчас.
Как может выглядеть скрам-доска. Иллюстрация автора
Идеально для: сложных, быстро меняющихся проектов с неясными долгосрочными целями. Часто используется в разработке программного обеспечения, но может применяться и в других областях.
Когда использовать: Scrum способствует командному сотрудничеству, прозрачности и быстрой разработке высококачественных продуктов, особенно когда ожидается, что цели и задачи могут меняться на протяжении всего процесса разработки.
Преимущества: очень гибкий, позволяет вносить изменения и корректировки практически на ходу. Владелец продукта обладает достаточным количеством информации и полномочий, чтобы оперативно принимать любые решения, например о смене приоритетов.
Ограничения: при неправильном управлении может произойти расползание масштаба (scope creep).
Не подходит для проектов с неизменными требованиями. Ограничивает команду 5–9 участниками, из-за чего опытный скрам-мастер может управлять сразу несколькими командами.
Ключевые элементы: спринты, скрам-мастер, владелец продукта, бэклог, скрам-встречи, спринты, скрам-доски, стендапы (ежедневные собрания), обзор спринта, ретро-ревью проекта.
Agile: от основ
до скрам-мастера
You do not have permission to view link please Вход or Регистрация
- За 5,5 месяцев освоите профессию scrum-мастера с нуля
- Освоите принципы Agile, разберётесь в методологиях Kanban, Lean и детально изучите фреймворк Scrum
- Сможете изменить стиль управления бизнесом и донести ценность продукта до клиентов
- Знаний и навыков, полученных на курсе, будет достаточно, чтобы сдать экзамен Professional Scrum Master I
PRINCE2 (1996)
PRINCE2 (PRojects IN Controlled Environments, или Проекты в контролируемой среде) — вторая редакция более раннего метода PRINCE, который в 1989 году разработало Центральное агентство по компьютерам и телекоммуникациям (CCTA) Великобритании в качестве стандарта для управления IT-проектами.
Основная цель этого стандарта ― предоставить проектную среду и структуру для управления проектами любого масштаба и типа. Под проектной средой подразумеваются условия, необходимые для воплощения проекта в жизнь.
Стандарт требует подробной документации каждой стадии проекта, что делает PRINCE2 подходящим методом для проектов, где важен контроль.
Что из себя представляет и как работает
Методология PRINCE2 основывается на:
- Принципах ― неизменных правилах успешной реализации проекта, которые включают в себя делегирование полномочий, постоянное обучение и улучшение, а также применение методологии с учётом конкретной проектной ситуации.
- Темах, областях знаний ― аспектах управления проектами: управление рисками, контроль изменений, управление стейкхолдерами и другие.
- Процессах ― обязательных шагах, которые следует пройти от начала до конца проекта. Включают в себя инициирование, планирование, выполнение, контроль и закрытие проекта.
Принципы, темы и процессы в PRINCE2 взаимосвязаны и взаимодействуют друг с другом. Принципы формируют общую основу для управления проектом. Темы помогают обеспечить управление важными аспектами проекта в соответствии с этими принципами. Процессы, в свою очередь, обеспечивают применение этих принципов и тем в конкретных действиях на протяжении всего проекта.
Структура методологии PRINCE2.
You do not have permission to view link please Вход or Регистрация
Рассмотрим подробнее процессы, темы и принципы.
Согласно методологии PRINCE2, проект проходит через 7 процессов — наборов операций, направленных на достижение конкретной цели:
- Начало проекта — предпроектная стадия, которая включает в себя идентификацию идеи проекта, разработку предварительного проекта, сбор команды по управлению проектом и планирование следующего этапа.
- Инициация проекта — подготовка стратегий управления рисками, качеством, коммуникациями и конфигурацией проекта, создание плана проекта и установка средств контроля проекта. Этот процесс выполняет менеджер проекта. Результат — проектная документация.
- Руководство проектом ― принятие ключевых решений стейкхолдерами и делегирование оперативного управления менеджеру проекта. Этот процесс не равен фактическому управлению проектом менеджером проекта.
- Управление границами стадии ― предоставление управляющему совету проекта информации для оценки успехов текущей стадии и утверждения плана следующей стадии с учётом экономической обоснованности.
- Контроль стадии ― переход проекта на следующий этап и отслеживание выполнения работы в рамках каждой стадии проекта, формирование отчётов о прогрессе, принятие решений по инцидентам и коррекция каких-либо действий в рамках реализации проекта.
- Управление разработкой продукта ― управление связью между менеджером проекта и менеджером команды при помощи формальных требований к приёмке, выполнению и поставке результатов проектной работы.
- Закрытие проекта ― завершение всех работ по проекту, документирование полученного опыта и официальное закрытие проекта. Признание достижения целевых показателей проекта или основания для досрочного прекращения проекта.
Для успешного прохождения обозначенных выше процессов проектная команда должна проработать 7 направлений — областей знаний:
- Бизнес-обоснование: оцениваем, стоит ли делать проект с коммерческой и стратегической точек зрения. Этот документ следует обновлять по мере продвижения проекта и поступления новых вводных.
- Организация: описываем роли и обязанности каждого участника проекта. На этой стадии определяется, кто принимает решения, управляет проектом, контролирует качество и другое.
- Управление качеством: фиксируем требования к качеству и то, как оно будет измеряться и поддерживаться на протяжении всего проекта.
- Планирование: подробно описываем, как и когда проект будет реализован, включая ресурсы, время и стоимость.
- Управление рисками: определяем риски проекта, их вероятность и влияние, а также стратегии управления ими.
- Управление изменениями: согласовываем действия участников проекта в случае изменения требований, обстоятельств или планов проекта.
- Прогресс: формулируем, как будет контролироваться и управляться прогресс проекта.
Методология PRINCE2 требует реализовывать проект в соответствии с 7 фундаментальными принципами:
- Постоянная оценка целесообразности проекта его заказчиком. Если потребность в проекте отпала, его нужно остановить.
- Учёт предыдущего опыта: постоянный анализ хода текущего проекта и других, использование извлечённых уроков.
- Чёткие роли и обязанности: формирование оргструктуры проекта, роли и уровень ответственности.
- Управление по стадиям: формулирование, планирование, осуществление и контроль на каждом этапе.
- Управление по исключениям: принцип, по которому представители каждого уровня управления осуществляют действия в рамках собственных полномочий, привлекая вышестоящий уровень только, если возникает серьёзная проблема, выходящая за пределы их компетенций.
- Фокус на продукте. Главная цель — конечный продукт и его качество, а также соответствие итогового продукта запланированному.
- Адаптация принципов методологии к внешним условиям — например корпоративным стандартам или оргструктуре. В целом подразумевается не жёсткий набор правил.
Вот как с помощью PRINCE2 можно реализовать проект разработки ПО ↓
1. Подготовка проекта
Ясно определяем цели проекта. Для примера возьмём создание функциональной удобной и надёжной мобильной кассы, которая ускорит оплату в магазинах и улучшит опыт покупателей.
Формируем список ключевых участников проекта, включая разработчиков, дизайнеров, менеджеров магазина, представителей клиентов.
2. Разработка бизнес-кейса
Аргументированно объясняем, почему этот проект стоит реализовать. Бизнес-кейс может включать прогнозирование увеличения продаж, улучшения удовлетворённости клиентов или повышения эффективности работы сотрудников магазина.
3. Планирование
Определяем ключевые этапы проекта, их сроки, ресурсы и ответственных. Может включать в себя разработку требований, дизайн, разработку, тестирование, запуск и пост-запускное обслуживание мобильной кассы.
4. Инициация проекта
После выполнения и утверждения стейкхолдерами подготовительных работ начинаем реализацию проекта.
5. Управление стадиями
Разрабатываем и реализуем план для каждого этапа проекта. После завершения каждого этапа проводим проверку его результатов и при необходимости адаптируем планы для следующего этапа.
6. Контроль этапов
На протяжении каждого этапа проекта регулярно проверяем ход выполнения работ, управляем рисками и проблемами, убеждаемся, что проект продвигается в соответствии с планом.
7. Завершение проекта
Оцениваем результаты проекты, сравниваем их с ожидаемыми выгодами из бизнес-кейса и проводим анализ опыта, полученного в процессе работы над проектом, чтобы использовать его в будущих проектах.
Идеально для: больших и сложных проектов, особенно в государственном секторе и IT.
Когда использовать: когда проект сложный и требует высокого уровня контроля и организации.
Преимущества: хорошо структурированный, широко признанный. Формируются определённая структура команды проекта и зоны ответственности каждого участника. Методология требует детальной документации для успешной разработки продукта, гарантирует грамотное управление рисками, подходит для проектов в любой области.
Ограничения: может быть бюрократическим и негибким подходом, а также излишним для небольших проектов. Нет рекомендаций по конкретным инструментам для менеджеров, таких как диаграмма Ганта или канбан-карточки.
Ключевые элементы: бизнес-обоснование, определённая организационная структура команды управления проектом, подход к управлению рисками, подробная документация, управление по исключениям.
Agile (2001)
Родом из мира разработки программного обеспечения, Agile является ответом на ограничения модели Waterfall. Манифест Agile написали 17 разработчиков, включая Джеффа Сазерленда и Кена Швабера, которые сформировали Scrum-метод. В манифесте создатели предлагают универсальный набор принципов, ведущих к улучшению процессов разработки проектов для любого направления деятельности и размера команды.
Что из себя представляет и как работает: методология Agile хорошо подходит для проектов, в которых некоторые детали с самого начала непонятны. Фокус на гибкости, сотрудничестве, удовлетворённости клиентов и высокое качество результатов.
Вместо линейного последовательного процесса проектирования в Agile используется итеративный подход и допускается смещение приоритетов от итерации к итерации. Работа разбивается на небольшие управляемые блоки — пользовательские истории — и выполняется короткими фазами продолжительностью 1–4 недели — спринтами.
При принятии решений Agile способствует частому общению и постоянной обратной связи с участием всех заинтересованных сторон — от членов команды до клиентов. Ежедневные стендапы проводятся для обсуждения прогресса и препятствий.
В основе Agile лежат 4 основные концепции, которые влияют на принцип и подход к управлению проектом:
- Люди и взаимодействие между ними важнее процессов и инструментов → отказ от формализма в пользу постоянной прозрачной и регулярной коммуникации между всеми заинтересованными сторонами, стремление к взаимопониманию.
- Работающий продукт или программное обеспечение важнее исчерпывающей документации → объём проектной документации сводится к необходимому минимуму на усмотрение команды, составление которого не сильно задерживает начало проекта. Например, верхнеуровневая диаграмма с архитектурой вместо детальной спецификации, если таковая на самом деле не нужна, или фиксирование достаточных требований в виде пользовательских историй. Главный принцип — создание документации в объёме, в котором она действительно нужна.
- Коллаборация c клиентами важнее формальной стороны отношений → это не означает, что контракт не важен, но смещает фокус с формализации сделки — когда составляется подробный контракт и обе стороны выполняют работу точно в соответствии с соглашением, даже если во время реализации возникли изменения — на перспективу сотрудничества, когда заказчик и команда разработчиков являются партнёрами, которые стремятся достигнуть общую цель, решая любые проблемы и обсуждая меняющиеся требования по мере их возникновения.
- Обязательное оперативное реагирование на изменение вместо следования плану → готовность к изменениям на любой стадии, оперативная подстройка проекта под меняющиеся нужды.
Идеально для: проектов разработки программного обеспечения или любого проекта с частыми изменениями и итерациями. Отлично подходит для проектов, где решающее значение имеют отзывы клиентов и постоянная перестройка и совершенствование на их основе.
Когда использовать: когда нужна гибкость и адаптируемость, особенно в быстро меняющихся условиях с неопределёнными или меняющимися требованиями. Или когда быстрое развитие технологий приводит к изменению требований.
Преимущества: очень гибкий и адаптируемый метод, позволяет сонастраиваться с целями и потребностями клиентов в течение всего цикла проекта.
Ограничения: менее предсказуем, требует плотного участия заказчика и команды на протяжении всего проекта. Может привести к расползанию масштаба (scope creep).
Ключевые элементы: итеративная разработка, самоорганизующиеся команды, сотрудничество с клиентами, постоянная обратная связь.
Чем различаются Scrum и Agile
Agile — это широкая философия, подход к управлению проектами, набор принципов и ценностей, общих для нескольких методологий, фреймворков и практик.
Scrum — методология, которая подпадает под философию Agile, хотя и появилась раньше неё.
Другими словами, Scrum — это разновидность Agile, но Agile — это не обязательно Scrum.
Резюмируем
Методы управления проектами, появившиеся ещё в 1950-е годы, представили нам концепции последовательности действий, планирования и распределения ресурсов. Однако именно разработка модели Waterfall позволила значительно шагнуть вперёд и стала одной из первых методологий управления проектами, основанных на процессах.
При этом жёсткость модели водопада — её же основной недостаток при адаптации к изменениям в ходе реализации проектов. Этот недостаток особенно заметен в проектах по разработке программного обеспечения, где потребности конечных пользователей могут быстро меняться.
В ответ на это в начале XXI века возникла методология Agile, в которой упор делается на гибкость, сотрудничество с клиентами и способность реагировать на изменения. Правда, хотя Agile-подход и произвёл революцию в управлении программными проектами, он также показал, что разные проекты требуют разных подходов к управлению, заложив основу для разработки гибридных методологий.
Читать также
You do not have permission to view link please Вход or Регистрация
You do not have permission to view link please Вход or Регистрация
You do not have permission to view link please Вход or Регистрация
You do not have permission to view link please Вход or Регистрация
Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши
You do not have permission to view link please Вход or Регистрация
. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к
You do not have permission to view link please Вход or Регистрация
.
Алина Голава
Solution Consulting Director (управление presale-процессами) в компании Mercaux
The post
You do not have permission to view link please Вход or Регистрация
first appeared on
You do not have permission to view link please Вход or Регистрация
.
