Автор статьи: Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.

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

Как с этими проблемами помогает справится Agile?

Но сначала — об основных основных ошибках, которые приводят к этому:

1. Закомитимся сразу на длительный проект, зафиксируем объем, бюджет и сроки.

   Уложиться в этот проектный треугольник — нереально. Чаще всего мы выйдем за бюджет или не успеем в срок. Или успеем, но пострадает качество. При таком подходе много рисков и неопределенности. Заказчик может изменить вводные, ведь он не всегда понимает, что конкретно ему нужно. В итоге все скатывается к абсурду — лишь бы уложиться, забывая про цель и ценность проекта. А все изменения даются сложно, поскольку требуют постоянного переписывания условий, объема работ, согласования бюджета. А доплачивать заказчик готов не всегда. Результат в конце, как правило, тоже может вызвать много вопросов из-за нехватки коммуникаций и отсутствия корректировки в процессе реализации проекта.

2. Привлечем больше ресурсов — закончим в срок.

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

Что имеем в итоге?

Проект замедляется. Сроки переносятся. Бюджет растет. Гарантировать попадание в срок по-прежнему невозможно. Заказчик недоволен изменением условий. Лояльность и доверие начинает быстро снижатся. 

Данные паттерны — коммит на объем, бюджет и сроки не работают, когда мы говорим о создании чего-то нового. Уровень неопределенности всегда будет высоким и поэтому вместо того, чтобы обещать на старте сделать все, Agile подход предлагает более гибкое сотрудничество с заказчиком, обеспечивая стабильность и предсказуемость.

Предлагаю рассмотреть гибридный подход к реализации проекта с помощью философии Agile:

Вместо того, чтобы коммититься на бюджет сроки и объём, на весь проект, мы будем двигаться циклами по 2-3 месяца и объем работы на цикл жестко не фиксировать. Что это нам даст? Во-первых, сразу коммититься на весь проект —довольно рискованно, так как ни заказчик, ни команда еще не знает, сколько подводных камней будет на пути. Даже если и заказчик декларирует, что у него сформирована картина, то все равно он ее будет менять по ходу разработки и первой обратной связи с рынка.

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

Как это реализовать на практике?

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

2. Коммититься мы будем не на все 3 стороны, а на две — зафиксируем бюджет и сроки (бюджет на команду на цикл, срок — длина цикла), а объём оставим гибким. То есть в начале мы обсудим основные задачи, составим беклог, приоритизируем его, выделим самое важное.

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

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

Таким образом, что мы имеем:

• Фиксированый бюджет на цикл.

• Фиксированный срок (2-3 месяца).

• Гибкий объём работ, который можем менять.

• Прозрачность для заказчика.

Что ещё:

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

2. Вероятность создать решение, удовлетворяющее потребности заказчика намного выше. 

3. Заказчик остается спокоен, так как ход проекта прозрачен, бюджет и сроки понятны.

4. Мы не не тратим время на то, чтобы досконально запланировать то, что все равно пойдёт не по плану.

5. Не даём необъективных ожиданий заказчику и выстраиванием с ним доверительные отношения на основе сотрудничества и прозрачности. 

6. Совсем неважно, в какой сфере бизнеса вы работаете, такой подход можно внедрять не только для разработки IT-решений.

Приглашаем всех желающих на открытое занятие «Выбор стратегии тестирования в зависимости от используемой архитектуры», на котором рассмотрим основные стратегии в построении автоматизации тестирования в зависимости от того, какая архитектура применялась в разработке продукта. Будут рассмотрены: монолитная, модульно-монолитная, микросервисная и событийная архитектура. Регистрация на занятие.