Я быстрее сделаю сама. Как эта привычка незаметно делает работу сложнее

Краткая аннотация

Иногда передать задачу коллеге объективно дольше, чем выполнить ее самостоятельно. Я много раз выбирала именно этот вариант и действительно экономила время — но только сегодня. Через несколько месяцев оказалось, что часть процессов без меня просто не запускается. Разбираюсь, почему так происходит и где проходит граница между нормальной эффективностью и опасной зависимостью команды от одного человека.

Введение

У меня есть рабочая привычка, которую очень легко принять за эффективность. Когда появляется небольшая задача, которую теоретически можно передать коллеге, я сначала мысленно оцениваю, сколько придется объяснять. Открыть нужные файлы, рассказать предысторию, показать исключения, предупредить про старую ошибку, проверить результат.

И довольно часто после этого возникает простая мысль: я сама закончу быстрее.

Самое неприятное в том, что эта мысль обычно правильная.

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

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

1. Почему объяснить работу иногда действительно сложнее, чем выполнить ее

Я раньше думала, что проблема только во времени. Теперь считаю иначе. Основная сложность передачи задачи — в количестве контекста, который хранится у меня в голове, но нигде больше не существует.

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

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

Нужно объяснить:

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

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

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

Причем передать нужно не только нормальный сценарий. Самое ценное обычно находится в исключениях.

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

Ни одна из этих проверок не требуется каждый день. Именно поэтому они быстро выпадают из инструкции.

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

Передача работы требует этот кэш хотя бы частично выгрузить.

И поэтому на короткой дистанции выполнить задачу самой действительно рационально.

2. Где быстрая самостоятельная работа начинает становиться дорогой

Долгое время я сравнивала только два числа: сколько времени уйдет у меня и сколько времени потребуется на объяснение.

Это слишком примитивная модель.

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

Я стала мысленно раскладывать такие задачи примерно так:

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

Особенно хорошо это стало видно на одном рабочем процессе.

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

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

Пятнадцать минут казались дешевле часа.

Но операция повторялась несколько раз в неделю.

Если смотреть только на одну задачу, самостоятельное выполнение выигрывает. Если смотреть на квартал, арифметика меняется. Я снова и снова платила по пятнадцать минут за то, чтобы не заплатить один раз час объяснения.

Но даже время оказалось не главной потерей.

Хуже было другое: эта маленькая операция начала определять мое расписание.

Я не могла полностью отключиться от проекта. Перед отпуском приходилось либо делать работу заранее, либо срочно кому-то объяснять. Если задача появлялась в неудобный момент, она все равно шла ко мне. Люди перестали думать, кто еще способен ее выполнить, потому что существовал надежный маршрут — отправить мне.

И здесь возникает довольно интересный эффект.

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

Я получаю больше опыта. Выполняю работу быстрее. Замечаю ошибки раньше. Коллеге тем временем задача становится все менее знакомой.

Через полгода сравнение уже выглядит примерно так: мне нужно десять минут, другому человеку — сорок.

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

Я постоянно тренировалась выполнять процесс, а остальные постоянно тренировались его не выполнять.

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

В какой-то момент такая система начинает сама поддерживать собственную зависимость.

3. Как я поняла, что стала не специалистом, а частью инфраструктуры

Самый неприятный момент наступает не тогда, когда задач становится слишком много.

Он наступает тогда, когда окружающие начинают строить процесс с учетом того, что ты всегда доступна.

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

Потом я заметила странную вещь. Люди уже не спрашивали, смогу ли я посмотреть результат. Следующий этап просто планировался после моей проверки.

То есть я незаметно перестала быть человеком, которому иногда передают задачу. Я стала обязательным компонентом процесса.

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

Проблема в архитектуре процесса.

Причем внешне все может выглядеть прекрасно.

Задачи выполняются быстро. Ошибок мало. Руководителю не приходится вмешиваться. Сроки соблюдаются.

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

Мне потребовалось время, чтобы понять еще одну вещь: передать задачу и передать способность решать задачу — не одно и то же.

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

Но стоит одному условию измениться — и процесс снова возвращается ко мне.

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

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

Иначе вместо передачи знаний получается запись макроса в человеческом исполнении.

Я заметила, что лучшие инструкции у меня начали появляться только после того, как я перестала описывать интерфейс и начала описывать решения.

Раньше запись могла выглядеть примерно так: открыть раздел, выбрать период, поставить фильтр, скачать файл.

Теперь я стараюсь сначала определить смысл шага: получить только завершенные операции за период, причем использовать дату завершения, а не дату создания.

После этого конкретные действия в системе становятся вторичными. Интерфейс может поменяться, кнопка может переехать, но логика останется.

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

Передача задачи в таких случаях превращалась почти в аудит процесса.

Я начинала объяснять действие и вдруг понимала, что оно больше не нужно.

Или что проверку можно автоматизировать.

Или что два разных файла содержат одну и ту же информацию.

Или что исключение, ради которого существует половина инструкции, исчезло после обновления системы полгода назад.

Получился парадокс: попытка отдать работу другому человеку иногда позволяла мне сначала упростить саму работу.

Что я теперь делаю иначе

Я не стала передавать коллегам вообще все задачи.

Мне кажется, это такая же крайность, как желание все сделать самостоятельно.

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

Но повторяющиеся процессы я теперь оцениваю не по сложности текущего выполнения.

Я задаю себе другой вопрос: что произойдет, если завтра я не смогу это сделать?

Если ответ — ничего страшного, значит, зависимости нет.

Если задача спокойно подождет несколько дней, тоже нормально.

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

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

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

Важно хотя бы видеть, что он существует.

Самая дорогая ситуация возникает тогда, когда зависимость от одного человека принимают за высокую производительность.

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

Это приятно примерно до того момента, пока понимаешь, что собственная компетентность постепенно превратилась в очередь входящих запросов.

Теперь для меня хороший рабочий процесс — не тот, в котором я могу очень быстро решить проблему.

Хороший процесс — тот, который продолжает работать, когда я на день закрываю ноутбук.