Agile и неопределенность

Как работает фреймворк Cynefin

Давайте посмотрим на примере, как работает фреймворк Cynefin. Представим себе три ситуации.

1. Нужно внедрить новую ИТ-систему, например, «1С:ERP Управление предприятием», но ИТ-специалисты никогда не работали с ней. У нас нет знаний по работе с этой ERP-системой, но у нас есть большой опыт внедрения ИТ-систем других вендоров, в том числе и ERP-систем, мы можем проанализировать наш проектный опыт. А также можем привлечь экспертов по «1С:ERP Управление предприятием», очевидно, что они есть и они подскажут как нужно внедрять. В результате, весьма вероятно, мы сможем обоснованно и реалистично спланировать ресурсы, сроки и риски. И это означает, что мы находимся в области усложненных систем.
2. Нужно внедрить ИИ-систему интеллектуальных подсказок для работников, причем с использованием технологий виртуальной и дополненной реальности. Технически это можно сделать, но совершенно непонятно, как все это будет работать, такого никто еще не делал в нашей индустрии. Даже по отдельности опыта использования ИИ и виртуальной и дополненной реальности еще мало, а уж вместе и подавно. Экспертов спросить не получится, потому что их просто нет. Это и есть область сложных систем, ведь нужно экспериментировать и исследовать, причем нам самим и в нашей конкретной ситуации. Большинство проектов цифровой трансформации относятся именно к этой области.
3. Нужно внедрить нейросеть в хорошо знакомой области – первой линии ответов на вопросы пользователей. Отчасти ситуация понятна, мы знаем эти вопросы и в целом знаем, как на них надо отвечать, мы этим занимаемся постоянно. Но, с другой стороны, необходимо обучить нейросеть, и это незнакомая нам часть работы, непонятно сколько нужно данных и какой будет результат. Кроме того, нейросети активно развиваются и надо идти в ногу с их прогрессом. Мы находимся в области между усложненными и сложными системами, то есть в области ограниченной сложности.

Agile в области ограниченной сложности

Как раз для таких ситуаций Agile и подходит лучше всего (рис. 5). Мы проводим небольшие эксперименты с нейросетями и создаем минимально жизнеспособный продукт (Minimal Viable Product, MVP). Он, вероятно, сначала будет далеко не идеальный, но его можно протестировать в реальной деятельности (возможно не во всей, а в пилотной зоне) и посмотреть, насколько эффективно он помогает решать задачу ответа пользователям. Здесь нетрудно получить обратную связь и доработать продукт в дальнейшем, экономя средства. Мы можем двигаться последовательными итерациями, ситуация не очень динамична и это позволяет (подробнее о ней читайте в статье Пограничная (liminal) версия фреймворка Cynefin).

Рис. 5. Действия во фреймворке Cynefin, в том числе и в области ограниченной сложности

Однако, встает вопрос, почему в сложности мы работаем другими методами, более близкими к исследованию и безопасным экспериментам? Почему Agile не годится для работы в сложной системе? Ведь там, на первый взгляд, все очень похоже. Как это ни странно звучит, но гибкие методологии оказываются недостаточно гибкими для работы в сложной системе. Можно выделить две основные причины этому.

1. Динамика системы. Да, система динамична, но не сильно, то есть за время итерации она меняется несущественно. Инструменты Agile предполагают, что для проверки гипотезы надо запланировать соответствующие работы в бэклоге, выполнить эти работы в ходе итерации (спринта) и затем проверить как работает продукт/система на реальных данных. Этот подход работает при условии, что ситуация не слишком динамична, пока мы формируем гипотезу и проверяем, их ситуация не слишком меняется. То есть системы, когда мы выдвигали гипотезу и когда ее проверяем, не слишком сильно отличаются. Изменениями системы можно пренебречь. В этом случае, если наша гипотеза или идея не сработала, то ничего страшного, мы проверяем следующую.
2. Уровень неопределенности. Инструменты Agile предполагают, что неопределенность такова, что гипотез не так уж и много. Более того, неопределенность позволяет ранжировать гипотезы, у нас есть разумные основания для ранжирования задач бэклога.

