Пользователь
0,0
рейтинг
13 сентября 2013 в 09:59

Разработка → О чем молчит диаграмма Ганта или почему проекты всегда опаздывают

Каждый раз, когда я смотрю на диаграммы Ганта [1], меня мучает один и тот же вопрос. Как? Вот как можно быть уверенным, что ресурс А, выполнит задачу Б за 5 дней? Нет, я понимаю, что есть исторические данные, есть, не побоюсь этого слова, статистика. Но вот как можно на основе всего этого делать уверенные прогнозы? Я не понимаю.
Если для вас термины «взаимозависимость событий» и «статистические отклонения» говорят что-то не только по отдельности, но и в совокупности, то статья вас вряд ли заинтересует. А вот если эти термины, употребленные в одном контексте, не говорят вам в чем проблема диаграмм Ганта, то приглашаю под кат, где на простом примере мы это и обсудим.

Для примера возьмем небольшую компанию, которая занимается разработкой веб-проектов. Работает компания уже давно, поэтому будем считать, что даже статистика по выполненным проектам за достаточно большой период у нас есть. В компании, с целью повышения эффективности, есть разделение труда. Поэтому процесс выполнения заказа состоит из четырех этапов: заключение договора с заказчиком, разработка дизайна, реализация проекта, внедрение.
Для демонстрации будут сделаны следующие предположения:
  1. Каждый этап занимает от 3 до 7 дней. Например, маркетинговый отдел продает нашу услугу заказчику и заключает с ним договор. Этот процесс занимает от трех рабочих дней (клиент с типовой задачей, подписал типовой договор) до семи рабочих дней (представитель заказчика уехал в командировку, появились дополнительные согласования по договору, необходимо обсудить расширенный функционал). Дизайнеры выполняют заказ от трех (заказчик не привередлив, согласен на стандартный шаблон, надо сделать логотип, внести несколько особенностей) до семи рабочих дней (заболел дизайнер, заказчик не подписывает макет).
  2. Вероятность завершить проект в каждый из дней распределена по закону непрерывного равномерного распределения [2]:

    В большинстве случаев, это будет конечно не так, скорее будет наблюдаться, что то вроде нормального распределения [3].
  3. При исходных данных из пунктов 1 и 2, математическое ожидание [4] для срока заключения договора составит 3*0,2+4*0,2+5*0,2+6*0,2+7*0,2 = 5 рабочих дней. Т.е. в среднем каждый этап завершается за 5 дней.

Все эти предположения позволяют нам обсуждать сбалансированную систему. Или, иными словами, систему, в которой на каждый этап, хотя бы в среднем уходит одинаковое количество дней. Если у вас все устроено именно так, то напишите об этом в комментариях, я вам позавидую белой завистью, т.к. еще не видел организаций без «узких звеньев», а вы в такой уже работаете.
Все, с введением заканчиваю, перехожу к теме.
Давайте построим первую диаграмму Ганта. На этой диаграмме, мы, зная о том, что средний срок выполнения этапа 5 рабочих дней, получим сколько времени у нас займет реализация 5 проектов:

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

Как видно, первый этап укладывается в наше предположение. Т.е. замедление одних этапов, компенсируется ускорением других. Но, если у нас присутствует упомянутая «взаимозависимость событий», то со вторым этапом ситуация наблюдается не такая радужная:

Обратили внимание, что вместо тридцатого рабочего дня, второй этап пятого проекта закончился на тридцать третий рабочий день? А тут еще и страшный сон «менеджера» вырисовывается: 13, 14, 18, 19, и 20 рабочий день сотрудникам нечего делать. Ну и последняя картинка:

Именно сейчас у читателя должна появиться мысль: «Да он просто пример такой подстроил!». К сожалению, не подстроил. Проведя моделирование 1000 раз, даже в таких тепличных условиях, с математическим ожиданием на всех этапах в 5 рабочих дней, вероятность завершения проекта в зависимости от дня выглядит так:

Да, наиболее вероятное значение 44-45 дней, но давайте построим еще и график, какова вероятность завершить проекты к заданному дню:

