Системные ловушки организационных трансформаций

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

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

##Трагедия общих ресурсов

###Проявление

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

Давайте заменим фермеров на бизнес стейкхолдеров, коров - на идеи/запросы/проекты, а поле - на общий пул ресурсов, например, на ИТ. Каждый стейкхолдер хочет делать больше проектов, при этом поле - общее. Чем больше будет делать один, тем меньше будут делать другие, что вызывает контр поведение: наращивание количества запросов всеми участниками. Конечно, так как ресурс - общий, каждый из них будет получать меньше готовых проектов, при этом никто не может отказаться от своего поведения. Если один стейкхолдер скажет, например, "я буду делать меньше проектов что бы разгрузить общее 'поле'", то другие, вероятно, займут его нишу.

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

###Выход

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

1. Знание производительности своей системы. То есть сколько проектов может переваривать "поле" максимально эффективно

2. Ограничение на вход. Не брать в работу все.

3. Фокус на окончании начатой работы, а не на старте новой

4. Общее (всеми участниками) понимание того, как система работает, единый процесс

Самым эффективным будет уход от общего к частному. Гаррет Хардин, американский философ, который популяризировал "Трагедию общин", видит это как самый оптимальный выход из проблемы. В Agile это решается через аллокацию в выделенные, независимые команды (Scrum) или целостного контроля Work in Processs (Kanban).

##Успех успешным

###Проявление

Предположим, есть 2 команды, А и Б. Ресурсы и знания, которым обладали 2 команды в отправной точке - одинаковы. В течение работы, из-за стечения различных факторов, А достигла больших результатов, из-за чего в компании ей начали отдавать преимущество: показательно благодарить, давать лучшие ресурсы, быстрее обрабатывать их запросы. Из-за этого А становится все более и более успешной, а Б - все менее.

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

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

###Выход

Важнее не помогать успешному, а понимать, что делает остальных менее успешными.

1. Что позволило одним проявить неординарные результаты, а другим - нет?

2. Как достичь подобного эффекта в других командах?

3. Как поддерживать этот успех?

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

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

##Ограничение роста, возможности роста

###Проявление

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

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

Вторая ловушка - рост без создания возможностей для такого роста. Это очень распространённая ошибка небольших стартапов и крупных компаний в трансформациях. Вот пример: компания А начинает делать организационную трансформацию и принимает решение, что для разработки всех ее инициатив ей нужно удвоить штат. Начинается наем персонала, однако система вокруг не готова к такому росту, вызываю повышенный уровень вынужденной координации. Чем больше людей, тем больше координации, тем больше хаоса. Тем временем, новых людей занимают старыми задачами под предлогом "не ждать же им светлого будущего, вон сколько делать нужно" (тут вспоминаем проблему общности), все новые становятся занятыми и компании снова не хватает людей для важных инициатив.

###Выход

Перед тем, как начинать рост, нужно ответить для себя на очень важный вопрос: чем заняты те люди, которые уже у нас работают? Чем занята вся система? Какова цель нашей компании? Соответствуют ли наши действия нашей стратегии? А действительно ли нам нужно быть быстрее? Может нужно быть качественнее? Инновационнее?

##Размытие изначальной цели

###Проявление

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

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

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

Знакомо?

###Выход

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

##Движение к неверной цели

###Проявление

Хорошим примером будет следующее: вы делает организационные изменения, менеджмент ставит цель - запустить 10 Scrum команд к концу года. Вы запускаете команды, но это ничего не изменило для клиента/компании, но фактическая цель выполнена.

Данная ловушка тесно связана с так называемыми Vanity (тщеславными) метриками, ее легко найти по ним. Это метрики, которые нужны для того, что бы просто что то мерять, но ничего не говорят о том, что на самом деле происходит. Например:

1. Количество прошедших Agile тренинги в организации

2. Количество Agile команд

3. Количество Agile коучей

4. Velocity команды

5. Количество скачиваний вашего приложения и тд.

###Выход

Важно измерять качественные показатели (Sanity) и делать их общими для системы. Какая разница, сколько у вас Scrum команд, если вы по-прежнему делаете неконкурентное гавно?

Хорошим вопросом будет: зачем мы все это делаем? Какая цель? Выпускать быстро? Отнюдь.

##Нарушение правил

###Проявление

Предположим, в компании есть правило, что в офис нужно приходить до 10 и это время отмечается автоматически, когда человек прикладывает карточку к входному турникету. Так же компания отслеживает, что за вычетом обеда, сотрудник проводит в офисе 8 часов в среднем за месяц.

Со временем в этой системе появляется следующие тенденции:

1. Человеку нужно к доктору, и он передает свою карточку коллеге, который "пикает" его вход в офис на турникете

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

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

В курилках люди хвастаются новыми способами обхода корпоративных правил или бюрократии, успехам, как они "все решили". Такая система воспитывает "решал" в процессе.

###Выход

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

##Подмена проблемы / Исправление симптомов

Ярким примером этой тенденции будет: у нас много багов, давайте введем bug-fixing спринты! Это никак не решает проблему некачественного кода, но исправляет баги.

В повседневной жизни эта тенденция более трагична. Хорошим примером будет фармакология. Мы боремся с болезнью, а не причиной ее возникновения (экология, слишком большая нагрузка). Или, например, такая ситуация. Человек в депрессии, он глубоко переживает. Вместо того, чтобы обратиться за помощью, он начинает принимать наркотики или пить, что вызывает временное облегчение, но не решает основную проблему.

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

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

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

###Выход

Это сложная ловушка, выходом из которой будет только поиск и устранение корневых причин. Для этого, в системном мышлении, мы используем Causal Loop Diagrams, Модель айсберга и Визуализация поведения во времени.

Любой ивент (проявление проблемы) можно отследить во времени - паттерн (то есть, единично ли явление или это не первый раз). Паттерны строятся на структурах, то есть системе, которая создает такое поведение. Структуры строятся на ментальных моделях - представлении людей о том, как система должна работать, их убеждениях "о правильности мира".

Вот пример модели айсберга для проблемы "много багов":

1. Ивент - мы снова нашли баг

2. Паттерн - уже пол года у нас куча багов

3. Структура - менеджмент затянул гайки, мы в постоянном стрессе, так как давят дедлайны (конкурентный рынок). Структуру можно описать следующей причинно-следственной диаграммой:

Есть некоторое ожидание менеджеров "desired velocity" о производительности команды. Они "пушат" делать больше, что увеличивает количество элементов в работе. Это вызывает переключение между задачами, что увеличивает время выхода отдельно взятой задачи, а также увеличивает количество ошибок, которые делают разработчики, что так же увеличивает время выхода задач. Это система каскадной деградации (Reinforcing) системы. Чем больше все делается, тем больше менеджмент "давит", что вызывает еще большую задержку выхода.

4. Ментальная модель? Может быть: они могут быстрее, нужно ставить амбициозные цели!

Меняя ментальные модели, можно изменить систему. Это и есть трансформация - изменения ментальных моделей, которые меняют правила игры.

Итоги

И что с этим всем делать? Изменения часто проваливаются, потому что участники прогрязают в системных тенденциях из-за того, что не видят целостной картины. Часто они сами не понимают как создают или влияют на эту тенденцию.

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

Я провожу тренинги о том, как искать ловушки, что с ними делать (как решать, какие есть выходы), как искать ментальные модели и трансформирвоать их.

Приходите, всех жду!