Руководитель команды на несколько часов уходит на встречи. Возвращается - в мессенджере уже ждут несколько вопросов (могут быть различные вариации):
Какую задачу делать первой?
Можно ли включать доработку в ближайший релиз?
Какую оценку назвать заказчику?
По первой задаче нужно вспомнить договорённости и понять, какой срок действительно критичен. По второй - уточнить, что проверили перед выпуском и чем рискует команда. По третьей - посмотреть оценку разработчика и разобраться, какие допущения в неё заложены.
Через полчаса очередь разобрана. Сотрудники продолжили работу, заказчик получил ответ, релиз снова сдвинулся с места.
Руководитель помог команде и снял сразу несколько проблем. Только на следующий день в мессенджере, скорее всего, появятся те же вопросы.
Операционная ловушка редко выглядит как неверно выстроенная работа. Руководитель реально работает, не игнорирует команду и не избегает ответственности. Он постоянно включён в работу и быстро принимает решения. Но движение держится не на понятном порядке, а на том, что один человек помнит нужный контекст и в любой момент может собрать его заново.
Почему очередь не заканчивается
В операционке часто застревает сильный специалист. Он хорошо знает продукт, помнит историю проекта, понимает особенности заказчика и замечает риски раньше остальных. Пока сотрудник будет выяснять обстоятельства, руководитель уже даст ответ.
Выглядит вполне разумно. Странно устраивать долгую дискуссию о распределении полномочий, если вопрос можно закрыть за пять минут. Поэтому руководитель отвечает сам. Затем ещё раз. Потом делает это уже почти автоматически.
Постепенно меняется не только его загрузка, но и поведение команды. Сотрудники привыкают, что спорные решения всё равно будут подтверждены сверху. Пока руководитель доступен, это почти не мешает. Проблема становится заметна во время отпуска, болезни или нескольких длинных совещаний подряд. Понятная и простая работа продолжается без остановок, а всё, где нужно определить приоритет, принять риск или что-то пообещать заказчику, ждёт его возвращения.
Майкл Портер и Нитин Нория изучали рабочие календари 27 руководителей крупных компаний. В сумме они собрали данные примерно о 60 тысячах рабочих часов. Масштаб управления там другой, но сама картина знакома любому руководителю IT-команды: встречи, сообщения, согласования и текущие запросы быстро занимают весь день. Время на изменение процессов не образуется где-то между звонками. Его каждый раз вытесняет вопрос, на который нужно ответить прямо сейчас.
По заполненному календарю трудно понять, какие решения действительно требуют уровня руководителя. Часть из них без него не принять. Остальные оказываются у него просто потому, что другого понятного порядка в команде нет.
«Какую задачу делать первой?»
Представим две задачи с одинаковой пометкой «срочно».
В первой - ошибка в отчёте. Работа пользователей не остановилась, но данные приходится перепроверять вручную. Вторая - доработка обмена, обещанная заказчику к концу недели. Сейчас она никого не блокирует, зато от неё зависит следующий этап проекта.
Разработчик видит две срочные задачи. Руководитель знает больше, например, какой срок был назван, где есть временный обход, кто ждёт результат и что произойдёт при переносе.
Можно разрешить разработчику расставлять задачи самостоятельно. Но без этой информации он всё равно будет сложно понять, какой вариант выбрал бы руководитель. А если несколько его решений позже отменят, сотрудник обожжется и поймет, что всё спорное безопаснее согласовать заранее.
Это может выглядеть как отсутствие инициативы. Хотя сотрудник может вести себя совершенно логично в сложившейся системе. Право выбрать задачу у него вроде бы есть, а понятных критериев выбора и права ошибиться - нет.
Можно рассматривать управленческую работу на нескольких уровнях: ценности, стратегия, тактика и текущая операционная деятельность. Для этой ситуации полезно само различие между ними.
Какую задачу взять сегодня - вопрос текущей работы. Что важнее при конфликте пользовательского ущерба, обещанного срока и риска для системы - уже не вопрос одной задачи в трекере, а более комплексный вопрос. Если общих ориентиров нет, приоритет приходится каждый раз восстанавливать из контекста, который хранится у руководителя.
Причём проблема не обязательно решается формальным регламентом. Можно описать десятки правил и всё равно оставить команде один безопасный вариант - идти за подтверждением. Значение имеет не только то, что написано, но и то, какие решения на практике разрешено принимать без последующей отмены.
«Можно ли включать доработку в ближайший релиз?»
С релизами цена ручного решения обычно выше. Фраза «задача готова» мало что означает, пока не понятны детали.
Проверен только основной сценарий или смежные процессы тоже? Затронут ли обмен с другой системой? Есть ли понятный вариант отката? Кто подтвердил результат со стороны заказчика? Что произойдёт, если выпуск перенести?
Если ответы каждый раз собирает руководитель, он постепенно становится ручным шлюзом перед релизом. Небольшое исправление печатной формы и изменение критичного обмена могут проходить один и тот же маршрут - сотрудник пересказывает задачу, руководитель восстанавливает контекст и в конце разрешает выпуск релиза.
Проверять риск - это важно. Странно было бы полностью отстраниться от решения, которое может остановить работу пользователей или сорвать обязательства перед заказчиком.
Но одно дело - получить от команды готовую картину. Другое - заново читать описание каждой доработки, выяснять ход тестирования и самостоятельно решать, достаточно ли проведённых проверок.
Во втором случае условия выпуска нигде полностью не собраны. Их каждый раз восстанавливает руководитель.
Пока релиз один, схема выдерживает нагрузку. Когда одновременно готовятся несколько, а у руководителя переговоры и другие проекты, задачи начинают ждать свободного окна. Команда при этом может быть вполне компетентной. Просто она не понимает, какие отклонения допустимы, а при каких решение должно подниматься выше.
Так руководитель незаметно начинает контролировать не только критичный риск. Он заново выполняет часть работы, которую команда без него не умеет завершить.
«Какую оценку назвать заказчику?»
Допустим, разработчик оценил доработку в 40–60 часов. Нижняя граница возможна, если существующий механизм удастся использовать без серьёзной переработки. Верхняя учитывает изменение обмена и дополнительное тестирование.
Заказчик слышит диапазон и запоминает 40. Через два дня обнаруживается зависимость, которой не было в первоначальном описании. Предварительная оценка постепенно превращается в «обещание, которое команда не выполнила».
Руководитель обычно чувствует этот риск заранее. Он помнит прежние договорённости, знает особенности общения с заказчиком и понимает, какие оговорки будут услышаны, а какие пропустят. Поэтому аналитик приносит ему оценку на подтверждение.
В какой-то момент общение по небольшим задачам передают аналитику. Теперь он сам обсуждает их с заказчиком. Но договорённости о границах остаются прежними, то есть фактически отсутствуют.
Может ли аналитик самостоятельно назвать диапазон? Вправе ли изменить срок после уточнения требований? Может ли предложить сократить объём, перенести часть задачи или исключить её из ближайшего релиза?
Когда ответы неочевидны, аналитик продолжает возвращаться к руководителю на каждой развилке. Вопрос идёт от заказчика к аналитику, затем к руководителю и тем же маршрутом возвращается обратно. Коммуникацию передали, а место принятия решения не изменилось.
Такой опыт легко записать в неудачное делегирование: «Я попробовал передать, но сотрудник всё равно ничего не решает сам». Хотя ему могли поручить разговоры, не дав доступа к истории договорённостей и права принимать решения, в которых действительно можно ошибиться.
В крупном метаанализе 259 исследований Стивен Хамфри, Дженнифер Наранг и Фредерик Моргесон рассматривали автономию вместе с обратной связью, сложностью работы, доступом к информации и другими характеристиками. Общая выборка превышала 219 тысяч человек. Анализ показал, что самостоятельность сотрудника нельзя свести к формальному разрешению принимать решения. Она зависит и от того, достаточно ли у человека контекста, понимает ли он последствия выбора и получает ли обратную связь по результату.
Для практики здесь важна простая вещь. Самостоятельность не появляется после фразы «теперь за это отвечаешь ты». Сотруднику нужно понимать ожидаемый результат, видеть последствия решения и знать, где он вправе действовать без дополнительного согласования.
Почему ручное управление держится годами
У него есть очевидное преимущество, так как результат виден сразу.
Ответил сотруднику - задача продолжилась. Сам поговорил с заказчиком - спор закрыт. Лично проверил релиз - стало спокойнее.
Изменение порядка работы выглядит менее комфортно. Нужно вынести наружу критерии, которые раньше существовали только в голове, передать контекст, позволить другому человеку принять несколько решений и не вмешаться сразу, если он выбрал не тот вариант, который выбрал бы руководитель.
Новая схема при этом вполне может с первого раза не сработать. Сотрудник что-то недооценит, задаст лишний вопрос заказчику или примет слишком осторожное решение. На этом этапе очень легко вернуть всё обратно и решить, что команда пока не готова.
Иногда это действительно необходимо. Цена ошибки бывает слишком высокой. Но часто участок забирают раньше, чем успевают понять причину неудачи. Возможно, человеку не хватило знаний. Возможно, часть договорённостей была ему неизвестна. Возможно, ответственность передали, а право выбора осталось у руководителя.
Есть и профессиональная привычка. Сильный аналитик или разработчик, став руководителем, продолжает приносить пользу знакомым способом: лично разбирается в сложном. Раньше он отвечал за собственные задачи. Теперь через него проходят решения всей команды.
Чем быстрее он помогает, тем меньше у сотрудников причин искать другой способ работы. Через некоторое время зависимость становится фактом: без него действительно начинают останавливаться решения.
Это удобно принять за доказательство незаменимости. Хотя иногда это всего лишь результат системы, которая долго строилась вокруг одного человека.
Я бы здесь прежде всего смотрел на повторяемость. Один вопрос может быть частным случаем. Если с тем же вопросом приходят разные сотрудники, значит, дело уже не в конкретной задаче.
Пожар, который снова оказался неожиданным
После релиза часть пользователей не может провести документы. Руководитель подключается к разбору, собирает аналитика и разработчика, определяет порядок проверки гипотез, договаривается с заказчиком о частоте статусов и принимает решение: исправлять ошибку на месте или откатывать релиз.
Во время аварии важнее быстро собрать единую картину и не допустить противоречивых действий, поэтому его участие может быть оправдано.
Сама операционная работа здесь не является проблемой. Вопрос возникает позже, когда ситуация уже стабилизирована.
Можно разобраться, почему дефект прошёл в релиз. Но часто появляется более быстрое решение: теперь перед каждым выпуском руководитель лично подтверждает готовность.
Следующий релиз проходит спокойнее. Затем выпусков становится больше, и новое согласование превращается в очередь. Причина прошлой ошибки при этом может так и остаться неразобранной.
Нельсон Репеннинг, Паулу Гонсалвес и Лора Блэк несколько лет изучали организационное «тушение пожаров» в продуктовой разработке. Они описали устойчивый цикл: люди заняты поздним исправлением проблем, поэтому у них остаётся меньше времени на нормальную проработку следующих проектов. В новых проектах снова возникают дефекты, и срочной работы становится ещё больше.
Исследование проводилось в крупных компаниях, но механизм знаком и небольшим IT-командам. Пожар потушили, а до разбора причин снова не дошли, потому что уже появилась следующая срочная задача.
Пока не решены общие вопросы, приходится возвращаться к частным. На практике это можно перевести в один вопрос: после прошлого случая изменилось что-нибудь, кроме того, что руководитель стал контролировать ещё один участок?
Связь с работой не требует участия в каждой задаче
Полный уход от текущей работы для руководителя вряд ли полезен. Если он не видит сложные обращения, не слышит заказчика и не понимает, как принимаются технические решения, то довольно быстро начинает управлять процессом, который существует только в отчётах.
Ему по-прежнему нужно участвовать в разборе серьёзных проблем, смотреть причины возвратов, понимать состояние релизов и подключаться там, где меняются обязательства или возникает существенный риск.
Для этого не обязательно подтверждать каждую задачу.
Связь с реальной работой теряется не в тот момент, когда руководитель перестаёт отвечать на все вопросы. Она теряется, когда он больше не понимает, где команда ошибается, что мешает людям работать и какие проблемы накапливаются внутри процесса.
Иногда нужно глубоко войти в одну сложную ситуацию, чтобы увидеть причину системного сбоя. Это совсем не то же самое, что понемногу присутствовать во всех задачах, весь день переключаться между обрывками контекста и снова отвечать на вопросы, которые уже возникали неделю назад.
Приоритеты, релизы и оценки всё равно будут время от времени требовать решения руководителя. Исключительные случаи никуда не денутся. Вопрос лишь в том, действительно ли перед ним исключение или команда снова ждёт ответа, который уже получала много раз.
Руководитель становится узким местом, когда без него нельзя повторно принять решение, которое он уже принимал десятки раз.