Если проектный менеджмент — это методология, то Waterfаll, Agile, Scrum, Kanban — это методы, благодаря которым достигаются цели по проектам и задачам. Если говорить проще: управление проектами является основой проектного менеджмента, а чем эффективнее управление — тем больше проектов завершаются успешно и с соблюдением дедлайнов.
Типичная картина хаоса в управлении проектами:
- Проекты ведутся в таблицах, облачных документах и фиксируются в разных файлах, доступы к которым могут теряться;
- Коммуникация внутри команды — это переписки по электронной почте, в мессенджерах или устное обсуждение деталей проекта, которые нигде не фиксируются;
- Нет понимания конечной цели по проекту;
- Нет разбивки проекта на мелкие задачи с конкретизацией: что нужно сделать, какая цель этих действий и кто за это ответственный;
- Перепрыгивание из одного этапа реализации проекта в другой, или даже перепрыгивание из одного проекта в другой;
- Отсутствие четкого распределения ролей в команде: кто Исполнитель, кто Ответственный, кто Руководитель проекта.
То, что мы описали выше — боль компаний, которые еще далеки от проектного менеджмента или пытаются перейти к принципам проектного менеджмента в управлении проектами, но переход получается болезненным для всей команды.
Болезненно — это когда участники команды не понимают: Зачем нужен проектный менеджмент? Что дает систематизация рабочих процессов? Как влияет новый формат работы на конечный результат и эффективность?
Каким бывает проектный менеджмент
Начнем с главного: гибкость — вот что спасает большинство компаний и позволяет довести проект до конечной цели с минимальными потерями. Потери могут быть как в бюджете, так и человеческом ресурсе, в репутации.
До того, как появились гибкие методы управления проектами, самым популярным методом был Waterfаll (каскадная модель или модель «водопада»). Основной принцип схемы управления проектами при Waterfаll — это переход от этапа к этапу постепенно, без возможности что-либо менять. То есть: есть проект, требования к нему, бюджет и т.д.
У проекта есть отдельные этапы работы и пока один этап не завершен — нет перехода к другому.
Каскадная модель управления проектами оправдывала себя до тех пор, пока не появились гибкие методы и не доказали, что гибкость в управлении проектами — это минимизация рисков, сохранение денег, человеческого ресурса и репутации (которая страдает в первую очередь, если проект «провалился»).
Особенности Agile метода в управлении проектами
Чтобы не было путаницы между Agile, Waterfаll, Scrum и Kanban, сразу скажем, что гибкий Agile — это как замена неповоротливому Waterfаll, а Scrum и Kanban — это уже инструменты Agile.
Пять ключевых особенностей Agile:
- Рабочий процесс — это короткие спринты от 1 недели до 1 месяца.
- Изменения можно вносить в процессе работы над проектом.
- На первом месте — готовый продукт и только после — документация.
- Во время работы над проектом идет тесное взаимодействие с клиентом. Клиент включен в рабочие процессы и может контролировать их на всех этапах.
- Каждый участник команды несет ответственность за конечный результат по реализации проекта.
Scrum и Kanban — как инструменты реализации проекта, изначально прижились в IT сфере, но как показывает опыт других ниш — они многофункциональны.
Например Скрам и Канбан отлично подходят для инженерии или производства.
Что нужно для реализации проекта на практике
Так, как мы определили основные преимущества гибкого Agile подхода и его инструментов для реализации проектов, для практического рассмотрения возьмем Scrum и Kanban.
Большинство систем управления проектами (или таск-менеджеров) построены на основе гибких инструментов реализации проектов.
Например Канбан, Диаграмма Ганта, таймер, фиксация плановых и фактических расходов — все эти инструменты внутри системы управления проектами обеспечивают гибкое управление проектами и их реализацию с максимальной эффективностью на каждом отдельном этапе.
Как применить Scrum в системе управления проектами
Когда все проекты будут заведены в систему и разбиты на отдельные задачи, самое время применить Scrum на деле:
Одна задача = один спринт. Как мы уже писали выше, Scrum предусматривает длительность одного спринта от недели до месяца. Если взять в качестве примера разработку ПО, то сам процесс разработки будет разбит на отдельные задачи, где за каждой задачей закреплен свой Исполнитель и Ответственный.
Несмотря на наличие Исполнителя и Ответственного по задаче (спринту), Scrum предусматривает коллективную ответственность за финальный результат по всему проекту. Если дедлайн по одной задаче в рамках проекта, например, сорван, не ищут «крайнего» или виноватого. Ответственность на команде. Такой подход идеален для стартапов.
Владелец компании и скрам-мастер активно задействованы во всех рабочих процессах. Контроль и внесение изменений (вовремя) ложится на плечи скрам-мастера. Если такого человека в команде еще нет, чаще всего его обязанности полностью переходят в руки владельцу компании.
Еще скрам-мастера можно узнать по другому, более распространенному названию: project manager. Можно смело сказать, что все бизнес-процессы по проекту — это зона ответственности проджект менеджера.
Если кто-то из рабочего процесса «выпал» — его работу подхватывает другой. Это важный принцип Scrum, так как спринты не должны становиться на паузу.
Если проект масштабный и новый, на первых этапах его реализации нет понимания, сколько продлятся спринты. Именно поэтому, участники команды запускают таймер для отдельных задач проекта, чтобы фиксировать затраченное время.
В дальнейшем, наличии зафиксированного времени работы над задачей даст возможность скорректировать спринты по похожим проектам.
Если предполагаемое время, заложенное для задачи (спринта) оказалось меньше реального (затреканного с помощью таймера), можно внести изменения в процессы работы. В этом и прелесть гибкого подхода в проектном менеджменте — адаптивность на всех этапах реализации проекта.
Выводы Scrum подход — это реализация проекта быстро, с минимальными рисками и потерями.
Также это максимальная вовлеченность в рабочий процесс участников команды и разбивка проекта на отдельные спринты (задачи) для детализации, понимания того, что и как происходит на каждом отдельном этапе и если в процессе реализации что-то пошло не так — определить быстро причину и скорректировать процесс.
Как применить Kanban в системе управления проектами
Если сравнивать Kanban и Srcum, то первый — более гибкий. Почему?
Канбан представляет собой виртуальную доску, по которой перемещаются задачи от этапа к этапу.
То есть: главная ценность Канбан в том, что эта доска позволяет отследить, на каком этапе находится задача и что с ней происходит.
Если задача задерживается по срокам, также можно увидеть, в чем причина. До появления систем управления проектами таких, например, как Worksection, Канбан представлял собой обычную физическую доску с цветными стикерами.
Сейчас менеджмент управления проектами — это гибкость и минимум рисков, на что Канбан влияет в первую очередь.
Почему Канбан важен в управлении проектами
Есть возможность переключаться между задачами. Часто бывает, что в процессе работы над одной задачей, неожиданно «прилетает» другая. Что делать: бросать первую и переходить ко второй или вторую ставить на ожидание? Этот вопрос легко решаем, если проследить этапы реализации проекта по Канбан и понять загрузку команды.
Новые задачи попадают в бэклог. Визуально это выглядит как колонка. Назовем бэклог, условно, колонкой ожидания. Все новые задачи, которые еще не приняты в работу, «выстраиваются» в бэклоге.
Когда задачу взяли в работу, она попадает на первый этап реализации и дальше «путешествует» по остальным этапам (визуально это также выглядит как отдельные колонки), пока не приходит к финишу — задача завершена.
Если информация по задаче меняется, эти изменения вносятся прямо в процессе работы, не затрагивая при этом другие задачи и процессы по ним.
Канбан, как инструмент реализации проектов, хорош со всех сторон. Еще один плюс этой доски: нет потребности в частых совещания и обсуждениях этапов реализации проекта (что приветствуется при Scrum подходе).
По Канбан можно отследить все изменения и текущую ситуацию каждого отдельного этапа, поэтому потребность в совещаниях отпадает сама собой (а это, конечно, приличная экономия времени).
Как выглядит Канбан
За каждую отдельную колонку Канбан отвечает статус. То есть: статус = этап реализации задачи. Чтобы задача могла перемещаться от этапа к этапу, она должна на старте иметь статус и в процессе реализации этот статус, как и этап, будут меняться.
Выводы Kanban — это максимальная гибкость рабочих процессов, идеальный инструмент для однотипных задач, возможность отследить задачу на каждом этапе реализации.
Если сравнивать Канбан и Скрам, то можно сделать вывод, что Скрам — больше о контроле, Канбан — о гибкости. Для новых проектов с большим количеством неизвестных и для стартапов лучше на первых порах придерживаться Scrum подхода.
Когда появятся однотипные задачи и процесс работы будет отлажен, можно переходить к Канбан, как ключевому инструменту гибкого управления проектами.
Как протестировать инструменты гибкого управления проектами
Вы можете сделать это прямо сейчас, зарегистрировав аккаунт на нашем сайте. Worksection — это система управления проектами, где гибкость и управляемость одинаковы важны и доступны для ваших проектов.
Нам важно, чтобы ваша команда могла перейти к проектному менеджменту максимально мягко.
Попробуйте перейти от хаоса к проектному менеджменту прямо сейчас.