Методологии управления проектами: разбираем ключевые для IT- и digital-проектов29.08.2023 12:32

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

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

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

В материале

Несмотря на то, что человечество долго не идентифицировало свои цели и задачи при помощи термина «проект» и не стремилось формализовать методологию управления, история управления проектами стара, как сама цивилизация. Возьмём, к примеру, известные египетские пирамиды Гизы, построенные в 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. Оба отображаются в виде сетевой диаграммы, отображающей элементы времени.

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: от основ
до скрам-мастера

Узнать больше

• За 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. Источник

Рассмотрим подробнее процессы, темы и принципы.

Согласно методологии PRINCE2, проект проходит через 7 процессов — наборов операций, направленных на достижение конкретной цели:

• Начало проекта — предпроектная стадия, которая включает в себя идентификацию идеи проекта, разработку предварительного проекта, сбор команды по управлению проектом и планирование следующего этапа.
• Инициация проекта — подготовка стратегий управления рисками, качеством, коммуникациями и конфигурацией проекта, создание плана проекта и установка средств контроля проекта. Этот процесс выполняет менеджер проекта. Результат — проектная документация.
• Руководство проектом ― принятие ключевых решений стейкхолдерами и делегирование оперативного управления менеджеру проекта. Этот процесс не равен фактическому управлению проектом менеджером проекта.
• Управление границами стадии ― предоставление управляющему совету проекта информации для оценки успехов текущей стадии и утверждения плана следующей стадии с учётом экономической обоснованности.
• Контроль стадии ― переход проекта на следующий этап и отслеживание выполнения работы в рамках каждой стадии проекта, формирование отчётов о прогрессе, принятие решений по инцидентам и коррекция каких-либо действий в рамках реализации проекта.
• Управление разработкой продукта ― управление связью между менеджером проекта и менеджером команды при помощи формальных требований к приёмке, выполнению и поставке результатов проектной работы.
• Закрытие проекта ― завершение всех работ по проекту, документирование полученного опыта и официальное закрытие проекта. Признание достижения целевых показателей проекта или основания для досрочного прекращения проекта.

Для успешного прохождения обозначенных выше процессов проектная команда должна проработать 7 направлений — областей знаний:

• Бизнес-обоснование: оцениваем, стоит ли делать проект с коммерческой и стратегической точек зрения. Этот документ следует обновлять по мере продвижения проекта и поступления новых вводных.
• Организация: описываем роли и обязанности каждого участника проект

  Полный текст статьи читайте на Нетология