Для изолированных задач не имеет смысла, а вот для связанных смысл большой. Одна из ключевых выгод в том, что каждый интуитивно закладывает одни и те же или схожие риски. У кого-то один риск сыграет, у кого-то другой, но каждый указал время своей задачи с учетом большинства известных рисков.
И тут срабатывает студенческий синдром — если срок назван, то очень маловероятно, что задача будет закончена раньше — даже если риск не сработает, заложенные излишки времени уйдут в лучшем случае на полировку решения или еще какой-нибудь перфекционизм.
А так — все риски собраны в один большой риск (буфер) и стоят в нужном месте, защищая дэдлайн. И схожие риски не дублируются.
А это и работает лучше на больших объемах. На маленьких сами издержки планирования могут быть выше возможного выигрыша. Но, по опыту, если с этими принципами пройти 2-3 больших проекта, то и маленькие идут быстрее — команда понимает, что в свои оценки риски закладывать не нужно — риски заложит менеджер или тимлид.
Спасибо за статью, это самая полезная вещь, которую я прочитал сегодня. И комменты под ней не уступают по полезности.
Хочу прокомментировать один момент, с которым лично столкнулся много раз и вразных проектах:
Мы оооочень много думали над проблемой КПД. Явных протечек видно не было:
программисты оценивали задачи довольно здраво
реально над ними работали, а не просто ставили таймер
с коммуникациями не было никаких проблем
Но потом всегда что-то шло не так и каждый раз разное:
находился подводный камень
итоговое решение не устраивало клиента
отваливался какой-то смежный функционал
при тестировании что-то пропускали и потом переделывали
теряли время на поиск каких-то доступов
…
Раз явных протечек не было, то второй список почти не имеет смысла — это просто жизнь / неопределенность / законы Мерфи. Его можно составлять на предмет анализа повторяемости, но с ним поделать ничего нельзя — проблема старая, как трактаты Сунь-Цзы.
Если занимаетесь взаимосвязанными задачами (и, в идеале, используете ганта), а не чистым хаосом типа разгребания багов из helpdesk, то мне помогает прием из ТОС (это который Голдратт / Цель и т.п.). Суть в двух словах проста — пусть все дают самую минимальную оценку для своих задач в идеальных условиях (если не отвлекают, ничего не отваливается, все доступы есть и т.п.). Это важный момент и он придет не сразу (!) — надо донести и донести(!) мысль, что это не обязательство и вообще завершение задачи в эти сроки вы не ждете — на то они и идеальные. Более того, если человек в эти сроки регулярно укладывается, то он явно не отдал всю подстраховку и с ним надо серьезно побеседовать.
Эти оценки пишете в ганта, получаете идеальную / нереальную дату завершения. Дальше к ней в конец добавляете «буфер проекта» — рекомендую начать с равного 100% критического пути. Если получили очень поздний дедлайн — значит либо народ не сдал в общий котел личные подстраховки, либо вы ставите нереальные дедлайны )).
Перед всеми боковыми ветками по той же схеме добавляете «боковые буферы» и определяете промежуточные дедлайны для второстепенных задач. Теперь вся неопределенность и риски будут пожирать время из буферов, вам остается направлять все усилия только на те задачи, которые пожирают буфер быстрее, чем продвигаются. Т.е. задача на 4 дня, которая съела 3 дня из буфера — ok. Задача на 1 день, которая съела 2 из буфера — НЕ ok. Плюс в том, что уже на первой трети проекта усилия и внимание автоматом будут на самых проблемных местах и есть шанс закончить без ночных бдений.
Конечно, это не так хорошо работает в коротких спринтах, на длинных проектах эффект очевидней. Но если научите давать оценку времени без учета подстраховки — это здорово вам поможет при любых принципах управления.
И тут срабатывает студенческий синдром — если срок назван, то очень маловероятно, что задача будет закончена раньше — даже если риск не сработает, заложенные излишки времени уйдут в лучшем случае на полировку решения или еще какой-нибудь перфекционизм.
А так — все риски собраны в один большой риск (буфер) и стоят в нужном месте, защищая дэдлайн. И схожие риски не дублируются.
Хочу прокомментировать один момент, с которым лично столкнулся много раз и вразных проектах:
Раз явных протечек не было, то второй список почти не имеет смысла — это просто жизнь / неопределенность / законы Мерфи. Его можно составлять на предмет анализа повторяемости, но с ним поделать ничего нельзя — проблема старая, как трактаты Сунь-Цзы.
Если занимаетесь взаимосвязанными задачами (и, в идеале, используете ганта), а не чистым хаосом типа разгребания багов из helpdesk, то мне помогает прием из ТОС (это который Голдратт / Цель и т.п.). Суть в двух словах проста — пусть все дают самую минимальную оценку для своих задач в идеальных условиях (если не отвлекают, ничего не отваливается, все доступы есть и т.п.). Это важный момент и он придет не сразу (!) — надо донести и донести(!) мысль, что это не обязательство и вообще завершение задачи в эти сроки вы не ждете — на то они и идеальные. Более того, если человек в эти сроки регулярно укладывается, то он явно не отдал всю подстраховку и с ним надо серьезно побеседовать.
Эти оценки пишете в ганта, получаете идеальную / нереальную дату завершения. Дальше к ней в конец добавляете «буфер проекта» — рекомендую начать с равного 100% критического пути. Если получили очень поздний дедлайн — значит либо народ не сдал в общий котел личные подстраховки, либо вы ставите нереальные дедлайны )).
Перед всеми боковыми ветками по той же схеме добавляете «боковые буферы» и определяете промежуточные дедлайны для второстепенных задач. Теперь вся неопределенность и риски будут пожирать время из буферов, вам остается направлять все усилия только на те задачи, которые пожирают буфер быстрее, чем продвигаются. Т.е. задача на 4 дня, которая съела 3 дня из буфера — ok. Задача на 1 день, которая съела 2 из буфера — НЕ ok. Плюс в том, что уже на первой трети проекта усилия и внимание автоматом будут на самых проблемных местах и есть шанс закончить без ночных бдений.
Конечно, это не так хорошо работает в коротких спринтах, на длинных проектах эффект очевидней. Но если научите давать оценку времени без учета подстраховки — это здорово вам поможет при любых принципах управления.