Руководитель проекта без иллюзий. Как начать, не утонуть в хаосе и довести проект до результата

2.5.3. ТРЁХТОЧЕЧНЫЙ МЕТОД ОЦЕНКИ ЗАДАЧ

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

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

Трёхточечная оценка полезна не потому, что она выглядит «математически красиво». Её главная ценность в том, что она заставляет исполнителя думать не только об идеальном сценарии, но и о реальности.

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

Для более точного расчёта продолжительности работ над задачей данный метод оценки можно представить в виде формул, где:

— О = оптимистичная оценка, то есть самый благоприятный прогноз;

— С = реалистичная / средняя оценка, то есть наиболее вероятный прогноз;

— П = пессимистичная оценка, то есть самый неблагоприятный прогноз;

— Е = итоговый прогноз;

— 4 и 6 в первой формуле представляют стандартный метод, придающий больший вес наиболее реалистичному значению;

— 3 во второй формуле используется для расчёта простого среднего значения.

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

— Реалистичная оценка показывает, сколько времени задача обычно занимает в нормальных рабочих условиях: с обычными вопросами, согласованиями, переключениями и небольшими уточнениями.

— Пессимистичная оценка показывает, что произойдёт, если появятся сложности: дополнительные требования, баги, задержки согласований, зависимость от других специалистов, необходимость исследования или переделки.

Значения О, С и П определяются экспертно — в часах, днях или денежных средствах — в ходе обсуждения с проектной командой.

Для этого участникам можно задавать одинаковые вопросы:

— Сколько времени займёт задача или проект, если всё пойдёт хорошо, без рисков и проблем?

— Сколько времени задача займёт при обычном рабочем сценарии?

— Каким может быть самый негативный сценарий и сколько времени или трудозатрат он потребует?

— Что может помешать выполнению задачи?

— Какие зависимости, уточнения, согласования или проверки могут увеличить срок?

— Есть ли у нас опыт выполнения похожих задач в прошлых проектах?

После этого полученные значения О, С и П подставляются в одну из двух формул: вариант с весом наиболее вероятной оценки показан в формуле 1, вариант простого среднего — в формуле 2.

Эта формула часто используется в PERT-оценке. В ней наиболее вероятная оценка получает больший вес, потому что чаще всего именно она ближе к реальному сценарию выполнения задачи.

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

Такой расчёт позволяет учесть возможные позитивные и негативные сценарии, оценить их влияние и получить более реалистичный прогноз. Да, он занимает чуть больше времени, чем обычная оценка «на глаз», но это время часто окупается уже на этапе исполнения проекта.

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

Например, исполнитель может сказать «Если всё пойдёт хорошо, задача займёт 6 часов. Скорее всего — 10 часов. Если появятся сложности с интеграцией, может занять 18 часов», тогда такая оценка гораздо полезнее для руководителя проекта, чем простое «Наверное, сделаю за день».

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

Управленческий принцип:

План без буферов — это не план, а пожелание.

Буфер — это не признак слабого планирования. Это профессиональный учёт неопределённости и управляемых рисков проекта. Если в проекте нет резервов, любая задержка, уточнение или ошибка сразу начнёт разрушать график.

Важно помнить:

Буфер не должен превращаться в скрытый запас «на всякий случай», который никто не контролирует. Его нужно использовать осознанно — для покрытия реальных рисков, уточнений, задержек и непредвиденных обстоятельств.

Трёхточечный метод особенно полезен, когда:

— задача новая для команды;

— есть техническая неопределённость;

— результат зависит от внешних участников;

— есть риск изменения требований;

— исполнитель сомневается в одной точной оценке;

— задача находится на критическом пути;

— ошибка в оценке может повлиять на срок всего проекта.

Запомните:

— одна оценка часто скрывает неопределённость;

— три оценки помогают увидеть диапазон возможных сценариев;

— большая разница между оптимистичной и пессимистичной оценкой означает высокий уровень неопределённости;

