Макомбер (Macomber, 2004) подчеркивает, что ни в коем случае нельзя рассматривать проект исключительно как выполнение ряда последовательных этапов. На проект необходимо смотреть как на быстрое и стабильное генерирование потока новых полезных возможностей и новых знаний. Новые возможности встраиваются в продукт, новые знания используются для его совершенствования.
Критическая проблема традиционных подходов к планированию заключается в том, что они сфокусированы на выполнении той или иной деятельности, а не на поставке функциональности. Диаграмма Гантта для традиционно управляемого проекта, или структура распределения работ, идентифицирует виды деятельности, подлежащие выполнению. Именно по ней мы определяем прогресс команды.
«Процессно-ориентированное планирование отвлекает внимание от функций, которые на деле определяют потребительскую стоимость продукта для клиента. Помимо этого, целый ряд проблем возникает в связи с вероятностью задержки поставок относительно календарного графика, полученного на основе процессно-ориентированного планирования»
Критическая проблема традиционных подходов к планированию заключается в том, что они сфокусированы на выполнении той или иной деятельности, а не на поставке функциональности. Диаграмма Гантта для традиционно управляемого проекта, или структура распределения работ, идентифицирует виды деятельности, подлежащие выполнению. Именно по ней мы определяем прогресс команды.
Первая проблема планирования по видам деятельности связана с тем, что клиенты не получают никакой стоимости от выполнения видов деятельности. Единицей стоимости для клиента является функция. Планирование, таким образом, должно осуществляться на уровне функций, а не видов деятельности.
Вторая проблема возникает при анализе ранее составленного традиционного календарного графика. Когда мы анализируем календарный график, в котором представлены виды деятельности, наше внимание приковано к поиску пропущенных видов деятельности, а не отсутствующих функций.
Дополнительные проблемы объясняются тем, что планы на основе видов деятельности (процессно-ориентированные планы) зачастую ведут к проектам, которые не укладываются в календарные графики. Сталкиваясь с невозможностью выдержать сроки, заложенные в календарный график, некоторые команды пытаются сэкономить время за счет неуместного снижения качества. Существует также практика принятия политики, которая ограничивает возможности внесения изменений в продукт, в том числе и очень ценных изменений.
Вот основные причины, по которым в результате планирования по видам деятельности трудно уложиться в сроки, предусмотренные календарным графиком:
– запланированные работы не завершаются досрочно;
«Работа растягивается так, чтобы занять все отведенное на нее время».
Пять дней, отведенные в календарном графике на работу, — это, по существу, разрешение разработчику использовать именно столько на выполнение задания. Человеку свойственно при опережении графика заполнять сэкономленное время другими, более интересными для него занятиями.
Считается, что работы не зависят друг от друга, если сроки исполнения одной из них не влияют на сроки исполнения другой.
– многозадачность приводит к дальнейшим задержкам
Второй причиной неудовлетворительных результатов традиционных подходов к планированию является многозадачность, под которой понимается одновременное выполнение нескольких задач. Многозадачность ужасным образом сказывается на производительности. Подробнее тут: проблемы многозадачности http://www.actually.pro/0883.html
Третья причина – работы, описанные в плане, не приоритизируются по их ценности для пользователей и клиента. Многие традиционные планы составляются в предположении, что все без исключения идентифицированные виды работ должны быть выполнены. Это означает, что работы обычно ранжируются и выстраиваются в определенной последовательности для удобства команды разработчиков.
Четвертый изъян традиционных подходов к планированию — игнорирование неопределенности. Справиться с неопределенностью лучше всего помогает итеративный подход. Чтобы снизить неопределенность, связанную с конечным обликом продукта, разбейте процесс выполнения работы на короткие итерации и показывайте (или в идеале предоставляйте) пользователям работоспособные версии программного обеспечения каждые несколько недель. Неопределенность, связанная с тем, как разрабатывать продукт, также устраняется путем итераций. Это позволяет, например, включить в план упущенные задачи, скорректировать допущенные ошибки. При таком подходе фокус смещается с плана на планирование.
Оценки превращаются в обязательства
Любая оценка — это вероятностная величина, предполагающая, что работа будет выполнена в расчетный срок. Допустим, вашей команде дают задание разработать новый высокоэффективный текстовый процессор. Вероятность завершения этой работы к концу недели равна 0%. Вероятность ее выполнения через 10 лет равна 100%. Если я попрошу вас дать оценку срока и вы назовете конец недели, то вероятность ее реализации будет нулевой. Если вы назовете 10 лет, то вероятность реализации оценки будет 100%-ной. Вероятность реализации всех оценок в диапазоне от конца недели до 10 лет будет находиться в интервале от 0 до 100% (Armour, 2002).
При традиционном подходе проблема может возникнуть, если проектная команда или другие участники проекта будут смешивать оценку с принятием обязательств. Как подчеркивает Филип Армор (Armour, 2002), оценка — это вероятностная величина, а обязательство не может быть вероятностным. Обязательства принимаются в виде конкретных дат. Обычно дата, которую команде предлагают (или требуют) принять в качестве обязательства, имеет, с ее точки зрения, менее чем 100%-ную вероятность. Прежде чем принять такое обязательство, команде необходимо учесть целый ряд экономических факторов и рисков. Очень важно, чтобы у команды была такая возможность и чтобы каждая оценка не превращалась автоматически в обязательство.
Литература:
Agile: оценка и планирование проектов / Майк Кон»: Альпина Паблишер; Москва; 2018г.