К сороковому дню, вероятность завершить проекты примерно равна 10%. К 44-45 дню вероятность завершить все проекты составляет всего 50%. Т.е., если мы согласны обманывать заказчика по срокам не чаще, чем один раз из пяти, то надо брать 80%, а это уже 48 день. Получается отклонение от первоначального плана в 40 дней на 20%. И это в условиях сбалансированной системы, с предположением, что все проекты одинаковы.
Ситуация чуть улучшается, когда у нас вероятность завершения распределена по нормальному закону. Например, при математическом ожидании равном 5 и дисперсии [5] равной 0,5. В этом случае вероятность завершить этап в один из дней от 3 до 7 будет распределена следующим образом:

С таким распределением вероятность завершения к определенному дню будет иметь вид:

Ситуация улучшилась. В запланированные 40 дней, мы будем успевать уже с вероятностью 30%. А к 43 рабочему дню вероятность составит 80%. К сожалению, в реальных проектах такая дисперсия может быть только при очень высокой повторяемости. Например, на сборочном конвейере. При разработке программного обеспечения дисперсия будет значительно выше, т.к. проекты в большинстве своем уникальные и разброс трудозатрат на них может быть весьма велик.
Ну и завершая, маленькая зарисовка для привлечения внимания к следующей статье. Как вы считаете, что произойдет с «идеальной» диаграммой Ганта, если на первом, третьем и четвертом этапе сдвинуть математическое ожидание на 4, в на втором этапе на 7. Т.е. три этапа будут быстрее в среднем на один день, а один этап длиннее на два?
Диаграмма Ганта и вероятность завершить к дню

Впечатляет? Т.е., теоретически сократив разработку проекта на 1 день, мы замедлили разработку 5 проектов на 6 дней. Но, зато, если мы посмотрим на диаграмму вероятности завершения 5 проектов к заданному дню, то там:

С вероятностью 80% мы завершим к 46 дню, который получен с диаграммы Ганта. Привлек внимание? Ну и хорошо, встретимся в следующей статье.

P.s. За вычитывание и советы по статье большая благодарность Андрею Потапову и CrazyViper. С днем программиста вас и всех читателей Хабра!

