Почему не работают оценки времени в проектах?

Kate

Administrator
Команда форума
Главный вопрос, который нас интересует при постановке задачи - как быстро она будет сделана. Но не всегда мы этот вопрос задаём. А зря. Даже если заказчик не требует сроков, это значит лишь одно из двух:

  • Он считает, что всё будет сделано “ещё вчера”
  • Задачу ставит человек без опыта и дело закончится конфликтом

Подходы к оценке времени​

Фото создано nakaridore - ru.freepik.com/photos/woman
Фото создано nakaridore - ru.freepik.com/photos/woman
Менеджеры и исполнители, ловившие “люли” за сорванные сроки, практикуют различные "инструменты управления", чтобы отвязаться от неприятного вопроса “Когда?”. Приведу примеры, с которыми сталкивался лично я (что уж греха таить, сам практиковал):

Уклонение​

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

Ложь​

“Через пару часов будет готово”. Это бывает неумышленно (по неопытности), или умышленно (пофигизм обыкновенный), но регулярно. 90% сроков, которые я слышу - сорванные с облаков произвольные величины времени. И это грустно. Не надо врать - лучше уж уклоняйтесь…

Делегирование​

А давайте не PM, а исполнитель скажет, сколько времени уйдёт на таск? А давайте! В случае срыва (гарантия 100%) делаем грустное лицо: - Ох уж этот верстальщик… Заболел… Не успел… О[}:{]ел… В общем, способ “делегирование” в чистом виде практически эквивалентен способу “ложь”.

Умножение​

Не со всеми прокатывает делегирование? Что же, мотаем на ус и умножаем срок от исполнителя на два (три, четыре, пять - учимся считать). С другой стороны, это уже попахивает риск-менеджментом и другими умными словами. Правда, коэффициент приходится постоянно нормировать на конкретного исполнителя и заказчика. Как выхлоп - известное правило, что работа занимает все отведенное на неё время.

Абстракция​

“На эту задачу уйдёт пять часов” - звучит здраво, опытно и обнадеживающе. Но проходит неделя и задача не выполнена. Как так? Мы же трудились без перерыва! Кофе, перекур, обсуждение тачки начальника - был завал, делали другие задачи, смотрели в окно. Какое-то время это прокатывает, даже очень неплохо. До тех пор, пока не входит в систему. В перспективе превращается в способ оценки “ложь”, причем, очевидный для обеих сторон.

Принятие оценки клиента​

Нужно сделать за неделю? Принято! Не успели? - Так Вы сами же поставили еще 10 задач! Так у нас же крыша протекла! Чёрный кот дорогу перебежал с утра.

Степень неадекватности такого рода уклонения зависит лишь от лояльности зрителя (заказчика). Срок, спущенный сверху, НИКОГДА не является зоной ответственности исполнителя. Заказчик может лишь высказывать пожелания или назначать предельные точки исполнения, в рамках которых задача имеет смысл (и это необходимо делать), но оценка реальности исполнения должна прилетать от исполнителя.

А какие ты знаешь?​

Делись в комментариях. Делать этого ты, конечно же, не будешь)

Реальные практики планирования сроков​

Учитывая все приёмы “уклонистов”, в цепочке постановки сроков нужно лавировать между здравым смыслом и желанием достичь результата. Это значит, что ты обязан знать все возможные приемы в уклонении и извлекать из них профит:

Требовать​

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

Уточнять​

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

Не назначать самому​

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

Только требуя назвать время исполнения, мы заставляем исполнителя декомпозировать задачу и брать на себя ответственность, прикидывать мозгами, а реально ли вообще здесь сделать что-то?

Контролировать​

Первоначальная оценка сроков - это, конечно же, важно. Но куда важнее их соблюдение. И тут начинается самое интересное: Люди делают только то, что ты контролируешь.

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

Как же всё-таки правильно ставить и соблюдать сроки?​

А никак. В идеальном мире любые рекомендации “как правильно” сталкиваются с суровой действительностью. Наверняка, ты задумывался об этом, читая статьи на схожую тематику? “Вот, как у автора всё хорошо! Сделал А, потом Б, записал в В, проконтролировал в Д. Но где же Г?”.

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

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

До связи!

UPD
: В данной статье я не рассуждаю о какой-то конкретной методологии и не перечисляю выдержки из учебников по менеджменту. Всё это - мои размышления о психологии управления. Управления не только программистами (ага, другими людьми тоже порой приходится управлять и там возникают схожие проблемы).

Возможно, для кого-то они покажутся банальными или "нетехническими", а кто-то скажет: что вам, манагерам-дуракам: декомпозировал задачки до уровня часа, в диаграмму всё разложил, графики нарисовал и сиди-кури, всё же написано 100 лет назад. А кому-то, в особенности начинающим руководителям, мои размышления могут показаться вполне себе полезными (мне бы в своё время точно показались).


 
Сверху