Почему внедрение Agile заканчивается провалом

Почему внедрение Agile заканчивается провалом
|10 декабря 2018| Линдси Макгрегор Нил Доши

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

Разработка ПО с помощью Agile

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

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

  • люди и взаимодействие важнее процессов и инструментов,

  • работающее ПО важнее исчерпывающей документации,

  • сотрудничество с клиентами важнее согласования условий контракта,

  • готовность к изменениям важнее следования плану.

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

Например, движущей силой в работе стали процессы и инструменты, а не люди и взаимодействие. Директор по цифровым продуктам одной крупной компании, входящей в список Fortune 100, объяснил это так: «Мы не должны сомневаться в Agile». В другой организации из списка Fortune 500 менеджеры по продуктам и разработчики общаются исключительно с помощью инструментов, в которых менеджеры преимущественно отдают команды подчиненным.

Точно так же документация часто оказывается важнее работающего ПО. В одной крупной технологической компании команда разработки продуктов тратила значительное время на работу с мелкими пользовательскими запросами (которые называли «пользовательскими историями»). Эти запросы накапливались, ставились в очередь задач и попадали первому освободившемуся разработчику. В результате задач становилось много, и в конце концов этот процесс превратился в классический waterfall, то есть модель, при которой работа передается из отдела продуктов разработчикам. Но именно такое взаимодействие была призвана устранить методология Agile! Неудивительно, что технический директор этой компании прокомментировал ситуацию так: «Мои сотрудники чувствуют себя как повара, которые получают заказы в заведении быстрого питания».

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

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

Например, партнер одного венчурного фонда рассказал, как компания по разработке видеоигр в течение года занималась игрой, хотя все сотрудники считали ее неудачной. В конце концов, они поняли, что напрасно потратили время и деньги.

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

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

Полная версия статьи доступна подписчикам
Выберите срок онлайн-подписки:

https://hbr-russia.ru/management/korporativnyy-opyt/788835

2018-12-10T09:32:30.238+03:00

Fri, 06 Mar 2020 15:27:19 GMT

Почему внедрение Agile заканчивается провалом

Как достичь настоящей гибкости в организации

Менеджмент / Корпоративный опыт

https://cdn.hbr-russia.ru/image/2018/9k/k6fxz/original-q5h.jpg

Harvard Business Review РоссияHarvard Business Review Россия

Harvard Business Review РоссияHarvard Business Review Россия