1. http://ru.wikipedia.org/wiki/Диаграмма Ганта [к тексту]
2. http://ru.wikipedia.org/wiki/Непрерывное равномерное распределение [к тексту]
3. http://ru.wikipedia.org/wiki/Нормальное распределение [к тексту]
4. http://ru.wikipedia.org/wiki/Математическое ожидание [к тексту]
5. http://ru.wikipedia.org/wiki/Дисперсия случайной величины [к тексту]
Алексей Лосев @Teacher
карма
75,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (46)

  • +3
    Пуассоновское горение сроков: vimeo.com/25500179
    • +2
      Доклад мне напомнил картинку «Как нарисовать сову».
      Сначала всё понятно, а затем из неоткуда появляются выводы, до которых не понятно как дошли.
      • 0
        В смысле, неоткуда? Там приведены аналогии с физическими процессами. Или вам нужно строго математическое доказательство?

        А вообще, это был блиц-доклад, к тому же на Agile-конференции. Мне кажется, из 10 минут автор выжал максимум.
        • 0
          Например, почему следует что «всё уже сделано и мы должны денег заказчику». Если с первой частью соглашусь, то почему должны денег?

          Не понял почему выбрано распределение Пауссона при мощности потока равной 4.
          Не понятно, почему этот график соотносится с определенным графиком логонормального распределения.
          И окончательный график вообще не понятно о чём говорит. Что по оси ординат? и откуда берутся засечки с вероятностью выполнения. Что нам говорит резкий скачёк?
          • +2
            всё уже сделано и мы должны денег заказчику

            Ну типа нужно сделать отрицательную работу, а значит за это надо заплатить отрицательную сумму. А вообще, это шутка была.

            Не понял почему выбрано распределение Пауссона при мощности потока равной 4

            Какая разница? Распределение Пуассона в любом случае асимметричное. Выбрал бы он 10 — получилось бы то же самое, только больше размазанное.

            Не понятно, почему этот график соотносится с определенным графиком логонормального распределения.

            Потому что это близкие по физической природе случайные величины.

            И окончательный график вообще не понятно о чём говорит. Что по оси ординат? и откуда берутся засечки с вероятностью выполнения. Что нам говорит резкий скачёк?

            Вы теорию вероятностей проходили? По оси X — время выполнения задачи, по оси Y — плотность вероятности завершить задачу к этому сроку. Если проинтегрировать плотность вероятности от 0 до t, то получим вероятность. Засечки — это просто опорные точки:
            * наименьшее значение, при котором появляется ненулевая вероятность
            * наиболее вероятное значение
            * мат. ожидание
            Резкий скачок означает появление вероятности завершить задачу к этому сроку. Меньше времени затратить нельзя, потому что это самый оптимистичный вариант.
            • 0
              Эм. Что простите?

              По оси X — время выполнения задачи, по оси Y — плотность вероятности завершить задачу к этому сроку

              Резкий скачок означает появление вероятности завершить задачу к этому сроку.

              При времени второй засечки (20-30%) значение ординаты максимальное на всём графике. Это не может быть вероятностью успешного выполнения задания. т.к. дальше график идет на резкое снижение. Чем больше времени, тем меньше вероятность успешно завершенного проекта?
  • +2
    На эту тему есть отличная книга «Критическая цепь» by Элияху Голдратт. Там описаны и проблемы, и их решения.
    • +1
      Да, мне тоже понравилась. Но она больше «Бизнес-мурзилка», а вот описание всего этого в строгом виде описано у Уильяма Детмера в книге «Теория ограничений Голдратта».
      • 0
        Детмер сильно тяжелей читается чем Голдрат
        • 0
          Ну да, это как Сквозь кротовую нору с Морганом Фрименом и учебник по квантовой физике. Вроде про одно и то же, но язык дюже разный.
          Сам с удовольствием перечитал практически всего Голдатта, но сесть и по всему этому нарисовать минд-мапы, уложить в голове по полочкам заставила именно книга Детмера.
        • –1
          Советую ознакомиться с книгой «Вовремя и в рамках бюджета» — Лоуренс Лич
  • +2
    Прочитал статью 3 раза.
    Понял про диаграмму Ганта.
    Понял про вероятности.

    Не понял какую позицию отстаивает автор. Дециграмма Ганта врёт или она показывает правду, но мы не умеем её читать?
    Если первое, то автор убедил меня в обратном, если второе, то тогда картинка сложилась.
    • 0
      Тоже не совсем понял позицию автора. Некоторые ругают диаграмму Гантта, а по мне это довольно удобный инструмент. Здесь, во-первых, планирование не должно опираться только на математику или статистику, должна быть доля здравого человеческого смысла (который должен быть у менеджера проектов). А во-вторых, расчет верен, только если у нас по одному исполнителю на каждый вид работ и работаем мы по жесткому «водопаду».
      • 0
        Мне вот диаграммы Ганнта нравятся как замечательный инструмент анализа и ретроспективы. Очень наглядно представляет прошлый опыт, на основе которого можно делать оценки на будущее.
    • +5
      Автор нам показывает, что события на диаграмме Ганта имеют вероятностную природу и это в среднем приводит к удлинению сроков разработки по сравнению с планируемыми.
      Одно дело умозрительно себе представить. Другое дело увидеть расчеты, что вероятность завершить проект в срок не просто низка, а реально равна нулю.
      • 0
        Спасибо, видимо не достаточно ясно выразил эту мысль в статье.
      • 0
        Т.е. если все же ответить на мой вопрос, то автор говорит, что нужно правильно её читать.
        • 0
          Диаграмму Ганта, зачастую, рассматривают как жесткую решетку. К 1 числу мы должны залить фундамент, как только зальют фундамент, нам не нужны рабочие занимающиеся опалубкой, а понадобится строительный кран и т.д. Но, как только в рамках одной системы появляются термины «взаимозависимость событий» и «статистические отклонения», то забудьте, диаграмма Ганта построенная исходя из математического ожидания начинает врать. Если в системе есть «узкое звено» или, как их стали часто называть, бутылочное горлышко, то процесс становится еще интереснее.
          • 0
            Спасибо что пояснили свое мнение, а то вашей позиции как то мне не хватало в статье :)
      • 0
        Проблема еще в том, что учитывается равная вероятность для всего, а на самом деле в реале мы имеем намного более точную картину, потому что знаем конкретных людей, конкретные задачи, и рассчитать все можно намного точнее, хотя, конечно, всего учесть нельзя, и тогда вылазит эта вероятность. По сути показано планирование «средней температуры по больнице», с чем в реальном планировании согласиться ну никак нельзя на мой взгляд. Хотя не могу не согласиться, что кое-что интересное в этом есть.
  • 0
    Очень странные рассуждения.
    Вот у Вас заключение договора одного проекта зависит от окончания завершения заключения договора по другому. Но если заказчик пока уехал например — то зачем тратить на него время? Давайте работать пока с другим заказчиком.
    Также, если кто-то простаивает — дать человеку работу по другому проекту. Все аккуратно выходит — сам рисовал картинки в свое время по проектам и ресурсам — всегда можно в «пустое» время перераспределить ресурсы и все будет ок.
    • 0
      Дело в том, что на тему переключения архитекторов, программистов, дизайнеров с задачи на задачу можно написать отдельную статью, к чему это приводит. Иногда бывает экономически целесообразнее команде подождать некоторое время и не начинать другой проект, если сдерживающий фактор за пределами команды и может в ближайшее время разрешиться. А так, да, большинство современных методологий как раз и ориентированы на то, чтобы снизить простой, например, за счет замены функциональных команда на фича-тимы…
  • –1
    хорошая и толковая статья. но вот есть одно но. Вы берете достаточно утрируемый вариант, когда в модель разработки проектов мы включаем только 4 составляющие. на практике, в агенствах, которые работают над серьезными проектами переменных далеко не 4, а часто за 20. и такая простая система проджект-менеджмента уже не работает, потому что будет присутствовать рисковая составляющая по каждой переменной. и в данном случае таким простым алгоритмом не обойтись
    • +1
      Конечно утрированный, представляете статью на Хабре с диаграммами Ганта на 5 проектов по 20 этапов? В реальной жизни все намного сложнее, да и там можно и, самое главное, нужно планировать. Но, ни в коем случае нельзя забывать, что чем дальше мы от текущей точки и чем ближе к горизонту планирования, тем больше будет сказываться математические погрешности, риски и т.д.
  • +1
    Когда станет больше одного ресурса на задачу красивые картинки перестанут быть красивыми и очевидное не успевание станет неочевидным.

    Диаграмма ганта молчит о других вещах:
    1) Продуктивность сотрудников. Если задача А занимает 3 дня, а задача Б (того же типа) 5 дней, обе задачи делал Вася П. Это означает что задача Б больше задачи А или просто Вася занимался своими делами?
    2) Скрытые работы. Чтобы построить диаграмму ганнта надо иметь полную структуру работ. Такая структура появляется в конце проекта. На этапе планирования и в ходе проекта часто появляются новые задачи.

    Поэтому Гантт с задачами категорически не подходит для точного планирования и отслеживания проектов. Особенно сложных проектов.
    • 0
      Он как раз подходит, если описывать полную структуру работ.
      Если Вася занимается своими делами — так впишите эти дела в план работ. Появляются новые задачи — дополняйте проект.
      Да, конечно сразу все учесть нельзя — но это в принципе нельзя учесть ни на какой диаграмме, если Вы это не заложили изначально.
      Если думаете, что задача продлится дольше, или есть фактор риска — так удлинните срок выполнения — и диаграмма покажет Вам то, что надо.
      • +1
        Именно! Бинго! Я ждал этого комментария! Задача менеджера состоит не в том, чтобы построить диаграмму Ганта (или нарисовать план работ в Excel-е), а в том, чтобы при изменении объективной реальности вносить изменения в планы. Есть новая задача? — Поправь план. Заболел сотрудник? — Поправь план.
        Нельзя поправить план? Так не сиди и не жди когда сорвется срок, а поднимайся со стула, договаривайся с заказчиком, с владельцем ресурсов вышестоящим в организации (например, ищи новый сервер для ускорения тестирования). Именно за это и платят деньги, а не за то, чтобы по срыву сроков менеджер доносил неудовлетворение вышестоящего руководства для подчиненных.
        • 0
          Нет, чувак. Тебе платят за то, чтобы не приходилось договариваться больше одного раза. Ну перенесешь ты сроки раз, второй, третий. Потом окажется что проект убыточен и тебя уволят нафиг.

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

          В статье об этом написано, но, увы, на очень примитивном примере.
          • +2
            Мы с вами говорим о разных вещах. Если говорить о коробочном продукте, то выдержать сроки очень важная задача. На этот срок завязана рекламная компания, маркетинг обещает постоянным клиентам и т.д. Если мы говорим о внутренней разработке, то как правило срок — это фикция. Есть задачи, которые возникают вчера и если их решения не будет завтра, то бизнес начнет терять деньги или вообще закроется под давлением законодательных актов. В этом случае, самый замечательный план идет в корзину и делается та задача, которая возникла вчера в связи с письмом из Центрального Банка. Сроки плывут? Плывут. А вот заказчик доволен… Оутсорс — где то посредине между этими двумя крайностями.
            Про пример, согласен. Специально старался выбрать попроще. Идею иллюстрирует? Ну и ладно.
        • 0
          Именно.
          Диаграмма Ганта — не цель, а средство. Средство наглядной визуализации состояния базы планов и фактов.

          Внеся в базу фактическое состояние дел, глядя на диаграмму Ганта проще вносить изменения в планы. А не внося факты и не имея задачи менять планы — смотреть на диаграмму Ганта не сильно осмысленная деятельность.
      • 0
        Скрытые работы на то и скрытые, что о них заранее неизвестно. А когда узнаешь — удлинять задачи уже поздно ибо по срокам пролетишь.
        Тоже самое касается продуктивности сотрудников.

        Если везде закладывать риски, то окажется что проект у вас более чем на 50% это риски.
        • 0
          Ээээ, Вы предлагаете риски не учитывать?

          В них-то как раз и учитывается то, что какие-то задачи невозможно сразу разрисовать, есть отдельное время на эти риски, т.е. если планируется, что таск делается ну пусть 10 дней, то 1-2 дня риска пойдет отдельной графой. Это даже не то, чтоб риск — это именно неучтенные задачи. И их надо закладывать, пусть не в детальном описании, но некоторое время на них.
          А продуктивность сотрудника — это уже величина прогнозируемая, есть риск, что заболеет, например — тут конечно не предугадаешь, но даже это можно учитывать — что осенью вероятность заболеть выше — и добавить время на это.
          Вобщем-то именно в этом и выражается опытность руководителя, который правильно учтет «неучтенку» и который в результате состыкует сроки.
          • 0
            Так всетаки, пихать риски в Гант или нет? Как учитывать вероятность риска? Какой финальный срок\стоимость называть с учетом риска? Какие действия предпринимать чтобы риски не оказывали влияния на проект?
            • 0
              Если известны оценки рисков — надо строить реалистичный, оптимистичный и пессимистичный прогнозы. Все три удобно смотреть на Ганте.
    • 0
      1) Некоторые системы управления проектами, например MS Project позволяют учитывать и визуализировать на диаграмме Ганта время реально потраченное на эту конкретную задачу.
      2) Структура работ вполне может появляться в начале проекта. Если она регулярно появляется только в конце, то лучше работать по agile и гант вообще не особо нужен. Кстати, диаграмма Ганта, построенная программно, легко меняется при необходимости.
      • 0
        Диаграмма Ганта не дает представление о сроках окончания проекта. К сожалению. Иерархическое дерево работ — да, оценки задач — ну да. Но вот когда все это закончится — нет. В этом и есть основная проблема…
        • 0
          Странно, но мне по этой диаграмме вполне всегда удавалось оценить время окончания… причем даже вполне успешно.
        • 0
          Teacher, я вообще-то отвечал на комментарий gandjustas. Но могу прокомментировать и сроки окончания проекта:
          Если вы не любите кошек, значит вы просто не умеете их готовить :)
          Диаграмма Ганта помогает рассчитать (и даже увидеть) критический путь проекта, а стало быть помогает рассчитать сроки окончания проекта. Более того, ее часто именно для этого и используют.
      • 0
        1) Сбор фактических данных сам по себе ни о чем не говорит. Повторяю кейс — есть две задачи, запланированные на 3 и 5 дней. Вася делает обе 5 дней. Вопрос — Вася просто в потолок плевал два дня или его продуктивность оказалась меньше задуманной. В первом случае увеличение срока — не проблема, во втором случае — огромная проблема, так как потеря продуктивности пропорционально удлинит весь проект. Как по диаграмме гантта, даже с фактическими данными, это узнать?
        2) Если структура работ известна на 100%, то была огромная фаза проектирования (как в стройке) или проект очень типовой (как разработка типовых интернет-магазинов). В ИТ встречается нечасто.
        • 0
          1) Если внесены фактические данные, то в MS Project на ганте в первом случае, вы увидите, что за 5 календарных дней разработчик реально внес в отчет по этой задаче к примеру 24 ч. работы. Это будет выглядеть в виде прерывистого прогресс индикатора на полосе ганта. Во втором случае вы увидите, что за 5 календарных дней выполнено работы на 5 человеко/дней. Индикатор потраченного времени будет сплошным.
          2) Для того, чтобы использовать гант нет необходимости знать структуру работ на 100%. Проектирование не обязано быть огромным, но является must have практикой для waterfall проектов.
  • +2
    А еще она молчит о мультипликативности ошибки: www.slideshare.net/Cartmendum/luxoft-seminar-multiplikativnost

    Да и вообще в ней информации лишней много: www.slideshare.net/Cartmendum/luxoft-seminar-lishnyaya-informaciya-2592235

    А еще есть эффект выпрямления сроков (слушать с 14-ого слайда): www.slideshare.net/Cartmendum/swp2012-part-ii

    И если очень хочется использовать матстат для планирования проектов, то предлагаю так: www.slideshare.net/Cartmendum/hitting-moving-target

    Плюс крайне рекомендую ознакомиться с управлением проектом по методу критической цепи: bit.ly/1dbyvsO
    • 0
      Как уже давно просмотревший слайдкасты по этим ссылкам, подтверждаю, и об этом молчит.
      Ну и чтобы два раза не вставать. Максим, не возражаете, если я картинку про скрам с вашего твиттера, для статьи на Хабре использую?
  • 0
    Диаграмма Ганта — это всего лишь средство визуализации. И описанные в статье проблемы заключается не в гантте, а в использовании мат. и стат. методов там, где лучше использовать экспертную оценку предстоящих объемов работ. Если есть история и статистика, то есть и специалисты, которые способны давать адекватные оценки. В оценках, разумеется тоже будут погрешности, но оценки не будут основываться на заведомо неверных предпосылках, что все 5 проектов будут одинаковыми и что все этапы каждого проекта будут одинаковой длительности.
    В общем, когда проекты опаздывают, это происходит не из-за диаграммы Ганта. :) см. факторы успеха IT проектов.
    • 0
      Чтобы проект успел во время. Нужно либо очень сильно перезаложится по срокам (и то не факт, что поможет, т.к. работа занимает все отведенное на нее время и еще чуть-чуть), либо использовать магию. Вы в своей статье как раз про эту магию и говорите, что вы постоянно меняете дерево работ (гибкие методологии и выкинуть половину того, что планировалось первоначально). Ну и о каких оценках после этого можно говорить? А если еще и риски подключить ко всему этому… Т.е. к концу проекта у нас получается от первоначального треугольника максимум это уложились в сроки и время. Скоуп в IT проектах выдерживается очень редко. Ну а если по правде, то и время с деньгами не обязательно должны уложится в первоначальные планы из устава. Треугольник не выдержали, но заказчик остался доволен — успешный проект. Треугольник выдержали, но заказчик недоволен — хм… Я бы успешным такой проект не назвал.

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