Agile и бирюзовые организации - ответ менеджмента на вызовы новой промышленной революции
Статья опубликована в сборнике «Практики Развития 1.0» (вышел 09.2018)
Тема развивается
- Доклад с видео Эволюция технологий управления (ПИР Сибирь-2019)
- Статья Бирюзовые организации и agile: какие полезные практики стоят за хайпом
- Серия из 59 статей Менеджмент цифрового мира (оглавление)
Содержание
Промышленная революция и ее вызовы
Сейчас появляется все больше статей о приближающейся четвертой промышленной революции, которая полностью перестроит современную индустрию — и появится Индустрия 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. Такое решение найдется, потому что у участников есть общая цель, ради которой они присоединились к организации, и они ищут решение, которое лучше приближает к цели.
Эти принципы могут показаться абстрактными и умозрительными, однако в каждой организации они воплощены в конкретную процедуру принятия решений. Рассмотрим такую процедуру принятия решений на управленческих собраниях в холакратии — фреймворке бирюзовых организаций. Вопросы рассматриваются по очереди, и на каждом такте обсуждается лишь текущий вопрос. Сопутствующие соображения и идеи могут быть лишь записаны для последующего рассмотрения.
- Инициатор предлагает решение для конкретной ситуации.
- Участники задают вопросы на понимание, инициатор отвечает. Фасилитатор следит, чтобы не высказывались мнения или возражения. Инициатор не обязан давать ответ на все вопросы, он может сказать, что какие-то детали не важны для принятия решения.
- Высказывание мнений. Здесь можно говорить что угодно. Участники говорят по кругу и каждый может высказаться только один раз. Дискуссия не допускается и инициатор не имеет права отвечать.
- Инициатор уточняет предложение, или оставляет формулировку без изменений.
- Участники высказывают возражения. В отличие от мнений к возражениям применяются жесткие требования: необходимо указать на новый вред, который нанесет реализация предложения, или объяснить, что это отбросит назад от цели. Возражение должно быть позиционным, то есть относиться к области ответственности того, кто его выдвигает. За другого можно говорить, лишь если он отсутствует, но это будет возражение о правомочности принятия решения.
- Если возражений нет, то решение принято.
- Когда все возражения высказаны, их обсуждают по одному. В обсуждении участвуют двое: возражающий и инициатор предложения. Возражающий предлагает изменения, а инициатор проверяет, ведут ли они к улучшению его предложения. Понятно, что коммуникация может быть не столь формальной, но возражающий должен принимать участие в поиске решения, которое удовлетворит обоих.
- Если после обсуждения возражений первоначальное предложение изменилось, инициатор фиксирует новую формулировку и такт возражений повторяется. Если инициатор видит, что поиск решения затягивается, или предложение требует дальнейшей проработки, он в любой момент может его снять. Пока он этого не сделал — поиск решения продолжается.
Этот механизм может показаться чересчур формальным, однако в него заложены элементы, устраняющие основную массу длинных обсуждений на совещаниях. Например, инициатор не обязан рассматривать и отвечать на идеи о расширении предложения или об альтернативных вариантах. Он их услышит на этапе мнений, а вот стоит ли изменять решение — только его ответственность. Поиск совместного решения возникает только на этапе работы с возражениями, однако на само возражение наложены серьезные ограничения. Поэтому такой процесс принятия решений очень эффективен, и его можно использовать в любых организациях.
Холакратия играет для бирюзовых организаций ту же роль, что и Scrum для Agile — это фреймворк, который можно взять целиком и начать применять. Как и Scrum, холакратия — жесткий фреймворк: в нее заложено много элементов, исключающих неявное возвращение к традиционному менеджменту.
Итак, Фредерик Лалу выделил обобщенную конструкцию бирюзовых организаций: работа с эволюционной целью, самоуправление через принцип всеобщей ответственности и принятие решений на основе внутреннего консультирования, процедуры решения конфликтов и декларации прав, гарантирующие безопасность сотрудника, а также описал, какие механизмы реализуют эти функции в разных организациях. Эти механизмы различны, и можно подобрать те из них, которые кажутся наиболее сокультурными.
Описание конструкции бирюзовых организаций редко встречается в статьях о них, хотя Фредерик Лалу четко приводит его в своей книге. Обращают внимание на внешние атрибуты: отсутствие иерархии, широкую свободу и инициативу сотрудников, отсутствие во многих организациях привычных функциональных подразделений (таких как HR или управление бюджетом) или открытые зарплаты и их назначение самими сотрудниками. Прочитав подобную статью, можно заключить, что организация может работать лишь чудом. Между тем, речь идет о реально работающих организациях, и после того, как Лалу написал свою книгу, их число увеличивается, в том числе и в России.
Практики Agile и бирюзовых организаций дополняют друг друга, и принципы работы с ответственностью и конфликтами в бирюзовых организациях позволяют решить многие вопросы, о которых методы Agile говорят «команда должна договориться и принять решение».
Новый менеджмент в России
Все написанное не означает, что любая организация немедленно должна перестраиваться и работать по-новому: конструкция организации должна быть адекватна внешним условиям функционирования. Надо оценить силу вызовов, действующих в вашей области, понять, что сломалось в регламентах механизмов управления эпохи индустриального общества под их влиянием. Вызов — это не только опасность, это еще и возможность придумать ответ и стать лидером. Каждая организация сама выбирает свою траекторию движения, а каждый сотрудник — сам определяет свое место на этом пути. На мой взгляд, по внедрению Agile в IT-отрасли и за ее пределами, также как и практик бирюзовых организаций, Россия не отстает от мирового фронтира. Многие ценностные аспекты были проработаны еще в советское время, зафиксированы в культуре и передаются новому поколению. Как пример приведу знаковый фильм «Карнавальная ночь»: если посмотреть на него как на производственный фильм, то там показана работа самоуправляющейся и самоорганизующейся гибкой команды, объединенной общей целью и достигающей результата. И даже начальник не может помешать этому. Примерно так и может выглядеть революционный приход поколения соцсетей с новыми паттернами лидерства в традиционные корпорации, о котором я писал в начале статьи.
Об этом же говорит движение за применение Agile в государственных организациях, которое началось осенью 2015 года, еще до выступления Германа Грефа, посвященного Agile-методикам, на Гайдаровском форуме, с AgileKitchen на территории Аппарата Правительства РФ. С 2016 года в премии «Проектный олимп» есть номинация по применению гибких методологий в госпроектах. На ней, например, был представлен интересный опыт Самарского пенсионного фонда по использованию Agile для организации работы и, в частности, для выдачи материнского капитала, что позволило избежать очередей. Весной 2017 года была организована подгруппа по применению гибких методологий при президиуме Совета при Президенте Российской Федерации по стратегическому развитию и приоритетным проектам. А на AgileDays-2018 и других конференциях рассказывают кейсы по применению Agile для организации операционной работы в Центральном банке, Росатоме и других крупных госорганизациях.
Все это позволяет надеяться на успешное развитие нового менеджмента в России.
Литература
- ↑ Друкер П. Менеджмент. Вызовы XXI века [Электронный ресурс] / URL: https://www.mann-ivanov-ferber.ru/books/paperbook/challenges/
- ↑ 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
- ↑ Тоффлер Э. Третья волна. М.: АСТ, 2010.
- ↑ Демарко Т., Листер Т. Человеческий фактор: успешные проекты и команды / Пер. с англ. М. Зислиса и С. Маккавеева. СПб.; М.: Символ, 2010.
- ↑ OMG Essence - стандарт, принятый группой OMG (Object Management Group), официальная страница стандарта https://www.omg.org/spec/Essence/About-Essence/