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