Методологии управления проектами: взвешенная классика Waterfall и гибкий Agile

Методология управления проектами отвечает не только на вопрос «Что делать?», но и «Как делать?» — это стандартизация ведения проектов. Выбор методологии определяет как будет работать и взаимодействовать команда: она учитывает особенности проекта (BAS ERP и т.д.) и устанавливает принципы управления, командной работы, форму контроля, проверки и оценки результата. От методологии управления зависит качество планирования и выполнения проекта по внедрению ERP. 

В статье описаны общепринятые методологии ведения проектов: Waterfall, инкрементальный, итерационный подходы, гибкие методологии (Agile): Scrum, KanBan. Их плюсы и минусы. Мы рассмотрим основные тезисы этих методологий, сравним и приведем примеры использования, чтобы реализация проекта автоматизации стала для Вас максимально наглядной.

Некоторые методологии направлены на скорость реализации проекта внедрения BAS ERP и не только. Другие больше ориентируются на охват его составляющих или управление сотрудничеством. Любая методология должна быть адаптирована под конкретный проект и его задачи.

Waterfall

Это классическая каскадная методология запуска проекта, которая делится на части — фиксированные этапы, которые есть всегда, в любом проекте. Waterfall идет строго постепенно: сначала собирается аналитика, описываются требования, дальше разработка, тестирование и запуск проекта с последующей поддержкой. iT.Artel выбирает для работы именно методологию Waterfall.

Комментарий от Алексея Бардакова, руководителя iT.Artel: Большое преимущество методологии Waterfall — это fixed cost. Исполнитель сразу понимает себестоимость проекта, трудозатраты, которые ожидаются и сроки его выполнения — все этапы прописаны, поэтому Заказчик входит в проект уже понимая и четкие сроки, и стоимость. Почему это важно: при участии в тендерах все заказчики просят предоставить fixed cost. И уже после озвученной стоимости принимают решение — идти в этот проект или нет. И если вести проект по Waterfall, мы можем эту стоимость назвать. 

Однако, другая сторона таких жестко регламентированных этапов такова, что если мы на этапе разработки или тестирования встречаем необходимость что-то переделать, придется вносить изменения в техническое задание, а значит мы вынуждены будем вернуться к дизайну и там все переписать. Конечно, управление изменениями в Waterfall есть, но оно не очень удобно: когда нужно внести изменения, их очень сложно, а иногда даже невозможно учесть в проекте. Соответственно, их нужно будет выносить в отдельный проект. Лучше их накапливать, обсуждать, а реализовывать только после завершения текущего проекта.

Для каких проектов рекомендуется использовать Waterfall

• Средние и большие проекты; 
• С несколькими командами: даёт возможность разделить задачи внутри проекта по нескольким командам — у нас есть четко расписанные этапы, которые не предусматривают изменений, поэтому команды могут выполнять задачи параллельно друг с другом. Такое распределение работы по Waterfall позволяет воплощать очень крупные проекты;
• Когда цели проекта понятны в начале и существенных изменений не предвидится;
• Когда внедряется тиражируемое решение: системы, которые относятся к тиражуемым это — 1С:Підприємство, SAP,  Axapta, Битрикс и другие. То есть системы функционирование и запуск которых понятны и стандартизированы можно успешно внедрять с помощью Waterfall;
• Проекти, которые требуют «fixed cost«.

Инкрементальный подход 

Инкрементальный подход можно назвать подвидом Waterfall. Он заключается в том, что проект мы делим на независимые части и запускаем их по очереди. Рассмотрим это на примере запуска бизнес-процессов, не связанных между собой. 

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

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

Итеративный подход

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

