Как рассчитать бюджеты гибких проектов (и придерживаться их)

С тех пор, как Agile Manifesto был впервые задуман еще в 2001 году, овладение Agile-менеджментом проектов стало святым Граалем для многих менеджеров по продуктам.

И кайф оправдан. Согласно отчету VersionOne 2016 State of Agile Report , 98% участников утверждают, что их организация добилась успеха благодаря гибким проектам. Аналогичным образом, другие исследования показали, что Agile-подход может ускорить время доставки на рынок в среднем на 37% и повысить продуктивность команды на 16%.

В результате, вопрос вокруг Agile не так уж велик: «Стоит ли нам попробовать?» (поскольку результаты говорят сами за себя), но «Как мы можем заставить Agile работать на нашу компанию и команду проекта?»

Мы поговорили с пятью успешными командами Agile во время исследования нашего руководства Agile по управлению проектами программного обеспечения. В этой статье мы поделимся некоторыми из их стратегий по претворению в жизнь сути Agile Manifesto, начиная с точного, но гибкого бюджета проекта.

Гибкие процессы приводят к точным бюджетам проекта

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

Более того, каждый шестой ИТ-проект имеет перерасход средств на 200% и перерасход графика почти на 70%, поэтому заинтересованные стороны захотят, чтобы бюджет проекта (как с точки зрения стоимости, так и времени реализации) был точным.

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

Чтобы компенсировать эти риски, важно, чтобы Agile-команды:

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

4 стратегии для составления точного бюджета проекта

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

1. Убедитесь, что все ключевые элементы входят в общий объем проекта.

Для создания реалистичного бюджета проекта ваша команда сначала должна определить ожидания и требования заинтересованных сторон. Для этого британская компания по разработке программного обеспечения IT Enterprise создает интеллектуальную карту проекта для каждого нового проекта, которой они делятся со своим клиентом на стадии консультации по проекту.

«Визуальное отображение требований клиента сразу демонстрирует сложность проекта как для нас, так и для клиента», - делится основатель IT Enterprise Томас Де Вос. «Связывание различных разделов интеллект-карты позволяет команде визуализировать взаимодействие между различными областями проекта, одновременно определяя пользовательскую историю клиента и то, как мы будем ее добиваться».

Ментальная карта бюджета Agile

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

Делясь визуальным представлением о масштабах проекта с клиентом до подписания каких-либо соглашений, ваша проектная группа может гарантировать, что то, что входит в объем вашего проекта (и бюджет), соответствует ожиданиям ваших заинтересованных сторон.

Затем вы можете предоставить реалистичный бюджет проекта, убедившись, что все ключевые функции были учтены в этой цене.

2. Наладить процесс уточнения бюджета.

Когда у вас появится четкое представление о требованиях к проекту, вы можете начать рассчитывать ожидаемую стоимость работы.

Американская компания по разработке Agile-технологий Praxent использует конус неопределенности для разработки реалистичного бюджета для своих программных проектов.

Конус неуверенности от Праксента

«Мы используем последовательность Фибоначчи для оценки запросов на новые функции», - делится Тим Гамильтон, генеральный директор Praxent. «Но чтобы не выходить за рамки, нужно с самого начала точно установить цену на продукт».

Процесс создания реалистичного бюджета Praxent начинается с трех этапов, охватывающих определение продукта, требования к продукту и UX-дизайн:

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

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

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

В результате, благодаря процессу составления бюджета, Гамильтон говорит, что команда Praxent смогла управлять своими проектами и даже превзойти ожидания по бюджету и объему.

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

Одна из ключевых ценностей Agile Manifesto заключается в том, что «меняющиеся условия применяются на каждом этапе процесса, чтобы предоставить заказчику конкурентное преимущество».

Способность адаптироваться к развивающимся рынкам и меняющимся требованиям бизнеса - вот что делает Agile уникальным.

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

Ниже приведены два варианта совместной работы над функциями.

Отслеживайте через физическую доску Scrum для спринтов

Компания AndPlus, занимающаяся гибкой разработкой, позволяет заинтересованным сторонам управлять функциями с помощью физической доски Kanban для своих карточек задач Scrum, которая предоставляется клиентам для отслеживания прогресса проекта:

«Мы отслеживаем объем работ с нашими клиентами, используя карточки задач разного цвета на нашей настенной панели управления проектами, чтобы представить элементы, которые были добавлены после создания плана выпуска. Это позволяет визуально легко (как для нас, так и для клиента) идентифицировать элементы или функции, которые были добавлены после первоначального объема проекта, поэтому их необходимо обменять на другую функцию с эквивалентными часами разработки, чтобы оставаться в рамках бюджета, или отложить до более поздний выпуск ». -Джонатан Роджер, операционный директор и сертифицированный мастер Scrum в AndPlus

Канбан-доска

Управляйте масштабом проекта с помощью онлайн-инструмента для совместной работы

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

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

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

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

4. Используйте свой бюджет как средство для создания изысканного продукта.

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

Йой Сигурдссон, основатель CrankWheel , обнаружил, что сокращение ненужных функций фактически позволило их команде согласовать приоритеты бизнеса и пользователей.

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

Как только у вас будет убедительная обратная связь от заинтересованных сторон по основным функциям, доска Kanban может помочь в управлении функциями. Разложив все задачи в рамках спринта проекта и поделившись этой дорожной картой спринта с заинтересованными сторонами, вы можете определить ограничение на количество функциональных задач на спринт. Это гарантирует, что проект не будет перегружен задачами, что поможет вам сохранить ваш продукт как усовершенствованным, так и целевым.

Как вы управляете бюджетом проекта?

Каковы ваши лучшие методы гибкого подхода к управлению проектами и составлению бюджета? Делитесь советами в комментариях!

Вы также можете найти эти другие статьи о бюджетах проектов:

• 3 причины, по которым ваш проект превысит бюджет
• Как построить свой первый бюджет
• Бесплатный шаблон бюджета для малого бизнеса