Что делать Agile-коучу в большой организации?

В 2016 году крупнейший банк страны, «Сбербанк», затеял масштабную перестройку своих рабочих процессов по Agile. Целый год Герман Греф давал интервью, а «Сбербанк» «высасывал» с рынка всех, кто умел «коучить», «создавать команды» и «внедрять Agile». 

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

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

В этом движении мы идем вслед за всем миром и, несмотря на то, что начали позже, в ряде отраслей — в частности, в финансовом секторе — мы даже опережаем остальной мир.

А с чего все началось? Почему потребовались более гибкие подходы к работе, ведь все отлично работало и до этого. Ответ кроется в двух трендах.

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

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

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

Второй тренд описывается исследованием профессора Йельской школы менеджмента Ричардом Фостером истории рейтинга «S& P 500», в котором представлены 500 крупнейших по капитализации компаний. Согласно этому исследованию, среднее время жизни этих компаний, драматически сократилось за последние 60 лет. Если в 1960 году среднее время жизни таких компаний составляло порядка 60 лет, то в настоящее время среднее время жизни — порядка 10-15 лет. Эта тенденция была также подтверждена в исследовании компании Deloitte: 50 лет назад средняя продолжительность жизни компании из списка Fortune 500 составляла 75 лет, а сегодня она сократилась до 15 лет.

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

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

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

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

Первый — кто может внятно объяснить, что это за Agile такой, и как он реализуется, кто нужен, чтобы этому обучать, и как можно обучить сотни сотрудников компании?

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

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

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

Давайте попробуем разобраться.

Обычно такого человека называют Enterprise Agile Coach (EAC), и он работает на уровне всей организации. Его задача состоит в том, чтобы выстраивать системный процесс, пронизывающий все подразделения компании.

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

Зона ответственности такого специалиста — вся организация, и было бы правильно говорить о том, что целью EAC является развитие Business Agility для всей компании, чтобы она стала адаптивной и гибкой по отношению к быстро меняющемуся рынку.

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

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

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

Обязанностью Enterprise Agile Coach будет поиск «узких мест» в компании, которые сдерживают Change-процессы. Иногда, в компании вообще нет подразделения, которое бы специально занималось Change-деятельностью, и это большая проблема, так как не имея запаса проверенных гипотез, не понимая своих альтернатив, компания становится «хрупкой» по отношению к внешним изменениям.

Если посмотреть на список компаний Fortune 500 1988 года и 2017 года, можно увидеть, что лишь 25% компаний, которые входили в Топ-30 этого списка, остались в нем и в 2017 году.

Из списка выбыли очень известные компании, такие как:

  • Intel
  • Texaco
  • DuPont
  • Chrysler
  • Procter & Gamble
  • Kodak
  • McDonnel Douglas
  • PepsiCo

И другие. Полный список представлен в исследовании Fletcher/CSI «Fortune 500».

Кто же остался? Всего семь компаний: Exxon Mobil, General Motors, AT& T, Ford Motor, General Electric, Chevron, Boeing.

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

Конечно, были и другие факторы, которые позволили удержаться этим компаниям среди Топ-30 Fortune 500, но нельзя отрицать, что все они осознают необходимость выстраивания Change-процессов и прикладывают к этому усилия.

Работа с Change значительно отличается от работы с Run. Требуется выстроить исследовательский процесс в условиях недостатка информации о способах достижения и даже о конечной точке назначения.

