Agile и бирюзовые организации - ответ менеджмента на вызовы новой промышленной революции

Версия от 15:14, 7 мая 2020; MaksTsepkov (обсуждение | вклад)

Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Версия от 15:14, 7 мая 2020; MaksTsepkov (обсуждение | вклад)

Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
PIR-book.jpg

Статья опубликована в сборнике «Практики Развития 1.0» (вышел 09.2018)

Тема развивается

Промышленная революция и ее вызовы

Сейчас появляется все больше статей о приближающейся четвертой промышленной революции, которая полностью перестроит современную индустрию — и появится Индустрия 4.0. Какие же она несет вызовы, с которыми не может справиться существующий менеджмент?

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

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

В этих условиях традиционный менеджмент, сформировавшийся в ХХ веке, в фазе завершения второй промышленной революции и последовавшем после него периоде устойчивого развития, перестает действовать. Этот менеджмент основан на регламентах, нормировании деятельности через инструкции и компетенции, и представлен в трех основных вариантах: Process, Project и Case management. Уверенный результат достигается только в случае Process management, однако сама организация процесса и разработка регламентов опирается на компетентность организатора, а не на технологию управления. В случае Project management на компетентность участников опираются фазы анализа и создания самого проекта, а для Case management требуется высокая компетентность во всей деятельности. В условиях быстрых изменений ни регламенты, ни компетентность не успевают за потоком изменений.

Второй вызов — переход от task work к knowledge work. Питер Друкер в книге «Менеджмент. Вызовы XXI века»[1] сформулировал, что по мере автоматизации рутинного труда и переходу к работе, связанной со знаниями, все большая доля деятельности будет требовать от сотрудников решений «менеджерского» уровня. В традиционном менеджменте такие решения требуют личных способностей и опыта, и доступны ограниченному кругу сотрудников, получивших соответствующее образование и прошедших отбор. В новом обществе, управляемом знаниями, области высокой компетентности расширяются и охватывают всю деятельность. Сейчас сила этого вызова стремительно нарастает в связи с цифровизацией бизнеса.

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

Однако под поверхностью лежит еще один слой — изменение шаблонов поведения успешного лидерства. Исследования поведения на форумах и в группах в Facebook показали, что способы достижения успеха противоречат традиционным шаблонам поведения, ведущим к продвижению в корпоративной культуре. Подробности можно прочитать в статье Гэри Хемела (Gary Hamel) «The Facebook Generation vs. the Fortune 500»[2], опубликованной в The Wall Street Journal (2009) и других исследованиях. Раньше школы и вузы готовили человека к принятию корпоративных правил. Выделялись дети, успешно воспринимавшие эту культуру, остальных относили к хулиганам. Соцсети показывают, что можно достигать успеха и принципиально иными способами. Существуют люди, умеющие адаптироваться в сообществах с традиционными стереотипами поведения, но, когда их там становится большинство — они перестраивают правила. Поколение, получившее mindset соцсетей еще в школе и институте, массово приходит на работу, и компании должны принципиально измениться, а кто не сможет — останется без кадров.

Изменения ценностей и мировоззрения в ходе промышленной революции были предсказаны почти 40 лет назад Элвином Тоффлером в книге «Третья волна»[3] (1980). Он писал, что грядущая промышленная революция не просто изменит технологии, а положит конец индустриальному обществу. Будут переосмыслены понятия и ценности, произойдет радикальное изменение бизнеса и организаций, семьи, государства и всего человечества. И это уже происходит.

Agile — ответ IT-отрасли на вызовы нового мира

Первой с новыми вызовами столкнулась IT-отрасль. То, что с помощью процедур и регламентов невозможно гарантированно достигать результатов в IT-проекта, стало ясно в 1980 годах и было показано в классической книге Тома ДеМарко и Тимоти Листера «Человеческий фактор»[4] (1987).

А в 2001 году, как ответ на бесполезные попытки менеджеров управлять IT-разработкой с помощью регламентов, приводящие к авралам и провалам проектов, появился Agile-манифест.

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

Манифест декларирует ценности, следующие из ключевой роли человеческого фактора — результативность и сотрудничество. Их дополняют принципы, показывающие способ работы, при которой ценности не являются пустой декларацией. Принципы не следуют из ценностей, они основаны на опыте IT-отрасли, имеют характер best practice и отражают ее специфику. Ценности достаточно легко переносятся между отраслями, а принципы требуют адаптации: успешное в IT не обязательно успешно в другой отрасли.

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

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

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

