После неудачного релиза перестал работать критичный обмен. В общем чате быстро собралось человек десять. Один проверял последние изменения, второй предлагал поправить данные прямо в рабочей базе, третий пытался понять, кого уже затронула ошибка. Параллельно пришел вопрос от заказчика: когда всё заработает?
Еще несколько минут такого разговора - и версий стало бы больше, а отвечающего за восстановление так и не появилось бы.
«Новые изменения пока не выпускаем. Сергей готовит откат. Анна собирает подтвержденные симптомы. Михаил помогает пользователям с временным решением. Я даю статус заказчику. Через пятнадцать минут сверяемся».
Обсуждение пришлось остановить. С точки зрения управления и компании было всё равно, насколько демократично команда выбирает решение. Пока люди спорят и действуют в разные стороны, простой продолжается.
Через несколько часов обмен восстановили. На следующий день прежний порядок уже мешал бы. Теперь нужны журналы, версии, вопросы к процессу выпуска и нормальный разговор с теми, кто видел проблему с разных сторон.
Один и тот же способ управления может утром спасти ситуацию, а вечером только снижать эффективность.
Прямая команда во время аварии
Слово «принуждение» в разговоре об управлении звучит неприятно. Угрозы и давление нельзя оправдать срочностью, но командно-административный режим управления иногда нужен. Здесь речь о коротком периоде, когда решение становится обязательным, а спор откладывается до момента разбора причин.
В Incident Command System, которую используют для управления чрезвычайными ситуациями, отдельно закреплены цепочка командования и единоначалие. Смысл простой: человек не должен одновременно получать противоречивые распоряжения. Технические решения остаются у специалистов, а общий порядок действий удерживает один центр управления.
Систематический обзор 32 исследований принятия решений в ситуациях высокого риска описывает знакомые условия: дефицит времени, стресс, неполную информацию и быстро меняющуюся обстановку. При таком наборе длинный поиск общего согласия иногда увеличивает ущерб. Но сама по себе срочность еще не делает любое жесткое решение правильным.
В истории с релизом руководитель распределяет работу и останавливает новые изменения. Способ отката и анализ журналов остаются за специалистами.
Есть разница между «делайте, как я сказал» и «до следующего статуса не выпускаем новых исправлений, сначала возвращаем устойчивое состояние».
Когда авария закончилась, а режим остался
Жесткий порядок легко ввести и трудно отменить. Во время восстановления руководитель привыкает получать статус каждые пятнадцать минут. Потом хочет видеть его несколько раз в день. Еще через неделю начинает проверять все задачи, которые хотя бы отдаленно связаны с инцидентом.
Это может позиционироваться как осторожность. Для команды авария при этом продолжается. Люди ждут подтверждения сверху даже там, где раньше спокойно решали сами.
Когда мне впервые доверили команду, я довольно быстро ушел в избыточный контроль. Хотелось понимать, что происходит, не пропускать проблемы и быть полезным. Я подключался к вопросам, которые люди нормально решали без меня, и добавлял еще один круг согласования.
Через некоторое время на встречах стало происходить странное. Вместо своих вариантов всё чаще звучал вопрос: «А как ты хочешь, чтобы мы сделали?» Сначала это можно было принять за уважение к роли руководителя. Потом я увидел, что команда просто перестала тратить силы на решение, которое я всё равно мог переделать под себя.
Признать это было неприятно.
В тот момент контроль уже почти не снижал риск. Он снижал мою тревогу и замедлял остальных.
Несколько сверок вместо постоянного надзора
Полностью отказаться от контроля после такого вывода тоже не получилось бы. В некоторых задачах ошибку слишком дорого обнаруживать только в конце.
У меня лучше работали короткие заранее запланированные встречи. На них не требовалось подробно пересказывать весь день. Достаточно было понять, куда пришла задача, что изменилось и где появился новый риск. Между встречами сотрудник продолжал работать сам.
Исследования адаптации новичков хорошо объясняют, почему призыва «действуй самостоятельно» бывает мало. Талья Бауэр с соавторами объединили данные 70 отдельных выборок новичков. Лучше входили в работу те, кому была понятна их роль, кто чувствовал, что способен справиться с задачами, и успел наладить взаимодействие с коллегами. Эти факторы были связаны с результативностью, удовлетворенностью работой и меньшим желанием уйти. Поэтому на старте человеку может быть нужна не постоянная проверка каждого шага, а ясность.
Опыт сам по себе ничего не гарантирует. Человек может много лет работать разработчиком и впервые столкнуться с конкретной интеграцией. Новый сотрудник, наоборот, может знать нужную технологию лучше всей команды.
Полезный контроль и микроменеджмент снаружи похожи. В обоих случаях руководитель задает вопросы и смотрит промежуточный результат. Разница проявляется после разговора.
Если сотрудник получил замечание по риску и дальше сам выбирает способ работы, задача осталась у него. Когда руководитель каждый раз переписывает решение под себя, добавляет новые согласования и оставляет исполнителю отдельные действия, самостоятельность существует только на словах.
Авраам Клугер и Анджело ДеНиси собрали в метаанализе 607 эффектов и 23 663 наблюдения. В среднем обратная связь улучшала результат, но больше чем в трети случаев производительность после нее снижалась. Один из важных факторов - куда такая обратная связь направляет внимание: к самой задаче или к переживаниям человека о себе.
Фраза «проверь еще раз этот сценарий, здесь может быть ошибка» оставляет предмет разговора снаружи. После слов «почему ты опять всё делаешь не так» сотрудник уже думает не о сценарии. Он начинает защищаться и угадывать ожидания руководителя.
Если человек несколько раз устойчиво прошел сложный участок, а число согласований не изменилось, контроль просто закрепился в процессе.
Когда свободы оказалось слишком много
У меня был и противоположный опыт. Сотруднику передали слишком большой участок самостоятельности. В задачах начали появляться проблемы, и стало видно, что часть последствий он пока не замечает заранее.
Некоторые проверки пришлось вернуть. Поначалу это воспринималось почти как отмена делегирования. Затем мы начали передавать работу небольшими участками. Сначала сотрудник сам готовил решение и приносил его на короткую сверку. Потом проходил участок полностью, но заранее сообщал об известных рисках. Со временем проверка оставалась только перед действиями, которые трудно откатить.
Иногда руководитель слишком рано решает, что границы задачи уже одинаково понятны обоим. Тогда шаг назад нужен, чтобы эту границу снова увидеть.
Сложнее выглядит ситуация, когда человек работает давно, но без постоянного сопровождения задачи всё равно начинаются проблемы. Руководитель привыкает к таким затратам и включает их в обычный рабочий день. Через некоторое время уже трудно понять, развивается сотрудник или начальник просто годами компенсирует одну и ту же проблему.
Собственное решение как черновик
В неоднозначной задаче у руководителя редко есть вся информация. Каждый специалист знает решение лучше в своей части.
В слаженной команде я стараюсь обозначать свое предложение именно как вариант:
«Я бы пошел вот так. Посмотрите, где этот вариант может не подойти и что можно сделать надежнее».
Нередко команда возвращается с более точным решением. Иногда сохраняет основную идею и меняет детали. Иногда показывает ограничение, о котором я вообще не подумал.
Хамфри, Наранг и Моргесон объединили результаты 259 исследований, в которых участвовали более 219 тысяч человек. Автономия была связана с удовлетворенностью работой, внутренней мотивацией и ощущением личной ответственности за результат. Но разные виды свободы работали неодинаково. Возможность самостоятельно выбирать время выполнения задачи почти не была связана с удовлетворенностью, а возможность выбирать способ работы и принимать решения показывала гораздо более заметную связь. Поэтому сотруднику важно не просто сказать «теперь действуй самостоятельно», а действительно оставить ему часть решений, которые раньше принимал руководитель.
В слаженной команде свобода часто дает более проработанное решение. Но бывает и иначе: руководитель говорит «решите сами», а команда воспринимает это как отсутствие решения вообще. Многое зависит от привычки людей поднимать риски, спорить по существу и доводить выбор до результата.
Обсуждение для вида
Вовлечение легко превратить в спектакль. Срок уже утвержден, но руководитель собирает встречу и спрашивает, когда команде удобнее выпустить результат. Люди пересчитывают объем, предлагают варианты, а затем получают ту дату, которая была известна еще до встречи.
Если дата уже утверждена, лучше сказать об этом сразу:
«Дату мы не меняем. Но еще можем пересмотреть объем и способ выполнения. Давайте посмотрим, что можно убрать и где мы рискуем больше всего».
Кэтрин Миллер и Питер Монж обобщили исследования участия сотрудников в принятии решений. Участие было связано и с удовлетворенностью работой, и с производительностью, но связь с удовлетворенностью оказалась заметнее. Особенно выделялся общий климат в организации: когда мнение сотрудников учитывали регулярно, это имело большее значение, чем приглашение поучаствовать в одном отдельном решении. При этом участие само по себе не гарантировало роста производительности. Обсуждение дает результат не автоматически - важно, стало ли оно обычной частью работы и меняет ли после него хоть что-то в реальном решении.
Бывает, что обсуждение продолжается просто по инерции. Новых аргументов уже нет, люди повторяются, но разговор не заканчивается. Выбор в итоге всё равно остается за руководителем.
Что произошло после релиза
История с упавшим обменом не заканчивается откатом.
В первые минуты руководитель распределяет роли и останавливает несогласованные действия. После восстановления просит подтвердить несколько критичных сценариев, но уже не диктует специалистам каждый шаг. На разборе причин больше говорят разработчики, поддержка и те, кто общался с пользователями.
Человек, которому во время аварии дали короткую команду, на следующий день может сам вести технический разбор. Через неделю он же предложит изменение процесса выпуска, о котором руководитель не подумал.
Если после этого руководитель всё еще требует отчет каждые пятнадцать минут, проблема теперь уже не в релизе.
