Pull to refresh

Comments 26

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

Ресурсы. На название ресурса я лично не обижаюсь ) А все перечисленные трудности с соблюдением графика можно избежать- обобщайте задачи так, чтобы каждая задача на графике у вас не была короче, например, 4х часов.

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

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

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

Все это естественно ИМХО. Мне тоже многое не нравится в имеющихся средствах планированияи мне действительно интересно к какой альтернативе пришли Вы.

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

Скоуп проекта.
Диаграмма Гантта и WBS (work breakdown structure) несколько разные понятия. Да WBS нужен для понимания декомпозиции работ и предоставления этого заказчику, чтобы он понимал на что расходуются средства. Моих заказчиков редко волнует что некоторая задача стоит на критическом пути, поэтому изменение условий (требований, сроков, ресурсов и т.п.) влечет изменение самого плана. Его больше интересует как добиться результата исходя из его требований, так что диаграмму вам перерисовывать по-любому.

Зависимости.
Вы правы, есть инструменты, выполняющие автоматический resource leveling, так что зависимости между задачами на одном ресурсе можно и не ставить. Но это только маленькая часть проблемы: есть логические и технологические зависимости. Копали: Primavera, MS Project, ужас как вспомню…

Итеративность.
Все верно, можно и на календаре колбаски нарисовать и громко заявить: «мы сделаем это!», вот только внутренний страх не точит непоколебимую уверенность? :)
Вобщем, думаю, вы тоже в какой-то степени правы. И кажется вы уже нашли идеальное средство планирования :)
Наверно идеальным средством планирования является опыт :) но где же его взять, не загубив полсотни проектов…
Статья верная. Но по-моему закончилась на самом интересном — какие же практики лучше всего заменяют традиционное планирование в разработке ПО? Scrum? Есть ли еще какие альтернативы?
Я хотел заинтриговать публику, посмотреть насколько интересная тема. У меня есть ответ на Ваш вопрос, но интересно было бы сначала услышать мнение других участников.

Альтернатив море, но каждая со своими особенностями. Вот если Вы считаете, что статья верная, то как выкручиваетесь?
Напишите про альтернативу. Будет интересно, т.к. сам сталкивался и до сих пор ничего более разумного чем подход Мила не нашел. :)
Вот если Вы считаете, что статья верная, то как выкручиваетесь?

Честно говоря, не знаю. Scrum подходит для написания ПО, но все другие действия (вокруг) не вписываются (или не должны вписываться): проверка качества, написание документации, закупка доменов, настройка серверов, раскрутка, продажа, обучение пользователей и т.п. Но если тот же Scrum дает планируемые результаты в предскауемые сроки, то значит их можно и на Гантт-чарте расположить. Я уже сомневаюсь в своем выводе выше ;)
В разработке ПО основным мерилом являются трудозатраты, измеряемые в часах. Раскрутка, продажа и вообще маркетинг измеряются другими показателями, например, количеством холодных звонков, привлеченных клиентов, величиной какого-нить индекса цитируемости и т.п.

Скорее всего некорректно сравнивать методики планирования разарботки и маркетинга.

Конечно, диаграмма Гантта позволяет описать то, для чего предназначена и Scrum тут не панацея, вопрос поднят относительно адекватности применения этой диаграммы для планирования разработки ПО.
ИМХО сравнивать вполне корректно.
Я считаю, что маркетинг в проекте нужно мерять не «количеством холодных звонков», а какими-то поставка проекта. Т.е. маркетинг в проект может поставить медиа-план. Ресурсы на разработку и исполнение медиа-плана вполне можно померять в человеках, деньгах и часах. Потому эти работы можно положить на диаграмму Гантта.

А «холодные звонки» будет мерять клиент и отзываться о Вас в хорошом или плохом смысле, в зависимости от количества «холодных звонков».

