Заметки о диаграмме Ганта

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

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

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

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

У нас был клиент, который требовал от менеджера проекта постоянно предоставлять диаграмму Ганта по всему проекту. Уже тогда по плану проект должен был длиться не менее 3х месяцев. При этом диаграмма была подробна, с декомпозицией задач объемом до 3-4 часов, и это на команду из нескольких человек! Когда у клиента по каким-то причинам смещался дедлайн он просил подкорректировать диаграмму, переставить работы. Передвижение дедлайна на пару дней занимало у PMа почти пол дня кропотливой работы в MS Project. Клиенту казалось, что именно подробная диаграмма хода проекта позволит контролировать ход работ. Но каждый разумный человек, который смотрел в такую диаграмму восклицал: “Они сумасшедшие, если хотят погрязнуть в таком количестве контроля!”. Да, этот разумный человек был я. 🙂

Недавно при расчете очередного проекта меня также попросили составить подробный план. Мы расписали все известные фичи проекта, оценили их объем по каждому из специалистов, я расставил майл-стоуны и определил какие фичи будут готовы на каждом этапе. А вот диаграмму Ганта составлять отказался.

И вот почему.

Для разработки интернет-проектов я считаю диаграмму Ганта очень полезным инструментом только на верхнем уровне планирования. Использование же диаграммы Ганта в качестве инструмента микропланиварония, а тем более контроля — пустая трата времени. Мало того, что на это тратиться огромное количество менеджерских усилий… менеджеры при этом выступают для разработчиков полными идиотами. Любой разработчик замечает по этому поводу: “Этих кретинов не волнует результат, им важны только отчеты, только процесс!”

Когда мы планируем проект, то используем планирование в MS Project только для верхнего уровня плана. Мы расставляем майл-стоуны и определяем, что к ним должно быть готово, в какой последовательности может идти разработка, исходя из тех данных, что у нас есть на текущий момент. Более детальное планирование идет уже на уровне итераций (2х или 4х недельных). Когда мы используем 2х недельные итерации, то фичи на планировании разбиваются на задачи по 4-8 часов. Расставить их в диаграмме Ганта, выстроить последовательность, связать, настроить ресурсы… задача просто нелепая и бессмысленная.

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

Контрольный вопрос: в каком случае склад будет освобожден быстрее?
Второй контрольный вопрос: в каком случае затраты на контроль будут ниже?
Вопрос третий: Что в сущности дает нам план с диаграммой Ганта при решении нелинейной задачи кроме спокойствия?

А?

Tags: ,

Post Author

This post was written by who has written 50 posts on Agile.by.

Менеджер проектов, тренер по гибким методологиям. Участвовал в крупных интернет-проектах в качестве менеджера проектов, бизнес-аналитика, проектировщика интерфейсов и координатора. Формировал команды разработки, занимался внедрением agile-методик.

  • http://golub.livejournal.com Kirill Golub

    Я, однако, всегда считал, что диаграмма Ганта и предназначена для верхнего уровня планирования. Как пример из строительства – единственный подъемный кран нужен и для прокладки, допустим, теплотрассы (трубы в раскоп опускать), так и при строительстве будочки для сторожа, но при этом никто на диаграмме не отмечает этапы “укладка первой трубы, укладка второй трубы, …, укладка энной трубы” 🙂

  • http://thetorch.ru/ Денис Петелин

    Салям!
    Кстати, у прожекта есть фича, которая офигенно помогает решать как раз вот эту часть:
    Более детальное планирование идет уже на уровне итераций (2х или 4х недельных). Когда мы используем 2х недельные итерации, то фичи на планировании разбиваются на задачи по 4-8 часов.
    Называется Resource Leveling. Работает примерно так:
    1. Добавляешь колонку Priority.
    2. Включаешь Resource Leveling, Hour by Hour.
    3. Переключаешься в представление Work.
    4. Вводишь задачи с нужным уровнем детализации.
    5. Автоматически увеличивается Work на каждого человека, заполняя бэклог и формируя план итерации 🙂
    6. Чтобы двигать в спринтиз спринта используешь колонку Priority.

    На словах конечно описание выглядит по дурацки, но если один раз все настроить (минут 5-10) – получается как раз то что надо.

  • http://yuri.shilyaev.com Yuri Shilyaev

    Против MS Project’а, как инструмента ничего не имею против, кстати. Мощная хорошая программа. Допускаю, что я знаю далеко не все ее возможности. Она о-очень большая.
    Однако, вот для наших потребностей она успеха не нашла. Оказалось проще использовать тул более легкий и простой.

  • Andrey Kalganov

    Если в компании используется система учета времени, то можно написать макрос в MS Project, который обновит actual hours для задач. Далее делаешь Reschedule uncomplete tasks. Потом leveling, о котором писал Денис. В итоге отслеживание проекта перестает быть проблемой. Плюс, по каждой задаче ты видешь то, во что ее оценили, и то, сколько это на самом деле заняло времени. Это весьма полезная информация, для daily митингов. В частности, если по задаче пошел перебор по времени, то скорее всего здесь проблема и нужна помощь команды. Еще один плюс внесения актуальных данных в Priject, эти данные можно использовать для последующих оценок.

  • Konstantin Razumovsky

    >В итоге отслеживание проекта перестает быть проблемой.

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

    Когда мы вдобавок к этому начинаем синхронизацию, все становится только запутаннее. Эта бесконечная полуручная и чаще всего никому не нужная синхронизация становится сама по себе головной болью. А ведь некоторые (как я и ты) еще и эксельный бэклог пытаются юзать, а это уже, получается, третье представление плана. И все это добро надо синхронизировать…

    Что касается самой статьи, то я лично с ней согласен (как и со всеми другими многочисленными статьями, которые утверждают, что MSP слишком сложный и негибкий). Но сам бы я такую никогда не написал, т.к. всегда найдется знаток MS Project, который скажет, что все проблемы от того, что я плохо знаю MS Project и возразить по сути мне ему будет нечего 🙂

  • Andrey Kalganov

    Я не говорил, что надо MSP синхронизировать с корпоративной системой управления проектами. Я хотел сказать, что если автоматизировать внесение данных (актуальных часов потраченных на конкретную задачу) из системы учета времени в MSP, то дальше механизм отлажен и бороться ни с чем не надо. Плюс, это дает дополнительную информацию для анализа (которая отсутствуюет в классическом TaskBoard и BurnDown chart). А именно, по какой конкретно задаче тратится больше времени, чем надо. Не всегда люди признают ошибки в эстимейтах, иногда бояться признаться, что что-то не получается… и начинают бороться с проблемой сами. Актуальная информация о потраченных часах позволяет решить эту проблему. Поэтому я доработал BurnDown chart следующим образом: график, как обычно… здесь ничего не меняет, но к графику идет таблица с фичами (и тасками по ним), одна колонка – начальный эстимейт, одна колонка – реально потраченное время, одна колонка – сколько осталось времени на задачу. Если сумма 2 и 3 колонок превышает значение из 1-ой – есть проблема с этой задачей, надо ее решать.