Свиридов Денис

Управление сроками проекта

Как грамотно управлять сроками ИТ-проектов

Общий подход

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

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

Просто примите как данность: подавляющее большинство исполнителей всегда недооценивает сроки реализации работ.

В моей практике с 2004 года в более чем 100 проектах еще ни разу исполнитель не оценил сроки реализации проекта, крупного этапа точно и безошибочно. Причины самые разные, но всегда сроки очень оптимистичны. Практически любой человек не может сразу точно оценить всю сложность решения задачи, выполнения работы. Всегда возникают некоторые обстоятельства, которые не учли, например, более срочная работа. Или изначальная задача оказалась более сложной, чем предполагалось. Не учли все риски, не имели всех вводных в начале и т. д. Даже если вам кажется, что сроки очень большие, то вам кажется. Они все равно с вероятностью 99% будут сорваны.

Поэтому, закладывайте буфер, временной запас на исполнение. Обычно это 20-30% . Чем больше первоначальные сроки, тем больше буфер.


Что и как делать?

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

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

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

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

Возможные результаты:
1️⃣Вас продавят и вы откажетесь от своей позиции. Если аргументированно и по делу, то вам повезло с руководством.

2️⃣Руководство согласится с вашими сроками и с вашими аргументами. Ваши сроки будут утверждены. Вам повезло с руководством.

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

4️⃣Будет найден компромисс. Руководство услышит ваши аргументы, вы услышите аргументы руководства и придёте к чему-то среднему, условно приемлемому для обеих сторон. Но в любом случае, свою первоначальную позицию фиксируйте протоколом.
Также компромисс возможен с точки зрения функциональности результата. Вы можете сделать какой-то работающий прототип, mvp (он же Minimum Viable Product, «минимально жизнеспособный продукт») в требуемые руководством сроков, а полную задачу (веха, продукт) сделать в свои сроки. Но тут имейте ввиду, после mvp часто возникают новые требования, которых нет при первоначальной постановке задачи. Это нормально. И именно под это вы и закладываете буфер в том числе.

При реализации проекта всегда необходимо верифицировать корректность как ближайшей контрольной точки, так и общих сроков. При их возможном изменении необходимо сразу предпринимать предупреждающие действия. Заранее!

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

Важное дополнение

Никогда, слышите, никогда не подписывайтесь (не обещайте) по срокам, которые отстоят от текущей даты более чем на квартал. Даже если вы в них уверены на 100%. За квартал может произойти все что угодно. На что вы повлиять не сможете. Даже при отличном управлении рисками.

Поэтому опытные руководители проектов с датами по основным вехам проекта, как и с окончательным сроком реализации проекта, работают так:

- Все что дальше года по срокам - дата реализации такой-то квартал.

- Все что более полугода и до года отстоит от текущей даты говорят - дата реализации такой-то месяц.

- Все что от квартала до полугода - дата реализации такая-то декада такого-то месяца

- А вот что в рамках квартала, уже говорят более менее-точно (плюс/минус)

И еще, хотя я говорил про планирование проекта и его вех, но все то же самое относится и к планированию спринта в Scrum. Да там оценить задачку можно в Story Point, да там оценка усредненная по больнице. Но мы говорим про Энтерпрайз, про большие проекты. В Энтерпрайзах, как бы они не старались быть Agile и т.д. ВСЕГДА спрашивают про окончательны сроки проекта и запуска продукта. Ну нет там условно бесконечного бюджета в любой момент времени. А есть жесткий процесс бюджетирования и планирования. Да, это вчерашний день, но пока он есть и что-то слабо гиганты отходят и стремятся стать бирюзовыми.

Вернуться в блог
и почитать другие статьи