Эти условия соблюдаются в области ограниченной сложности. Но сложная система слишком динамична и/или неопределенность слишком велика. Если у нас одновременно 20 гипотез и все хорошо бы проверить до того, как система заметно изменится? Как тогда выбирать, какие гипотезы проверить в первую очередь? Если первые гипотезы не сработают, то нам придется несколько раз выбрасывать то, что сделано в ходе итерации (спринта), и если он длится, скажем 3-4 недели, то придется ждать слишком долго.

Именно таким образом движется наука, и в сложной системе надо использовать такие исследовательские методы (подробнее о ней читайте в статье Пограничная (liminal) версия фреймворка Cynefin).

Разные проектные подходы для разных систем

Фреймворк Cynefin хорошо показывает, где и в каких условиях можно применять различные проектные подходы и инструменты (рис. 6).

1. В ясных и очевидных системах проекты типовые, ничего нового, это уже много раз делалось. Здесь не надо сильно думать, не надо использовать большой инструментарий проектного управления, достаточно стандартных облегченных инструментов и типовых планов. Иногда, к сожалению, в таких ситуациях пытаются использовать сложные проектные инструменты и это плохо получается, люди говорят: «зачем, это же тривиально».
2. В усложненных системах проекты экспертные, они строятся на экспертном опыте и знаниях. И здесь хорошо подойдет классическое проектное управление, которое как раз и построено как «лучшие практики» и весь тот набор инструментов, который приведен в PMBoK. Но, необходимо отметить, что проектные ситуации здесь уже не типовые и поэтому «лучшие практики» требуют экспертной адаптации под конкретный проект. Что, как правило и происходит в реальности.
3. В сложных системах проекты запутанные, с высокой неопределенностью и в заметно динамичной ситуации. Никто этого еще не делал и экспертов нет. Поэтому единственный вариант – найти свой путь самим путем исследований и экспериментов. Причем мы должны вести параллельные эксперименты по нескольким направлениям, так как всегда есть много вариантов идей и гипотез как это можно сделать.
4. В ограниченно сложных системах проекты – это Agile-проекты. Здесь средняя неопределенность и невысокая динамика. Выше мы пояснили, что именно в этих условиях мы можем идти последовательными итерациями.
5. В хаотических системах проекты крайне неопределенные (высокорисковые) и крайне динамические. Тут подойдут только инструменты управления в реальном времени, например, оперативно-диспетчерское и штабное управление.

Рис. 6. Различные проектные подходы и инструменты во фреймворке Cynefin.

Когда нужен Agile, а когда нет?

Эксперты в области управления проектами, среди которых нам бы хотелось выделить Павла Алферова, профессора практики «Школы управления Сколково», разработали методические рекомендации по применению Agile. Приведем некоторые из них.

Agile применять стоит, когда:

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

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

1. Невозможно или очень дорого менять созданный продукт. Если есть технологические, инфраструктурные, политические барьеры, препятствующие постепенному выпуску продукта путем его поэтапного улучшения.
2. Отсутствие возможности финансировать доработки. Изменения и многочисленные доработки продукта могут значительно увеличить стоимость разработки и сделать Agile-подход неприемлемо дорогим и экономически неоправданным.
3. Высокая цена ошибки. Если нет возможности быстро, регулярно и безопасно демонстрировать создаваемые версии продукта (инкременты). Если каждый выпуск без исчерпывающих проверок несет существенные риски финансового, имиджевого характера или безопасности. Если от наших экспериментов кто-то умрет — это будет катастрофическая итерация.
4. Высокая предсказуемость. Условия реализации проекта стабильны, требования к продукту незначительно меняются и известны заранее, проект носит типовой характер, у команды есть опыт реализации таких проектов и нет ценности в получении результата проекта частями в короткие сроки.

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

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

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

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

Это один из очень серьезных барьеров на пути внедрения Agile в России, где у многих осталось восприятие, что «у каждой аварии есть имя, фамилия и отчество». Если команда сделала что-то неправильно, не должно быть «расстрелов».

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

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

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

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

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

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

***

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

Комментарии 0