Если вам интересна эта тема, то вам точно понравится наша шпаргалка: "Какие шаблоны поведения команды мешают проекту"
Павел Хариков — Head of Project Management Office в VEON Group (Kyivstar, Beeline). У него больше 10 лет опыта проектного и портфельного менеджмента в международных компаниях. Реализовывал масштабные проекты с бюджетом до $150 млн.
В колонке для LABA Павел рассказал, как эффективно управлять гибкими проектами.
Чем гибкие проекты отличаются от консервативных
Рассмотрим отличия на примере четырех составляющих — бизнес-ценность, риск, прозрачность и адаптивность.
#1. Бизнес-ценность
При классическом подходе к управлению проектами бизнес-ценность продукта проявляется в финале. И то в результате огромных усилий и доброй доли везения. А при гибком подходе бизнес-ценность реализуется с каждой итерацией.
Как это происходит? В классическом проекте вы тратите много ресурса, но долго не получаете результат. То есть заказчик инвестирует деньги, чтобы только в конце получить выгоду. А гибкий подход предусматривает регулярную поставку дополнительной ценности. Вы сразу же создаете полезные для бизнеса вещи.
#2. Риск
Поскольку в классическом подходе вы получаете результат в конце проекта, то на протяжении работы вы не можете снизить неопределенность того, как пользователи примут ваш продукт. Это высокий риск.
В гибком подходе все риски вы отрабатываете в ходе реализации, получая обратную связь от пользователя. По сути, у вас есть возможность на каждой итерации немного изменить направление, чтобы их обойти. Поэтому риски здесь — на достаточно низком уровне.
Самый большой риск при реализации любого проекта: ваш заказчик не угадал, и вы создаете продукт, который никому не нужен. С гибкими методологиями этого можно избежать — вы с ранних этапов проекта показываете бизнесу, что создаете, и подстраиваетесь под фидбек.
#3. Прозрачность
С ходом проекта прозрачность растет. На старте всё, как в тумане, — непонятные цели, неизвестно, с кем и для кого работаете. Но постепенно вы разбираетесь, и прозрачность увеличивается.
В гибких подходах с этим проще — здесь вы работаете по маленьким спринтам, детально прорабатывая только ближайший горизонт.
#4. Адаптивность
При гибком подходе на протяжении всего проекта вы можете менять какие-то моменты, адаптируясь к обстоятельствам — внешним или рыночным.
В классическом варианте у вас есть такая возможность только в начале — когда вы планируете. После, когда все зафиксируете, будете четко двигаться по плану, боясь оступиться. Поэтому адаптивность здесь на низком уровне.
Еще важное отличие
Любой проект характеризует треугольник ограничений — бюджет, график и содержание.
В основе классического проекта лежит график и бюджет — если нужно, их можно изменять. Например, если вам важнее вложиться в график, вы увеличиваете бюджет и всеми силами стараетесь успеть. Если важнее бюджет — удлиняете график. Содержание проекта здесь зафиксировано и не меняется.
В гибком подходе такой треугольник — перевернутый. Здесь постоянными обычно остаются график и бюджет: есть финальная дата, к которой вы должны выйти, и сумма денег, в которую нужно вложиться.
При этом содержание не фиксируем — готовы постоянно что-то менять, чтобы получить максимально ценный продукт.
Как планировать в гибких проектах
Может сложиться впечатление, что в проектах с гибким подходом нет планирования. Это не так — просто оно происходит по-другому.
В гибких проектах планирование выполняется постоянно — для каждой итерации. Вы разбиваете проект на мелкие этапы и продумываете реализацию каждого из них. Для РМ-а в таком подходе больше работы — нужно постоянно держать руку на пульсе и вносить корректировки в планы.
Главное здесь — расставлять приоритеты. В первую очередь создаете самое ценное для клиента. Дальше постепенно добавляете новый функционал.
Это гарантирует, что заказчик получит максимальный выхлоп за все ресурсы, которые вы потратили. И сразу же сможет использовать продукт, который вы создали.
Концепция MVP
MVP — это минимально жизнеспособный продукт. Он не идеален, но достаточен, чтобы выполнить базовые потребности клиента.
Лучше всего MVP иллюстрирует картинка:
Здесь показано два подхода к созданию автомобиля.
Первый — вы постепенно создаете продукт, но на каждом из этапов, кроме финального, он не приносит ценности.
Второй — на каждом этапе у вас есть ценность для пользователя. Изначально это скейт, после — самокат, велосипед, мотоцикл и наконец автомобиль. Да, клиент не сразу получает то, что хотел. Но он сразу же получает продукт, который сможет покрыть базовые потребности.
Представьте, что вы хотите открыть ресторан. Какие базовые функции нужно реализовать? Заказ, готовку, оплату и выдачу.
Каждый из этих направлений вы наверняка продумали до мелочей — возможность заказа онлайн, богатое меню и разные способы оплаты. Но сначала сделайте так, чтобы все работало на минимально достаточном уровне, соберите обратную связь от клиентов. А после можете постепенно добавлять новый функционал и развиваться в нужном направлении.
Как работать по системе Scrum
Один из самых известных фреймворков в управлении гибкими проектами — Scrum. Он описывает набор правил, на основании которых работают эффективные команды. Три опоры Scrum — это прозрачность, инспекция и адаптация.
Прозрачность. Важные аспекты процесса доступны всем, кто влияет на его результат. Есть единый стандарт, который дает понимание, как идут дела и кто за что отвечает. У всех одинаковое понимание структуры работы.
Инспекция. Нужно изучать прогресс на пути к цели каждого спринта и определять нежелательные отклонения. Такая инспекция не должна быть частой, чтобы не мешать работе.
Адаптация. Если есть проблемы, которые тормозят работу, нужно что-то менять. Делать это важно как можно скорее, чтобы минимизировать отклонения.
Главное правило Scrum — 3-5-3: есть три роли, пять церемоний и три артефакта.
Три роли — это Scrum-мастер, Product Owner и команда разработки. В гибких подходах нет PM-а, но его функции распределены между Scrum-мастером и Product Owner-ом.
Scrum-мастер отвечает за то, чтобы команда работала по правилам Scrum. Он знает все церемонии и обеспечивает корректную работу коллектива. Контролирует процессы, чтобы задачи вовремя и качественно выполнялись, не дает возможности стейкхолдерам нарушать установленные правила.
Product Owner отвечает за продукт. Он изучает рынок, понимает, как сделать продукт востребованным и постоянно его развивает.
То есть Scrum-мастер отвечает за команду, обеспечивая эффективную работу, а Product Owner отвечает за бэклог и за его приоритизацию — приносит задачи для команды.
Третья роль — команда разработки. Здесь могут быть разные специалисты — в зависимости от того, какой продукт вы создаете. В идеале это 7-9 человек.
Пять церемоний — это проведение спринтов, их планирование, ежедневные стендапы, демонстрация и ретроспектива.
Product Owner приходит со своим списком «хотелок» к команде, и вместе они планируют, как будут их реализовывать. Вся работа разбивается на несколько спринтов, каждый длится от одной до четырех недель.
После планирования команда приступает к работе. Каждое утро во главе со Scrum-мастером все собираются на стендап. Смотрят на канбан-доску и решают, какими задачами будут заниматься. Стендап должен длиться не больше 15 минут.
Когда первый спринт заканчивается, происходит демонстрация. На нее приходят заказчик и все заинтересованные стороны. Смотрят, что у команды получилось сделать за это время и дают обратную связь. Product Owner слушает и вносит корректировки в бэклог.
Важный момент в церемониях — ретроспектива. Это встреча, которую проводит Scrum-мастер, чтобы все обсудили, что было хорошего и плохого за прошедший спринт. Scrum-мастер фиксирует недочеты, чтобы сделать последующую работу эффективнее.
Три артефакта Scrum — это:
- продуктовый бэклог (бесконечный список того, что можно сделать)
- бэклог спринта (четкий список задач, которые выбрала команда)
- инкремент (продукт, который вы показали клиенту на демонстрации)
Весь бизнес-контент в удобном формате. Интервью, кейсы, лайфхаки корп. мира — в нашем телеграм-канале. Присоединяйтесь!
Как оценивать задачи в Scrum
Задачи можно оценивать по времени, которое тратит команда на их решение. Но так не принято. Чаще всего задачи оценивают в стори поинтах — относительной мере объема работы, которую формирует сама команда.
Можно использовать понятные всем характеристики — S, M, L — маленькая, средняя и большая задача. Так команда понимает, что за двухнедельный спринт успевает сделать, например, 20 маленьких задач или 10 маленьких и 4 средних.
Как измерять скорость работы команды
Можно сделать график и с его помощью отслеживать, сколько стори поинтов команда сделала за одну итерацию (спринт). Вот пример:
Задача Scrum-мастера — организовать командную работу так, чтобы скорость работы росла или вышла на определенный уровень и не падала.
Еще эффективность работы команды можно показывать через диаграмму сгорания задач. Например, вы себе представляли, что объем работы в спринте займет 120 стори поинтов и вы сделаете его за семь дней.
Но в реальности все может оказаться по-другому. За первый день можете сжечь не 20 стори поинтов, как планировали, а 12. Потом догонять и отслеживать, из-за чего упала эффективность. Так вы видите, как работаете относительно плана.
В Agile главное, чтобы форма не возобладала над сутью. Это работает только в том случае, если вся организация разделяет ценности Agile Manifesto:
#1. Люди и взаимодействие важнее процессов и инструментов.
#2. Работающий продукт важнее исчерпывающей документации.
#3. Сотрудничество с клиентом важнее согласования условий контракта.
#4. Готовность к изменениям важнее следования первоначальному плану.
Хотите получать дайджест статей?
