В предыдущем посте я сравнивала организацию с нейронной сетью, потому что они обе могут автономно обучаться, используя данные. Данные эти поступают извне или являются продуктом внутренней “кухни”. Встречаются у них обеих и “баги”: дефекты, которые ломают их способность обучаться. Со скрытыми багами обучение все равно идет, но не совсем так, как мы этого ожидаем. Есть риск, что конечный результат такого обучения нас, скорее всего, тоже мало устроит. Но узнаем мы об этом не сразу.
Такого рода баги не “выкидывают” пользователя из приложения, не прекращают работу нашей сети, но заставляют ее неверно обрабатывать данные, которые поступают, и делать неправильные выводы. В итоге сеть как бы обманывает сама себя. Ну и нас заодно.
Баги в обучении организации возникают на разных уровнях. И как любой баг логики, чем раньше его получается отловить, тем меньше последствий придется потом разгребать. Некоторые баги организации затрагивают фундаментальные процессы и настолько глубоко пускают свои корни в психологию и поведение людей, что способны подорвать нормальное взаимодействие, нарушить тонкий баланс внутренних сил, остановить развитие организации или изрядно подпортить ее репутацию.
Локализовать баги организации сложно. Но возможно. Они оставляют свои следы. Так называемые симптомы бага. Существуют определенные “маркеры”, поведенческие, речевые (смысловые и интонационные), анализ которых помогает выявить практически любой баг во взаимодействии людей.
Питер Сенге в своей книге “Пятая дисциплина” выделил 7 багов самообучающейся организации и я перечисляла их в своей предыдущей статье. В этой же я подробнее остановлюсь на самом первом: I am my position. Немного авторского перевода и он превратился в “Заложники своей роли“. Ниже вы убедитесь, почему. Итак, приступим.
#1 – Заложники своей роли (I am my position)
В двух словах, баг заключается в том, что каждый занимается исключительно своим делом: менеджер менеджит, разработчик разрабатывает код, а тестировщик тестирует. И в чем тут баг, спросите вы? И будете правы. Каждый должен заниматься своим делом и в большинстве нормальных компаний так и происходит. Баг начинается там, где участники воспринимают свою проектную роль немного буквально и теряют способность смотреть на проект без “ролевых” очков.
Этот баг сложно уловить, потому что он очень легко маскируется под “норму” в нашем привычном понимании того, как должна функционировать приличная организация. В общем, на первый взгляд, ситуация действительно выглядит вполне нормальной.
Но если присмотреться получше, становится ясно, что перед нами не команда классных спецов с богатым опытом, набором навыков и глубоким знанием проекта, а набор ролей. Проектных ролей, которые едва пересекаются, с трудом могут найти общий язык, либо вовсе предпочитают держаться друг от друга на “безопасном” расстоянии.
Суть бага “Заложники своей роли” состоит в том, что проектная роль становится “вещью в себе” и возводится в абсолютную ценность. Участники проекта начинают ассоциировать себя с ролью больше, чем с общими целями и вкладом в общее дело. Фокус рабочего диалога смещается с общего результата на зоны отвественности, которые часто превращаются в настоящий камень преткновения.
Характер коммуникации при этом баге напоминает больше “хождение по инстанциям“: все избегают ответственности за решения, которые лежат вне зоны их полномочий. Чем глубже баг пускает свои корни, тем больше “хождение по инстанциям” превращается в “хождение по мукам” и неизбежно выводит ситуацию на “новый уровень” – бюрократию.
Вы, возможно, столкнулись с симптомами этого бага, если наблюдаете следующие примеры:
- Ответственным за качество или, например, развитие продукта, гласно или нет, признается конкретный отдел или даже человек, и в случае провалов, все яйца, тухлые и не очень, летят в его сторону.
- Менеджмент зацикливается на дедлайнах и в случае их несоблюдения “делегирует” ответственность за сработавшие риски исполнителям (как правило, в виде овертаймов).
- Техническая команда считает финальным результатом своей работы стройную и подтянутую кодовую базу, а команда дизайна занимается любованием своими шедеврами, но никто из них не может увязать свои труды с ценностью, которую они несут конечному пользователю.
- На митингах уверенно звучит, ЧТО делают участники проекта, но далеко не каждый может сходу ответить ЗАЧЕМ.
- Главной “забавой” становится перебрасывание “мячика” ответственности из отдела в отдел. В мыслях и коридорах все чаще всплывает фраза “как хорошо, что проблема не на нашей стороне”.
- Растет прокрастинация, особенно в тех случаях, когда решение лежит на стыке полномочий и полностью зависит от результатов взаимодействия.
Постепенно баг пускает свои корни в корпоративную культуру организации и влечет за собой сложно обратимые последствия.
Фокус смещается со стратегии и общих целей на отдельные задачи.
Борьба за общий результат уступает место положению, где “своя рубаха ближе к телу”.
Между отделами/ролями образуется коммуникативный вакуум. Это приводит к тому, что многие решения навсегда застревают в “сумеречной зоне” либо уступают дорогу “дешевым” компромиссам. Инновации “на стыке” экспертиз превращаются в что-то недостижимое, потому что “стыка” как такового нет и в помине.
Нет больше жарких споров, в которых рождается истина, нет ликования и криков радости от совместных решений и открытий, нет обмена эмоциями. Есть оловянные солдатики и маски, снующие по коридору, отсиживающие свои, положенные по трудовому законодательству часы, исправно выполняющие свои должностные обязанности, но при этом тоскливо устремляющие свои взгляды в заманчивые дали. Туда, где настоящая жизнь, полная ярких впечатлений, настоящего драйва и простого человеческого общения…
Почему баг “Заложники своей роли” мешает организации самообучаться?
Как правило, пустив глубокие корни, баг вызывает стагнацию. Организация не может учиться и развиваться, потому что участники проекта перестают разговаривать как специалисты. Вместо этого между собой разговаривают их “маски” с весьма ограниченным набором “функциональностей”. Участники проекта все чаще действуют согласно “должностной инструкции”, которая написана для их роли и искусственно сужает их “проектный кругозор”.
Этот баг нарушает “проводимость” нашей “нейронной сети”. Делает ее компоненты изолированными друг от друга. Чем больше траншей и бюрократических “окопов” мы роем вокруг своей проектной роли, тем больше естественных связей мы нарушаем.
Без общей картины в головах участников проекта, взаимодействие между ними носит очень ограниченный характер, а проектные роли все больше напоминают “семафор”, пропуская решения, словно поезда, доводя до автоматизма свои рабочие реакции и слабо вникая в детали маршрута. Как следствие, связь между отправной точкой и пунктом назначения так же нарушается. А это именно то, что нам нужно для обучения.
Если внутренняя кухня не варит, организация не получает достаточно данных о том, как обучаются ее компоненты и обучаются ли вообще. Нарушение внутреннего взаимодействия неизбежно ведет к нарушению связей с внешним миром. Чтобы эффективно работать с данными извне, нам нужно в первую очередь научиться работать с нашими собственными данными и наладить их беспрепятственную циркуляцию.
Что с этим делать?
Если вам удалось этот баг выявить, считайте, вы сделали полдела! Остается всего лишь размыть границы проектных ролей и реабилитировать взаимодействие, а потом выстроить коммуникацию таким образом, чтоб максимально направить ее в конструктивное русло. Звучит просто!
Простите за сарказм.
Конечно же, это ни разу не просто. Но и бросаться чинить этот баг точечными мерами тоже не стоит.
Вы уже будете на голову выше других, если одернете свой мозг, когда он потянется на полку с суждениями о недобросовестности или непрофессионализме всех этих людей. Вместо этого вспомните о мухе ФОА и не спешите с выводами.
Важно помнить, что баги, о которых мы говорим, это баги системы, и кто угодно, оказавшись в “забагованной” системе, может пасть их жертвой.
Нужно лечить систему. И лечить ее нужно системно. И лучшая стратегия в данном случае – наблюдение. На начальном этапе так точно. Недостаточно увидеть симптомы бага. Надо понять его причину. А так как речь идёт о такой сложной науке, как взаимодействие людей, придётся потрудится и собрать побольше информации: было ли так всегда в компании, как взаимодействие строилось раньше и почему изменилось, речь идёт о нескольких людях или “тренд” распространился на всю организацию. И много других вопросов, ответы на которые не лежат на поверхности.
А так как объект нашего анализа – это взаимодействие, то и наблюдать нужно за взаимодействием. Желательно, живым. Лучше всего это делать, когда люди непосредственно взаимодействуют, а вы имеете возможность посмотреть на это со стороны. Создайте “лабораторные” условия, поместите туда участников и наблюдайте, как они взаимодействуют. Старайтесь не включаться, чтобы иметь возможность собирать данные. Метаданные, которые расскажут вам не только о том, ЧТО обсуждается, но и КАК.
Качественные изменения не бывают быстрыми. Так что вооружитесь терпением и наблюдательностью. Будем искать причины и чинить следствия. И главный помощник нам в этом – наш старый добрый системный анализ.
Подписывайтесь на мой Телеграм канал. Будем искать причины вместе.
До связи!
Реверс инжиниринг менеджерской неосознанки 
Leave a Reply