Чтобы это реализовать, надо посмотреть на организацию с точки зрения потока поставки ценности. Для каждой организации этот поток организован по-разному, но так или иначе, для развития Business Agility нужно, чтобы в нем были следующие шаги:

  • Discovery — исследование новых продуктов и проверка продуктовых гипотез. Здесь наши идеи должны пройти первую «обкатку» в полях, через интервью с потенциальными покупателями, заинтересованными лицами и экспертами. Мы должны выяснить, как они сейчас решают ту или иную задачу, или справляются с проблемой, какие готовые решения применяют, что занимает больше всего времени и сил. И дальше — выдвигаем гипотезы о том, что и как мы могли бы облегчить, улучшить или ускорить для них в этом процессе?
    Можно использовать такие инструменты, как Customer Jorney Map или Value Proposition Canvas, с помощью которых мы «упаковываем» собранную информацию, и можем лучше понять, какие именно эксперименты стоит проводить для проверки гипотез.
    Но лучшей проверкой жизнеспособности нашей идеи является то, что покупатель готов ее купить. Поэтому на этапе Discovery критически важно иметь возможность быстро и дешево реализовать первую, самую простейшую рабочую версию нашей идеи, и  попробовать продать ее. Если клиент купил —  значит мы на правильном пути. Начинают обычно с Minimal Viable Product — Минимальной Жизнеспособной Версии Продукта, которую мы можем начать продавать клиентам, чтобы получить первый фидбек, и понять, какие функции наращивать следующими, чтобы повышать ценность для клиента.
  • Prioritization — определяется результатами Discovery и является частью следующего этапа Delivery (разработка и поставка). Мы можем создать много гипотез, но не все они равнозначны с точки зрения ценности получаемой информации, да и ресурсы наши не безграничны, поэтому нам следует приоритезировать гипотезы друг относительно друга, чтобы понять, на чем делать упор. Здесь нам пригодятся модели AAARRR, понимание воронки продаж, и расчет экономики — например с использованием юнит-экономики или иных инструментов расчета. Приоритеты должны исходить из потребностей, и долгосрочного видения компании, в этом случае мы не будем распылять наши усилия, а планомерно исследовать нужное нам направление, концентрируя усилия.
  • Delivery — этап быстрого производства новых версий продукта и поставки клиенту. Здесь в дело вступают Scrum-команды, которые итеративно, в тесном контакте с заказчиком, создают улучшения продукта, так, чтобы в каждую итерацию можно было продать клиенту новые возможности.
  • Support — этап поддержки после поставки продукта клиенту. Критически важен для сбора обратной связи и увеличения лояльности клиентов.

Enterprise Agile Coach должен уметь выстраивать эти процессы, исследовать существующий поток поставки ценности, находить в нем «заторы», и уметь устранять препятствия, ускоряя Change-процессы во всей компании.

Чтобы понять, за что браться в первую очередь, и каков будет план действий, Enterprise Agile Coaching и представители компании должны ответить на многие вопросы касательно собственной организации, например: как поток поставки ценности соотносится с оргструктурой? Помогает или способствует текущая оргструктура Change-процессам? Есть ли административные барьеры на этом пути? Есть ли подразделения, занимающихся Discovery? Способен ли Delivery поставлять с нужной скоростью? Как соотносятся этапы работы с воронкой продаж? Что нам говорит экономический расчет продуктов? Какую бизнес-метрику надо выбрать за точку отсчета? К какому этапу эта бизнес-метрика относится? И еще много других вопросов, которые позволяют прояснить модель, и сделать достоверную гипотезу о том, какие изменения требуются для достижения целевого состояния.

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

Есть программа обучения ICAgile Enterprise Agile Coaching, и ее стоило бы освоить всем руководителям. Правда, провайдеров такого обучения в России можно по пальцам одной руки пересчитать.

В общем, рынок Agile в РФ ждет появления новых специальностей, где гибкость становится стилем работы не для отдельных команд, но для целых организаций.

Комментарии
Управляющий директор, Москва

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

IT-консультант, Украина

Аджайл - это антипод техническому заданию и производственному плану.

В айти вещь применимая в некоторых случаях.

Но в других сферах - спорная.

И да, мне как айтишнику приятнее ТЗ.

 

Партнер, Москва
Сергей Русанов пишет: Отличный и весьма актуальный материал. Но огорчает пристрастие автора к иностранной терминологии. Возможно это дань зарубежному передовому бизнес-образованию, от которого пока отстает отечественное.

обычная мантра по поводу agile вне сферы предметной области IT разработки. Особенно "вне сферы".

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

Партнер, Москва
Андрей Роговский пишет: Аджайл - это антипод техническому заданию и производственному плану. ... И да, мне как айтишнику приятнее ТЗ.

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

