Agile или нет: подходят ли вам гибкие методы управления и работы

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

В 2001 году известные разработчики ИТ- систем собрались вместе, чтобы описать, как правильно создавать новые продукты в отрасли. Результатом этой встречи стал Agile Manifesto, текст которого был переведен на более чем 50 языков и получил глобальное распространение в ИТ-сфере. В нем сформулировано 4 базовых принципа и 12 правил работы по Agile, которые многие команды программистов взяли на вооружение.

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

Манифест — то, в чем все эти люди смогли максимально сойтись.
Для методологов проектного управления Agile
делится на:

Mindset, образ мышления — установки, парадигмы, взгляды человека, нацеленные на быструю реакцию.
4 базовых принципа и 12 правил - философская основа Agile.
Набор практик: что делать и как выстраивать
работу, чтобы образ мышления и принципы
манифеста естественно сочетались

Американские горки продуктивности

Любая технология или подход переживают различные стадии: от популярности и очарования, до бесполезности и забытья. Компания Gartner, знаменитая своими исследованиями ИТ-рынка, описала эту динамику циклами хайпа — Hype cycle.

Первая стадия: сначала никто о технологии не знает, но постепенно о ней начинают говорить — хайп начинает расти.

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

Далее выясняется, что она работает не всегда, не везде, не у всех.

Потом наступает разочарование.

На следующей стадии приходит понимание, что где-то технология все-таки применима, а кое-где по-настоящему эффективна.

Последняя стадия, следующая за этим пониманием, — выход на плато производительности.

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

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

Agile для бренда или результата

В ИТ-индустрии Agile сейчас находится на «выходе на плато производительности», а в российском бизнесе во многом благодаря Герману Грефу — на пике. Примерно три года назад председатель правления Сбербанка начал говорить, что те, у кого не будет Agile в ближайшее время, умрут в страшных муках. Сбербанк стал внедрять свой Agile-подход, так называемый Сберджайл. При этом никто, кроме сотрудников, вообще-то не знает, как выглядит Сберджайл, как именно он внедрялся и какова общая эффективность от его применения. Узнать это снаружи — нельзя. Информация закрыта. И, насколько мне известно, в Сбербанке оценка эффективности этого подхода не проводилась.

Зачем Agile Сбербанку? На мой взгляд, Сбербанк внедрял Agile, потому что руководство хотело позиционировать себя как инновационную, передовую ИТ-компанию, а не как традиционный и консервативный банк. Они убедили многих, что стремительно двигаются в сторону цифровизации и технологизации.

Упорядоченность и запутанность

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

Одна из самых известных — модель Дейва Сноудена («Киневин») CYNEFIN. Модель Киневин говорит о системах в широком смысле, как о наборе элементов и связей между ними. Касательно бизнеса проект — это система, подразделение — система, отдельная команда — тоже система. Все системы бывают:

упорядоченные простые, с понятной причинно-следственной связью. Табуретка на 4 ножках. Отпилишь две ножки — табуретка упадет. Велосипед. Крутишь педали — едет. Все понятно;

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

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

хаотические. Что бы ни делали — непонятно, как это устроено.

Представим, что нужно выпустить брошюру к конференции, а сотрудники никогда не занимались издательством или публикациями? Это сложная система, но мы проанализировали ее этапы и привлекли экспертов, которые подсказали как нужно. Другой уровень — нужно выпустить журнал с использованием виртуальной реальности для тех, у кого есть очки дополненной реальности. Они смогут в 3D-формате взаимодействовать со статьями. Технически это можно сделать, но совершенно непонятно, как все это будет работать и нужно ли кому-то. Экспертов позвать нельзя, потому что их просто нет. Это и есть Agile, ведь нужно экспериментировать. Как раз для таких запутанных и комплексных историй он подходит лучше всего.

Мы проводим небольшие эксперименты, создаем продукт, который нам удается собрать на свой страх и риск. Этот продукт в Agile называется MVP (minimal viable product) или минимально жизнеспособный продукт. MVP быстро оказывается на рынке, и можно протестировать насколько эффективно он помогает решать проблемы целевой аудитории, получить обратную связь и доработать продукт в дальнейшем, экономя средства.

Agile или не Agile?

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

Стоит применять Agile, когда существуют:

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

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

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

Нецелесообразно применять Agile, когда существуют:

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

Отсутствие возможности финансировать доработки. Изменения и многочисленные доработки продукта могут значительно увеличить стоимость разработки и сделать Agile-подход неприемлемо дорогим и экономически неоправданным.

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

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

Чек-лист готовности

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

Что нужно проверить до начала работы по Agile.

Команда и стейкхолдеры готовы принять принципы и правила Agile-подхода. Принципы и правила прописаны в манифесте, в множестве книг и статей. Самым сложным для нашей ментальности является «право на ошибку». Для неопределенности ошибки — это нормально. Аgile — это и есть институционализированный метод проб, ошибок, экспериментов. Делаем, смотрим, что получается, что нет, быстро переделываем. Работает принцип «fail fast, fail safe» (ошибайся быстро, ошибайся безопасно). Неважно, что ошибся, важно, что ошибку обнаружили, распознали и быстро исправили. Это один из очень серьезных барьеров на пути внедрения Agile в России, где у многих осталось восприятие, что «у каждой аварии есть имя, фамилия и отчество». Если команда сделала что-то неправильно, не должно быть «расстрелов».

Есть Agile-команда. Agile-команда — это непростая команда. В ней должны сочетаться ряд характеристик:

Она должна быть компактная: 7 сотрудников плюс-минус 2 человека. Ее еще называют «2 pizza team», команда, которую можно накормить двумя пиццами. То есть совсем небольшая. Техники масштабирования Agile на большие команды существуют, но они очень и очень нетривиальны. Начинать с них точно не стоит;
В команде должны присутствовать сотрудники, обладающие компетенциями, необходимыми для разработки продукта и представляющие все подразделения, которые необходимы для разработки продукта;
У сотрудников должно быть достаточно времени для работы в команде. Крайне желательно, чтобы они все свое время посвящали работе над проектом, принцип «100 на 0» — 100% вовлечения;
Крайне желательно, чтобы все сидели вместе, в одном помещении;
Важно, чтобы команда брала на себя ответственность. Наши сотрудники не любят брать на себя ответственность. В моих опросах руководства компаний это одна из самых часто упоминаемых проблем.

Есть владелец продукта (заказчик), который:

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

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

Согласованы накладываемые на проект ограничения. Между командой и ключевыми заинтересованными сторонами достигнуты и документально зафиксированы договоренности по критическим ограничениям: срокам, бюджету, ресурсам и так далее.

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

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

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

Об авторе. Павел Алферов — профессор бизнес-практики Московской школы управления «Сколково».

Источник: https://hbr-russia.ru/management/prinyatie-resheniy/809338