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