Под термином «управление проектами» подразумевается формирование и управление всеми процессами, требуемыми для достижения результата без срыва сроков и незапланированных затрат. Безусловно, концепций управления проектами (далее КУП) без недостатков не существует, как нет систем, идеально подходящих любому руководителю и членам его коллектива. Тем не менее за весь период самого существования КУП было разработано достаточно эффективных методов, способов и стандартов, которые активно применяются в проектной деятельности. Ниже будут рассмотрены наиболее популярные из них.

Чаще всего в работе используются следующие КУП:

  • Agile
  • Scrum
  • Lean
  • Kanban
  • Six Sigma
  • PRINCE2

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

Классические КУП

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

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

Как правило, в традиционных КУП используется пятиступенчатая модель, но при необходимости проект можно дополнять этапами.

5 стадий традиционного проектного управления:

  1. Инициация. Руководитель совместно со своим коллективом разрабатывает проектные требования. На этой стадии часто возникают совещания, обсуждения типа brainstorm – все это нужно, чтобы определить, как будет выглядеть итоговый продукт.
  2. Планирование. Коллектив определяет, каким образом достичь поставленных на прошлой стадии целей. Производится уточнение целей, их разбиение, детализация итогов проекта, перечень необходимых проектных работ. Эти данные нужны, чтобы выработать календарный график, определить затраты, выявить всех заинтересованных и обозначить потенциальные риски.
  3. Разработка. Этот этап характерен не для любого проекта, нередко он является лишь элементом планирования. Данная стадия, которая, в основном, присутствует в технологических проектах, закладывает будущую конфигурацию продукта (или проекта) и определяет технические методы, необходимые для его достижения. Применительно к проектам IT-сектора эта стадия отвечает за определение языка программирования.
  4. Реализация и проверка. Эта стадия отвечает за главную проектную работу – создание программного кода, возведение постройки и т. д. Согласно созданным планам, формируется определенное ранее проектное содержание, производится контроль параметров. Вторая фаза этой стадии – тестирование. Проверка продукта ведется в соответствии с ТЗ и запросами всех заинтересованных. В рамках тестирования обнаруживаются и исправляются недостатки.
  5. Контроль и завершение. Тип проекта определяет, будет ли данный этап обычной передачей заказчику итогов проекта или потребуется долгий процесс общения с клиентами для доработки и улучшения функционала, поддержки итогов проекта (актуально для сферы клиентского сервиса и софта). Различные проекты требуют разных стадий реализации – в каких-то случаях хватит и трех, остальные нуждаются в большем количестве. Порой применяют т. н. «итеративный водопад» — в этом случае любая стадия является, по сути, самостоятельным проектом, в рамках которого задачи выполняются четкими итерациями. Причем суть от этого не меняется – проект по-прежнему является разбитым на стадии, выполняемые в четкой последовательности.

Традиционное управление проектом подразумевает реализацию в определенных временных рамках, это определяется на стадии планирования. Поэтому для таких проектов уместно применять методику календарно-сетевого графика. Наиболее популярный инструмент в таком планировании – диаграмма Гантта, причем есть достаточное количество способов ее создания – это могут быть и электронные таблицы (например, Excel), и специализированные пакеты наподобие Microsoft Project и др.

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

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

Из недостатков классической КУП можно выделить недостаточную гибкость.

Agile

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

В такой ситуации будет уместно воспользоваться Agile – методикой, которая позволяет разбивать проект не на традиционные фазы, идущие друг за другом, а на более мелкие подпроекты, которые впоследствии можно соединить в единый продукт.

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

Непосредственно Agile не является КУП. Скорее, Agile можно охарактеризовать как перечень идей и концепций того, каким образом должна осуществляться реализация. На их основании в сочетании с наиболее эффективными практиками были в свое время созданы самостоятельные гибкие системы вроде Scrum, Crystal и пр.

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

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

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

Scrum

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

Scrum использует принципы Agile, каждый проект при этом разбивается на три стадии. Любая из них может использоваться заказчиком для выявления ценностей, которые носят название product backlog («задел продукта»). Для каждой из частей заказчик определяет приоритеты. Наиболее приоритетные части выбираются для выполнения в т. н. спринте (шаги в Scrum, длительность каждого шага составляет 2-4 недели). По завершении спринта заказчик может получить инкремент – важные элементы, которые уже можно применять. Скажем, веб-сайт с некоторым рабочим функционалом или софт, с которым, хоть и частично, но можно работать.

Далее команда начинает очередной спринт. Длительность спринтов фиксируется на начальном этапе и зависит от особенностей проекта и производительности команды.

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

Гибкость этой КУП, ее высокая структурированность, в отличие от неопределенности и размытости Agile – гарантия того, что проектная работа не пойдет по незапланированному пути.

Scrum отлично подойдет для случаев, когда не каждый участник проекта обладает квалификацией в той области, в которой ведется проект – постоянная взаимосвязь между участниками восполняет недостаток подготовки или неопытность сотрудников благодаря помощи коллег.

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

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

Lean

Данная система так же использует концепцию Agile, однако дополняет ее понятием «поток операций» (англ. workflow), что позволяет всем итерациям осуществляться одинаково эффективно.

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

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

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

Kanban

Метод был создан японским инженером из Toyota в далеком 1963 г. Создатель Kanban, Тайичи Оно, заложил в его основу принцип промышленного производства: в качестве входного параметра используется металлическая болванка, в качестве выходного – готовая продукция.

Kanban разрешает неполное завершение задач на стадиях, если это подразумевает смену приоритета стадии, и при этом существуют более срочные задачи.

Kanban более гибкий, чем Scrum – отсутствуют временные рамки по спринтам и роли. Мало того, каждый участник коллектива может трудиться над рядом задач параллельно, а Scrum такого не допускает.

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

Kanban основан на 4-х принципах, которые и лежат в основе системы:

  1. Карточки. Присутствуют у любой из задач. Служат для хранения всех данных о задаче. Благодаря этому нет необходимости лишний раз искать информацию.
  2. Ограниченное число задач на стадии. Такой подход быстро позволяет видеть, где в workflow образовалось «узкое место» и как можно его быстро устранить.
  3. Потоковая непрерывность. Задачи в backlog ставятся в поток приоритетным образом, благодаря чему работа не прерывается никогда.
  4. Kaizen, или непрерывное улучшение. Сама концепция (также родом из Японии) возникла в конце прошлого века и подразумевает непрерывный анализ процесса производства, что способствует улучшению производительности.

Подобно Scrum, Kanban также используется в хорошо сплоченном коллективе, где нет проблем со взаимодействием. А если опытный коллектив нацелен на результат, то отсутствие в Kanban фиксированных сроков может улучшить результат. Особенно хорошо Kanban зарекомендовал себя там, где члены коллектива в состоянии заменять друг друга, что ускоряет решение трудностей.

Если вы сможете определить идеальную проектную методику – вам повезет, поскольку, как правило, руководители затрачивают массу ресурсов для формирования и конфигурирования своих КУП. Такие системы могут как включать в себя ряд составляющих из имеющихся систем, так и создаваться с самого начала.

Читайте также: