Режимы работы энергосистемы как модель управления командой

Представьте команду, в которой всё вроде бы работает. Задачи закрываются, клиент получает ответы, запуск состоится вовремя. Правда, руководитель каждый вечер доделывает чужую работу, один специалист не может уйти в отпуск, а любая новая просьба вызывает маленькую панику. По отчётам порядок. По ощущениям – ещё немного, и что-нибудь отвалится.

Мне нравится смотреть на такую ситуацию через модель энергосистемы. В ней недостаточно просто обеспечить потребление в данный момент: нужно учитывать ограничения сети, возможные отключения и способность системы выдержать изменения. Для команды это полезная оптика: важен и сегодняшний результат, и то, какой ценой мы его получили, и сможем ли повторить его завтра.

Это управленческая аналогия, а не попытка описать людей законами электротехники. Ниже я использую понятия нормального, переходного, аварийного и послеаварийного режимов, чтобы разобрать разные задачи руководителя. Это не полная нормативная классификация режимов энергосистем.

Сначала посмотрим, где проходит нагрузка

В энергосистеме имеет значение не только объём доступной мощности, но и то, как она может быть передана потребителям. В команде тоже мало посчитать сотрудников и сложить их свободные часы. Если согласовать решение может только один человек, именно через него пройдут все задачи – даже когда у остальных есть время.

Предположим, в студии три дизайнера, два разработчика и руководитель, который проверяет каждый макет, отвечает всем клиентам и утверждает все оценки. Найм ещё одного дизайнера увеличит число макетов на согласовании. Скорость всей работы может почти не измениться: ограничение осталось на прежнем месте.

Поэтому прежде, чем обсуждать продуктивность отдельных людей, я бы посмотрела на путь задачи. Где она ждёт? Чьего решения не хватает? Что остановится, если конкретный сотрудник исчезнет из чата на день? Такие вопросы дают больше, чем просьба ко всем «немного ускориться».

Нормальный режим: работа идёт и есть запас

В управленческой версии нормального режима команда выполняет обязательства в обычное рабочее время, понимает приоритеты и справляется с повседневными отклонениями. Заболел коллега, клиент задержал материал, понадобилась дополнительная проверка – план приходится поправить, но весь проект не рушится.

В энергетике резерв нужен, в частности, чтобы компенсировать неожиданную потерю генерации. У команды резерв устроен иначе: это свободное время, взаимозаменяемость, понятные инструкции и возможность получить решение без единственного незаменимого человека. Аналогия здесь в готовности к отклонениям; измерять человеческий запас в процентах мощности было бы слишком буквально.

Если расписать всё доступное время до последней минуты, любая непредвиденная задача вытеснит уже обещанную работу. Поэтому свободное окно в календаре само по себе не означает, что сотрудник недогружен. Оно может быть тем, благодаря чему команда вообще соблюдает сроки.

Задача руководителя в этом режиме – поддерживать предсказуемость. Обозначать приоритеты, ограничивать количество одновременно начатых задач, убирать повторяющиеся задержки и заранее готовить замены. Универсальный «правильный процент загрузки» здесь не поможет: запас зависит от изменчивости работы и цены ошибки.

Переходный режим: правила меняются, результат ещё не устоялся

Команда переходит на новую систему, принимает крупного клиента, меняет распределение ролей или вводит в работу нового сотрудника. Старый способ уже меняется, а новый ещё требует внимания и настройки.

В электротехнике переходный процесс возникает при изменении состояния системы; он не обязательно означает аварию. В команде эта мысль особенно полезна: временное снижение скорости при изменениях не всегда говорит о плохой работе. Часть усилий уходит на обучение, согласование и исправление новых ошибок.

Например, вы внедряете систему управления задачами. Сотрудникам нужно перенести текущие проекты, договориться о статусах и привыкнуть к новому порядку. Если при этом оставить прежний объём обязательств и потребовать немедленного ускорения, у изменения не будет выделенного времени. Его придётся оплачивать вечерами.

Задача руководителя – спланировать сам переход. Кто отвечает за внедрение? Что временно убираем из нагрузки? Где проверяем результат? По каким признакам понимаем, что новый порядок заработал? И как вернёмся к рабочему варианту, если эксперимент не удастся?

Мне кажется важным отдельно называть этот период. Фраза «две недели осваиваем новый процесс и не берём дополнительные проекты» понятнее, чем ожидание, что люди одновременно сохранят прежнюю скорость и полностью изменят способ работы.