Каким же образом Scrum смог решить проблемы, стоящие перед IT-разработкой?

Во-первых, он признал, что тщательное планирование результата и проектирование путей его достижения невозможно. Традиционный путь проекта был заменен короткими (1–4 недели) итерациями, в каждой из которых создается законченный продукт. Этот продукт демонстрируется разработчиками и оценивается пользователями и заказчиками проекта, что позволяет скорректировать траекторию движения, направить его в нужном направлении, быстро устранить ошибки проектирования. Ошибок нельзя избежать: опыт показывает, что все проекты являются лишь гипотезами, которые следует проверить как можно быстрее.

Во-вторых, Scrum решил проблему недостатка компетентных руководителей групп и проектов, разделив ответственность менеджера на три части: ответственность за результат возложена на владельца продукта (Product Owner), ответственность за организацию команды возложена — на скрам-мастера (Scrum Master), а ответственность за повседневную операционную работу — на саму команду. Проблема была острой, поскольку менеджер должен был совмещать профессиональные компетенции IT-разработчика с soft skills руководителя, а это встречается достаточно редко. Но только разделение ответственности не решает проблему, наоборот, появляются проблемы синхронизации взаимодействия. И Scrum предложил для этого эффективные инструменты: доска показывает ход работ по конкретным задачам, а burndown chart позволяет оценивать приближение к результату в ходе итерации. И каждый разработчик оценивает это, выбирая на scrum-доске очередную задачу, а каждый день проходят встречи для синхронизации представлений всей команды о ходе движения. Да, руководитель все это представлял и без scrum-доски — но теперь ситуацию проекта видит вся команда.

В-третьих и в-четвертых, Scrum решил проблему невозможности организации процесса, нормированного регламентами в условиях сильно вариативных проектов и задач, а также проблему недостатка компетентных специалистов при быстром развития технологий. Решение — объединение всех ключевых специалистов в одну кроссфункциональную команду, которая обладает достаточными компетенциями для выполнения всех необходимых работ, а если этих компетенций оказывается недостаточно — члены команды коллективно ищут решения проблем и обычно находят. Кросс-функциональность первоначально означала отсутствие специализации, это было важно на этапе становления Scrum как метода работы для разрушения функциональных границ. Сейчас она понимается несколько иначе: команда не должна быть заложником конкретных специалистов, которые могут заболеть, и команда должна быть способна обрабатывать неоднородный по специализациям поток задач. Такое состояние не достигается автоматически, но в Scrum заложены механизмы совершенствования процесса: на ретроспективе в конце каждой итерации команда оценивает стоящие перед ней проблемы, включая недостаточную кроссфункциональность или недостаток компетенций, и формулирует задачи, нацеленные на их устранение, включаемые в следующую итерацию наряду с производственными.

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

И, наконец, в-шестых, Scrum обеспечивает вовлеченность и сотрудничество разработчиков для результативного решения общей задачи.

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

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

Далее семейство Agile-методов развивалось, включив и переосмыслив Lean, практики проектного управления, теории ограничений Голдратта, создавая гибридные методы, такие как ScrumBan и различные фреймворки масштабирования — Scrum of Scrum, Nexus, LeSS, Spotify, SAFe. Впрочем, задача хорошего масштабирования Agile на организацию значительного масштаба (от 100 человек) не решена. А последним словом является разработанный под руководством Ивара Якобсона OMG Essence[5] — формализм для описания гибридных методов, позволяющий реализовать подход «Каждому проекту — свой метод».

За пределами IT-отрасли идут многочисленные попытки применения методов и Agile-манифеста. Есть редакции манифеста для маркетинга и образования. Есть eduScrum — применение Scrum для школьного образования в Голландии. Есть российский вариант применения Scrum для организации школьных уроков, разрабатываемый Павлом Рабиновичем, которому удалось совместить новый подход с существующей нормативной базой школьного обучения.

Использование концепта потоков создания ценности (value stream), который не несет отраслевой специфики, позволяет переносить методы Agile за пределы IT-отрасли. Это реализует LeanKanban, основанный на представлении цепочек создания ценности в организации в сервисной модели. И это же сделал Майк Бидл (Mike Beedle) в Enterprise Scrum, очистив Scrum от специфики IT и масштабировав его на организацию в целом.

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

Бирюзовые организации — самоуправление и самореализация в работе