P.S. тема очень интересна и интересно к чему же Вы пришли. Ждем продолжения :)
UFO just landed and posted this here
а зачем Вам диаграммы?
UFO just landed and posted this here
А, вы никогда не использовали диаграммы Гантта? То есть не представляете себе их визуально что-ли?
UFO just landed and posted this here
UFO just landed and posted this here
лично для меня диаграмма Гантта сегодня актуальна как никогда:
today преподаватель дал на практике задачу «Утро на даче». И решается она как раз таки диаграммой Гантта… Вечером, придя домой немного погуглил и нашел это.
Лично у меня, на паре, все решение укладывалось за 108 минут… а преподаватель требовал 97-102… немного не укладывался в норматив… (:
по ссылке найдете условия задачи — может кому то будет интересно себя тоже попробовать в составлении сией диаграммы… (:

P.S.: прошу прощения за то, что мой комментарий не имеет ничего общего с разработкой ПО, но все же, надеюсь, пример задачи по диаграмме Гантта спасет меня от «заминусовки»… (:
По моему опыту эти диаграмы, Project-ы и пр. делается только для того чтобы удволетворить заказчика или руководство, и только теми кто не хочет объяснить им, что все это мало имеет отношения к реалям современной разработки.
Пробовал приспособить диаграмму Ганна к проекту. Не получилось. Диаграмма предполагает, что все этапы уже известны. Увы это не так.

Сделал этап по плану — вроде все ок. Теперь начальник говорит — надо сделать вот еще что. Или «а мы это делать не будем», или «сделаем по другому», то есть налицо итерация.

Неплохо работает список глобальных целей и туду лист по ним.
Диаграммы Ганта, по-моему, предназначены для удовлетворения низменных желаний неквалифицированного менеджера. Многие считают MS Project чуть ли не панацеей, пока не воспользуются им в программерском проекте… После чего уже не считают. На моей практике подобные диаграммы работают только на короткие сроки, а на длинных же получается слишком высокая погрешность. Но для примерной оценки времени они вполне годятся, не нужно только их ставить во главу угла.

П.С.
Аналогии со строительством тоже бесят.
В разработке основным… ресурсом является человек.… НО он не является в чистом виде ресурсом, потому что… человек крайне нелинейный элемент всей этой цепочки, а значит, вы не можете 100% рассчитывать на его заинтересованность, лояльность и доступность.


Автор оч. хорошо написал! Подправил карму )

Работал в нескольких проектах, единственный способ как мы выдерживали сроки — это увеличение продолжительности рабочего дня. (Товарищи менеджеры, это можно использовать крайне редко. Есть большой риск замыливания мозгов и уменьшения производительности труда).

Сколько раз планировали, всегда появляется какая-то вроде бы мелочь, НО сдвигающая сроки на пару дней. Хорошо если такая мелочь одна, но зачастую так не бывает.

Для меня пилюля следующая:
Опыт, полное понимание проекта, доверительные отношения и чувство возможностей каждого разработчика!
Я сейчас потихоньку курю ПЕРТ-диаграммы. На мой взгляд они являются логичным эволюционным развитием диаграмм Ганта. При этом они проигрывают в простоте восприятия и построения. Также для них достаточно мало автоматизированных средств, взамен предоставляя большую гибкость.

Касаемо всех сетевых моделей для оценки продолжительности проекта — не стоит забывать, что они дают только прогноз, исходя из текущего состояния дел по проекту. При этом исходя из общей производительности команды вполне будет разумно корректировать план, отодвигая сроки завершения, дабы уложиться в них :)
Сейчас я использую минимальную единицу длительности — 1 неделя. И кажется я снова полюбил диаграммы Ганта. Когда в ней были задачи длительностью час, поддерживать ее в актуальном состоянии было просто не реально.

А причиной тому стал переход на скрам с двух-недельной итерацией. Теперь мне нужно только понимать что в какой спринт войдет. А весь микроменеджмент уже внутри команды происходит.
Sign up to leave a comment.