Тармолов про работу

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

Обычно объяснение методологии Agile сводится к перечислению идей и принципов из манифеста. Но основатели Agile заложили в методологию решение конкретной проблемы.

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

Для полноценного планирования проекта необходимо провести оценку задач, просчитать риски, нарисовать диаграмму Ганта и т.д. На этом бюрократическая часть не заканчивается, ведь нужно еще поддерживать построенную диаграмму Ганта и остальное описание проекта. Это много времени и сил.

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

Тщательное планирование на начальном этапе исчезает, т.к. в нашем изменчивом мире технические требования также «плывут». Очень часто по мере движения IT-проекта всплывают сюрпризы, в корне меняющие сроки завершения проекта.

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

Далее этот измеримый показатель декомпозируется на несколько более гранулярных метрик.

Например, сервис хочет заработать больше денег на 30%. Декомпозируем метрику на две: вырастить аудиторию на 10% и повысить конверсию в рекламном продукте на 18%. Рост аудитории также можно декомпозировать по способу получения трафика: 2% через SEO, 3% через продуктовые запуски и 5% с помощью маркетинга.

Автономные команды со всеми нужными ресурсами работают над этими метриками и пытаются всеми силами достигнуть таргета. Как они будут достигать требуемых результатов — неважно. Дается полная свобода. Главное, чтобы метрика росла :)

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

И если изначальная "главная" метрика была выбрана верно, то Agile подход поможет добиться хороших результатов.

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

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

У адептов Agile нет цели дедлайна, есть только путь.

#менеджмент

👍13

www.tgoop.com/tarmolov_work/177

1.6K viewsedited  Nov 17, 2023 at 11:56

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

Обычно объяснение методологии Agile сводится к перечислению идей и принципов из манифеста. Но основатели Agile заложили в методологию решение конкретной проблемы.

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

Для полноценного планирования проекта необходимо провести оценку задач, просчитать риски, нарисовать диаграмму Ганта и т.д. На этом бюрократическая часть не заканчивается, ведь нужно еще поддерживать построенную диаграмму Ганта и остальное описание проекта. Это много времени и сил.

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

Тщательное планирование на начальном этапе исчезает, т.к. в нашем изменчивом мире технические требования также «плывут». Очень часто по мере движения IT-проекта всплывают сюрпризы, в корне меняющие сроки завершения проекта.

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

Далее этот измеримый показатель декомпозируется на несколько более гранулярных метрик.

Например, сервис хочет заработать больше денег на 30%. Декомпозируем метрику на две: вырастить аудиторию на 10% и повысить конверсию в рекламном продукте на 18%. Рост аудитории также можно декомпозировать по способу получения трафика: 2% через SEO, 3% через продуктовые запуски и 5% с помощью маркетинга.

Автономные команды со всеми нужными ресурсами работают над этими метриками и пытаются всеми силами достигнуть таргета. Как они будут достигать требуемых результатов — неважно. Дается полная свобода. Главное, чтобы метрика росла :)

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

И если изначальная "главная" метрика была выбрана верно, то Agile подход поможет добиться хороших результатов.

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

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

У адептов Agile нет цели дедлайна, есть только путь.

#менеджмент

BY Тармолов про работу