Мышление в стиле Agile: гибкие методы в управлении проектами
25 Янв 2016
Гибкие методологии набирают популярность за пределами ИТ, крупные компании всё чаще рассматривают Scrum в качестве альтернативы классическому проектному управлению. Но прежде чем приступить к внедрению гибких методик управления проектами необходимо найти ответы не несколько вопросов, таких как: подходит ли Agile нашей компании? Подойдёт ли существующая организационная структура для таких изменений? Как измерить отдачу от внедрения?
Во многих ситуациях внедрение Agile может серьёзно повысить производительность и улучшить результативность всех членов команды. Однако недостаточно просто нанять «гибкого» менеджера проектов (Agile Project Manager (APM) – прим. пер.). Для успешного внедрения и использования гибких методологий необходимо изменение всей организации, метрик и образа мышления.
Хотите использовать гибкие методы? Вам нужна гибкая организация!
Одна из сильных сторон традиционной каскадной модели управления проектами состоит в том, что она основана на простом и проверенном временем наборе наглядных метрик, которые позволяют легко отслеживать прогресс проекта и его состояние. Поскольку каждая задача разбита на простые пакеты работ, отслеживать прогресс выполнения задачи достаточно просто. Гибкие методики, напротив, фокусируются больше на достижении цели, а не на метриках и документации. «Гибкий» менеджер проектов формирует видение проекта и управляет ожиданиями проекта, а самоорганизующиеся команды реализуют проект, принимая на себя ответственность и управление.
Часто члены команды работают одновременно над разными аспектами проекта, чтобы достичь поставленной цели. Это приводит к тому, что настоящий прогресс проекта достаточно трудно оценить и описать традиционными для каскадной модели методами. Однако и в гибких методиках есть способы измерения и отчётности.
Переосмысливая метрики проектов
«Гибкий» менеджер проекта должен понимать, насколько продвинулась команда в работе над проектом и предоставлять отчётность высшему руководству. Он может делать отчёт о состоянии всего проекта, в форме, например, диаграммы сгорания. Или о какой-то его части во время ежедневных встреч или в форме отчётов. Но важно понимать, что все усилия сконцентрированы на устранении препятствий в работе проекта, а не на подчинении его процессу отчётности.
Именно это и пугает организации с традиционным подходом – они уверены, что гибкие методики управления проектами хаотичны и не ориентированы на детали. Но это плата за освобождение менеджера проекта от рутины постоянного детального планирования и отчётности. Теперь руководитель может больше времени уделить работе над проектом, решению проблем, мотивации команды. В этом состоит основное отличие каскадных и гибких методологий с точки зрения функций руководителя проекта. «Гибкий менеджер» меньше занимается контролем, и больше – решением проблем и работой с командой. Если удастся привлечь к преобразованиям в сторону Agile руководство, компанию и клиентов, то точность «гибких» метрик может достичь того же уровня, что и у традиционных «каскадных» методологий, и даже превзойти их благодаря концентрации Agile на главных аспектах продукта.
| Особенности Agile | |
| Традиционные «каскадные» методики | Гибкие методики |
| Диаграмма Гантта Детальный график, иллюстрирующий расписание проекта. На нём отображены даты начала и конца каждого действия, а также зависимости между ними | Диаграмма сгорания Понятная с одного взгляда диаграмма, показывающая количество очков историй или задач на количество итераций проекта. Чем более крут график – тем быстрее исполняется проект. В редких случаях, при добавлении новых задач, может иметь положительный наклон |
| Встречи по статусу проекта Чётко распланированная встреча, где менеджер проекта с командой разбирает каждую задачу, её статус, результаты и сроки, когда она будет выполнена. Руководитель ответственен за выполнение задач (тут авторы приводят какой-то свой пример, обычно на классических статус митингах разбирают примерно то же, что и на «встречах на ходу» — прим. пер.) | Ежедневные встречи «на ходу» Короткие встречи с командой на ходу, на которой каждый из членов команды отвечает на 3 вопроса: «Что было сделано с последней встречи? Что должно быть сделано перед следующей? Какие препятствия мешают достичь цели?». Руководитель получает необходимую ему информацию, чтобы быть в курсе дел проекта, а член команды берёт на себя ответственность за выполнение задачи |
| Заказчик ожидает Заказчик назначает цель проекта, а затем ожидает его завершения. Его информируют о состоянии бюджета или о срыве сроков, после того, как это происходит (но могут информировать заранее о рисках, которые могут привести к перерасходу средств или срыву сроков – прим. пер.) | Заказчик вовлечён В Agile Заказчик – активный участник проекта. Владелец продукта («product owner») присутствует на ежедневных встречах, участвует в принятии решений. Задача руководителя проекта состоит в поддержании тесных взаимоотношений с заказчиком и обучении его принципам работы с Agile |
Авторы статьи в таблице привели примеры из своей практики. Однако в опыте компании «Проектные сервисы» встречались случаи применения инструментов, указанных в статье, как «гибкие», в традиционных методиках и компаниях – прим. пер.
Если вы хотите стать Agile, то вы можете зарегистрироваться на наш открытый тренинг Agile Certified Professional в онлайн или очном формате.
Смотрите также:
- Консалтинг: Методология управления проектами: разработка и внедрение
- Статья: Agile PMO: эффективный и ценностно ориентированный Проектный офис
- Статья: Оценка проектов в Agile по методу MoSCoW
- Статья: Можно ли разработать стандарт, охватывающий и Agile и традиционный проектный подход?