{"id":14285,"url":"\/distributions\/14285\/click?bit=1&hash=346f3dd5dee2d88930b559bfe049bf63f032c3f6597a81b363a99361cc92d37d","title":"\u0421\u0442\u0438\u043f\u0435\u043d\u0434\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0443\u044e \u043c\u043e\u0436\u043d\u043e \u043f\u043e\u0442\u0440\u0430\u0442\u0438\u0442\u044c \u043d\u0430 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u0435 \u0438\u043b\u0438 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u044f","buttonText":"","imageUuid":""}

Agile вне IT на примере коров и кофе. Зачем внедрять и почему это больно

Как работает Agile? Какие трудности неизбежны для бизнеса во время трансформации? Кто может пренебречь изменениями?

Эти вопросы я задал партнеру TeamStorm, генеральному директору компании «Лидеры изменений» и основателю сообщества OKR Russia Сергею Рогачёву. Вот его рассказ.

Сергей Рогачёв
Основатель OKR Russia

Почему рынку понадобился Agile

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

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

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

Встал вопрос: как добиваться успеха при выполнении проектов в среде высокой неопределенности?

У айтишников болело больше всего. IT — молодая отрасль, где степень изменчивости колоссальна. Заранее почти невозможно определить перечень задач, которые необходимо сделать, чтобы добиться успеха. Поэтому именно они выработали новый подход и прописали манифест Agile.

Agile как самонаводящаяся ракета 🚀

Определение Agile и есть содержание его манифеста. В ценности вынесены четыре идеи о взаимодействии команд, практических результатах и адаптивности — в противовес жесткой иерархии и регламентам.

  • Люди и взаимодействие важнее процессов и инструментов
  • Работающий продукт важнее исчерпывающей документации
  • Сотрудничество с заказчиком важнее согласования условий контракта
  • Готовность к изменениям важнее следования первоначальному плану

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

Такая команда — как самонаводящаяся ракета 🚀

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

Как гибкие методологии применяют в нефтянке

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

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

Успешный пример показала «Газпром нефть», когда запустила свой кофейный проект: оказалось, что наиболее эффективный источник прибыли АЗС — не бензин, а кофе.

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

Еще один пример внедрения гибких подходов — на коровах

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

Как реализовать подобную сомнительную идею? Вдруг не взлетит? Тут и помогает Agile — дает возможность проведения более быстрых и менее дорогих экспериментов в четыре шага. Как это могло выглядеть в проекте с коровами:

Шаг 1. Галлюцинации. Так мы шутим о гипотезах. Компания галлюцинирует, придумывает идею: «Если мы оденем VR-очки на корову и покажем ей солнышко, она будет давать больше молока».

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

Шаг 3. Проверка гипотезы. Допустим, прототип тестируют на небольшой группе коров и собирают данные.

Шаг 4. Корректировка. Если результаты подтверждают положительное воздействие на надои молока, проект развивается дальше. Если результаты отрицательные, нужно менять концепцию или полностью отказаться от идеи.

Проект в результате был закрыт. Концепция не сработала, и это нормально. По сути, это была запланированная ошибка.

Почему не всегда получается стартовать Agile вне IT

Однажды наши клиенты из Северстали выступали на конференции, полчаса рассказывали аудитории, как работают по Scrum. Один из слушателей встает и спрашивает:

Про Скрам я знаю, вы мне лучше расскажите, как вы сталь по Аджайлу льете?

Главная проблема при старте Agile в традиционных отраслях — технологическая. Подобно тому, как компиляторы помогают программистам быстро менять ПО, вне IT должны быть разработаны собственные «компиляторы». Например, в строительстве существуют технология построения BIM-моделей, которая упрощает внесение изменений в проект.

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

Чтобы решить эту проблему, необходимо привлечение экспертов предметной области.

Культурные сложности при Agile-трансформации

Еще одно направление рисков — в необходимости трансформации мышления. Любой бизнес можно условно разделить на две части: операционная и область развития. Это два разных мира.

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

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

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

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

Так почему это больно?

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

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

Сейчас эта проблема уже не такая острая, как 7–10 лет назад. Каждая отрасль накопила примеры успешных кейсов для всех сомневающихся. Поэтому, как правило, большинство решается на трансформацию.

Кому (на первый взгляд) не нужен Agile

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

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

Глава Nokia, пытаясь спасти компанию в 2011 году, описал такую ситуацию метафорой burning platform — когда не меняться уже нельзя.

Компания Nokia была первой в отрасли мобильных телефонов, но не поймала волну, когда появились смартфоны. И несмотря на все усилия остаться на плаву не удалось, в том числе из-за позднего старта трансформации — платформа все-таки сгорела.

Внедрение гибких подходов может быть сложным процессом, который требует культурной и структурной перестройки.

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

И если задаться вопросом, какому бизнесу нужен Agile, у меня есть понятный ответ — любому!

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

0
Комментарии
-3 комментариев
Раскрывать всегда