Последние месяцы я много писал о психологии работы разработчиков: о страхе ошибки, перегрузке, поддержке и конфликтах. Постепенно стала заметна одна закономерность: психологический процесс начинает влиять на работу раньше, чем появляется событие, которое мы уже называем проблемой.
Из этой мысли мы начали собирать Практику эмоциональной профилактики.
Сразу оговорюсь: всё описанное дальше не обязательно относится именно к вам. Возможно, вы давно замечаете такие процессы и умеете с ними работать. Но вполне вероятно, что что-то похожее вы встречали у коллег, руководителей или в других командах.
Разработчик понимает, что не успевает, но молчит до последнего. Сильный специалист не отдаёт задачи, потому что другим не доверяет. Человек из страха ошибки бесконечно проверяет решение. Тимлид видит, что проблема выходит за пределы команды, но не сообщает наверх, потому что боится выглядеть слабым. Два подразделения начинают защищать свои границы вместо решения общей задачи. После нескольких ошибок руководитель усиливает контроль, а команда начинает ещё больше скрывать проблемы.
Я видел все эти ситуации вживую ещё до того, как стал заниматься психологией. Тогда каждая выглядела отдельной управленческой проблемой. Позже мне стало интереснее смотреть не только на то, что человек делает, но и на то, что им в этот момент движет.
Разработчик, который не сообщает о задержке, может пытаться сохранить ощущение собственной компетентности: «Я должен справиться сам». Чем дольше он пытается решить проблему самостоятельно, тем сложнее становится признаться, что помощь была нужна ещё несколько дней назад.
Сильный специалист, который не делегирует, часто защищает контроль и предсказуемость. Если цена ошибки высока, сделать самому действительно кажется безопаснее. Постепенно задач становится больше, времени объяснять другим всё меньше, доверия тоже меньше, и человек оказывается в ловушке собственной надёжности.
За бесконечными проверками тоже редко стоит любовь к проверкам. Человек пытается получить чувство уверенности и защититься от ошибки, критики или ощущения собственной несостоятельности. Но абсолютной уверенности не наступает, поэтому появляется ещё одна проверка.
Тимлид может слишком долго удерживать проблему внутри команды, потому что сама его роль предполагает способность справляться. Просьба о помощи иногда переживается как признание: «Я не вывез». Чем важнее человеку сохранять образ компетентного руководителя, тем труднее вовремя показать предел собственных возможностей.
Даже конфликт подразделений может быть не только спором о процессах. Люди защищают ответственность, статус, ресурсы, свои решения и право не оказаться виноватыми в чужой ошибке.
А руководитель, усиливающий контроль после нескольких сбоев, обычно пытается вернуть себе предсказуемость. Логика понятна, но если команда начинает воспринимать ошибку как угрозу дополнительного давления, она решает уже другую задачу: как обезопасить себя. Плохие новости приходят позже, руководитель получает меньше информации и усиливает контроль ещё сильнее.
Получается неприятная конструкция: поведение человека может иметь совершенно понятную внутреннюю логику, но способ, которым он защищает важную для себя потребность, постепенно сам становится частью рабочего сбоя.
Именно эта точка и интересует меня в эмоциональной профилактике.
Что такое Практика эмоциональной профилактики?
Сразу ещё одно уточнение: в этой статье я ничего не продаю.
Более того, значительную часть того, о чём здесь написано, команда может делать совершенно самостоятельно.
Для меня Практика эмоциональной профилактики — это прежде всего способ организации внимания. Регулярно смотреть не только на результат работы, но и на то, что происходит с людьми до появления очевидных последствий.
Можно раз в одну-две недели взять одну реальную ситуацию и спокойно восстановить её развитие. Когда всё начало меняться? Что двигало человеком? Чего он пытался избежать или, наоборот, сохранить? Почему выбранное поведение казалось ему разумным? В какой момент оно перестало помогать? Что можно было заметить раньше?
Тема одного разговора может быть страхом ошибки, другого — перегрузкой сильного специалиста, поздней эскалацией, гиперконтролем или конфликтом между командами.
Форма здесь вообще не главное. Это может быть отдельная встреча, ретроспектива, one-to-one или разговор после сложного релиза.
Гораздо важнее само проявление внимания.
И ещё важнее — что произойдёт после того, как человек решится рассказать правду.
Можно сколько угодно учить разработчика раньше сообщать о проблемах. Но если после слов «я не справляюсь» его публично разберут на запчасти, следующий риск он принесёт позже, а не раньше.
Человек всегда в какой-то степени оценивает последствия откровенности.
Можно ли здесь сказать «я не знаю»? Можно ли признать ошибку? Можно ли спорить с руководителем? Безопасно ли сообщить, что срок под угрозой? Можно ли попросить помощи, не потеряв статус компетентного специалиста?
И здесь наша идея неожиданно пересекается с одним из самых известных исследований команд в IT.
Project Aristotle
Несколько лет Google изучал вопрос, почему одни команды оказываются эффективнее других. Исследование получило название Project Aristotle.
Исследователи первоначально искали различия в составе команд, опыте участников и других характеристиках. Но в итоге ключевыми оказались прежде всего нормы взаимодействия внутри самой команды.
Google выделил пять факторов эффективных команд, а психологическую безопасность назвал наиболее важным из них.
Речь не о том, что всем должно быть постоянно комфортно. Психологическая безопасность означает возможность задать вопрос, признать ошибку, высказать сомнение или предложить другую точку зрения без ожидания, что тебя за это унизят или накажут.
Для эмоциональной профилактики это принципиально.
Можно научиться прекрасно замечать собственную перегрузку, но этот навык мало поможет, если сообщать о ней небезопасно.
Плохие новости должны приходить раньше
Похожая логика есть у DORA, только уже непосредственно применительно к разработке и эксплуатации программных систем.
В материалах DORA о generative organizational culture отдельно говорится о работе с носителями плохих новостей: организация должна хотеть получать такую информацию, а не наказывать человека за то, что он её принёс. Отсюда же рекомендация проводить blameless postmortems, где после сбоя исследуют причины и устройство системы вместо поиска удобного виноватого.
Это очень близко к тому, что мы пытаемся сделать в профилактике.
Ценность плохой новости максимальна не тогда, когда всё уже рухнуло, а тогда, когда с ней ещё можно что-то сделать.
И здесь особенно важен руководитель
В исследованиях психологической безопасности Эми Эдмондсон есть ещё одна важная для меня мысль: руководитель способен влиять на безопасность разговора собственным поведением.
Один из описанных ею способов — признание собственной ошибаемости.
Не демонстративная исповедь перед командой и не обязательные рассказы о детских травмах. Всё значительно проще.
Руководитель может показать, что сам способен чего-то не знать, что-то пропустить или принять неверное решение. В одном из приведённых Эдмондсон примеров руководитель прямо говорил команде, что ему необходимо слышать сотрудников, потому что он сам способен что-то упустить.
В этом есть довольно простая логика.
Если самый статусный человек должен всегда выглядеть правым и уверенным, остальные довольно быстро усваивают те же правила.
Если руководитель способен спокойно признать: «Здесь я ошибся», «Этого я не знаю», «Я мог чего-то не учесть», другим становится чуть безопаснее показать собственное ограничение.
Конечно, одних правильных фраз недостаточно. Если руководитель говорит «ошибаться нормально», а затем наказывает за первую же ошибку, команда довольно быстро выяснит, какое из двух сообщений настоящее.
Поэтому эмоциональная профилактика — это не набор правильных формулировок. Это постепенно создаваемая атмосфера, в которой проблему безопаснее показать, чем скрыть.
Внимание важнее формы
Не нужно превращать тимлидов в психологов и диагностировать коллегу по трём сообщениям в Slack.
Иногда профилактика выглядит гораздо проще.
Обычно инициативный человек перестал спорить. Сильный разработчик всё больше замыкает задачи на себе. Коллега, который раньше спокойно показывал промежуточный результат, теперь приносит только почти законченный. Плохие новости начали появляться в последний момент.
Ни один из этих признаков сам по себе ничего не доказывает.
Но можно обратить внимание и спросить: «Что происходит?»
А дальше самое важное — суметь выдержать ответ.
Профилактика не заменяет процессы, метрики и нормальное управление. Она также не должна психологически приспосабливать людей к хронически плохой организации работы. Если команда постоянно недоукомплектована, люди работают ночами, а за ошибки наказывают, никакой разговор о чувствах это не исправит.
Но между «всё нормально» и «у нас уже серьёзная проблема» существует довольно большая территория.
Именно она меня сейчас интересует.
Практика эмоциональной профилактики для меня — это способ регулярно замечать повторяющиеся человеческие сценарии, понимать, какие страхи, потребности и ограничения стоят за ними, и создавать условия, в которых об изменении можно рассказать раньше.
Техническую систему мы стараемся сделать устойчивой к предсказуемым сбоям до аварии.
Возможно, с человеческим фактором имеет смысл поступать так же.
И если после этой статьи руководитель не купит никакой программы, а просто станет внимательнее смотреть на изменения в команде, спокойнее относиться к собственным ошибкам и чуть раньше спрашивать человека «что происходит?», то Практика эмоциональной профилактики уже начала работать.
ссылка на оригинал статьи https://habr.com/ru/articles/1072748/