Например: закупки, склад, продажа. Мы должны запустить продажу, но не можем этого сделать, пока у нас нет склада, хотим запустить склад, но не можем этого сделать, пока нет закупок. Эти бизнес-процессы интегрированы и могут работать только в связке друг с другом. Здесь и рекомендуется запускать все итеративно — на первой фазе проекта все бизнес-процессы воплощаются в общих чертах. То есть этот функционал еще не реализует, например, ячеистое хранение склада, заказ для поставщика и клиента. На этом этапе мы запускаем: оприходовать товар, переместить по складу и продать товар. Это «первое приближение» и оно уже дееспособное — компания может начинать работать с этим функционалом, но в ограниченном режиме. На следующей фазе мы уже более подробно прописываем бизнес-процессы — добавляем заказы поставщикам, покупателям, добавляем ордера на складе. Мы уже уточнили эти бизнес-процессы и после второй фазы заказчик уже может пользоваться более подробно описанными бизнес-процессами, но все три части мы запускаем одновременно — для того, чтобы у нас не было разрыва по остаткам, ошибок, ситуаций, когда мы не можем осуществить продажу, потому что чего-то нет в наличии. На следующей фазе мы «наводим резкость» и начинаем запускать более глубокий функционал: обеспечение заказов, резервирование, возможно, ячеистый склад и на следующей итерации мы получаем уже полнофункциональную систему. Но, как было показано, пользоваться этим функционалом Заказчик мог еще на предыдущих фазах.

Agile — гибкие методологии 

Методологии Agile разработали программисты и создали свод правил, которые позволяют ускорить запуск ИТ проекта. Они рассчитаны на то, чтобы в любой момент можно было изменить цель проекта и направление, в котором он движется. И если Waterfall это — «договорились-запланировали-действуем» с установленными сроками завершения и запуска, то в Agile мы постоянно доделываем функционал и без перерывов выпускаем его.

Комментарий от Алексея Бардакова: Развивать проект, реализованный методиками Agile после его условного завершения (потому что проект может не получить четкого завершения и иметь «открытый финал» с последующим внесением изменений) сможет или только команда, работавшая над ним, или она вынуждена будет потратить немало времени на передачу этого проекта той команде, которая будет его дальше поддерживать и развивать. Также замена отдельных специалистов в команде или даже всей команды будет усложнена из-за слабой документации — все реализуется очень быстро и упор идет на скорость внедрения, а вот документация на этой дистанции отстает. Этот момент требует внимания. 

Для каких проектов рекомендуется использовать Agile

• Проекты-стартапы, когда разрабатываем что-то новое и не знаем, что должны получить в конце;
• Проекты по разработке собственными силами «с нуля» или в ходе которых предполагается глубокая кастомизация решения;
• В любом случае только для проектов с открытым бюджетом.

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

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

Scrum

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

Функции участников команды: владелец отвечает за функционал продукта, Scrum-мастер отвечает за коммуникацию в команде, но не входит в её состав, а стоит над ней, наблюдает и дает консультативные замечания по работе команды. Если по истечению одного из спринтов продукт не работает, значит что-то пошло не так. 

KanBan

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

Часто в KanBan не используется оценка трудозатрат. Рассчитываются средние трудозатраты на выполнение задач, но в момент, когда задача запускается в работу заранее не планируется сколько это займет времени — команда просто пытается сделать ее как можно быстрее.

Нельзя сказать, что какая-то из методологий «лучше» другой — все зависит от проекта. Целью нашей статьи было сделать для Вас обзор действенных методологий, чтобы показать как внедряется проект. Ведь понимание этого процесса позволяет сделать ожидания от каждой стадии проекта более четкими и увеличить их соответствие реальному хода проекта.

Если хотите узнать больше о процессе и результатах внедрения проекта автоматизации, рекомендуем материалы:

1. Как автоматизация бизнес-процессов влияет на бизнес
2.  Кто отвечает за автоматизацию бизнес-процессов на предприятии?
3. Методи внедрения ERP-системы: какие этапы ожидают компанию на пути внедрения и каким будет результат
4. Строй — автоматизуй! Почему построение и автоматизация бизнес-процессов не одно и то же

Возникли вопросы? Онлайн или офлайн — мы всегда рядом! Вы можете:

Замовити консультацію