Agile-менеджмент: гибкое управление проектами
Представьте себе начинающий технологический бизнес, основатели которого пытаются создать устойчивую бизнес-нишу. Сектор рынка быстро меняется, и они должны быстро разработать сервис, за который пользователи готовы платить. Это очень сложно!
Разработчики могут получать информацию только с помощью маркетинговых исследований, поэтому им нужно активно экспериментировать, то есть перепробовать множество различных предложений. Шаг за шагом они должны извлекать уроки из полученных результатов и совершенствовать предложение, пока в конце концов не разработают действительно востребованное решение.
Вероятно, вам встречались многие проекты, связанные со сложными, быстро меняющимися ситуациями, которые напоминают этот сценарий. Вы можете работать над одним результатом или решать одну проблему, но затем вам нужно изменить курс и пересмотреть свои планы.
Если вы используете традиционный подход к управлению проектами, эти изменения приведут к сорванным срокам, повышению затрат и увеличению рабочей нагрузки. А в худшем случае ситуация настолько изменится в ходе проекта, что ваш конечный продукт в результате больше будет не интересен потребителю.
Управление проектами Agile — это подход, который помогает вам справиться с проблемами такого рода. В этой статье мы объясним, что такое Agile и почему его выгодно использовать.
Что такое управление проектами Agile
Управление проектами Agile строится на основе гибкого подхода. Члены команды работают «короткими очередями» над небольшими, но функциональными частями продукта — пользовательскими историями (User Stories). Затем они тестируют каждую сделанную часть в соответствии с потребностями клиентов, вместо того чтобы стремиться к единому конечному результату, который будет достигнут только в конце проекта.
Конечный продукт проекта в Agile-подходе может сильно отличаться от изначально задуманного. Однако благодаря процессу поэтапной проверки члены команды смогут убедиться, что именно этот продукт будет востребован на рынке.
Поэтому гибкое управление проектами Agile особенно подходит для новых или быстро развивающихся предприятий, для сегментов, работающих в быстро меняющейся среде, или для очень сложных ситуаций, когда менеджеры "идут на ощупь", чтобы найти оптимальную бизнес-модель. Это также полезно для срочных проектов, которые не имеют времени на полную традиционную настройку.
Истоки Agile
Элементы гибкого управления проектами существуют уже несколько десятилетий. Однако заложить основы для такого подхода помогли два события.
Сначала, в 1986 году, Хиротака Такеучи и Икудзиро Нонака в журнале Harvard Business Review опубликовали статью под названием "Новая игра для разработки новых продуктов". В нем авторы изложили новый способ разработки продуктов, напоминающих игру в регби.
Они представили подход к управлению проектами, при котором, как и на поле, члены команды достигали бы своей цели, постоянно переоценивая ситуацию и реагируя соответствующим образом. Таким образом, проекты будут эволюционировать, но в результате приведут к созданию продуктов, которые смогут более полно удовлетворять потребности клиентов.
Второе событие произошло в 2001 году, когда группа экспертов по программному обеспечению и проектам собралась, чтобы обсудить, что общего у их наиболее успешных проектов. Они создали манифест Agile, в котором изложили ценности и принципы, лежащие в основе гибкого управления проектами.
Управление проектами Agile основано на подходе Такеучи и Нонаки к разработке продуктов и включает в себя ценности и принципы, изложенные в манифесте Agile.
Сравнение управления проектами Agile с традиционным управлением
Давайте сравним гибкое управление проектами с традиционным управлением проектами, чтобы показать их различие.
УПРАВЛЕНИЕ ПРОЕКТАМИ AGILE | ТРАДИЦИОННОЕ УПРАВЛЕНИЕ ПРОЕКТАМИ |
Команды проектов самоорганизуются и могут достигать результатов по своему усмотрению, при условии, что они следуют согласованным правилам. | Команды, как правило, жестко контролируются менеджером проекта. Они работают в соответствии с подробными графиками, согласованными с самого начала. |
Требования к проекту разрабатываются в рамках процесса по мере возникновения потребностей и условий использования. Это может означать отличие конечного результата от изначально предусмотренного. | Требования к проекту определяются до начала проекта. Иногда это может привести к "расползанию масштаба проекта", потому что заинтересованные стороны часто выдвигают больше требований, чем реально необходимо, "на всякий случай". |
Получение обратной связи для изучения потребностей клиентов происходит постоянно, поэтому можно быстро учиться на ошибках и совершенствовать результаты. Однако тестирование — трудоемкий процесс, которым трудно управлять, не задействуя пользователей. | Тестирование пользователей и обратная связь с клиентами происходят ближе к концу проекта, когда все уже разработано и внедрено. Это может означать, что после выпуска продукта могут возникнуть проблемы, иногда приводящие к дорогостоящим исправлениям и даже публичным отзывам продукта из продажи. |
Команды постоянно оценивают масштаб и направление своего продукта или проекта. Это означает, что они могут изменить направление в любой момент процесса, чтобы убедиться, что их продукт будет соответствовать меняющимся потребностям. Однако из-за этого могут возникнуть затруднения с начальным составлением бизнес-обоснования, поскольку точный конечный результат заранее не известен. | Команды работают над конечным продуктом, который может быть создан через некоторое время — часто через месяцы или годы — после начала проекта. Может оказаться, что конечный продукт или проект больше не актуальны, потому что изменились потребности бизнеса или клиентов. |
Как показывает практика, традиционное управление проектами обычно лучше всего работает в стабильной среде, где требуется определенный результат при фиксированном бюджете. Управление Agile больше подходит в тех проектах, где конечный продукт точно не определен, или когда среда быстро меняется.
Описание процесса
Гибкое управление проектами Agile также отличается от других методов управления проектами используемыми ролями и событиями, которые описаны ниже.
«Структура Scrum» и «спринты»
В основе управления проектами Agile лежит принцип Scrum. В нем используются определенные роли, события и встречи для реализации цели: создания полезного продукта в определенные сроки, например, в течение 30 дней.
Структура Scrum включает в себя три ключевые роли:
1. Владелец продукта представляет ключевые заинтересованные стороны, клиентов и конечных пользователей и отвечает за определение приоритетов проекта и получение финансирования.
Задача владельца продукта заключается в том, чтобы обеспечить понимание требований, функционала и приоритетов, а также воплотить в жизнь все эти аспекты. Его опыт также помогает бороться с «расползанием масштабов проекта».
2. Ведущий отвечает за организацию ежедневных совещаний, улучшение взаимодействия в команде и повышение продуктивности, иными словами, решает внутренние проблемы, помогая владельцу продукта стимулировать разработку и получать максимальную отдачу от инвестиций. Ведущий гарантирует автономность каждого спринта и контролирует коммуникацию, демонстрируя заинтересованным сторонам и членам команды текущие достижения.
3. Команда — это группа профессионалов, ответственных за трансформацию требований в функциональность.
Команда работает над каждым проектом с помощью «спринтов» — коротких отрезков работы, по завершении которых будут получены готовые, протестированные, задокументированные и функционирующие продукты.
Каждый спринт начинается с совещания по планированию спринта, на котором члены команды определяют цель и распределяют обязанности по выполнению задач, которые они могут выполнить в согласованные сроки.
Во время спринта члены команды сосредотачиваются исключительно на достижении поставленной цели. Они будут собираться каждый день на «летучку» (15-минутное совещание, также называемое Scrum-совещанием), чтобы отчитаться о проделанной работе, обсудить, предстоящие ежедневные задачи и обсудить любые проблемы, с которыми они сталкиваются. «Летучки» — неотъемлемая часть ежедневного процесса отчетности.
Команды могут свободно изменять свой подход, основываясь на целесообразности, исходя из конкретного проекта.
Отчетность
Управление проектами Agile предусматривает регулярную отчетность о положении дел.
Помимо ежедневных «летучек», после каждого спринта члены команды встречаются с владельцем продукта и ключевыми заинтересованными сторонами, чтобы представить результаты спринта. На этом собрании группа совместно решает, что им следует изменить для следующего спринта.
После этого ведущий (а иногда и владелец продукта) проводит ретроспективное совещание, на котором рассматривается процесс, который использовался в предыдущем спринте, чтобы обсудить улучшения, которые нужно ввести в следующем спринте.