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

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

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

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

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

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

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

Но это не статья о том, как тяжело управлять проектами. Кому-то это удается лучше, кому-то – хуже, но у всех иногда бывают провалы. Когда дело доходит до управления проектами, распределение времени – наша ахиллесова пята. В прошлом мы бы с радостью взялись за работу, не подумав, не спланировав и не передав функции. Но сейчас нам приходится отказывать. Это грустно и печально, но нельзя больше допускать, чтоб дела накапливались, а масса обязательств проносилась мимо нас.

Традиционный подход (как он выглядит на бумаге)

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

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

Структура декомпозиции работ – это не список действий для выполнения проекта. Структура декомпозиции работ – это работа, ориентированная на разделение результата, а не на саму работу. Однажды создав структуру, мы можем сформировать список задач, которые должна выполнить проектная команда для достижения результата.

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

Список действий должен быть расставлен в таком порядке, в каком действия должны будут происходить. Большинство действий полагаются на постоянную логику - они должны происходить в определенном порядке для того, чтобы проект достиг успеха. Нам необходимо установить операционную систему до установления приложений. Программируемая логика полагается на решения руководства. К примеру, мы могли бы создать такой скрипт, который после установления операционной системы вызвал бы удаленный сервер для получения приложения и установил бы его на целевой станции сразу после завершения установки ОС. Но этого можно и не делать. Это избирательная логика, основанная на опыте, природе выполняемой работы, вашем настроении и т.д.

Теперь начинается самое интересное - в качестве руководителя вы изучаете последовательность работ и понимаете, что вы на самом деле можете следовать нескольким путям в тандеме для завершения проекта. Итак, вы планируете работу визуально в сетевой диаграмме проекта (PND). Сетевая диаграмма визуализирует работу и позволяет вам найти критический путь. Критический путь - это не тот путь, на котором расположены наиболее важные действия. Это самый длинный путь достижения завершения проекта. Критический путь раскрывает действия, запоздалое завершение которых может привести ваш проект к опозданию и нарушению сроков. Вы можете определить критический путь, отследив длительность действий с первого дня до завершения проекта.

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

Вам вовсе не обязательно быть гением, чтобы уметь пользоваться математикой, гораздо проще и легче положиться на информационную систему (такую, как Microsoft Project) для выполнения вычислений.

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

• Старт-после-финиша. Это наиболее используемый тип связи , который предполагает завершение одного действия для старта следующего действия. К примеру, вы должны создать образ диска до того, как вы будете распространять его на другие 1,200 компьютеров.
• Старт-к-старту. Этот тип связи позволяет двум действиям стартовать одновременно, но при этом завершаться одновременно им не обязательно. К примеру, представьте, что ваша организация решит распространить новое программное обеспечение, которое необходимо будет установить всем пользователям. В плане проекта все пользователи должны пройти четырехчасовое обучение до того, как приложение будет установлено. Вы создаете систему, которая устанавливает программное обеспечение на компьютеры пользователей, в то время как они получают знания по использованию данного ПО. Оба действия стартуют одновременно, но они точно не будут завершены одновременно.
• Финиш-к-финишу. Данное отношение требует от обоих действий единовременного завершения. К примеру, вы управляете проектом по дизайну веб-сайта. Для предложения нового стильного вида ваша организация вышлет миллион открыток текущим и потенциальным клиентам. План проекта требует, чтобы финальные модификации вашего веб-сайта и прибытие открыток в офисы потенциальных клиентов завершились одновременно.
• Старт-к-финишу. Это наиболее редкий и необычный тип связи - особенный. Вы прибегнете к нему в случае, если ваше планирование происходит в момент выполнения задачи. В общем, действие должно начаться для того, чтобы другое было завершено. Представьте себе, что вы производитель пластиковых бутылок. Но у вас нет бесконечного пространства для всего пластика, поэтому вы заказываете его, как только ваши запасы будут минимальны. Поглощение пластика текущими действиями вызывает оформление заказа большего количества пластика для того, чтобы вы могли создать больше бутылок в будущем.

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

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

