Очень часто, когда я занимаюсь с командами планированием проекта — в качестве руководителя проекта или «играющего тренера», — возникает проблема с планированием сроков. Дескать, как можно прогнозировать какой-то срок по проекту, когда непонятно, что делать? С другой стороны, мы же не можем поставить в плане «ХЗ пока».

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

Так как же быть?

Два вида сроков

В этой ситуации я всегда сначала объясняю, что на самом деле существует два вида сроков:

«Когда можем» — это технологически и ресурсно обусловленный срок. Мы понимаем, что нужно сделать и какие ресурсы доступны. Это позволяет нам сказать: окей, мы выполним эту работу к такому-то числу.

«Когда надо» — это срок, к которому необходимо получить результат. Например, мы точно знаем, какого числа должна начаться олимпиада. Или когда должны стартовать продажи нового товара. Нарушение этого срока ведет к убыткам, порой — огромным, как в случае с олимпиадой, поэтому на самом деле он является элементом обоснования целесообразности проекта.

Мне рассказывали про одного члена Правления банка, который говорил: «Не можете сказать срок? Тогда я вам скажу срок!».

Начинаем «крупными мазками»

Второй нюанс заключается в том, что проект можно планировать, постепенно повышая точность. Более того, в моем любимом PRINCE2 (британская методология управления проектами) это вообще способ по умолчанию. В других источниках это называется «метод набегающей волны».

Вы планируете весь проект «крупными мазками», приблизительно. Набрасываете основные этапы, даты, когда нужно получить ключевые результаты. Можно пользоваться достаточно грубыми предпосылками.

А вот ближайший этап вы планируете уже тщательно. При этом не забываете добавить в этап работы по планированию следующего этапа и уточнению плана всего проекта.

Срок — это принятие обязательств «со звездочкой»

Если вы работали в гос.органах или в гос.компаниях, возможно вы сейчас подумали: «Ага, я скажу предварительный срок, а мне потом его „пришьют“. Нет уж, спасибо!». Действительно, такое бывает. Здесь уже надо включать мастерство управления ожиданиями заинтересованных сторон.

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

Во-вторых, если установлен жесткий срок «когда надо» для всего проекта, не терпящий никакой приблизительности, у вас остается вариант управлять содержанием и (иногда) бюджетом. Надо тут же на берегу договориться, что в этой ситуации приблизительными будут требования к результатам проекта: не будем успевать — придется что-то «отрезать».

Сроки — не самое важное

К сожалению, есть руководители, которых не устраивает ни один из этих вариантов, считающие, что если сильно надавить, можно «впихнуть невпихуемое». Обычно это приводит к «выпихиванию ранее впихнутого», и, если заказчик сильно давит, это происходит в скрытом режиме и приводит к тому, что рвется что-то совсем в другом, неожиданном месте.

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

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

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

Ну и, конечно, важно помнить, что счастье заказчика = результаты — ожидания заказчика.