Фредерик Лалу, консультант «McKinsey», решил найти и исследовать «новые» самоуправляющиеся организации, о которых уже много лет говорят визионеры. Чтобы отделять «новые» организации от «обычных», он адаптировал для описания организаций системы уровней Спиральной динамики и Интегрального подхода Уилбера. Новые организации соответствуют желтому уровню Спиральной динамики, но цвет он взял у Уилбера — teal, серо-синий. Переводчик назвал его бирюзовым, смешав, таким образом, с цветом следующего уровня в обоих системах — turquoise.

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

Итак, как устроена бирюзовая организация?

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

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

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

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

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

  1. Инициатор предлагает решение для конкретной ситуации.
  2. Участники задают вопросы на понимание, инициатор отвечает. Фасилитатор следит, чтобы не высказывались мнения или возражения. Инициатор не обязан давать ответ на все вопросы, он может сказать, что какие-то детали не важны для принятия решения.
  3. Высказывание мнений. Здесь можно говорить что угодно. Участники говорят по кругу и каждый может высказаться только один раз. Дискуссия не допускается и инициатор не имеет права отвечать.
  4. Инициатор уточняет предложение, или оставляет формулировку без изменений.
  5. Участники высказывают возражения. В отличие от мнений к возражениям применяются жесткие требования: необходимо указать на новый вред, который нанесет реализация предложения, или объяснить, что это отбросит назад от цели. Возражение должно быть позиционным, то есть относиться к области ответственности того, кто его выдвигает. За другого можно говорить, лишь если он отсутствует, но это будет возражение о правомочности принятия решения.
  6. Если возражений нет, то решение принято.
  7. Когда все возражения высказаны, их обсуждают по одному. В обсуждении участвуют двое: возражающий и инициатор предложения. Возражающий предлагает изменения, а инициатор проверяет, ведут ли они к улучшению его предложения. Понятно, что коммуникация может быть не столь формальной, но возражающий должен принимать участие в поиске решения, которое удовлетворит обоих.
  8. Если после обсуждения возражений первоначальное предложение изменилось, инициатор фиксирует новую формулировку и такт возражений повторяется. Если инициатор видит, что поиск решения затягивается, или предложение требует дальнейшей проработки, он в любой момент может его снять. Пока он этого не сделал — поиск решения продолжается.

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

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

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

Описание конструкции бирюзовых организаций редко встречается в статьях о них, хотя Фредерик Лалу четко приводит его в своей книге. Обращают внимание на внешние атрибуты: отсутствие иерархии, широкую свободу и инициативу сотрудников, отсутствие во многих организациях привычных функциональных подразделений (таких как HR или управление бюджетом) или открытые зарплаты и их назначение самими сотрудниками. Прочитав подобную статью, можно заключить, что организация может работать лишь чудом. Между тем, речь идет о реально работающих организациях, и после того, как Лалу написал свою книгу, их число увеличивается, в том числе и в России.

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

Новый менеджмент в России

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

Об этом же говорит движение за применение Agile в государственных организациях, которое началось осенью 2015 года, еще до выступления Германа Грефа, посвященного Agile-методикам, на Гайдаровском форуме, с AgileKitchen на территории Аппарата Правительства РФ. С 2016 года в премии «Проектный олимп» есть номинация по применению гибких методологий в госпроектах. На ней, например, был представлен интересный опыт Самарского пенсионного фонда по использованию Agile для организации работы и, в частности, для выдачи материнского капитала, что позволило избежать очередей. Весной 2017 года была организована подгруппа по применению гибких методологий при президиуме Совета при Президенте Российской Федерации по стратегическому развитию и приоритетным проектам. А на AgileDays-2018 и других конференциях рассказывают кейсы по применению Agile для организации операционной работы в Центральном банке, Росатоме и других крупных госорганизациях.

Все это позволяет надеяться на успешное развитие нового менеджмента в России.

Литература

  1. Друкер П. Менеджмент. Вызовы XXI века [Электронный ресурс] / URL: https://www.mann-ivanov-ferber.ru/books/paperbook/challenges/
  2. Hamel G. The Facebook Generation vs. the Fortune 500 // The Wall Street Journal. 2009 [Online] / URL: https://opensource.com/business/10/9/facebook-generation-vs-fortune-500
  3. Тоффлер Э. Третья волна. М.: АСТ, 2010.
  4. Демарко Т., Листер Т. Человеческий фактор: успешные проекты и команды / Пер. с англ. М. Зислиса и С. Маккавеева. СПб.; М.: Символ, 2010.
  5. OMG Essence - стандарт, принятый группой OMG (Object Management Group), официальная страница стандарта https://www.omg.org/spec/Essence/About-Essence/