Автор статьи: Дмитрий Курдюмов
Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.
Многие из нас, кто занимался реализацией проектов, сталкивался со сложностью планирования и реализации точно в срок качественного результата. И в итоге тратили большое количество времени на планирование, которое впоследствии все равно не сработало и требовало корректировки из-за высокой неопределенности на старте. И в итоге все могло привести к тому, что проект сыпался, сроки горели, требования менялись. А заказчик с каждым днем терял лояльность.
Как с этими проблемами помогает справится Agile?
Но сначала — об основных основных ошибках, которые приводят к этому:
-
Закомитимся сразу на длительный проект, зафиксируем объем, бюджет и сроки.
Уложиться в этот проектный треугольник — нереально. Чаще всего мы выйдем за бюджет или не успеем в срок. Или успеем, но пострадает качество. При таком подходе много рисков и неопределенности. Заказчик может изменить вводные, ведь он не всегда понимает, что конкретно ему нужно. В итоге все скатывается к абсурду — лишь бы уложиться, забывая про цель и ценность проекта. А все изменения даются сложно, поскольку требуют постоянного переписывания условий, объема работ, согласования бюджета. А доплачивать заказчик готов не всегда. Результат в конце, как правило, тоже может вызвать много вопросов из-за нехватки коммуникаций и отсутствия корректировки в процессе реализации проекта.
-
Привлечем больше ресурсов — закончим в срок.
Не выйдет. При пополнении команды специалистами растет количество коммуникаций в команде, новым людям нужно притереться друг к другу, ломается выстроенная динамика работы. Также новым людям в команде требуется адаптация и погружение. Новички всегда делают больше ошибок и за ними приходится исправлять. В итоге новые люди в команде забирают время тех, кто уже давно работает. И вместо ускорения мы, как правило, получаем замедление. И здесь, как снежным ком, появляются мысли: а не нанять ли нам еще разработчиков? В результате растет бюджет, падает производительность и никаких выгод ни для одной стороны. Таким образом, увеличение команды для того, чтобы закончить быстрее в срок, никаких выгод в моменте не приносит, а только раздувает бюджет и еще больше замедляет разработку.
Что имеем в итоге?
Проект замедляется. Сроки переносятся. Бюджет растет. Гарантировать попадание в срок по-прежнему невозможно. Заказчик недоволен изменением условий. Лояльность и доверие начинает быстро снижатся.
Данные паттерны — коммит на объем, бюджет и сроки не работают, когда мы говорим о создании чего-то нового. Уровень неопределенности всегда будет высоким и поэтому вместо того, чтобы обещать на старте сделать все, Agile подход предлагает более гибкое сотрудничество с заказчиком, обеспечивая стабильность и предсказуемость.
Предлагаю рассмотреть гибридный подход к реализации проекта с помощью философии Agile:
Вместо того, чтобы коммититься на бюджет сроки и объём, на весь проект, мы будем двигаться циклами по 2-3 месяца и объем работы на цикл жестко не фиксировать. Что это нам даст? Во-первых, сразу коммититься на весь проект —довольно рискованно, так как ни заказчик, ни команда еще не знает, сколько подводных камней будет на пути. Даже если и заказчик декларирует, что у него сформирована картина, то все равно он ее будет менять по ходу разработки и первой обратной связи с рынка.
Для заказчика цель проекта — заработать больше денег, получить эффект от проекта, а не просто разработать какой-то объем работы. Поэтому правильнее будет создавать этот проект в сотрудничестве с заказчиком, проводя тестирование на пользователях и собирая реальную обратную связь с рынка. И корректировать вектор на основе новых данных.
Как это реализовать на практике?
1. Вместо того, чтобы планировать весь проект, мы будем планировать его циклами по 2-3 месяца. К примеру, в первом цикле мы будет создавать минимально работающее решение, которое будет протестировано вместе с заказчиком на пользователях. На цикл должна быть сформирована четкая цель, чтобы команда понимала, куда она должна прийти.
2. Коммититься мы будем не на все 3 стороны, а на две — зафиксируем бюджет и сроки (бюджет на команду на цикл, срок — длина цикла), а объём оставим гибким. То есть в начале мы обсудим основные задачи, составим беклог, приоритизируем его, выделим самое важное.
3. Внутри трехмесячного цикла запустим недельные или двухнедельные итерации, в ходе которых будем создать готовый кусок продукта и показывать его заказчику, чтобы вместе обсуждать, куда двигаться дальше. То есть после каждого спринта мы будем видеть новое приращение к продукту, обсуждать его и корректировать беклог. Перед каждой итерацией мы будем проводить тщательную декомпозицию и приоритизацию, постоянно выкидывая лишнее и помня про цель цикла.
4. По результатам трехмесячного цикла подводим итоги и планируем следующий цикл. И так далее. То есть после того, как мы запустили минимально работающее решение, мы можем сильно скорректировать план, поскольку получим много обратной связи с рынка. И это нормально, так как это ведет к достижению целей заказчика, а не формальному выполнению плана.
Таким образом, что мы имеем:
-
Фиксированый бюджет на цикл.
-
Фиксированный срок (2-3 месяца).
-
Гибкий объём работ, который можем менять.
-
Прозрачность для заказчика.
Что ещё:
-
Самое важное, что в такой модели, с одной стороны, у вас управляемый расход бюджета, понятные сроки и объём зависит от того, что вам действительно нужно, то есть на основе полученной информации.
-
Вероятность создать решение, удовлетворяющее потребности заказчика намного выше.
-
Заказчик остается спокоен, так как ход проекта прозрачен, бюджет и сроки понятны.
-
Мы не не тратим время на то, чтобы досконально запланировать то, что все равно пойдёт не по плану.
-
Не даём необъективных ожиданий заказчику и выстраиванием с ним доверительные отношения на основе сотрудничества и прозрачности.
-
Совсем неважно, в какой сфере бизнеса вы работаете, такой подход можно внедрять не только для разработки IT-решений.
Приглашаем всех желающих на открытое занятие «Выбор стратегии тестирования в зависимости от используемой архитектуры», на котором рассмотрим основные стратегии в построении автоматизации тестирования в зависимости от того, какая архитектура применялась в разработке продукта. Будут рассмотрены: монолитная, модульно-монолитная, микросервисная и событийная архитектура. Регистрация на занятие.
ссылка на оригинал статьи https://habr.com/ru/company/otus/blog/674992/