Главный вопрос, который нас интересует при постановке задачи - как быстро она будет сделана. Но не всегда мы этот вопрос задаём. А зря. Даже если заказчик не требует сроков, это значит лишь одно из двух:
Он считает, что всё будет сделано “ещё вчера”
Задачу ставит человек без опыта и дело закончится конфликтом
Подходы к оценке времени
Менеджеры и исполнители, ловившие “люли” за сорванные сроки, практикуют различные "инструменты управления", чтобы отвязаться от неприятного вопроса “Когда?”. Приведу примеры, с которыми сталкивался лично я (что уж греха таить, сам практиковал):
Уклонение
Лучший способ избежать последствий от сорванных сроков - не называть этих сроков: "Не могу сейчас сказать", "Не буду даже пытаться", "Скажу завтра - может, забудут уточнить?", "Это нетипичная задача", "У нас сейчас много задач"... Прокатывает, но не со всеми и не каждый раз.
Ложь
“Через пару часов будет готово”. Это бывает неумышленно (по неопытности), или умышленно (пофигизм обыкновенный), но регулярно. 90% сроков, которые я слышу - сорванные с облаков произвольные величины времени. И это грустно. Не надо врать - лучше уж уклоняйтесь…
Делегирование
А давайте не PM, а исполнитель скажет, сколько времени уйдёт на таск? А давайте! В случае срыва (гарантия 100%) делаем грустное лицо: - Ох уж этот верстальщик… Заболел… Не успел… О[}:{]ел… В общем, способ “делегирование” в чистом виде практически эквивалентен способу “ложь”.
Умножение
Не со всеми прокатывает делегирование? Что же, мотаем на ус и умножаем срок от исполнителя на два (три, четыре, пять - учимся считать). С другой стороны, это уже попахивает риск-менеджментом и другими умными словами. Правда, коэффициент приходится постоянно нормировать на конкретного исполнителя и заказчика. Как выхлоп - известное правило, что работа занимает все отведенное на неё время.
Абстракция
“На эту задачу уйдёт пять часов” - звучит здраво, опытно и обнадеживающе. Но проходит неделя и задача не выполнена. Как так? Мы же трудились без перерыва! Кофе, перекур, обсуждение тачки начальника - был завал, делали другие задачи, смотрели в окно. Какое-то время это прокатывает, даже очень неплохо. До тех пор, пока не входит в систему. В перспективе превращается в способ оценки “ложь”, причем, очевидный для обеих сторон.
Принятие оценки клиента
Нужно сделать за неделю? Принято! Не успели? - Так Вы сами же поставили еще 10 задач! Так у нас же крыша протекла! Чёрный кот дорогу перебежал с утра.
Степень неадекватности такого рода уклонения зависит лишь от лояльности зрителя (заказчика). Срок, спущенный сверху, НИКОГДА не является зоной ответственности исполнителя. Заказчик может лишь высказывать пожелания или назначать предельные точки исполнения, в рамках которых задача имеет смысл (и это необходимо делать), но оценка реальности исполнения должна прилетать от исполнителя.
А какие ты знаешь?
Делись в комментариях. Делать этого ты, конечно же, не будешь)
Реальные практики планирования сроков
Учитывая все приёмы “уклонистов”, в цепочке постановки сроков нужно лавировать между здравым смыслом и желанием достичь результата. Это значит, что ты обязан знать все возможные приемы в уклонении и извлекать из них профит:
Требовать
Получать сроки от исполнителя или другого ПМ по цепочке - это необходимость. Иначе получаем бесконечную задачу. Это просто реальность, в которой мы живём. Не получив срока, не получишь результат. И обязательным условием является наглядная фиксация. Исполнитель должен понимать дату, под которой подписался, и за которую с него спросят.
Уточнять
Так как практика учит: большинство сроков не соблюдаются, наивно надеяться, что в конкретном случае всё пойдёт не так. Перестраховывайся. Обновление актуального состояния прогресса и сроков по ходу выполнения задачи - не невроз или прихоть, а необходимость. Если процесс критичен, то время от времени уточняй, насколько актуальна первичная оценка времени и сколько потребуется ещё ресурсов для завершения теперь.
Не назначать самому
Разве что можно обозначить какую-то срочность, но это есть суть - расстановка приоритетов. За спущенные сверху сроки исполнитель не несет никакой ответственности, даже если лично тебе показалось иначе. И в любой непонятной ситуации он назовет тысячи причин, помешавших ему достигнуть желаемого тобой - от проблем со здоровьем до тебя самого, некорректно описавшего задачу.
Только требуя назвать время исполнения, мы заставляем исполнителя декомпозировать задачу и брать на себя ответственность, прикидывать мозгами, а реально ли вообще здесь сделать что-то?
Контролировать
Первоначальная оценка сроков - это, конечно же, важно. Но куда важнее их соблюдение. И тут начинается самое интересное: Люди делают только то, что ты контролируешь.
И это точка. Нет, они, конечно, могут придумывать себе задачи, заниматься креативом, смотреть видео… Но это совершенно не то, чего от них ждёшь ты. Поэтому, самое главное правило для достижения сроков - регулярный контроль их исполнения. Да, это душно. Да, это ужасно. Да, это некомфортно. Но только это работает. По крайней мере, исходя из моего опыта.
Как же всё-таки правильно ставить и соблюдать сроки?
А никак. В идеальном мире любые рекомендации “как правильно” сталкиваются с суровой действительностью. Наверняка, ты задумывался об этом, читая статьи на схожую тематику? “Вот, как у автора всё хорошо! Сделал А, потом Б, записал в В, проконтролировал в Д. Но где же Г?”.
Дело в том, что PM в ходе своей работы сталкивается не с управляемым кодом или красивыми рисунками, а с самым непредсказуемым в природе материалом - людской психикой. Только держа в голове разнообразные хитрости, слабости и приемы уклонения, мы можем если не избежать, но уменьшить фактор риска при срыве тех или иных сроков.
Это значит, что применяемые практики контроля сроков должны сводиться к нейтрализации слабостей конкретных людей и процессов. Исполнитель не умеет объективно оценивать время? - закладываем риск и требуем от него делать оценку почаще (пусть учится). Исполнитель бодро берётся за дело, а потом переключается на другие задач? - постоянно возвращаем его в русло. Исполнитель отказывается от оценки - требуем до последнего патрона (шутка).
До связи!
UPD: В данной статье я не рассуждаю о какой-то конкретной методологии и не перечисляю выдержки из учебников по менеджменту. Всё это - мои размышления о психологии управления. Управления не только программистами (ага, другими людьми тоже порой приходится управлять и там возникают схожие проблемы).
Возможно, для кого-то они покажутся банальными или "нетехническими", а кто-то скажет: что вам, манагерам-дуракам: декомпозировал задачки до уровня часа, в диаграмму всё разложил, графики нарисовал и сиди-кури, всё же написано 100 лет назад. А кому-то, в особенности начинающим руководителям, мои размышления могут показаться вполне себе полезными (мне бы в своё время точно показались).
Никому не навязываю свою точку зрения. Всем спасибо за критику и замечания!
