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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Единица производительности команды — минимально жизнеспособный продукт. Команды часто тратят время на слишком тщательную адаптацию продукта. Чтобы избежать этого и как можно скорее понять, что устроит клиентов, следует не только формулировать идеи для стратегических задач, но и быстро проверять гипотезы. Иначе говоря, команды должны действовать с максимальной «скоростью познания истины».

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