Ставлю задачу инженеру. Спрашиваю: сколько делать? Часа два, отвечает. Спрашиваю: когда будет готово? Через две недели.

Оба ответа верны. Как так?

Дело в том, что инженер оценивает эффорт (effort): сколько реального времени займёт настроить сервис, поменять правило файервола, накатить патч. А бизнес слышит срок получения результата. Это абсолютно разные величины, и разрыв между ними очень редко понимается обеими сторонами одинаково... Про согласованность, я вообще молчу, это каждый раз сюрприз, хотя повторяется такое из раза в раз.

Правило на файерволе меняется за десять минут. Заявку на его изменение согласовывают три дня, потому что она должна пройти через ИБ. Восстановление сервера из бэкапа занимает час, но доступ к резервному хранилищу выдают только после подтверждения от владельца системы, который в отпуске. Патч готов к установке сразу, но должен дождаться регламентного окна на изменения, которое бывает раз в неделю. Расследование инцидента технически можно закрыть за день, если бы не три дня ожидания логов от подрядчика, который их вообще не собирает не торопится присылать. Ни один из этих пунктов не связан с квалификацией инженера. Всё это очереди, согласования и ожидания, которые существуют вне его зоны контроля, но полностью съедают срок.

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

Ну а второе, признаюсь моё самое любимое, контекст-свитчинг. Почему любимое? Ну потому что оно самое недооценённое, и при этом дороже, чем кажется. Пока задача ждёт доступа или согласования, инженер, логично, переключается на другую задачу. "И что с того?" - спросит меня любопытный читатель. А я и отвечу, мне же не сложно 😊 Исследователь Глория Марк из Калифорнийского университета много лет изучала это на практике и выяснила, что после каждого прерывания человеку требуется в среднем 23 минуты, чтобы вернуться к тому же уровню сосредоточенности, с которым он работал до переключения. 23, КАРЛ! Американская психологическая ассоциация оценивает суммарные потери от частых переключений между задачами в 40% продуктивного времени. Получается, что инженер теряет не пару минут на то, чтобы вспомнить контекст, а почти половину рабочего дня на то, чтобы постоянно возвращаться к тому, откуда его выдернули! И это время никогда не попадает ни в одну оценку. Прикольно, да?

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

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

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

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