Комментарии 46
Пуассоновское горение сроков: vimeo.com/25500179
Доклад мне напомнил картинку «Как нарисовать сову».
Сначала всё понятно, а затем из неоткуда появляются выводы, до которых не понятно как дошли.
Сначала всё понятно, а затем из неоткуда появляются выводы, до которых не понятно как дошли.
В смысле, неоткуда? Там приведены аналогии с физическими процессами. Или вам нужно строго математическое доказательство?
А вообще, это был блиц-доклад, к тому же на Agile-конференции. Мне кажется, из 10 минут автор выжал максимум.
А вообще, это был блиц-доклад, к тому же на Agile-конференции. Мне кажется, из 10 минут автор выжал максимум.
Например, почему следует что «всё уже сделано и мы должны денег заказчику». Если с первой частью соглашусь, то почему должны денег?
Не понял почему выбрано распределение Пауссона при мощности потока равной 4.
Не понятно, почему этот график соотносится с определенным графиком логонормального распределения.
И окончательный график вообще не понятно о чём говорит. Что по оси ординат? и откуда берутся засечки с вероятностью выполнения. Что нам говорит резкий скачёк?
Не понял почему выбрано распределение Пауссона при мощности потока равной 4.
Не понятно, почему этот график соотносится с определенным графиком логонормального распределения.
И окончательный график вообще не понятно о чём говорит. Что по оси ординат? и откуда берутся засечки с вероятностью выполнения. Что нам говорит резкий скачёк?
всё уже сделано и мы должны денег заказчику
Ну типа нужно сделать отрицательную работу, а значит за это надо заплатить отрицательную сумму. А вообще, это шутка была.
Не понял почему выбрано распределение Пауссона при мощности потока равной 4
Какая разница? Распределение Пуассона в любом случае асимметричное. Выбрал бы он 10 — получилось бы то же самое, только больше размазанное.
Не понятно, почему этот график соотносится с определенным графиком логонормального распределения.
Потому что это близкие по физической природе случайные величины.
И окончательный график вообще не понятно о чём говорит. Что по оси ординат? и откуда берутся засечки с вероятностью выполнения. Что нам говорит резкий скачёк?
Вы теорию вероятностей проходили? По оси X — время выполнения задачи, по оси Y — плотность вероятности завершить задачу к этому сроку. Если проинтегрировать плотность вероятности от 0 до t, то получим вероятность. Засечки — это просто опорные точки:
* наименьшее значение, при котором появляется ненулевая вероятность
* наиболее вероятное значение
* мат. ожидание
Резкий скачок означает появление вероятности завершить задачу к этому сроку. Меньше времени затратить нельзя, потому что это самый оптимистичный вариант.
Эм. Что простите?
При времени второй засечки (20-30%) значение ординаты максимальное на всём графике. Это не может быть вероятностью успешного выполнения задания. т.к. дальше график идет на резкое снижение. Чем больше времени, тем меньше вероятность успешно завершенного проекта?
По оси X — время выполнения задачи, по оси Y — плотность вероятности завершить задачу к этому сроку
Резкий скачок означает появление вероятности завершить задачу к этому сроку.
При времени второй засечки (20-30%) значение ординаты максимальное на всём графике. Это не может быть вероятностью успешного выполнения задания. т.к. дальше график идет на резкое снижение. Чем больше времени, тем меньше вероятность успешно завершенного проекта?
На эту тему есть отличная книга «Критическая цепь» by Элияху Голдратт. Там описаны и проблемы, и их решения.
Да, мне тоже понравилась. Но она больше «Бизнес-мурзилка», а вот описание всего этого в строгом виде описано у Уильяма Детмера в книге «Теория ограничений Голдратта».
Детмер сильно тяжелей читается чем Голдрат
Ну да, это как Сквозь кротовую нору с Морганом Фрименом и учебник по квантовой физике. Вроде про одно и то же, но язык дюже разный.
Сам с удовольствием перечитал практически всего Голдатта, но сесть и по всему этому нарисовать минд-мапы, уложить в голове по полочкам заставила именно книга Детмера.
Сам с удовольствием перечитал практически всего Голдатта, но сесть и по всему этому нарисовать минд-мапы, уложить в голове по полочкам заставила именно книга Детмера.
Советую ознакомиться с книгой «Вовремя и в рамках бюджета» — Лоуренс Лич
Прочитал статью 3 раза.
Понял про диаграмму Ганта.
Понял про вероятности.
Не понял какую позицию отстаивает автор. Дециграмма Ганта врёт или она показывает правду, но мы не умеем её читать?
Если первое, то автор убедил меня в обратном, если второе, то тогда картинка сложилась.
Понял про диаграмму Ганта.
Понял про вероятности.
Не понял какую позицию отстаивает автор. Дециграмма Ганта врёт или она показывает правду, но мы не умеем её читать?
Если первое, то автор убедил меня в обратном, если второе, то тогда картинка сложилась.
Тоже не совсем понял позицию автора. Некоторые ругают диаграмму Гантта, а по мне это довольно удобный инструмент. Здесь, во-первых, планирование не должно опираться только на математику или статистику, должна быть доля здравого человеческого смысла (который должен быть у менеджера проектов). А во-вторых, расчет верен, только если у нас по одному исполнителю на каждый вид работ и работаем мы по жесткому «водопаду».
Автор нам показывает, что события на диаграмме Ганта имеют вероятностную природу и это в среднем приводит к удлинению сроков разработки по сравнению с планируемыми.
Одно дело умозрительно себе представить. Другое дело увидеть расчеты, что вероятность завершить проект в срок не просто низка, а реально равна нулю.
Одно дело умозрительно себе представить. Другое дело увидеть расчеты, что вероятность завершить проект в срок не просто низка, а реально равна нулю.
Спасибо, видимо не достаточно ясно выразил эту мысль в статье.
Т.е. если все же ответить на мой вопрос, то автор говорит, что нужно правильно её читать.
Диаграмму Ганта, зачастую, рассматривают как жесткую решетку. К 1 числу мы должны залить фундамент, как только зальют фундамент, нам не нужны рабочие занимающиеся опалубкой, а понадобится строительный кран и т.д. Но, как только в рамках одной системы появляются термины «взаимозависимость событий» и «статистические отклонения», то забудьте, диаграмма Ганта построенная исходя из математического ожидания начинает врать. Если в системе есть «узкое звено» или, как их стали часто называть, бутылочное горлышко, то процесс становится еще интереснее.
Проблема еще в том, что учитывается равная вероятность для всего, а на самом деле в реале мы имеем намного более точную картину, потому что знаем конкретных людей, конкретные задачи, и рассчитать все можно намного точнее, хотя, конечно, всего учесть нельзя, и тогда вылазит эта вероятность. По сути показано планирование «средней температуры по больнице», с чем в реальном планировании согласиться ну никак нельзя на мой взгляд. Хотя не могу не согласиться, что кое-что интересное в этом есть.
Очень странные рассуждения.
Вот у Вас заключение договора одного проекта зависит от окончания завершения заключения договора по другому. Но если заказчик пока уехал например — то зачем тратить на него время? Давайте работать пока с другим заказчиком.
Также, если кто-то простаивает — дать человеку работу по другому проекту. Все аккуратно выходит — сам рисовал картинки в свое время по проектам и ресурсам — всегда можно в «пустое» время перераспределить ресурсы и все будет ок.
Вот у Вас заключение договора одного проекта зависит от окончания завершения заключения договора по другому. Но если заказчик пока уехал например — то зачем тратить на него время? Давайте работать пока с другим заказчиком.
Также, если кто-то простаивает — дать человеку работу по другому проекту. Все аккуратно выходит — сам рисовал картинки в свое время по проектам и ресурсам — всегда можно в «пустое» время перераспределить ресурсы и все будет ок.
Дело в том, что на тему переключения архитекторов, программистов, дизайнеров с задачи на задачу можно написать отдельную статью, к чему это приводит. Иногда бывает экономически целесообразнее команде подождать некоторое время и не начинать другой проект, если сдерживающий фактор за пределами команды и может в ближайшее время разрешиться. А так, да, большинство современных методологий как раз и ориентированы на то, чтобы снизить простой, например, за счет замены функциональных команда на фича-тимы…
хорошая и толковая статья. но вот есть одно но. Вы берете достаточно утрируемый вариант, когда в модель разработки проектов мы включаем только 4 составляющие. на практике, в агенствах, которые работают над серьезными проектами переменных далеко не 4, а часто за 20. и такая простая система проджект-менеджмента уже не работает, потому что будет присутствовать рисковая составляющая по каждой переменной. и в данном случае таким простым алгоритмом не обойтись
Конечно утрированный, представляете статью на Хабре с диаграммами Ганта на 5 проектов по 20 этапов? В реальной жизни все намного сложнее, да и там можно и, самое главное, нужно планировать. Но, ни в коем случае нельзя забывать, что чем дальше мы от текущей точки и чем ближе к горизонту планирования, тем больше будет сказываться математические погрешности, риски и т.д.
Когда станет больше одного ресурса на задачу красивые картинки перестанут быть красивыми и очевидное не успевание станет неочевидным.
Диаграмма ганта молчит о других вещах:
1) Продуктивность сотрудников. Если задача А занимает 3 дня, а задача Б (того же типа) 5 дней, обе задачи делал Вася П. Это означает что задача Б больше задачи А или просто Вася занимался своими делами?
2) Скрытые работы. Чтобы построить диаграмму ганнта надо иметь полную структуру работ. Такая структура появляется в конце проекта. На этапе планирования и в ходе проекта часто появляются новые задачи.
Поэтому Гантт с задачами категорически не подходит для точного планирования и отслеживания проектов. Особенно сложных проектов.
Диаграмма ганта молчит о других вещах:
1) Продуктивность сотрудников. Если задача А занимает 3 дня, а задача Б (того же типа) 5 дней, обе задачи делал Вася П. Это означает что задача Б больше задачи А или просто Вася занимался своими делами?
2) Скрытые работы. Чтобы построить диаграмму ганнта надо иметь полную структуру работ. Такая структура появляется в конце проекта. На этапе планирования и в ходе проекта часто появляются новые задачи.
Поэтому Гантт с задачами категорически не подходит для точного планирования и отслеживания проектов. Особенно сложных проектов.
Он как раз подходит, если описывать полную структуру работ.
Если Вася занимается своими делами — так впишите эти дела в план работ. Появляются новые задачи — дополняйте проект.
Да, конечно сразу все учесть нельзя — но это в принципе нельзя учесть ни на какой диаграмме, если Вы это не заложили изначально.
Если думаете, что задача продлится дольше, или есть фактор риска — так удлинните срок выполнения — и диаграмма покажет Вам то, что надо.
Если Вася занимается своими делами — так впишите эти дела в план работ. Появляются новые задачи — дополняйте проект.
Да, конечно сразу все учесть нельзя — но это в принципе нельзя учесть ни на какой диаграмме, если Вы это не заложили изначально.
Если думаете, что задача продлится дольше, или есть фактор риска — так удлинните срок выполнения — и диаграмма покажет Вам то, что надо.
Именно! Бинго! Я ждал этого комментария! Задача менеджера состоит не в том, чтобы построить диаграмму Ганта (или нарисовать план работ в Excel-е), а в том, чтобы при изменении объективной реальности вносить изменения в планы. Есть новая задача? — Поправь план. Заболел сотрудник? — Поправь план.
Нельзя поправить план? Так не сиди и не жди когда сорвется срок, а поднимайся со стула, договаривайся с заказчиком, с владельцем ресурсов вышестоящим в организации (например, ищи новый сервер для ускорения тестирования). Именно за это и платят деньги, а не за то, чтобы по срыву сроков менеджер доносил неудовлетворение вышестоящего руководства для подчиненных.
Нельзя поправить план? Так не сиди и не жди когда сорвется срок, а поднимайся со стула, договаривайся с заказчиком, с владельцем ресурсов вышестоящим в организации (например, ищи новый сервер для ускорения тестирования). Именно за это и платят деньги, а не за то, чтобы по срыву сроков менеджер доносил неудовлетворение вышестоящего руководства для подчиненных.
Нет, чувак. Тебе платят за то, чтобы не приходилось договариваться больше одного раза. Ну перенесешь ты сроки раз, второй, третий. Потом окажется что проект убыточен и тебя уволят нафиг.
Суть в том, чтобы составить такой план, который за заранее определенно время позволит достингуть успеха с высокой долей вероятности.
В статье об этом написано, но, увы, на очень примитивном примере.
Суть в том, чтобы составить такой план, который за заранее определенно время позволит достингуть успеха с высокой долей вероятности.
В статье об этом написано, но, увы, на очень примитивном примере.
Мы с вами говорим о разных вещах. Если говорить о коробочном продукте, то выдержать сроки очень важная задача. На этот срок завязана рекламная компания, маркетинг обещает постоянным клиентам и т.д. Если мы говорим о внутренней разработке, то как правило срок — это фикция. Есть задачи, которые возникают вчера и если их решения не будет завтра, то бизнес начнет терять деньги или вообще закроется под давлением законодательных актов. В этом случае, самый замечательный план идет в корзину и делается та задача, которая возникла вчера в связи с письмом из Центрального Банка. Сроки плывут? Плывут. А вот заказчик доволен… Оутсорс — где то посредине между этими двумя крайностями.
Про пример, согласен. Специально старался выбрать попроще. Идею иллюстрирует? Ну и ладно.
Про пример, согласен. Специально старался выбрать попроще. Идею иллюстрирует? Ну и ладно.
Именно.
Диаграмма Ганта — не цель, а средство. Средство наглядной визуализации состояния базы планов и фактов.
Внеся в базу фактическое состояние дел, глядя на диаграмму Ганта проще вносить изменения в планы. А не внося факты и не имея задачи менять планы — смотреть на диаграмму Ганта не сильно осмысленная деятельность.
Диаграмма Ганта — не цель, а средство. Средство наглядной визуализации состояния базы планов и фактов.
Внеся в базу фактическое состояние дел, глядя на диаграмму Ганта проще вносить изменения в планы. А не внося факты и не имея задачи менять планы — смотреть на диаграмму Ганта не сильно осмысленная деятельность.
Скрытые работы на то и скрытые, что о них заранее неизвестно. А когда узнаешь — удлинять задачи уже поздно ибо по срокам пролетишь.
Тоже самое касается продуктивности сотрудников.
Если везде закладывать риски, то окажется что проект у вас более чем на 50% это риски.
Тоже самое касается продуктивности сотрудников.
Если везде закладывать риски, то окажется что проект у вас более чем на 50% это риски.
Ээээ, Вы предлагаете риски не учитывать?
В них-то как раз и учитывается то, что какие-то задачи невозможно сразу разрисовать, есть отдельное время на эти риски, т.е. если планируется, что таск делается ну пусть 10 дней, то 1-2 дня риска пойдет отдельной графой. Это даже не то, чтоб риск — это именно неучтенные задачи. И их надо закладывать, пусть не в детальном описании, но некоторое время на них.
А продуктивность сотрудника — это уже величина прогнозируемая, есть риск, что заболеет, например — тут конечно не предугадаешь, но даже это можно учитывать — что осенью вероятность заболеть выше — и добавить время на это.
Вобщем-то именно в этом и выражается опытность руководителя, который правильно учтет «неучтенку» и который в результате состыкует сроки.
В них-то как раз и учитывается то, что какие-то задачи невозможно сразу разрисовать, есть отдельное время на эти риски, т.е. если планируется, что таск делается ну пусть 10 дней, то 1-2 дня риска пойдет отдельной графой. Это даже не то, чтоб риск — это именно неучтенные задачи. И их надо закладывать, пусть не в детальном описании, но некоторое время на них.
А продуктивность сотрудника — это уже величина прогнозируемая, есть риск, что заболеет, например — тут конечно не предугадаешь, но даже это можно учитывать — что осенью вероятность заболеть выше — и добавить время на это.
Вобщем-то именно в этом и выражается опытность руководителя, который правильно учтет «неучтенку» и который в результате состыкует сроки.
1) Некоторые системы управления проектами, например MS Project позволяют учитывать и визуализировать на диаграмме Ганта время реально потраченное на эту конкретную задачу.
2) Структура работ вполне может появляться в начале проекта. Если она регулярно появляется только в конце, то лучше работать по agile и гант вообще не особо нужен. Кстати, диаграмма Ганта, построенная программно, легко меняется при необходимости.
2) Структура работ вполне может появляться в начале проекта. Если она регулярно появляется только в конце, то лучше работать по agile и гант вообще не особо нужен. Кстати, диаграмма Ганта, построенная программно, легко меняется при необходимости.
Диаграмма Ганта не дает представление о сроках окончания проекта. К сожалению. Иерархическое дерево работ — да, оценки задач — ну да. Но вот когда все это закончится — нет. В этом и есть основная проблема…
Странно, но мне по этой диаграмме вполне всегда удавалось оценить время окончания… причем даже вполне успешно.
Teacher, я вообще-то отвечал на комментарий gandjustas. Но могу прокомментировать и сроки окончания проекта:
Если вы не любите кошек, значит вы просто не умеете их готовить :)
Диаграмма Ганта помогает рассчитать (и даже увидеть) критический путь проекта, а стало быть помогает рассчитать сроки окончания проекта. Более того, ее часто именно для этого и используют.
Если вы не любите кошек, значит вы просто не умеете их готовить :)
Диаграмма Ганта помогает рассчитать (и даже увидеть) критический путь проекта, а стало быть помогает рассчитать сроки окончания проекта. Более того, ее часто именно для этого и используют.
1) Сбор фактических данных сам по себе ни о чем не говорит. Повторяю кейс — есть две задачи, запланированные на 3 и 5 дней. Вася делает обе 5 дней. Вопрос — Вася просто в потолок плевал два дня или его продуктивность оказалась меньше задуманной. В первом случае увеличение срока — не проблема, во втором случае — огромная проблема, так как потеря продуктивности пропорционально удлинит весь проект. Как по диаграмме гантта, даже с фактическими данными, это узнать?
2) Если структура работ известна на 100%, то была огромная фаза проектирования (как в стройке) или проект очень типовой (как разработка типовых интернет-магазинов). В ИТ встречается нечасто.
2) Если структура работ известна на 100%, то была огромная фаза проектирования (как в стройке) или проект очень типовой (как разработка типовых интернет-магазинов). В ИТ встречается нечасто.
1) Если внесены фактические данные, то в MS Project на ганте в первом случае, вы увидите, что за 5 календарных дней разработчик реально внес в отчет по этой задаче к примеру 24 ч. работы. Это будет выглядеть в виде прерывистого прогресс индикатора на полосе ганта. Во втором случае вы увидите, что за 5 календарных дней выполнено работы на 5 человеко/дней. Индикатор потраченного времени будет сплошным.
2) Для того, чтобы использовать гант нет необходимости знать структуру работ на 100%. Проектирование не обязано быть огромным, но является must have практикой для waterfall проектов.
2) Для того, чтобы использовать гант нет необходимости знать структуру работ на 100%. Проектирование не обязано быть огромным, но является must have практикой для waterfall проектов.
А еще она молчит о мультипликативности ошибки: 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
Да и вообще в ней информации лишней много: 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
Диаграмма Ганта — это всего лишь средство визуализации. И описанные в статье проблемы заключается не в гантте, а в использовании мат. и стат. методов там, где лучше использовать экспертную оценку предстоящих объемов работ. Если есть история и статистика, то есть и специалисты, которые способны давать адекватные оценки. В оценках, разумеется тоже будут погрешности, но оценки не будут основываться на заведомо неверных предпосылках, что все 5 проектов будут одинаковыми и что все этапы каждого проекта будут одинаковой длительности.
В общем, когда проекты опаздывают, это происходит не из-за диаграммы Ганта. :) см. факторы успеха IT проектов.
В общем, когда проекты опаздывают, это происходит не из-за диаграммы Ганта. :) см. факторы успеха IT проектов.
Чтобы проект успел во время. Нужно либо очень сильно перезаложится по срокам (и то не факт, что поможет, т.к. работа занимает все отведенное на нее время и еще чуть-чуть), либо использовать магию. Вы в своей статье как раз про эту магию и говорите, что вы постоянно меняете дерево работ (гибкие методологии и выкинуть половину того, что планировалось первоначально). Ну и о каких оценках после этого можно говорить? А если еще и риски подключить ко всему этому… Т.е. к концу проекта у нас получается от первоначального треугольника максимум это уложились в сроки и время. Скоуп в IT проектах выдерживается очень редко. Ну а если по правде, то и время с деньгами не обязательно должны уложится в первоначальные планы из устава. Треугольник не выдержали, но заказчик остался доволен — успешный проект. Треугольник выдержали, но заказчик недоволен — хм… Я бы успешным такой проект не назвал.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О чем молчит диаграмма Ганта или почему проекты всегда опаздывают