для команды сложного проекта и экипажа воздушного судна почти идентичны.
С 2017 года я помогаю технологическим компаниям создавать лучшие практики управления эффективностью коммуникаций, оптимизировать процессы принятия решений в командах и повышать качество отношений с заинтересованными сторонами. До 2020 года для меня это был своего рода «пет-проект», параллельный основной работе – управлению портфелем проектов инновационного развития Авиакомпании «Россия». Основная часть задач, само собой, относилась к технологиям, но мне всегда были интересны управление продуктами и процессами. Поэтому я никогда не упускал возможности получить новые знания и практический опыт именно в этом. Когда ситуация на рынке авиаперевозок заставила компанию сменить фокус, я перешел с этими знаниями и опытом в частную практику.
Поскольку за время работы в авиации часто приходилось глубоко погружаться в специфические методики и технологии организации совместной работы, а за плечами уже был большой опыт управления в коммерческом секторе – быстро выяснил, что довольно много хорошо проработанных и проверенных жизнью авиационных фреймворков (если их слегка адаптировать) могут быть весьма полезными для «неавиационного» менеджмента. Особенно при разработке и внедрении IT-продуктов. Тем более, что в зарубежных источниках, ориентированных на технологических предпринимателей, можно обнаружить довольно много различных отсылок к самой распространенной в авиации технологии управления коммуникациями и командной работой – Crew Recourse Management (CRM, управление ресурсами экипажа).
В результате появилась «Коммуниканомика» – набор практик, объединяющий наработки из авиации с методологиями управления продуктовыми и проектными командами. К примеру, тренинг «Экипаж», в основе которого – переработанные российские методики на основе CRM.
В своем дебюте на Хабре я хочу поделиться описанием проверенного практикой фреймворка, который позволяет более эффективно управлять вниманием руководителя проекта или лидера продукта в ситуациях, где максимально высока цена ошибок и несогласованности.
Этот фреймворк называется «Ситуационная осведомленность».
Короткая предыстория
Понятие ситуационной осведомленности появилось не в авиации, но примерно одновременно с ней – во времена Первой мировой. В отдельный аспект теории и практики принятия решений его выделили специалисты американских ВВС, анализируя опыт воздушных боев в Корее и Вьетнаме. С началом эпохи массового применения сверхзвуковой авиации влияние скорости принятия верных решений кратно выросло.
концом II Мировой и началом Корейской войны выросла в 1,8 раза
В гражданской авиации методология закрепилась в 80-х годах прошлого века, когда международные авиаперевозки сильно повысили плотность загрузки воздушного пространства.
Сегодня большинство распространенных определений этого понятия основаны на словосочетании «понимание ситуации», но для нас больше подойдет формулировка из одной научной статьи: «Ситуационная осведомленность — это ментальная модель состояния окружающей среды, имеющаяся у людей, принимающих решение». Она хороша тем, что связывает принятие решений не с абстрактным «пониманием», а с картиной реальности, которая в определенный момент времени складывается в голове у тех, от кого эти решения ожидаются. К тому же позволяет несколько отдалить себя от «аналитического паралича» - для субъективного «понимания» можно до бесконечности вытаскивать информацию из внешнего мира, ничего не предпринимая. Тогда как архитектурой и параметрами ментальной модели можно оперировать достаточно гибко. Но это семантический нюанс из категории «я автор, я так вижу» и фокусировать на нем внимание не предлагаю.
Внимание стоит сфокусировать на том, что для регулярных задач фреймворк ситуационной осведомленности, чаще всего, избыточен (если вы не control freak). Однако очень полезен как основа подготовки к ситуациям экстремальным. Например, к тестированию сложной информационной системы на серверах заказчика. Или на первых этапах внедрения изменений.
Следуя изложенному в этой статье «мануалу» можно более качественно подготовиться к работе в экстремальном режиме, в том числе согласовать приоритетность источников информации и распределить ответственность за мониторинг и реагирование.
В прикладной конфигурации ситуационная осведомленность образуется тремя составляющими: System Awareness, Environmental Awareness и Anticipation.
System Awareness. Осведомленность о состоянии (статусе) систем
Для пилотов чуть ли не каждое значение любого показателя на приборах описано в инструкциях по принципу «если … то делай раз, делай два». Для большинства IT-процессов это, пожалуй, не обязательно, однако будет очень полезно обсудить заблаговременно в команде: кто отслеживает какой поток информации, с какой периодичностью и главное – с какой целью. Чтобы не получилось в самый ответственный момент как в старом анекдоте – «Петрович, приборы? – Восемь! – Что «восемь»!? – А что «приборы»?». Еще полезно в принципе определить какие данные необходимы, а какие можно временно проигнорировать. В типичной ситуации постоянно следить за температурой в офисе может, особой необходимости и нет, но, если в ключевом процессе участвует человек с гипертонией, который должен быть за монитором/клавиатурой постоянно – разумно будет кого-то из второстепенных (в данный момент) сотрудников этим озадачить. Когда я провожу командные сессии – у меня на ноутбуке, как правило, висит стикер с надписью «Т-О2». Каждый раз, переключая слайд сценария, я натыкаюсь на него глазами. Зачем? Я модератор увлекающийся. Работаю, как правило, со сложными задачами, в которых важна максимальная вовлеченность группы. Без дополнительного напоминания легко забыть, что люди в помещении теплокровные и дышат, а когда жарко и душно – качество совместной работы резко снижается и потом долго не восстанавливается.
Как один из элементов управления вниманием можно использовать список из пяти ключевых элементов ситуации – его я тоже взял из авиационных гайдов, упростив и чуть докрутив для адекватного применения: полет, пилот, летательный аппарат, окружающая среда и тип операции. Первое – про инструкции, регламенты, описание процедур и прочие известные заранее нормы, правила и установки. Второе – индивидуальные особенности ключевых участников, их типичные реакции в различных ситуациях, уровень знаний и индивидуальные шаблоны принятия решений. Третье – технические параметры и возможности задействованных программных и аппаратных средств. Четвертое – внешние условия, в которых принимаются решения и пятое – насколько то, что будет делать команда привычно или непривычно, просто (с учетом имеющихся компетенций) или сложно, завязано только на команду или будут задействованы другие люди и т.п.
На этапе моделирования команде будет полезно согласовать порядок действий при определенных значениях и/или динамике показателей. В каком диапазоне каждый из участников принимает решение сам; в каком – согласовывает свои действия с лидером, а в каком – сообщает о ситуации «наверх» и складывает ручки на коленках до особых распоряжений. Последний вариант не совсем шутка, поскольку множество проблемных ситуаций разворачивалось до критических масштабов как раз из-за того, что человек просто продолжал делать то же самое, что и прежде, но в изменившейся ситуации. Именно это и становилось причиной распространения каскада усиливающих друг друга ошибок.
Для отдельных ситуаций можно (а иногда и нужно) вводить «голосовую сигнализацию». Почти все действия КВС (командира воздушного судна, в авиации официально нет понятия «первый пилот») и второго пилота дублируются голосом – сначала объявляешь «делаю то-то», а только потом совершаешь действие. Кто-то сейчас ухмыльнулся, представив, но я и мои клиенты на своем опыте прочувствовали, насколько сокращает издержки коммуникации эта простая процедура. Сначала делаешь звонок коллеге из технического отдела – «отправляю начальнику департамента обновленный расчет по проекту», и только потом нажимаешь кнопку «Отправить». Коллега готов к тому, что через час-полтора шеф позвонит ему с вопросами и уточнениями, а он успеет посмотреть историю нашей с ним переписки и, скорее всего, уже не окажется в момент звонка где-нибудь в ангаре в активном диалоге с техниками. В итоге следующий шаг в реализации проекта произойдет сразу, а не через день-два-неделю.
Environmental Awareness / Осведомленность о текущих условиях
Этот параметр включает информацию об окружающей среде в широком смысле. Что происходит в реальности и как осуществляется взаимодействие с внешними ресурсами. Для пилота, к примеру, сюда входят диспетчер, состояние облачности на эшелоне, положение находящихся поблизости других воздушных судов и т.д. Очевидно, что команда проекта также может заблаговременно определить круг ключевых участников и аспекты ситуации, которые будут влиять на ход процесса. Чтобы не отвлекаться на то, что не влияет.
Как и в первом разделе – при оценке текущей ситуации важно не забывать делится информацией с другими. Какой и зачем – вопрос, не имеющий универсального ответа, но элементарно проясняющийся процессе моделирования.
Anticipation / Ожидание (прогнозирование)
Поскольку основная идея этой статьи – управление вниманием, я намеренно не стану углубляться в тонкости процесса принятия решений как такового, хотя в авиации для этого также есть специализированные и весьма полезные фреймворки под общим названием Aeronautical Decision Making. Под прогнозированием понимается проекция будущего состояния, то есть возможность предсказать, что произойдет дальше, на основе данных, полученных на предыдущих шагах. Здесь лидеру команды и основным экспертам необходимо понимать, что в определении из первого абзаца под «оператором» можно понимать как одного человека (если для ситуации установлен авторитарный порядок управления) так и группу. Например, создать штаб на время особых обстоятельств. Моделирование позволяет более гибко конструировать сочетание ключевых процессов, определяющих эффективность прогнозирования: применение системных знаний для выявления тенденций; экстраполяция имеющихся данных на перспективу; выявление возможных /будущих проблем и проработка стратегий на случай непредвиденных обстоятельств.
Очевидно, что лидер, скорее всего, не будет обладать всем объемом узких системных знаний, необходимых для прогнозирования всех возможных ситуаций. Из чего возникает коммуникационная задача – построить взаимодействие команды на особый период так, чтобы в нужный момент можно было быстро задать вопрос тому, кто этими знаниями обладает и максимально быстро получить ответ. Крайний и неэффективный (как минимум экономически) вариант – собрать узко специализированных экспертов в одном месте где-то поблизости и пусть сидят «на всякий случай». Значительно эффективнее заранее провести «штабную игру», на которой зафиксировать в каком диапазоне «нормальности» должна развиваться ситуация в штатном режиме, каковы наиболее вероятные варианты ее нештатного развития и что в этом случае следует делать, чтобы минимизировать ущерб. Непосредственно в рабочем процессе возможность в необходимый момент подключить эксперта значительно повышается благодаря уже упомянутой «голосовой сигнализации». Например, можно договориться, что перед запуском какой-то из процедур сначала поступает сообщение в чат команды «готовы запускать …», но сам запуск не производится, пока эксперт не проведет «проверку готовности»: «Такие-то параметры проверили? Такие-то действия уже выполнили? Ок, запускайте». Дальше эксперт по предварительной договоренности может находится в режиме «готовности номер ноль» до момента, пока в тот же чат не поступит сообщение о том, что все нормально запустилось.
Необходимо понимать, что мониторинг состояния системы, оценка обстановки, прогнозирование и принятие решений — все это процессы, оказывающие взаимное влияние в непрерывном цикле, который может быть разорван посторонними факторами. Поэтому моделирование по алгоритму ситуационной осведомленности не имеет смысла применять формально, «для галочки». Только в случае, если действительно есть намерение сконструировать ситуацию, в которой:
все, кто влияет на ситуацию, в курсе того, что происходит;
каждый понимает какую информацию и в каком порядке получает и что эта информация означает;
можно достоверно предположить, что эта информация будет значить в будущем.
Поэтому в практике стоит учитывать факторы, которые снижают ценность осведомленности:
1. Туннельное внимание. Фиксация на одном ограниченном наборе информации в ущерб другим данным приводит к ошибкам в оценке контекста.
2. Завышенные ожидания относительно рабочей памяти членов команды. Надежда, что в момент принятия решения всю необходимую информацию можно будет удержать «в голове», никогда не оправдывается.
3. Тревожность, усталость и другие психоэмоциональные факторы, снижающие возможность человека адекватно обрабатывать информацию. Здесь понятно, но многие это обстоятельство игнорируют.
4. Перегрузка информацией. Слишком большое количество информации уменьшает осведомленность. Также стоит учитывать «считываемость» данных.
5. Попытки оперировать желательным, а не объективным состоянием системы. На выходе - ложная трактовка событий и неверные прогнозы.
Необходимо подчеркнуть, что на стороне лидера определяющим фактором осведомленности служит умение учитывать не только свое видение ситуации. Это подразумевает умение и, что важнее, намерение быстро собирать варианты, оценивать их и выбирать наиболее правильный, даже если это не твой.
Дополнение. Принцип «чистой кабины»
В завершение поделюсь еще одной полезностью. Это уже не часть фреймворка, а простая, но эффективная техника. Самые напряженные этапы полета, требующие от летного экипажа максимальной концентрации, это (само собой) взлет и посадка. На этих этапах действует принцип «чистой кабины» - никаких отвлекающих факторов. IT-команда может применять этот принцип довольно творчески. Например, в одном из кейсов по моему совету со всеми представителями заказчика, кроме трех действительно нужных (а их в проект было вовлечено что-то около полутора десятков) заранее договорились о том, что на время особой ситуации команда отправляет их телефоны в «черный список». На связи для них остается только один из ЗГД, не участвующий в процессе непосредственно. Раз в час операционный лидер получал от него информацию о настроениях стейкхолдеров и отгружал им актуальный статус. При этом заранее было согласовано какие сообщения будут передаваться сразу, в обход «фильтра». Остальные «парковались» до очередного «сеанса связи».
Спасибо, что дочитали. Для меня эта статья своего рода эксперимент. Если он окажется удачным – буду и дальше делиться подобными наработками, поскольку «Коммуниканомика» это объемный пакет нестандартных решений для разработки адаптивных бизнес-стратегий, развития команд и лидеров изменений, а также повышения экономической эффективности управленческих коммуникаций в целом.
Мы умеем:
делать бизнес‑анализ систем принятия решений по адаптивному набору метрик;
разрабатывать и проводить стратегические сессии в техниках сценарного моделирования и группового исследования;
проводить командные сессии и тренинги, в том числе с включением методологий подготовки авиационных экипажей;
поддерживать индивидуальное развитие менеджеров уровней B/C на основе профиля коммуникативно компетентного лидера;
создавать и развивать высокоэффективные команды по принципу ролей, основанных на сильных сторонах.
В декабре 2023 года на платформе Литрес опубликована моя книга «Коммуниканомика. Рецепты национальной кухни управления изменениями». Читатели Хабр могут получить электронную версию до (и после) официальной публикации просто так, под добровольную договоренность о развернутой обратной связи.
Для этого напишите мне в Телеграм - @vshumovsky.