Аварийный режим: сначала остановить ущерб

Здесь привычные договорённости уже не позволяют удерживать ситуацию. Перестала работать оплата в день запуска, команда потеряла доступ к основному сервису, критическая ошибка затронула клиентов. Нужно быстро определить масштаб проблемы и восстановить самое важное.

Не всякая срочная просьба – авария. Если помечать так каждое пожелание клиента, команда перестаёт различать реальную угрозу и чужое нетерпение. Критерий лучше связывать с последствиями: что именно мы теряем, кому уже причинён ущерб и как он увеличится, если ничего не делать.

В аварийном режиме меняется порядок управления. Нужен человек, который координирует действия, общий канал информации и короткий список приоритетов. Некритичные задачи временно останавливаются. Тем, кого затронула проблема, сообщают, что известно и когда будет следующее обновление.

Допустим, перед стартом курса перестала проходить оплата. Переделка баннеров и обсуждение новых уроков могут подождать. Один человек разбирается с технической причиной, другой проверяет безопасный временный способ оплаты, третий собирает обращения и информирует покупателей. Если все одновременно чинят всё, легко получить и дублирование работы, и незамеченные задачи.

Усиленная координация здесь уместна, но у неё должна быть граница. Управлять каждым действием сотрудников и после устранения проблемы – значит закрепить чрезвычайный порядок как повседневный.

Послеаварийный режим: уже работает, но ещё не восстановилось

Самая обманчивая точка – момент, когда видимая проблема исчезла. Оплата снова проходит, сайт открывается, клиент успокоился. Хочется объявить, что всё закончилось, и сразу вернуть прежнюю нагрузку.

Но в команде могли остаться ночные переработки, отложенные задачи, временные решения и неразобранные обращения. Если немедленно нагрузить её новым запуском, следующий сбой она встретит с меньшим запасом.

Задача руководителя – вернуть устойчивый способ работы. Проверить последствия, разобрать накопившееся, убрать временные обходы и дать людям восстановиться. После этого – выяснить, почему проблема возникла и что поможет раньше заметить её повторение.

На разборе полезно спросить: какие сигналы были доступны? Почему принятое тогда решение выглядело разумным? Чего не хватало – доступа, информации, времени, полномочий? Поиск одного виноватого редко объясняет, почему процесс позволил ошибке пройти так далеко.

Вернуться к обычной работе можно, когда критичные последствия устранены, ответственность снова понятна, а обещания команде и клиентам пересобраны с учётом реального состояния дел. Сам факт, что в чате стало тихо, этого ещё не гарантирует.

Как использовать модель на планировании

Я бы начала с короткого разговора о текущей работе. Причём режим лучше определять для конкретного проекта или процесса: один проект может идти спокойно, пока другой находится в запуске. Общий режим «у нас всё горит» скрывает эту разницу.

• Что сейчас происходит: обычная работа, изменение, критический сбой или восстановление после него?
• Какие признаки это подтверждают: растущая очередь, повторные ошибки, переработки, задержки согласований?
• Что мы перестаём делать в этом режиме, а что получает приоритет?
• Кто принимает решения и где команда видит актуальную информацию?
• По каким наблюдаемым признакам мы сможем вернуться к обычной работе?

Предположим, специалист заболел перед запуском. Можно молча распределить его задачи между остальными и сохранить все сроки. А можно признать изменение доступных ресурсов, выделить обязательный минимум запуска и перенести второстепенное. Во втором случае руководитель принимает решение о нагрузке сам, вместо того чтобы оставить сотрудникам решать это ночными переработками.

Есть и предел самой метафоры. Люди умеют спорить, договариваться, учиться и предлагать неожиданные решения. Они не обязаны постоянно компенсировать недостатки организации. Поэтому модель стоит использовать для обсуждения условий работы, а не для вычисления, сколько ещё можно «выжать» из команды.

Мне близка мысль, что хорошее управление заметно по способности команды работать без постоянного спасения ситуации. Для этого нужно различать режимы, менять вместе с ними свои действия и оставлять достаточно запаса, чтобы следующий сложный день не стал последним рабочим днём всей системы.

На чём основана аналогия

Техническую сторону можно подробнее посмотреть у Системного оператора ЕЭС: расчёт режимов, планирование режимов и глоссарий. О назначении оперативного резерва – объяснение британского оператора NESO. Перенос этих идей на управление командой – предложенная здесь интерпретация, а не вывод из исследований эффективности команд.