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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Иногда для этого требуется уменьшить свойства продукта до самого минимума, необходимого для тестирования. Также в подобных случаях команда может просто проводить своего рода «полевое» исследование.

3. В центре внимания команды должен находиться клиент. Процесс создания программного обеспечения (даже для внутреннего пользования) должен быть однозначно ориентирован на клиента.

В самом простом случае эти принципы реализуются так:

• Задачи всегда должны формулироваться с учетом их воздействия на клиента;

• Собрания команды всегда должны начинаться с новой информации о клиентах, и на них следует приглашать сотрудников, работающих с клиентами;

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

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

4. Используйте временные ограничения, чтобы сделать эксперименты более целенаправленными. Гибкая разработка программного обеспечения поощряет ограничения по времени как способ оптимального проведения экспериментов. С другой стороны, специалисты, работающие по методу Agile, избегают ограничений по времени и не устанавливают дедлайнов для сдачи проектов, опасаясь эмоционального давления.

Однако тяжелейшее разочарование испытывает разработчик ПО, который потратил несколько месяцев на создание бесполезного продукта. Эти чувства нарушают эмоциональное равновесие («Я всех подвел») и вызывают инерцию («Зачем я этим вообще занимаюсь?»). Поэтому следует заранее договориться, насколько далеко может зайти разработчик, прежде чем он удостоверится, что по-прежнему движется в правильном направлении. Чем выше неуверенность команды в гипотезе и риск, тем короче должен быть этот путь. Также не следует забывать, что ограничения по времени — это не дедлайн для сдачи проекта. Они лишь очерчивают глубину и качество эксперимента перед реальными испытаниями. Таким образом, ограничения по времени должны стать мотиватором для команды.

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

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

• Эксперты работают не в одной, а в «параллельных» командах. Например, в команде разработки продукта есть отдельные «команды ускорения». Это не кросс-функциональная команда.

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

• Отдел проектирования и разработки продукта имеют разные цели. Руководители обоих отделов пользуются своей властью, чтобы заставить подчиненных ставить цели отдела выше всех других целей, в том числе целей кросс-функциональной команды. Эти конфликты ведут к столкновениям в рабочих командах и мешают настоящей командной работе.

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

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

6. Команда должна постоянно критически оценивать свою работу. Аксиома проектирования, известная как закон Конвея, гласит: организация, проектирующая информационную систему, производит продукт, который копирует структуру и связи в самой организации. То есть если у вас сплоченная организация, вы произведете монолитный продукт. Если компания сегментирована, продукт будет таким же.

Следует постоянно сопоставлять структуру и рабочий процесс с решаемой проблемой, если вы хотите преодолеть закон Конвея. У команды должна быть простая структура и ее нужно постоянно критически оценивать и настраивать.

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

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

Об авторах

Линдси Макгрегор (Lindsay McGregor) — соавтор бестселлера «Primed to Perform: How to Build the Highest Performing Cultures Through the Science of Total Motivation». CEO и одна из основательниц стартапа Vega Factor, помогающего организациям трансформировать свою культуру. Ранее вела проекты в McKinsey & Company. Имеет степень MBA Гарвардской школы бизнеса и степень бакалавра Принстонского университета.

Нил Доши (Neel Doshi) — соавтор бестселлера «Primed to Perform: How to Build the Highest Performing Cultures Through the Science of Total Motivation». Один из основателей Vega Factor. Ранее был партнером в McKinsey & Company. Имеет степень MBA Уортонской школы бизнеса и степень бакалавра Массачусетского технологического института.