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

Введение

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

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

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

1. Два часа работы и два часа жизни задачи — совершенно разные величины

Для себя я разделяю две метрики. Первая — активное время. Это минуты, когда я действительно что-то делаю с задачей: пишу код, считаю, проверяю, редактирую, тестирую. Вторая — время прохождения. Оно начинается в момент, когда задача фактически попадает в работу, и заканчивается только после результата.

Условно я считаю так:

время прохождения = активная работа + ожидание + возвраты + восстановление контекста + технические паузы

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

Однажды я специально восстановил историю небольшой доработки отчёта. Нужно было добавить показатель, который уже хранился в базе. Никакой новой архитектуры, сложного API или миграции. Чистого времени получилось примерно 1 час 55 минут. Но задача прожила почти 27 часов рабочего времени. Первый раз я открыл её утром, обнаружил неоднозначность в формуле и написал аналитику. Ответ получил после обеда. К тому моменту уже переключился на другой проект. Вернулся ближе к вечеру, вспомнил структуру данных, сделал расчёт и отправил результат на проверку. На следующий день выяснилось, что показатель нужен не за календарный период, а относительно даты сделки. Снова открыл запрос, снова восстановил контекст, поменял условие, протестировал.

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

2. Основное время короткой задачи часто находится в очереди

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

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

Особенно заметно это в цепочках, где результат должен пройти несколько точек:

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

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

На практике здесь начинает работать простая механика очереди. Допустим, специалист способен проверять восемь запросов в день и в среднем получает семь. На бумаге свободная мощность есть. Но запросы приходят не равномерно по одному каждый час. В 10:00 может не быть ни одного, а в 14:30 одновременно появятся пять. В этот момент даже десятиминутная проверка перестаёт означать ответ через десять минут.

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

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

Я видел это на вполне бытовом примере. Для изменения одной формы мне требовалось подтверждение трёх полей. Само подтверждение занимало у владельца продукта минут пять. Но у него шли встречи с 11 до 15 часов. Я написал в 10:47. Ответ пришёл в 15:18. Пять минут чужой работы превратились для моей задачи в четыре с половиной часа ожидания.

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

3. Переключение контекста превращает несколько пауз в повторную работу

Самая дорогая часть подобного процесса для меня начинается после первого прерывания.

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

Мне снова нужно понять, где я остановился.

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

Поэтому я начал отдельно отмечать четыре вида потерь:

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

Одна такая пауза почти ничего не меняет. Пять пауз меняют экономику задачи полностью.

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

В итоге двухчасовая задача становится почти трёхчасовой даже без учёта ожиданий.

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

Я однажды замерял похожую работу по истории изменений файла и сообщениям. Картина получилась почти комичная. Первый подход — 38 минут. Потом ожидание 2 часа 17 минут. Второй подход — 21 минута. Затем другая срочная задача. Возврат через 3 часа 40 минут. Ещё 34 минуты работы. Ночью задача, естественно, не двигалась. На следующий день проверка, возврат, 27 минут исправлений и финальная отправка.

Если просто сложить работу руками, выходит два часа. Если посмотреть на календарь — почти два рабочих дня.

И то и другое правда.

Вывод

После нескольких таких разборов я почти перестал доверять оценке вида эта задача на два часа, если речь идёт о сроке. Для оценки трудоёмкости она полезна. Для прогноза готовности — недостаточна.

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

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

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

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