Третья причина, по которой традиционное планирование не может обеспечить стабильное создание высокоценных продуктов, заключается в том, что работы, описанные в плане, не приоритизируются по их ценности для пользователей и клиента. Многие традиционные планы составляются в предположении, что все без исключения идентифицированные виды работ должны быть выполнены. Это означает, что работы обычно ранжируются и выстраиваются в определенной последовательности для удобства команды разработчиков.
В соответствии с традиционным мышлением если выполнению подлежат все виды работ, то для клиентов проекта не имеет значения, в какой последовательности они выполняются. Такой подход приводит к тому, что команда разработчиков занимается созданием функций в случайном, с точки зрения клиента, порядке. Затем в конце проекта команда, пытаясь уложиться в календарный график, начинает сокращать набор функций. Поскольку никто не старается выстроить работу над функциями в зависимости от их приоритетности, среди отброшенных функций оказываются такие, которые имеют более значительную ценность, чем функции, включенные в продукт.
Мы не учитываем неопределенность
Четвертый изъян традиционных подходов к планированию — игнорирование неопределенности. Мы не принимаем во внимание неопределенность, связанную с продуктом, и считаем, что первоначальный анализ требований позволяет определить полный и идеальный набор характеристик продукта. Мы исходим из того, что пользователи не передумают, не изменят свое мнение и не выдвинут новые требования в период, охватываемый планом.
Аналогичным образом мы не учитываем неопределенность, связанную с процессом создания продукта, и делаем вид, что можем дать точную оценку («две недели») работе, которой присуща неопределенность. Невозможно идентифицировать каждое действие, которое потребуется для осуществления проекта. Так или иначе, мы нередко не учитываем этот аспект в составляемых планах.
Несмотря на неопределенность, календарные графики зачастую содержат конкретные, безусловные даты, например «Поставка продукта — 30 июня». В начале проекта неопределенность наиболее высока. Оценки, которые мы даем, должны отражать эту неопределенность. Можно, например, представить срок окончания в виде диапазона: «Поставка продукта — июнь — август». Оценки по мере выполнения проекта и устранения неопределенности и риска можно пересматривать и уточнять. Именно в этом суть конуса неопределенности, представленного в главе 1 «Цель планирования».
Справиться с неопределенностью лучше всего помогает итеративный подход. Чтобы снизить неопределенность, связанную с конечным обликом продукта, разбейте процесс выполнения работы на короткие итерации и показывайте (или в идеале предоставляйте) пользователям работоспособные версии программного обеспечения каждые несколько недель. Неопределенность, связанная с тем, как разрабатывать продукт, также устраняется путем итераций. Это позволяет, например, включить в план упущенные задачи, скорректировать допущенные ошибки. При таком подходе фокус смещается с плана на планирование.
Оценки превращаются в обязательства
Любая оценка — это вероятностная величина, предполагающая, что работа будет выполнена в расчетный срок. Допустим, вашей команде дают задание разработать новый высокоэффективный текстовый процессор. Вероятность завершения этой работы к концу недели равна 0 %. Вероятность ее выполнения через 10 лет равна 100 %. Если я попрошу вас дать оценку срока и вы назовете конец недели, то вероятность ее реализации будет нулевой. Если вы назовете 10 лет, то вероятность реализации оценки будет 100 %-ной. Вероятность реализации всех оценок в диапазоне от конца недели до 10 лет будет находиться в интервале от 0 до 100 % (Armour, 2002).
При традиционном подходе проблема может возникнуть, если проектная команда или другие участники проекта будут смешивать оценку с принятием обязательств. Как подчеркивает Филип Армор (Armour, 2002), оценка — это вероятностная величина, а обязательство не может быть вероятностным. Обязательства принимаются в виде конкретных дат. Обычно дата, которую команде предлагают (или требуют) принять в качестве обязательства, имеет, с ее точки зрения, менее чем 100 %-ную вероятность. Прежде чем принять такое обязательство, команде необходимо учесть целый ряд экономических факторов и рисков. Очень важно, чтобы у команды была такая возможность и чтобы каждая оценка не превращалась автоматически в обязательство.
Резюме
С учетом представленного выше перечня проблем, связанных с традиционными подходами к планированию, вряд ли можно удивляться неудовлетворительным результатам многих проектов. Процессно-ориентированное планирование отвлекает внимание от функций, которые на деле определяют потребительскую стоимость продукта для клиента. Помимо этого, целый ряд проблем возникает в связи с вероятностью задержки поставок относительно календарного графика, полученного на основе процессно-ориентированного планирования. С самыми благими намерениями участники проектов уповают на многозадачность как возможное решение проблем, однако в конечном итоге еще больше отстают от календарного графика из-за скрытых издержек многозадачности. Когда не удается выдержать график выполнения проекта, исполнители начинают урезáть функциональность. Поскольку работа над функциями ведется в том порядке, который наиболее удобен разработчикам, далеко не всегда в жертву приносятся функции, имеющие наименьшую потребительскую стоимость для пользователей.
