В каких случаях Agile-подход бесполезен

Мнение продуктового разработчика Джона Катлера.

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

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

Если посмотреть на время разработки продукции — время от момента, когда мы только придумали новую идею, до момента, когда идея дошла до клиента, — то заметно, что большая его часть тратится на «ожидание». 15% пропускной способности (соотношение рабочего времени и времени на разработку продукции) — это норма. Невероятно, правда?

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

Нередко команды тратят 75% своего времени на незапланированную работу и многозадачность. Иногда сотрудники вообще так и не приступают к основной работе. Могут случаться разные накладки, и зачастую такая сверхурочная работа не отслеживается системой. Скорее всего, команда даже жалуется на этот счёт. Но после продолжительного игнорирования сотрудники всё-таки смиряются с печальной действительностью.

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

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

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

В большинстве компаний всё наоборот — «размер» работы не имеет никакого отношения к срокам выполнения задач. Почему? Слишком много факторов влияют на то, сколько времени уходит на завершение конкретной работы (например, зависимость одной задачи от другой, появление незапланированных дел, большое количество одновременной работы).

Еще очень много усилий уходит на то, чтобы сократить так называемый «риск поставки». Например, когда вы создаёте индивидуальные проекты, а покупатель платит после получения продукта. При рабочей SaaS-модели нам платят не тогда, когда мы сдаём работу, — выгода приходит со временем. Я называю это «риском выгоды» (опасность в том, что вся работа может оказаться бесполезной).

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

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

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

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

И снова я возвращаюсь к Agile. Agile бесполезен, если не выступает катализатором постоянного улучшения. Scrum и SAFe (Scaled Agile Framework) бесполезны, если не служат катализатором постоянного улучшения. Почему? Потому что все эти спринты, описания требований заказчика, демо-версии, выходящие раз в две недели, отчасти вас только замедляют.

Чтобы стать более проворным с помощью Agile, придется потратить огромное количество денег и энергии на:

• Выполнение действительно нужной работы (реализацию преимуществ).
• Автоматизацию, закупку инструментов, настройку конвейера, использование инструмента feature flags и так далее. А также на интеграцию разработки и эксплуатацию ПО.
• Изменение культуры управления.
• Настройку финансирования. Нужно перейти на постепенное финансирование стратегических целей, вместо финансирования проектов.
• Распределение ресурсов для решения проблем (регулярная перестройка кода, перепроектирование архитектуры ПО).
• Систематизирование потоков ценности. Вы должны рассматривать свою компанию как сервисную среду.
• Свежий взгляд на коллективную работу.

Простого решения нет. Придётся поработать. Сторонитесь тех, кто говорит вам иначе.

#agile