Прогнозирование длительности проекта

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

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

• Ограничения. Ограничение - это все, что угодно, что может ограничить ваши возможности. Вы наняли консультанта, который может уделить время только 29 декабря. Вы записали вашу команду на курс тренингов, начинающийся с 20 января. Виктор, системный программист, уходит в месячный отпуск в феврале. Все это ограничения - и их великое множество.
• Предположения. Мы все знаем что происходит, когда мы предполагаем что-либо. К примеру, мы предполагаем, что поставщик честно заявил, что новые серверы поступят к 1-му октября. Мы предполагаем, что клиент использует Windows 95 или лучше, а не OS/2. Мы предполагаем, что у нас есть неограниченный доступ к месту работы, а не только 8 часов в день. Вы встретите проблемы, если вы не учтете не будете оглашать данные предположения.
• Доступность ресурсов. Бывало ли так, что вы считали, что для проводки и установки кабеля вам понадобится 4 человека, при этом у вас всего 2 специалиста в проекте? Если вам недоступны необходимые ресурсы, то ваш проект пострадает.
• Закон убывающей отдачи. Данный закон контролирует выгоду по отношению к доступным объемам рабочей силы. Допустим, у нас действие, которое требует 40 часов работы двух специалистов. Если к данному действию добавить еще двоих специалистов, то сможем ли мы завершить работу за 20 часов? Может быть, но если мы добавим 40 специалистов к действию, то будет ли все выполнено в считанные минуты? Наверняка нет. В дополнение, не все действия основываются на усилиях - множество из них обладают фиксированной длительностью. Это хороший пример того, что иногда неважно количество специалистов - действия все равно занимают некоторый объем времени.
• Закон Паркинсона. Закон Паркинсона гласит, что работа продлевается на то количество времени, сколько ей было выделено. Представьте, что вам скажут, что действие занимает 40 часов, хотя  известно, что работу можно выполнить и за 12 часов. Некоторое количество времени добавлено на возможные ошибки, проблемы и другие не связанные с работой действия. Но получилось так, что задача реально занимала 40 часов. Представьте себе работу, которую вы выполняете перед отпуском - вы можете выполнить все в один день. А после отпуска? Вам понадобится целый день только на то, чтобы отправить одно письмо (и это относится ко всем работникам).
• Риски. Риски бизнеса могут иметь как отрицательные, так и положительные стороны, хотя мы вспоминаем только плохое. Большинство рисков чаще всего приводят к задержке проекта, добавлению действий и в некоторых случаях приводят к полному абстрагированию от проекта и его закрытию.

Управление временем и грубые прогнозы

А откуда нам известно, сколько времени занимает каждое действие? В некоторых случаях вы можете положиться на опыт. В других случаях вам стоит верить экспертам, исторической информации и апроксимации. Апроксимация? Да, представьте себе любой ИТ-проект, где вы были руководителем или участвовали. Каждый проект имеет право на первичную ошибку. Практически каждый ИТ-проект уникален. Даже если это проект по установке старого ПО в новой среде, он обладает уникальными аспектами. Не существует двух абсолютно идентичных ИТ-проектов. Всегда существуют некоторые различия

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

Потому прогнозы и называются прогнозами. Но клиенты и руководство не всегда это понимают. Приходилось ли вам давать совершенно случайный прогноз, взятый из воздуха? Такой простой приблизительный прогноз, который ожидают от вас клиенты и руководство, называется грубой оценкой. Мы рекомендуем не давать таких прогнозов - если вам необходимо, то уж лучше укажите, что данная оценка не обоснована и может быть неверна на 75% и даже 125%. В противном случае, вам придется придерживаться прогноза, и если в реальности результаты будут отличаться, то платить придется вам.

Время завершения проекта

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

У нас у всех одинаковое количество времени - мы управляем лишь тем, что мы с ним делаем.

Joseph Phillips