— PERT помогает встроить сомнения исполнителя в план, а не игнорировать их;

— буферы нужны не для красоты, а для управляемости проекта.

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

2.5.4. РЕДЛАЙН: ВНУТРЕННЯЯ КРАСНАЯ ЛИНИЯ СРОКА

Сейчас хочу поговорить об одном небольшом, но очень полезном управленческом инструменте. На первый взгляд он кажется простым: всего лишь поставить внутренний срок раньше внешнего срока сдачи. Но на практике именно такие простые вещи часто спасают проект от аврала, нервов и неприятных разговоров с заказчиком.

Речь пойдёт о редлайне.

Все знают слово «дедлайн». Все понимают, что финальный срок нарушать нельзя. Но проблема в проектах обычно возникает не в сам день сдачи, а раньше — когда команда слишком поздно понимает, что результат ещё сырой, тестирование не закончено, документы не подготовлены, а времени на спокойные исправления уже нет.

Именно для этого и нужен редлайн.

Редлайн от англ. redline — «красная линия» — это внутренний контрольный срок, к которому работа должна быть готова для проверки, исправлений, тестирования, согласований и спокойной финальной сдачи.

Проще говоря, редлайн — это момент, когда команда должна перестать «просто делать» и перейти к проверке готовности результата.

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

Если внешний срок стоит на пятницу, 18:00, грамотный руководитель проекта не планирует завершение работ на пятницу, 17:59. Он ставит внутренний редлайн раньше: например, на среду вечер или четверг утро. Оставшееся время используется не для героического добивания задач в последний момент, а для проверки результата, исправления ошибок, согласования и подготовки к сдаче.

Это не бюрократия и не перестраховка. Это нормальный управленческий инструмент.

Если вы запланировали завершение работы ровно к финальному сроку, вы уже опоздали управленчески. У вас не осталось пространства для ошибки.

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

— заранее увидеть реальное состояние проекта;

— защитить проект от форс-мажоров;

— оставить время на исправления, тестирование и согласования;

— улучшить качество результата;

— снизить стресс перед сдачей.

Заострю ваше внимание на том, что редлайн и буфер связаны, но это не одно и то же:

— Буфер — это запас времени, который защищает проект от неопределённости.

— Редлайн — это контрольная точка перед этим запасом, говорящая, что пора начинать использовать этот запас осознанно.

Связь между редлайном, буфером и дедлайном показана на рисунке 3.

Рисунок 3 — Редлайн, буфер и дедлайн в управлении сроками

Например:

— внешний срок сдачи: пятница, 18:00;

— редлайн: среда, 18:00;

— буфер: четверг и пятница до сдачи.

Редлайн показывает момент, когда работа должна перейти из режима «делаем» в режим «проверяем, исправляем, сдаём».

Как определить редлайн? Универсального процента нет. Но для начинающего РП можно использовать простое правило: редлайн ставится на 10—30% раньше финального срока, в зависимости от сложности, неопределённости и критичности результата.

Например:

— если задача маленькая и понятная, достаточно 10% запаса;

— если задача связана с тестированием, согласованием или несколькими исполнителями, лучше заложить около 20%;

— если проект сложный, есть внешний заказчик, интеграции, подрядчики или высокая цена ошибки, нужен запас ближе к 30%.

Важно:

Редлайн нельзя ставить «из воздуха». Он должен быть связан с реальными действиями после него.

После редлайна должно остаться время на:

— тестирование;

— исправление ошибок;

— ревью результата;

— согласование с заказчиком или руководством;

— подготовку документов;

— упаковку релиза;

— проверку доступов, инструкций и сопроводительных материалов;

— финальную коммуникацию со стейкхолдерами.

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

Например:

Команда должна показать заказчику готовый функционал в пятницу в 15:00.

Плохой план:

— разработка заканчивается в пятницу в 13:00;

— тестировщик проверяет «на бегу»;

— баги чинятся за час до демонстрации;

— РП параллельно пишет письмо заказчику;