Совместить несовместимое: что делать, если исполнитель планирует работу по Scrum, а заказчик — нет

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

— Сетевые диаграммы используются в управлении проектами очень давно. Если верить статьям и книгам, то впервые в бизнесе они появились в корпорации DuPont в 1956, для составления планов-графиков масштабных работ по модернизации заводов фирмы.

Что такое сетевые диаграммы и как они составляются?

Мне кажется, что многие из вас уже что-то слышали, а кто-то даже прекрасно владеет методикой сетевого планирования и методом критического пути. Но на всякий случай напомню на простом примере, как выполняются расчеты в сетевом графике, что они означают для руководителя проекта.

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

Руководитель проекта с командой:

• Определил список работ
• Присвоил задаче код
• Сделал прогноз по длительности каждой из них
• Определил последовательность выполнения работ (в поле «предшественник» указывается код задачи, которая должна быть завершена до старта следующей)

В результате получилась таблица:

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

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

Как составлять график критического пути. Для каждой из задач заполняется отдельная ячейка с легендой. Последовательность их выполнения указывается стрелками.

Например, задача B, которой соответствует определенная ячейка с легендой, может начинаться только после того, как будет полностью завершена задача A (по ней будет получен ожидаемый результат). Задача F начинается только тогда, когда полностью завершены задачи C и D.

Для простоты понимания расчетов параметров графика можно использовать не даты, а количество необходимых для выполнения работ дней. При этом договоримся, что если работа A начинается сегодня, мы присвоим ей значение 0 (ноль). Тогда расчет ранних дат старта и финиша для работы А выполняется следующим образом:

• Ранний старт работы А: день с номером 0
• Ранний финиш работы А: равен «ранний старт» плюс «длительность», т.е. 0 + 2 = 2 (второй день)

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

• Ранний старт: день с номером 2
• Ранний финиш: 2 + 15 = 17 день

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

Также нам нужно определить поздние даты старта и финиша по задаче. Для их расчета используются следующие правила:

• Поздняя дата финиша задачи-предшественника равна поздней дате старта задачи-последователя (если у задачи нет последователя, поздний финиш задачи равен ее раннему финишу)
• В случае, если последующих задач несколько (как у задачи А) — выбирается наименьшее значение из имеющихся
• Поздняя дата старта задачи определяется как разница между ее поздним финишем и длительностью

В результате выполнения расчетов ранних/поздних дат старта и финиша, график будет выглядеть вот так:

Что дает понимание критического пути руководителю проекта?

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

Несмотря на то, что методу критического пути уже скоро 60 лет, мне кажется, он актуален для планирования проектов и сегодня.

Как происходит планирование времени по Agile

Адепты Agile, а в частности, фреймворка Scrum, обычно не используют сетевые диаграммы при управлении проектом. В Scrum используется другая техника планирования сроков проекта, которая предполагает управление приоритетами требований (историй), отбор самых приоритетных требований для выполнения следующего этапа работы (спринта).

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

При этом еще раз повторюсь — никакие сетевые графики, о которых мы говорили выше, не требуются.

Как совместить Agile и сетевые графики? И самое главное — для чего это надо

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

Управляя проектами, я заметил, что заказчик проекта хочет видеть старую добрую диаграмму Ганта, которая чаще всего строится на основании сетевого графика, в качестве расписания: какие задачи будут выполнены в ходе проекта. В Беларуси заказчики проекта до сих пор не представляют себе, как можно по-другому представить план проекта, кроме как в виде диаграммы Ганта.

Заказчик хочет видеть верхний уровень плана проекта: план с не очень глубокой детализацией работ, например, на 2−3 уровня в глубину.

В свою очередь команда исполнителя хочет работать итерациями (или спринтами) и планировать список требований на следующий спринт.

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

Как совмещать несовместимое, чтобы заказчику было удобно?

Давайте разберемся, с какими сложностями столкнется команда проекта, решившая использовать для планирования проекта два подхода: сетевой график для верхнего уровня плана и планирование спринтов для составления планов на неделю (2−3 недели вперед):

Сложность 1. Задачи верхнего уровня, представленные в виде сетевого графика, могут иметь продолжительность больше, чем один спринт.

Сложность 2. Задачи сетевого графика могут иметь плановые даты старта/финиша, не совпадающие с этими датами в спринте.

Сначала разберемся с причинами этих двух сложностей. Дело в том, что в основе сетевого графика лежат задачи и этапы, а в основе планирования спринтов лежат требования (истории пользователей), которые разбиваются на более мелкие задачи.

Однако, если вдуматься, никакой особой сложности нет.

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

1. На верхнем уровне ставятся задачи: достичь определенных результатов, которые представляют из себя разработанные продукты проекта, основанные на пользовательских историях (требованиях к продукту).

2. На втором уровне ставится задача по декомпозиции продуктов на фичи (разработка определенных функций продукта).

3. На третьем уровне фичи будут детализированы на требования пользователей.

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

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

Ответ: не можем, т.к. это право владельца продукта, и запретить ему менять приоритеты по требованиям команда не может.

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

Мой опыт такого симбиоза показывает, что сетевой график остается полезен скорее для заказчика проекта, которому «легче спится», когда он видит прогресс проекта на диаграмме Ганта.

А команда начинает все же жить спринтами, изредка подглядывая в диаграмму Ганта, чтобы увидеть там незаконченные элементы работ.

Еще один способ: использовать сетевую диаграмму внутри спринтов

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

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

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

Итак, сделаем выводы:

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

Максим Якубович Эксперт по управлению проектами. Директор компании «АйТи уит» Опыт работы в сфере управления проектами — с 2003 года. Более 20-ти выполненных проектов в роли руководителя проекта и руководителя программы проектов. Консультант и бизнес-тренер в консалтинговой группе «Здесь и сейчас». Преподаватель модуля «Управление проектами» Русской школы управления. Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна. Приглашенный преподаватель компании «Инфопарк-проект». Опыт преподавания — с 2005 года (прошли обучение около 2300 студентов). Ведущий блога по управлению проектами.