Когда мы стали использовать средства быстрой разработки ПО (RAD), то в это же время появился и Agile в IT. Уже тогда можно было прямо при заказчике набросать экранные формы, и даже что-то можно было показать - как примерно будут вводиться данные, и что будет на выходе в виде простых отчётов. Что-то похожее в работе с заказчиком в это же время делали архитекторы и дизайнеры. 

Но надо понимать, что в каком-то виде ТЗ в Agile всё равно существует, чтобы кто-то обратное на говорил на плохом "английском", собирая толпы благодарных слушателей, которые не любят писать ТЗ ... ))) Кто-то всё время занимается ТЗ. Иначе не будет Delivery и загнётся Support, о которых пишет автор )))

Технический директор, Новосибирск
Андрей Радионов пишет:
собирая толпы благодарных слушателей

обирая...

IT-менеджер, Мурманск

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

Партнер, Москва
Сергей Зайков пишет: и тогда от Agile может вообще ничего не остаться (кроме терминов)

В среднем, каждые 5 лет происходит смена предложений на рынке консалтинга.  Дольше всех - почти 20 лет продержался "процессный подход". Судя по прибавляющейся в большом количестве словесной шелухе по теме, Agile вне предметной области IT особенно долго не продержится. 

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

 

IT-менеджер, Красноярск

Кто же остался? Всего семь компаний: Exxon MobilGeneral Motors, AT& T, Ford MotorGeneral ElectricChevronBoeing.

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

Конечно, были и другие факторы, которые позволили удержаться этим компаниям среди Топ-30 Fortune 500, но нельзя отрицать, что все они осознают необходимость выстраивания Change-процессов и прикладывают к этому усилия.

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

Управляющий партнер, Москва

Хочется привести несколько примеров использования Agile - подходов в не-IT сфере, чтобы прояснить ситуацию 

Северсталь: https://www.youtube.com/watch?v=I5MQdes-IAU&feature=youtu.be

Росатом: https://m.youtube.com/watch?v=PBBgp1D2lRU

ПФР Самарской области: http://bujet.ru/article/383912.php

Альфа-банк: https://www.youtube.com/watch?v=p3fVTauR4V8

Достаточно посмотреть на результаты исследования Agile Russia  чтоб убедиться  что представление о том, что "Agile - это только для IT" - уже устарело: https://scrumtrek.ru/blog/agilesurvey18/

Мировой опыт точно об этом свидетельствует

Boeing https://www.innovel.net/how-to-avoid-fatal-product-flaws-with-agile-and-scrum/

Или BMW: https://www.itpro.co.uk/agile-development/31552/how-bmw-embraced-agile-to-hit-new-speeds

Или Saab: https://wiki.businessagility.institute/w/CaseStudies:Owning_the_Sky_with_Agile_-_Building_a_Jet_Fighter_Faster,_Cheaper,_Better_with_Scrum

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

Партнер, Москва
Василий Савунов пишет: Росатом: ...

Это, как раз, хороший пример - на выходе серийный дизайн-проект АЭС поколения III+ - докладчик по ссылке  называет его ещё концепт  т.е что-то типа типа макета. О том, что после Scrum, который и использовался, больше макета не получишь, уже много раз говорилось в этом форуме.

Кстати, докладчик по ссылке начинает свой доклад со слов - прошу вас успокойтесь, по Agile, мы атомные электростанции не строим. Вот здесь стоит уточнить - по некоторым методологиям Agile можно что-то построить, путь не связанное с атомной промышленностью. А по Sсrum точно нет - только макет.

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Эксперты: 4-дневная рабочая неделя приведет к снижению зарплат

Закон не препятствует пропорциональному снижению ФОТ при переходе на четырехдневную рабочую неделю.

75% россиян не верят в пенсии

Три четверти россиян не верят в пенсии, показал опрос Райффайзенбанка. А те кто верят, полагают, что она составит всего 10-20 тыс. руб.

Японцы доказали, что при четырехдневной рабочей неделе производительность растет. В Microsoft сообщили о росте на 40%

Японское подразделение Microsoft подвело положительные итоги месячного эксперимента по переходу на четырехдневную рабочую неделю.

 
Кто счастлив в России?

Самыми счастливыми оказались - медики, госслужащие и HR-ы. Об этом сообщается в исследовании Headhunter.