Весь день занят, а работа стоит: почему высокая загрузка не делает команду продуктивнее
Я долго оценивал рабочую нагрузку довольно примитивно. Если человек занят почти весь день, значит, ресурс используется эффективно. Свободное окно в календаре выглядело подозрительно. Особенно если рядом сидит коллега, у которого звонок заканчивается звонком, а чат мигает быстрее новогодней гирлянды.
Проблема обнаружилась позже. Некоторые очень занятые люди действительно делали много. Но вокруг других постоянно копилась работа. Они были нужны сразу пяти проектам, согласовывали десятки мелочей, отвечали на вопросы и в итоге превращались в точку, через которую команда физически не успевала проталкивать задачи.
С тех пор я стараюсь смотреть не на количество действий человека, а на скорость прохождения работы через всю цепочку.
Человек может работать десять минут, а задача ждать два дня
Представим обычную ситуацию. Дизайнер закончил макет в понедельник и отправил его руководителю. Руководитель занят встречами, отчётами и другими проектами, поэтому открывает файл только в среду. Проверка занимает десять минут.
Если смотреть на загрузку руководителя, всё отлично. Он потратил на задачу всего десять минут.
Если смотреть глазами команды, задача стояла почти двое суток.
Вот здесь я впервые почувствовал разницу между временем работы и временем прохождения задачи. Большую часть жизни проект иногда проводит не в работе, а в ожидании.
Сейчас я обычно смотрю на несколько вещей:
- сколько задач одновременно начато;
- сколько из них действительно заканчивается за неделю;
- сколько времени работа лежит в ожидании;
- возле каких сотрудников чаще всего образуются очереди.
Последний пункт оказался самым интересным. Если четыре человека регулярно ждут ответа пятого, его высокая занятость уже не выглядит достижением. Скорее перед нами узкое место.
Сам сотрудник при этом может работать прекрасно. Проблема вообще не в нём. Проблема в устройстве процесса.
Чем ближе загрузка к максимуму, тем хуже система переносит неожиданности
На бумаге идея загрузить специалиста на сто процентов кажется разумной. Если человек может обработать десять задач, логично дать ему десять.
В реальности почти никогда не приходит ровно десять.
Во вторник клиент внезапно просит срочную правку. Потом ломается что-то старое. Следом коллега приносит вопрос, без которого у него стоит проект. А вечером появляется задача, про которую утром вообще никто не знал.
Производительность сотрудника при этом не выросла. Просто одиннадцатая задача встала в очередь.
Потом двенадцатая.
Потом начинается знакомая история: специалист целый день что-то делает, но получить от него результат всё сложнее.
Поэтому свободное время я теперь воспринимаю немного иначе. Это не обязательно простой. Иногда это резерв мощности.
Если человек загружен примерно на весь доступный день, любой сбой ломает график. Если у него остаётся пространство для неожиданной работы, система выдерживает её намного спокойнее.
В реальной работе это особенно заметно у руководителей, разработчиков, дизайнеров, юристов и других специалистов, через которых проходят чужие решения. Их нельзя оценивать только по собственной очереди задач. Один быстрый ответ такого сотрудника иногда экономит несколько часов сразу нескольким людям.
Семь активных задач могут быть хуже трёх
Однажды я посмотрел на день человека, который объективно работал очень много.
Утром он ответил клиенту по одному проекту. Потом переключился на документ по второму. Через полчаса началась встреча по третьему. После неё появилась небольшая правка по первому. Затем попросили посмотреть проблему по четвёртому проекту.
Вечером он был уставшим абсолютно заслуженно.
Только законченных задач почти не было.
На следующий день те же проекты снова открылись вместе с ноутбуком.
Самая неприятная часть такой работы в том, что переключение тоже требует ресурсов. Особенно если речь идёт не о механических действиях, а о сложных задачах.
Разработчику нужно снова вспомнить архитектуру и состояние кода. Руководителю — восстановить историю договорённостей. Аналитику — вспомнить, почему вчера были отброшены две гипотезы. Даже обычный большой документ после перерыва приходится некоторое время читать собственными глазами, будто его писал кто-то другой.
Поэтому количество задач само по себе мне теперь почти ничего не говорит.
Я стараюсь различать:
- задачи одного типа, которые можно спокойно сделать подряд;
- работу из совершенно разных контекстов;
- проекты, постоянно требующие чужих ответов;
- работу, которую человек выполняет сам;
- работу, где от человека главным образом нужны быстрые решения для остальных.
Последняя категория особенно коварная. Сотрудник может закрыть всего три пункта своего списка, но этими тремя действиями разблокировать работу десяти коллег.
В статистике личной продуктивности это выглядит скромно. Для команды эффект может быть огромным.
Занятость хорошо видна. Пропускная способность почти незаметна
Есть причина, почему мы так легко попадаемся на эту ловушку.
Занятость можно увидеть.
Человек сидит на встрече. Пишет сообщения. Переключает окна. Отвечает на звонок. Что-то обсуждает с коллегой. Его календарь заполнен цветными прямоугольниками.
А скорость прохождения работы глазами увидеть намного сложнее.
Возьмём простую цепочку: специалист подготовил предложение, дизайнер оформил его, юрист проверил, руководитель согласовал, менеджер отправил клиенту.
Можно ускорить дизайнера в два раза. Но если согласование всё равно занимает три дня, клиент почти ничего не заметит.
Можно заставить менеджеров быстрее писать внутренние отчёты. Но если эти отчёты никто не использует, компания всего лишь научилась быстрее производить отчёты.
Мне нравится задавать в таких случаях один неприятный вопрос.
Что именно мы сейчас ускоряем: получение результата или выполнение действия?
Иногда после него часть очень важной занятости внезапно оказывается не такой уж важной.
Где я теперь ищу настоящую перегрузку
Раньше перегруженным для меня был человек, который говорил, что ничего не успевает.
Сейчас интереснее другой сигнал: человек, которого постоянно ждут.
Причём сам он может вообще не жаловаться. Он привык к такому режиму, быстро отвечает, много работает и даже считает ситуацию нормальной.
Но вокруг него постепенно растёт очередь.
Особенно настораживают ситуации, когда маленькая задача требует пятнадцать минут чистой работы, но проходит через систему четыре дня. Обычно проблема находится где-то между людьми, а не внутри самой задачи.
Иногда достаточно убрать одно согласование.
Иногда можно разрешить сотрудникам самостоятельно принимать решения до определённой суммы или уровня риска.
Иногда человеку просто нужно два часа без встреч.
А иногда стоит перестать одновременно запускать пятнадцать проектов, если команда физически способна нормально вести восемь.
Самое трудное здесь даже не изменение процесса. Труднее отказаться от ощущения, что свободный сотрудник обязательно недозагружен.
Спокойная команда иногда работает быстрее нервной
Сейчас меня уже не пугает человек со свободным окном в календаре.
Возможно, через двадцать минут у него появится срочная задача, и он сделает её сразу, вместо того чтобы перестраивать планы ещё трёх человек.
А вот команда, которая постоянно работает на пределе, стала вызывать больше вопросов.
Все заняты. В чатах движение. Встречи идут одна за другой. К вечеру люди устали и совершенно справедливо чувствуют, что много работали.
Но я всё чаще смотрю не на это.
Сколько задач действительно закончили?
Сколько времени они ждали?
Кого ждали чаще всего?
Сколько работы начали и сколько довели до результата?
Иногда оказывается, что самый полезный человек в команде вообще не выглядит героем. Он не тушит десять пожаров одновременно. У него есть время закончить начатое, подумать и быстро ответить коллегам.
А сотрудник с самым безумным календарём может оказаться не двигателем процесса, а местом, через которое пытается пройти слишком много работы.
Поэтому я больше не пытаюсь добиться постоянной занятости каждого.
Мне гораздо важнее, чтобы постоянно двигалась сама работа.