Три уровня объяснения сложных ситуаций

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

Уровни объяснения сложной ситуации

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

• Модели поведения - адаптивный подход. Этот подход более сложный. На этом уровне мы начинаем чуть больше анализировать и рассуждать.

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

События - реакционный подход

Реакционный подход - это когда у нас что-то загорелось, и мы побежали тушить пожар. Думаю, все сталкивались с этим на работе. Я в свое время два года провела именно в таком состоянии: когда с утра заходишь в офис, и тебе говорят «Маша, все плохо». Берешь одну ситуацию, решаешь ее, появляется следующая, решаешь ее - так проходит весь день и вся рабочая неделя. Вся эта деятельность - чисто реакционный подход.

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

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

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

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

Модели поведения - адаптивный подход

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

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

Общесистемная структура - генеративный подход

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

Есть ситуации, на которые мы можем повлиять, меняя внутренние правила, стандарты, улучшая коммуникацию и давая друг другу обратную связь. А есть ситуации, которые от нас не зависят - например, внешние обстоятельства или события, влияющие извне.

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

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

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

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

Если речь идет, например, о коллективе или организации: кто эти сотрудники? Зачем они пришли в эту организацию? Каковы их ценности? Понимают ли они цели организации, цели конкретного проекта? Разделяют ли они общие ценности внутри команды? В разных ситуациях, особенно в стрессовых, когда, например, приходится работать до ночи или тушить какой-то «пожар» - разные люди реагируют по-разному. Я уверена, что вы не раз с этим сталкивались. Видеть картину целиком — значит учитывать все аспекты системы.

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

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

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

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

Архетипы систем в теории и на практике

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

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

Например, в моем опыте было так: каждое утро я прихожу на работу, и мне говорят: «Маша, все плохо». Это был мой циклический процесс, и я примерно представляла, какие будут последующие шаги. В вашей ситуации это может быть что угодно, даже то, как вы собираетесь на работу с утра - тот же самый циклический процесс.

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

Циклы влияния и обратная связь

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

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

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

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

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

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

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

Усиливающая обратная связь работает, когда незначительное действие начинает значительно влиять на событие.

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

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

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

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

Есть некоторый симптом проблемы, который мы пытаемся решить. Например, мы что-то «костылим» в программном коде, когда нам нужно быстро решить проблему. Есть фундаментальное решение, которое мы, скорее всего, должны были бы реализовать, но сейчас нет времени, нет денег, и вообще ситуация не позволяет.

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

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

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

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

• почему в некоторых случаях у нас получается обучаться на своем опыте, а иногда — нет;

• почему в некоторых ситуациях у нас эффективно развивается команда, а иногда «буксует»;

• почему наш личный профессиональный рост иногда может «выстреливать» быстро и эффективно, а иногда мы начинаем застревать.

P.S. Благодарю Кирилла Анастасина за предоставленную возможность использовать его иллюстрации.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.