Re[19]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там - Управление проектами

Здравствуйте, stranger_v, Вы писали:

_>Всем привет!

_>Вот, запустил свой бизнес по созданию интернет порталов. Не могу понять, как эффективно построить управление проектом.

_>В частности, нужен проектный план. Классический, где большие куски работы, связи между ними, назначенные работники и т.д. Чтобы можно было увидеть, когда что примерно будет готово, и успеваем мы или нет. Для этого хорошо подходит MS Project или OpenProj.

_>С другой стороны с этим сложно работать обычным разработчикам. Им нужно назначать уже конкретные задачи (иногда небольшие, являющиеся частью большого куска работы) с детальным описанием, что нужно сделать. Поэтому здесь поможет система типа JIRA или Redmine. Где можно назначать тикеты на разработку некоего конкретного функционала с подробным описанием.

_>В то же время, JIRA/Redmine не позволят создать классический план работ. Например, если разработчику Иванову была назначена разработка модуля А, после чего есть еще ряд работ, назначенных на него, то при изменения даты конца разработки модуля А в MS Project достаточно руками поменять конечную дату, и остальные работы Иванова сдвинутся. А в JIRA нужно руками проставлять все изменившиеся даты. Другими словами, JIRA не может отслеживать загрузку и выравнивание ресурсов.

_>Так вот, выходит так, что нужны две системы. Так как ни одна из них не решает всего спектра задач. Вот и выходит, что каждое новое требование, нужно вносить как в MS Project, так и в JIRA. И все изменения в требованиях также отражать сразу на двух системах.

_>Я поражаюсь, что до сих пор приходится так делать. Неужели ничего не придумали для избежания такого?? Или я чего-то не знаю?

_>Неужели нельзя избежать дублирования работы???

Я использую в Jira Time Tracking и отчёт "Сводка работ над версией". То есть я проставляю количество часов, необходимое на разработку, а не конечную дату выполнения. Очередность выполнения управляется приоритетом (также я дополнительно ввёл числовое поле для очередности). Соответственно, когда я назначаю Иванову задачу по разработке модуля А, я в этой задаче указываю, сколько требуется часов на разработку и ставлю приоритет в соответствии с которым Иванов выполняет его в нужном порядке.
Да, согласен, что нет графического представления, но, тем не менее, по каждому разработчику я вижу, сколько рабочих дней на нём "висит". Для планирования сроков и выравнивания загруженности мне хватает.
Конечно, мне приходится сначала назначить все работы разработчикам, и только после этого я могу более точно оценить время. С другой стороны, "примерно" оценить время я могу по тому объёму, который собираюсь включить в очередную версию.
Не уверен, что эта схема будет удобной при большом количестве разработчиков, но мне на моих 8 вполне хватает.Неужели нельзя избежать дублирования работы???

Я использую в Jira Time Tracking и отчёт Неужели нельзя избежать дублирования работы???

Я использую в Jira Time Tracking и отчёт Неужели нельзя избежать дублирования работы???

Я использую в Jira Time Tracking и отчёт

Здравствуйте, stranger_v, Вы писали:

_>Я поражаюсь, что до сих пор приходится так делать. Неужели ничего не придумали для избежания такого?? Или я чего-то не знаю?
Придумали.

Есть, например, task adapter, он как минимум в одном направлении поможет данные перегонять. Может быть, сможет и в обратном направлении синхронизировать. Если интересно, спросите автора (alskor), он вам подробнее расскажет.

Здравствуйте, Centaur, Вы писали:

C>Project более подходит для проектов по копанию траншей. Где «могу копать. могу не копать.» и все работники взаимозаменяемы.

Да ну? А как хотя-бы примерно рассчитать сроки и объяснить их заказчику без подобного механизма? Я не вижу альтернативы, мы же разрабатываем софт не для себя, а для заказчика, где есть вполне конкретные бюджеты и сроки.

Здравствуйте, Nikolay_Ch, Вы писали:

N_C>Здравствуйте, stranger_v, Вы писали:

_>>Вот, запустил свой бизнес по созданию интернет порталов. Не могу понять, как эффективно построить управление проектом.
N_C>А сколько суммарно людей в проектах и сколько одновременных проектов?
Пока что один проект, потом рассчитываем на еще один или два параллельных проектов.
Суммарно людей в проекте сейчас 5: Менеджер (он же аналитик), тим лид, два разработчика, один тестер.
С появлением новых проектов еще планируем набрать одного или двух разработчиков.

Здравствуйте, maxkar, Вы писали:

M>Есть, например, task adapter, он как минимум в одном направлении поможет данные перегонять. Может быть, сможет и в обратном направлении синхронизировать. Если интересно, спросите автора (alskor), он вам подробнее расскажет.
229 долларов в месяц. Для нашего проекта это пока много... Тем более, мы нашли достойную бесплатную альтернативу JIRA. Я об этом напишу в посте ниже.

Здравствуйте, Аноним, Вы писали:

А>Я использую в Jira Time Tracking и отчёт "Сводка работ над версией".

Мы решили уйти от JIRA. Сейчас запощу ответ на свой же вопрос. Прошу прокомментировать, если что...

Я сейчас промониторил тулы этого направления. Остановился на:
Для проджект-менеджмента: Gantter, который ставится как приложение на Google Docs. Позволяет строить проектный план. Вполне мощное приложение + возможность заходить на него с любого места, не устанавливая никакой специфичный софт и не морочась с синхронизацией проектных файлов.
Для issue management: Redmine с бесплатным хостингом на hostedredmine.com. Тоже хорошее приложение.
Можно ли их как-то подружить? Или есть, возможно, другие бесплатные или недорогие альтернативы?

Здравствуйте, stranger_v, Вы писали:
_>Пока что один проект, потом рассчитываем на еще один или два параллельных проектов.
_>Суммарно людей в проекте сейчас 5: Менеджер (он же аналитик), тим лид, два разработчика, один тестер.
_>С появлением новых проектов еще планируем набрать одного или двух разработчиков.
Для такого количества людей достаточно Excel. Городить связки программ для управления проектами при одном-трех одновременных проектах, трех-пяти разработчиках и одном ПМе — ИМХО пустая трата времени и сил прежде всего самого ПМа.

Здравствуйте, Nikolay_Ch, Вы писали:

N_C>Для такого количества людей достаточно Excel. Городить связки программ для управления проектами при одном-трех одновременных проектах, трех-пяти разработчиках и одном ПМе — ИМХО пустая трата времени и сил прежде всего самого ПМа.

И как рассчитать первоначальные сроки для заказчика и оценить трудозатраты? Неужели в Excel это проще, чем в MS Project-подобном туле?

А как трегать баги, общие задание в Excel-файле? Как организовать с ним совместную работу? Как назначать новые задачи и присылать о них уведомления? По-моему, с Redmine все равно проще, даже при таком небольшом количестве разработчиков.

Или Вы со мной не согласны?

Здравствуйте, stranger_v, Вы писали:

_>Здравствуйте, Nikolay_Ch, Вы писали:

_>И как рассчитать первоначальные сроки для заказчика и оценить трудозатраты? Неужели в Excel это проще, чем в MS Project-подобном туле?
Да. Расчет трудозатрат зиждется на оценке трудозатрат по каждой задаче, это да, но в прожекте их хранить — безумство. В прожекте надо делать только крупные мазки проекта, типа "Разработка", "Тестирование" и пр. и уж их оценивать. А еще надо менеджмент резерв заложить. И прочее и прочее. Заказчику, обычно с высокой колокольни все эти премудрости — ему важен срок и стоимость. Но те сроки, которые Вы называете заказчику и те, которые называют программеры достаточно различны. Также обычно заказчику каждую неделю не делают релизы ПО, поэтому можно просто в прожекте сделать одинаковые стадии релизов, а уж в тулзе управления тасками группировать их по релизам. В итоге прожект оказыватся и не так нужен. Важен срок релиза и объем задач к этому релизу.

_>А как трегать баги, общие задание в Excel-файле? Как организовать с ним совместную работу? Как назначать новые задачи и присылать о них уведомления? По-моему, с Redmine все равно проще, даже при таком небольшом количестве разработчиков.
Не... Трекать баги, конечно, удобнее в тулзе какой-нибудь. Но импортировать потом эти баги в MSProject — верх странности. Прожект не предназначен для учета всей этой мелкотни.

_>Или Вы со мной не согласны?
Смотря в чем.

Здравствуйте, stranger_v, Вы писали:

_>Всем привет!
_>Неужели нельзя избежать дублирования работы???

Можно, используй только jira и объясни сам себе и нам зачем тебе project.

Здравствуйте, stranger_v, Вы писали:

_>Я сейчас промониторил тулы этого направления. Остановился на:
_>Для проджект-менеджмента: Gantter, который ставится как приложение на Google Docs. Позволяет строить проектный план. Вполне мощное приложение + возможность заходить на него с любого места, не устанавливая никакой специфичный софт и не морочась с синхронизацией проектных файлов.
_>Для issue management: Redmine с бесплатным хостингом на hostedredmine.com. Тоже хорошее приложение.
_>Можно ли их как-то подружить? Или есть, возможно, другие бесплатные или недорогие альтернативы?

В итоге Вы заменили бесплатным Gantter'ом MS Project и вместо Jira взяли Redmine. Проблема осталась та же. В чём смысл (кроме бесплатности Gantter)?
Вы так никогда работать не начнёте, подыскивая инструменты для планирования.
Я на Jira 2,5 года веду проект и мне её хватает и для того, чтобы раздать задания разработчикам, и для того, чтобы не срывать сроки перед клиентами. И людей у Вас в проекте почти вдвое меньше, чем у меня.

Планирование ради планирования...

Здравствуйте, Nikolay_Ch, Вы писали:

_>>А как трегать баги, общие задание в Excel-файле? Как организовать с ним совместную работу? Как назначать новые задачи и присылать о них уведомления? По-моему, с Redmine все равно проще, даже при таком небольшом количестве разработчиков.
N_C>Не... Трекать баги, конечно, удобнее в тулзе какой-нибудь. Но импортировать потом эти баги в MSProject — верх странности. Прожект не предназначен для учета всей этой мелкотни.
Если честно, я всё ещё пытаюсь выяснить, для чего же реально предназначен проджект. Пока что, кроме умения рисовать гантт-чарты, ничего интересного я в нём не нашёл.
То есть он много обещает, и оно "почти работает", но реально вызывает чудовищный фрустрейшн.
Простейшая вещь — рассчитать срок изготовления проекта.
Работает только в том случае, если задачи реально зависимые по окончанию. Если делать "крупными мазками", то неприменимо даже к копанию траншей. Тупо потому, что "укладка труб" у вас будет зависеть от "копания траншей", которое само по себе занимает шесть месяцев. А на самом деле, можно выкопать сто метров, и уже начинать укладывать трубы, пока траншеекопатель фигачит себе дальше по графику. Итого, "крупномазочный" проект покажет срок окончания в 12 месяцев там, где на самом деле должно быть семь.
Все книжки по планированию софтных проектов говорят "используйте мелкие таски". "Если вы планируете крупными мазками — вы скорее всего сильно ошибаетесь". При этом проджект "не предназначен для учёта всей этой мелкотни".
Далее, те же книжки на вопрос "а как же нам планировать мелкие таски до того, как мы проведём детальное исследование" отвечают "используйте метод набегающей волны". То есть, накидываем задачки "крупными мазками", делаем приблизительные связи (типа start-to-start +30 days для копания и трубоукладывания), а потом, по мере приближения, начинаем дробить на более мелкие задачи.
В проджекте это делать практически нереально — он очень плохо понимает ситуации, когда подзадачи залинканы одновременно с задачами.
Кроме того, тщательное следование этой болезненной практике приводит в будущем к ещё большим проблемам. Стандартный вопрос "как так получилось, что проект, стоивший по оценке 50 человекомесяцев за 1 год, выполнился за 20 месяцев и потратилось 150 человекомесяцев" ответа не находит. Нет в проджекте способа сравнить два списка задач, увы.

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

Здравствуйте, Sinclair, Вы писали:

S>В сказки про ексель я тоже не верю. Потому что в нём ещё труднее, чем в проджекте оперативно ответить на вопрос вице-президента "а что будет с проектом, если мы по-быстрому всунем в него фичу ХХХ, которую попросил наш большой друг?".
Ну как Вам сказать. Из опыта работы с заграничными кампаниями (не совсем маленькими и не крупными, которые доросли до создания собственного софта по управлению проектами) могу сказать, что Excel достаточно легко подходит под водопадную модель. И делать в нем такие вещи не сильно сложне прожекта, более того, иногда — даже проще. Понятно, что Excel не дает автоматически производить перерасчет дат, не даст рассчитать критический путь и пр. но для типовых задач по развертыванию ПО с доработками у заказчика (а это развертывание может длятся не один год (сбор требований, проведение фит-гэп анализа, доработка, тестирование) вполне подойдет.
По Вашему примеру — ведь обычно вставка фичи, это ровно столько времени, во сколько ее оценили. И варианта у менеджера, по сути, три — либо что-то выкинуть из проекта (аналогичной трудоемкости), либо задержать проект, либо увеличить ресурсы. На всякие "если" (типа а что если мы ее сделаем не сейчас, а через два месяца) ответить не сможет ни одна программа.

Здравствуйте, stranger_v, Вы писали:

_>Я поражаюсь, что до сих пор приходится так делать. Неужели ничего не придумали для избежания такого?? Или я чего-то не знаю?
_>Неужели нельзя избежать дублирования работы???

Можно.

Но это не так просто. Для этого необходимо хоть на минуту перестать поражаться, набраться смелости, и заглянуть в репозиторий плагинов JIRA.

С двумя прямолинейными поисковыми запросами.

https://plugins.atlassian.com/search?q=Gantt
https://plugins.atlassian.com/search?q=Project

И обратить, например, внимание, хоть вот эту штуку, которая существует уже много лет: https://plugins.atlassian.com/plugins/com.ecliptictech.connector

Здравствуйте, Nikolay_Ch, Вы писали:

N_C>Не... импортировать потом эти баги в MSProject — верх странности. Прожект не предназначен для учета всей этой мелкотни.
Да, убедили, проджект и JIRA, все же, не стоит сдруживать...

_>>Также обычно заказчику каждую неделю не делают релизы ПО, поэтому можно просто в прожекте сделать одинаковые стадии релизов, а уж в тулзе управления тасками группировать их по релизам. В итоге прожект оказыватся и не так нужен. Важен срок релиза и объем задач к этому релизу.
У меня вот тоже начинается фрустрация. Как все же оценить сроки проекта, который достаточно сложный и состоит из множества задач? Project не помогает, получается, JIRA не для этого, как все-таки делать оценку??? Я в потерях ,помогите, плиз!

Здравствуйте, Sinclair, Вы писали:

S>Если честно, я всё ещё пытаюсь выяснить, для чего же реально предназначен проджект. Пока что, кроме умения рисовать гантт-чарты, ничего интересного я в нём не нашёл.

Ок, я тебе помогу.

S>То есть он много обещает, и оно "почти работает", но реально вызывает чудовищный фрустрейшн.
S>Простейшая вещь — рассчитать срок изготовления проекта.
S>Работает только в том случае, если задачи реально зависимые по окончанию.

То есть, про функцию MS Project "Resource Levelling" ("выравнивание загрузки ресурсов"), ты пока не знаешь.

Не беда, это можно исправить за 5 минут чтением, например, вот этой заметки.
http://gaperton.livejournal.com/19205.html

Добро пожаловать в увлекательный мир MS Project

. Это основная фукнция — по сути, главное, что он вообще делает.

Здравствуйте, Sinclair, Вы писали:

S>Если честно, я всё ещё пытаюсь выяснить, для чего же реально предназначен проджект. Пока что, кроме умения рисовать гантт-чарты, ничего интересного я в нём не нашёл.
Во-во, подписываюсь под каждым словом!

К сожалению, похоже, что подход
декомпозировать задачи --> проставить зависимости между задачами --> оценить длительность каждой --> сложить --> добавить 30%
Не сильно поможет в ответе на вопрос, какой срок сдачи проекта.

Как планировать тогда??? Это казалось бы, простой вопрос, но реально почему-то всегда получается по-другому. Как быть, как планировать? Помогите разобраться, пожалуйста!

Здравствуйте, Аноним, Вы писали:

А>В итоге Вы заменили бесплатным Gantter'ом MS Project и вместо Jira взяли Redmine. Проблема осталась та же. В чём смысл (кроме бесплатности Gantter)?
А>Вы так никогда работать не начнёте, подыскивая инструменты для планирования.
А>Я на Jira 2,5 года веду проект и мне её хватает и для того, чтобы раздать задания разработчикам, и для того, чтобы не срывать сроки перед клиентами. И людей у Вас в проекте почти вдвое меньше, чем у меня.
Аноним, поделитесь опытом, пожалуйста, как у вас получается контролировать и рассчитывать сроки, используя JIRA? Неужели Вы полностью все работы учитываете и покрываете тасками? Без исключения? Как тогда оценить общий срок проекта? Ведь тасками занимается разное количество людей, где-то эти таски можно распараллелить, где-то одни зависят от других. Как высчитать конечный срок?

Здравствуйте, Аноним, Вы писали:

А>Можно, используй только jira и объясни сам себе и нам зачем тебе project.

Я бы рад пользоваться только JIRA, но я не знаю, как можно при помощи JIRA рассчитать срок релиза проекта. Можете объяснить, плиз, как это сделать?

И продублирую сюда свой вопрос:

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

Здравствуйте, Gaperton, Вы писали:

G>Но это не так просто. Для этого необходимо хоть на минуту перестать поражаться, набраться смелости, и заглянуть в репозиторий плагинов JIRA.

С двумя прямолинейными поисковыми запросами.

G>https://plugins.atlassian.com/search?q=Gantt
G>https://plugins.atlassian.com/search?q=Project

Спасибо! Есть сразу вопрос: плагином там бесчисленное количество. Все перебрать — занятие не на один день. Вы какими-то из них пользовались? Можете поделиться опытом?

Здравствуйте, stranger_v, Вы писали:

G>>Но это не так просто. Для этого необходимо хоть на минуту перестать поражаться, набраться смелости, и заглянуть в репозиторий плагинов JIRA.

С двумя прямолинейными поисковыми запросами.

G>>https://plugins.atlassian.com/search?q=Gantt
G>>https://plugins.atlassian.com/search?q=Project

_>Спасибо! Есть сразу вопрос: плагином там бесчисленное количество. Все перебрать — занятие не на один день. Вы какими-то из них пользовались? Можете поделиться опытом?

Не, их не так много, на самом деле — поиск находит лишнее. В районе десятка должно быть. И ставятся они очень просто — через UPM в админке JIRA.

Но я не сторонник подхода к планированию и контролю работ, который стоит за MS Project. Так что обзора плагинов дать не могу — не смотрел. Из них я несколько лет назад пробовал TheConnector. Он работает — честная синхронизация в обе стороны. Ссылку на него я дал. Но он платный и дорогой.

Здравствуйте, stranger_v, Вы писали:

_>У меня вот тоже начинается фрустрация. Как все же оценить сроки проекта, который достаточно сложный и состоит из множества задач? Project не помогает, получается, JIRA не для этого, как все-таки делать оценку??? Я в потерях ,помогите, плиз!
Разработчики могут оценить трудоемкость задач? Если да, то пусть оценивают и вперед. Сколько оценили — это время разработки (с разными оговорками про запас времени, компетентность разработчика и прочее и прочее), остальные времена, по вашей методологии разработки.

Здравствуйте, Gaperton, Вы писали:

G>То есть, про функцию MS Project "Resource Levelling" ("выравнивание загрузки ресурсов"), ты пока не знаешь.

G>Не беда, это можно исправить за 5 минут чтением, например, вот этой заметки.
G>http://gaperton.livejournal.com/19205.html

G>Добро пожаловать в увлекательный мир MS Project

. Это основная фукнция — по сути, главное, что он вообще делает.

Я, судя по всему, так и не понял, как это правильно использовать. Людей на задачи назначаю всё равно я. Перевести work в duration при помощи операции деления я могу и самостоятельно. Чтобы левелинг работал, в проджект надо вбить много информации. И как поддерживать эту информацию актуальной — непонятно. О чём я и написал в своём посте.

Здравствуйте, Gaperton, Вы писали:

G>Но я не сторонник подхода к планированию и контролю работ, который стоит за MS Project. Так что обзора плагинов дать не могу — не смотрел. Из них я несколько лет назад пробовал TheConnector. Он работает — честная синхронизация в обе стороны. Ссылку на него я дал. Но он платный и дорогой.

А кто-нибудь может посоветовать плагины для JIRA, которые позволят отменить необходимость использования MS Project?

Здравствуйте, stranger_v, Вы писали:

_>А кто-нибудь может посоветовать плагины для JIRA, которые позволят отменить необходимость использования MS Project?
А какой функционал из Прожекта Вы используете?

Здравствуйте, Nikolay_Ch, Вы писали:

_>>А кто-нибудь может посоветовать плагины для JIRA, которые позволят отменить необходимость использования MS Project?
N_C>А какой функционал из Прожекта Вы используете?

Я использую проджект для того, чтобы хотя бы примерно рассчитать сроки выполнения каждого этапа проекта. Бью работы по этапу проекта на задачи, назначаю ответственного, распарралеливаю где могу, выравниваю, добавляю contingency 30%, получаю примерный срок.

Могу ли я сделать аналогичные задачи при помощи JIRA?

_>Я использую проджект для того, чтобы хотя бы примерно рассчитать сроки выполнения каждого этапа проекта. Бью работы по этапу проекта на задачи, назначаю ответственного, распарралеливаю где могу, выравниваю, добавляю contingency 30%, получаю примерный срок.

_>Могу ли я сделать аналогичные задачи при помощи JIRA?

Да, и еще... Проджект дает мне возможность при смене сроков текущей задачи автоматически сдвигать даты начала/конца следующих задач, которые зависят от этой, либо сдвигать аналогично даты по выравниваю. Может ли это сделать JIRA?

_>Неужели нельзя избежать дублирования работы???
Можно, TFS и Project прекрасно интегрированы друг с другом.

Здравствуйте, Tom, Вы писали:

_>>Неужели нельзя избежать дублирования работы???
Tom>Можно, TFS и Project прекрасно интегрированы друг с другом.

Ой, а без TFS можно? Я уже ориентируюсь на JIRA. Нашел дешевый JIRA-хостинг. Можно ли как-то обойтись только JIRA, без Project?

Здравствуйте, stranger_v, Вы писали:

_>Ой, а без TFS можно? Я уже ориентируюсь на JIRA. Нашел дешевый JIRA-хостинг. Можно ли как-то обойтись только JIRA, без Project?
Для Вашего количества сотрудников и проектов, можно обойтись одним трекером. Не думаю, что необходимы такие сложности, как параллеливание задач и прочие функции прожекта. Ну не верю я, что Вы оперируете проектом с тысячей задач. Да даже если это и так, то 70 процентов из них будет сделана не в те сроки, которые Вы планируете, так стоит ли тратить на них время? Планируйте ближайшую итерацию. Дальнейшие планируйте только в общих мазках.

Здравствуйте, stranger_v, Вы писали:

_>Ой, а без TFS можно? Я уже ориентируюсь на JIRA. Нашел дешевый JIRA-хостинг. Можно ли как-то обойтись только JIRA, без Project?
И, кстати, в 11-express студии, будет бесплатная версия TFS, насколько я понял...

Здравствуйте, Nikolay_Ch, Вы писали:

_>>Ой, а без TFS можно? Я уже ориентируюсь на JIRA. Нашел дешевый JIRA-хостинг. Можно ли как-то обойтись только JIRA, без Project?
N_C>Для Вашего количества сотрудников и проектов, можно обойтись одним трекером. Не думаю, что необходимы такие сложности, как параллеливание задач и прочие функции прожекта. Ну не верю я, что Вы оперируете проектом с тысячей задач. Да даже если это и так, то 70 процентов из них будет сделана не в те сроки, которые Вы планируете, так стоит ли тратить на них время? Планируйте ближайшую итерацию. Дальнейшие планируйте только в общих мазках.

А как спланировать ближайшую итерацию? Даже в ближайшей итерации десятки задач, их все нужно как-то сложить, и разделить между разработчиками. Как при помощи JIRA рассчитать срок, когда сможем сдать ближайшую итерацию?

Здравствуйте, Sinclair, Вы писали:

G>>То есть, про функцию MS Project "Resource Levelling" ("выравнивание загрузки ресурсов"), ты пока не знаешь.
S>

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

Ты считаешь, то, что ты оказался среди них — это как-то необычно, или смешно, да?

S>Людей на задачи назначаю всё равно я.

Да. Все равно ты.

S>Перевести work в duration при помощи операции деления я могу и самостоятельно.

Это не имеет отношение к выравниванию.

S>Чтобы левелинг работал, в проджект надо вбить много информации.

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

S>И как поддерживать эту информацию актуальной — непонятно. О чём я и написал в своём посте.

А вот кэп мне шепчет, что должно быть как минимум два варианта — либо руками, либо автоматом.

Первое делается через сам Project (о чем я и написал в своем посте в ЖЖ), или через его вебморду, а второе — второе через интеграцию с трекерами (о чем я написал здесь в комментариях рядом).

S>Я, судя по всему, так и не понял, как это правильно использовать.

Ты меня поражаешь.

Здравствуйте, stranger_v, Вы писали:

_>А как спланировать ближайшую итерацию? Даже в ближайшей итерации десятки задач, их все нужно как-то сложить, и разделить между разработчиками. Как при помощи JIRA рассчитать срок, когда сможем сдать ближайшую итерацию?
Ну да, сложить и разделить. Я же не против прожекта совсем, просто мне кажется, что при Вашей нагрузке, все можно делать и без него. Если Вы считаете, что не сможете без него обойтись, то что же делать — используйте его.

Здравствуйте, stranger_v, Вы писали:

_>>Я использую проджект для того, чтобы хотя бы примерно рассчитать сроки выполнения каждого этапа проекта. Бью работы по этапу проекта на задачи, назначаю ответственного, распарралеливаю где могу, выравниваю, добавляю contingency 30%, получаю примерный срок.

_>>Могу ли я сделать аналогичные задачи при помощи JIRA?

_>Да, и еще... Проджект дает мне возможность при смене сроков текущей задачи автоматически сдвигать даты начала/конца следующих задач, которые зависят от этой, либо сдвигать аналогично даты по выравниваю. Может ли это сделать JIRA?

TheConnector попробуй, ссылку на который я дал. И JIRA все сможет.

Здравствуйте, Gaperton, Вы писали:

_>>Да, и еще... Проджект дает мне возможность при смене сроков текущей задачи автоматически сдвигать даты начала/конца следующих задач, которые зависят от этой, либо сдвигать аналогично даты по выравниваю. Может ли это сделать JIRA?

G>TheConnector попробуй, ссылку на который я дал. И JIRA все сможет.

500$ за одного пользователя!!! Это ж нифига себе!! Можно ли как-то с более доступными технологиями все порешать? Возможно, самой JIRA или какими-то плагинами к ней?

Здравствуйте, Nikolay_Ch, Вы писали:

N_C>Ну да, сложить и разделить. Я же не против прожекта совсем, просто мне кажется, что при Вашей нагрузке, все можно делать и без него. Если Вы считаете, что не сможете без него обойтись, то что же делать — используйте его.

А есть какие-нибудь плагины для JIRA, упрощающие планирование? Понятно, что могу поискать и найти. Подозреваю, их будет много. Может, у кого-нить есть позитивный опыт работы с каким-нибудь плагином?

Здравствуйте, stranger_v, Вы писали:

_>>>Да, и еще... Проджект дает мне возможность при смене сроков текущей задачи автоматически сдвигать даты начала/конца следующих задач, которые зависят от этой, либо сдвигать аналогично даты по выравниваю. Может ли это сделать JIRA?

G>>TheConnector попробуй, ссылку на который я дал. И JIRA все сможет.

_>500$ за одного пользователя!!! Это ж нифига себе!! Можно ли как-то с более доступными технологиями все порешать? Возможно, самой JIRA или какими-то плагинами к ней?

Дык и Project сам по себе недешевый, не?

Ну вот сейчас у меня стоит вот эта штука:
https://plugins.atlassian.com/plugins/com.soyatec.jira.plugins.jira-ganttchart-project

Попробуй ее, может подойдет. Вроде по описанию все должна уметь.

Здравствуйте, Gaperton, Вы писали:

G>Ее надо "вбить" ровно столько, сколько в принципе необходимо для того, чтобы рассчитать сроки.
Это трюизм.
S>>И как поддерживать эту информацию актуальной — непонятно. О чём я и написал в своём посте.
G>А вот кэп мне шепчет, что должно быть как минимум два варианта — либо руками, либо автоматом.
Это тоже.

S>>Я, судя по всему, так и не понял, как это правильно использовать.
G>Ты меня поражаешь.
Может, вместо того, чтобы поражаться, вы объясните подробный алгоритм использования проджекта? В вашей статье, простите, написаны только настройки, которые надо сделать в проджекте, и то, какие View важнее, чем другие.

Как-то не раскрыты темы
1. Как именно определить длительность проекта, исходя из входящих в него задач
2. Как определить, сколько нужно людей, чтобы выполнить этот проект
3. Как вносить изменения в Project по ходу выполнения проекта
4. Как определить причины изменений сроков и стоимости по сравнению с изначальным планом

Понятное дело, с учётом того, что этап первоначального планирования должен занимать приемлемое время. Когда тим лидера просят спланировать разработку на следующие полгода для команды в 8 человек, он не может себе позволить забить и оценить ~2000 задач. Тем более что гантт с такими объёмами будет абсолютно не наглядным. И вообще я не нашёл в проджекте ни одного способа приемлемо визуализировать такие объёмы информации.

А то, как переключить левелинг по приоритету на левелинг по ID, это не очень интересно.

Здравствуйте, Sinclair, Вы писали:

S>>>И как поддерживать эту информацию актуальной — непонятно. О чём я и написал в своём посте.
G>>А вот кэп мне шепчет, что должно быть как минимум два варианта — либо руками, либо автоматом.
S>Это тоже.

Странно, строкой выше ты написал, что тебе это непонятно (см. выделенное).

S>>>Я, судя по всему, так и не понял, как это правильно использовать.
G>>Ты меня поражаешь.

S>Может, вместо того, чтобы поражаться, вы объясните подробный алгоритм использования проджекта? В вашей статье, простите, написаны только настройки, которые надо сделать в проджекте, и то, какие View важнее, чем другие.

Пошаговый алгоритм его использования содержится в туториале, который встроен в MS Project. Я — читал.

Ты хочешь, чтобы я его тебе в деталях, подробно, и по шагам воспроизвел в форуме? Зачем? Тебе что-то мешает самому нажать кнопку Help?

S>1. Как именно определить длительность проекта, исходя из входящих в него задач

Посмотреть на график справа[/b], там будет это будет прекрасно видно. Не ошибешься.

S>2. Как определить, сколько нужно людей, чтобы выполнить этот проект

Выходит за рамки вопросов использования MS Project.

S>3. Как вносить изменения в Project по ходу выполнения проекта

Пункт (8) заметки в ЖЖ. С подробностями в Help MS Project.

Веб-интерфейс MS Project. С подробностями в Help к MS Project Server.

Плагин TheConnector. С подробностями сюда.
https://plugins.atlassian.com/plugins/com.ecliptictech.connector

S>4. Как определить причины изменений сроков и стоимости по сравнению с изначальным планом

Выходит за рамки вопросов использования MS Project.

S>Понятное дело, с учётом того, что этап первоначального планирования должен занимать приемлемое время.

Не важно. К вопросам работы с MS Project не относится.

S>Когда тим лидера просят спланировать разработку на следующие полгода для команды в 8 человек, он не может себе позволить забить и оценить ~2000 задач.

Когда какого-то твоего знакомого тим-лида просят спланировать, он не может себе позволить все бросить, и оценить. Понятно.

Какое отношение проблемы твоего тимлида имеют к вопросам использования MS Project? Непонятно.

S> Тем более что гантт с такими объёмами будет абсолютно не наглядным. И вообще я не нашёл в проджекте ни одного способа приемлемо визуализировать такие объёмы информации.

Вложенные задачи. Внешние проекты. Что такое? Читай мануал.

S>А то, как переключить левелинг по приоритету на левелинг по ID, это не очень интересно.

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

_>Ой, а без TFS можно? Я уже ориентируюсь на JIRA. Нашел дешевый JIRA-хостинг. Можно ли как-то обойтись только JIRA, без Project?
Первая ссылка в гугле
http://www.the-connector.com/index.aspx

Здравствуйте, Tom, Вы писали:

_>>Ой, а без TFS можно? Я уже ориентируюсь на JIRA. Нашел дешевый JIRA-хостинг. Можно ли как-то обойтись только JIRA, без Project?
Tom>Первая ссылка в гугле
Tom>http://www.the-connector.com/index.aspx
Так это же плагин для MS Project. Который к тому же и стоит 500$ за однопользовательскую лицензию...

Здравствуйте, stranger_v, Вы писали:

_>Аноним, поделитесь опытом, пожалуйста, как у вас получается контролировать и рассчитывать сроки, используя JIRA?

Я не Аноним, но у меня как-то получается.

_>Неужели Вы полностью все работы учитываете и покрываете тасками? Без исключения?

Конечно. Невозможно планировать то что не оценено и оценивать то, что не записано.

_>Как тогда оценить общий срок проекта?

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

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

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

Здравствуйте, Gaperton, Вы писали:

G>Дык и Project сам по себе недешевый, не?

Дык я не хочу Project уже, я нашел бесплатный вариант — Gantter. Он может ставиться в гугл докс еще. Он вполне устраивает меня для планнига. Но это все равно получается два инструмента.

G>Ну вот сейчас у меня стоит вот эта штука:
G>https://plugins.atlassian.com/plugins/com.soyatec.jira.plugins.jira-ganttchart-project

G>Попробуй ее, может подойдет. Вроде по описанию все должна уметь.

По описанию все выглядит круто, спасибо за ссылку. По отзывам на той страничке выходит, что сыровата. Попробую на днях — отпишусь. Знает кто проверенные плагины?

Здравствуйте, Miroff, Вы писали:

_>>Как тогда оценить общий срок проекта?

M>Сложить оценки всех задач, добавить фиксированный гэп между задачами, разделить на количество людей и перевести часы в календарную дату.

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

M>По моему опыту то совершенно не важно. Зависимые здачи встречаются настолько редко, что никакого измеримого влияния на ход проекта не оказывают. Для оценки сроков достаточно допущения что при достаточно хорошем оперативном управлении все задачи могут выполняться параллельно.

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

Кстати, а сколько гэпа между задачами Вы обычно закладываете и как Вы его рассчитываете? Можете поделиться опытом?

Здравствуйте, Sinclair, Вы писали:

S>Понятное дело, с учётом того, что этап первоначального планирования должен занимать приемлемое время. Когда тим лидера просят спланировать разработку на следующие полгода для команды в 8 человек, он не может себе позволить забить и оценить ~2000 задач.

MS Project вообще не предназначен для того, чтобы в нем "тимлиды планировали разработку на следующие полгода".

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

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

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

И Project в этом совершенно не виноват. Этот факт, видишь-ли, не делает Project ни лучше, ни хуже. И, по идее, не должен мешать тебе понять, для каких ситуаций предназначен Project.

22.05.2012 16:18, Gaperton написал:

> MS Project вообще не предназначен для того, чтобы в нем "тимлиды
> планировали разработку на следующие полгода".
Мало-ли для чего он не предназначен. Именно для этого его чаще всего и
используют. Особенно прикольно, когда в нем планируют с детализацией 3
дня на год вперед все что можно и нельзя.

Posted via RSDN NNTP Server 2.1 beta

22.05.2012 15:30, Miroff написал:

> По моему опыту то совершенно не важно. Зависимые здачи встречаются
> настолько редко, что никакого измеримого влияния на ход проекта не
> оказывают. Для оценки сроков достаточно допущения что при достаточно
> хорошем оперативном управлении все задачи могут выполняться параллельно.
Очень интересно. У меня совершенно противоположный опыт.
Кстати, когда некто предполагал, что все задачи можно распараллелить,
обычно выходил провал проекта.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Gaperton, Вы писали:

G>Пошаговый алгоритм его использования содержится в туториале, который встроен в MS Project. Я — читал.
Я — тоже.
G>Ты хочешь, чтобы я его тебе в деталях, подробно, и по шагам воспроизвел в форуме? Зачем? Тебе что-то мешает самому нажать кнопку Help?

S>>1. Как именно определить длительность проекта, исходя из входящих в него задач
G>Посмотреть на график справа[/b], там будет это будет прекрасно видно. Не ошибешься.
Конечно же ошибусь.

G>Выходит за рамки вопросов использования MS Project.

S>>3. Как вносить изменения в Project по ходу выполнения проекта
G>Пункт (8) заметки в ЖЖ. С подробностями в Help MS Project.
Не раскрыта тема отказа от ненужных более задач; не раскрыта тема разбиения задач на подзадачи "на ходу", при уточнении проекта.

G>Выходит за рамки вопросов использования MS Project.
G>Не важно. К вопросам работы с MS Project не относится.
G>Какое отношение проблемы твоего тимлида имеют к вопросам использования MS Project? Непонятно.
Вот поэтому я и говорю, что в функции MS Project входит только рисование гантт-чарта. Всё остальное — "выходит за рамки вопросов использования MS Project", а это как раз ежедневная деятельность тим лида.
Получается этакая каша из топора.

Здравствуйте, Gaperton, Вы писали:

G>Он предназначен для шедулинга и отслеживания ходя выполнения проекта. То есть, осмысленной деятельности с конкретной конечной целью, определенным уникальным финальным результатом, имеющей начало, и конец. А не для того, чтобы как-то спланировать процесс копания от забора до обеда.
Ещё раз: размер приведён просто для сопоставления масштабов. В нормальном софтостроении не бывает релизов раз в неделю. Вот, скажем, у микрософта цикл длиной в три года; у нас — примерно в год.
Когда мы готовим релиз, у которого есть конечная цель, определённый уникальный финальный результат, начало, и конец, нам надо его спланировать.
Основные вопросы, на которые должен отвечать тим лид, это "когда будет готово", "что именно будет готово", "почему изменились результаты", и "как скорректировать план в соответствии с новой ситуацией".
Для этого и нужен инструмент. Инструмент для рисования гантт-чартов — не нужен. Гантт чарт шириной в 12 месяцев и высотой в 4000 задач абсолютно неинформативен.

G>Наличие целенаправленной (проектной) деятельности (то есть, первичности цели, которую надо достичь, а не двух тысяч мелких слабосвязанных друг с другом задач, и срока взятого от балды) здесь принципиально — только в этом случае тебе интересны разнообразные "критические пути" и прочее.
Давайте разберёмся. Ведущие собаководы рекомендуют при оценках не делать задачи длиннее 4х часов. Иначе вы рискуете ошибиться в оценке на порядок.
Я вам привёл пример на пальцах про копание канавы, который вы проигнорировали. Чтобы корректно получить длительность проекта, нам нужно одно из двух:
а) сделать зависимость для прокладки трубы не finish-to-start, а start-to-start с задержкой в неделю (есть риск ошибиться, т.к. эта неделя взята более-менее с потолка)
б) поделить задачи копания канавы и укладки трубы на мелкие поздадачи, в которых уже будут честные finish-to-start зависимости.
Второй способ точнее, и он автоматически адаптируется к реальному прогрессу. Потому, что если в первом способе мы за первую неделю прокопали вдвое меньше, чем планировали, проджект по-прежнему будет оптимистично рапортовать, что укладку можно начинать.

Отсюда мы и получаем порядка 2000 задач, из которых состоит проект для маленькой команды, занимающий примерно шесть месяцев.
При этом для согласования проекта нужно оценить не 2000 задач, а примерно 6000, потому что две трети в итоге будут выкинуты в результате многочисленных болезненных обсуждений. Т.к. хотят все сразу всего, а ресурсов есть только для 30%.
Что вы предлагаете с этим делать? Или это тоже "выходит за рамки использования MS Project"?

G>И Project в этом совершенно не виноват. Этот факт, видишь-ли, не делает Project ни лучше, ни хуже. И, по идее, не должен мешать тебе понять, для каких ситуаций предназначен Project.
Простите, а что мне поможет понять, для каких ситуаций он предназначен? Пока что я видел на практике только одно предназначение — один раз в начале проекта нарисовать красивый водопадный план, состоящий из псевдозадач типа "закодить всё, протестировать всё", получить аппрувал, а потом выбросить его и больше никогда не возвращаться.

Здравствуйте, Sinclair, Вы писали:

S>>>1. Как именно определить длительность проекта, исходя из входящих в него задач
G>>Посмотреть на график справа[/b], там будет это будет прекрасно видно. Не ошибешься.
S>Конечно же ошибусь.

Оснований не верить тебе (что лично ты можешь ошибиться) у меня нет — но я ничем не могу помочь.

Ибо я искренне не понимаю, как тут можно ошибиться.

S>>>3. Как вносить изменения в Project по ходу выполнения проекта
G>>Пункт (8) заметки в ЖЖ. С подробностями в Help MS Project.
S>Не раскрыта тема отказа от ненужных более задач; не раскрыта тема разбиения задач на подзадачи "на ходу", при уточнении проекта.

В сравнении с типичным учебником по MS Project, у меня там, вообще, очень много тем "не раскрыто". Намекать не надо. Если ты считаешь нужным — почему бы тебе не сказать прямо и не обозначить проблему явно. Догадываться, какие из них ты считаешь необходимым раскрыть, и почему (т.е. "продумывать ходы за тебя") — я не буду.

В чем у тебя проблема с удалением задач и добавлением новых, и откуда они берутся — я не понимаю. У меня это никогда проблем не вызывало.

G>>Выходит за рамки вопросов использования MS Project.
G>>Не важно. К вопросам работы с MS Project не относится.
G>>Какое отношение проблемы твоего тимлида имеют к вопросам использования MS Project? Непонятно.

S>Вот поэтому я и говорю, что в функции MS Project входит только рисование гантт-чарта. Всё остальное — "выходит за рамки вопросов использования MS Project", а это как раз ежедневная деятельность тим лида.

"Поэтому" подразумевает наличие причинно-следственной связи.

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

А во-вторых, вывод твой объективно неверен, ибо в функции project входит как минимум resource leveling.

И еще много чего.

Принимая это во внимание — я не понимаю, что в принципе можно тебе осмысленного ответить, ибо ты ставишь меня в тупик.

Ты зачем меня поражаешь?

S>Получается этакая каша из топора.

Вот с этим согласен.

On 22.05.2012 19:03, Sinclair wrote:

> Простите, а что мне поможет понять, для каких ситуаций он предназначен?
> Пока что я видел /на практике/ только одно предназначение — один раз в
> начале проекта нарисовать красивый водопадный план, состоящий из
> псевдозадач типа "закодить всё, протестировать всё", получить аппрувал,
> а потом выбросить его и больше никогда не возвращаться.

Ну, вы всё верно поняли-то

Конечно не "закодить всё, протестить
всё", но очень coarse-grained. И после утверждения оставить только для
ретроспективных целей.

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

--
WBR,
Serge.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Gaperton, Вы писали:

G>Ибо я искренне не понимаю, как тут можно ошибиться.

Я привёл пример ошибки вот тут: http://rsdn.ru/forum/management/4742911.1.aspx
Если вам непонятен пример из 2х задач — не стесняйтесь, спрашивайте.

G>В сравнении с типичным учебником по MS Project, у меня там, вообще, очень много тем "не раскрыто". Намекать не надо. Если ты считаешь нужным — почему бы тебе не сказать прямо и не обозначить проблему явно. Догадываться, какие из них ты считаешь необходимым раскрыть, и почему (т.е. "продумывать ходы за тебя") — я не буду.
Я сказал прямо, и проблемы обозначил.
G>В чем у тебя проблема с удалением задач и добавлением новых, и откуда они берутся — я не понимаю. У меня это никогда проблем не вызывало.
Проблемы — очень простые: Невозможность сравнить план с baseline. Вместе с удаленим задачи навсегда исчезает вся информация о ней.
То есть проджект ничего не может предложить для самого основного сценария уточняющегося планирования: берём задачу размером в человеко-неделю и режем на задачи по 2-4 часа. При этом первые шесть часов на эту задачу могут быть уже отрепорчены. Нормальная, жизненная ситуация. "Выходит за рамки вопросов использования MS Project". Отож.

G>"Поэтому" подразумевает наличие причинно-следственной связи.
Ну так если из четырёх вопросов на три ответ "он не для этого", а на один — "я не понимаю, в чём проблема", то какие ещё причинно-следственные связи нужны?

G>Я, во-первых, ее в твоем рассуждении не вижу (ну не понимаю я, каким образом из личных проблем одного тимлида в принципе могут следовать какие-либо утверждения о функциональности Project).
Нет никаких личных проблем. Это вопросы, которые ставит работа перед каждым менеджером малого подразделения. Ответов на них проджект не даёт. Вопрос: а для чего он тогда?

G>А во-вторых, вывод твой объективно неверен, ибо в функции project входит как минимум resource leveling.

И еще много чего.
В таких объёмах, как вы рассказали в своей заметке, ресурс левелинг входит и в MS Visio. То есть просто лепим одну задачку за другой — и всё. Понятно и наглядно.
Мне более-менее безразличны тысячи функций проджекта, пока они не помогают решать основную задачу менеджера: спланировать загрузку ресурсов в динамически изменяющемся окружении.

S>>Получается этакая каша из топора.
G>Вот с этим согласен.
Поясню на отдалённом примере. Есть такой тип программно-аппаратных решений, называется "спутниковый навигатор". Он помогает водителю планировать маршрут и идти по нему.
То есть водитель ставит задачу, "попасть в точку B". Иногда — более сложную задачу "попасть в точку B, потом в C, потом в D, и между С и D нужно найти заправку".
Навигатор прокладывает ему маршрут, и напоминает о действиях, которые нужно выполнять по ходу маршрута.
Пока что всё вполне аналогично работе проджекта — мы описываем точку B в терминах шагов, которые нужны для её достижения, проджект рисует путь до неё, который не противоречит физической реальности. Мы можем играть вариантами, выбирая между рискованными или менее дорогими вариантами.
Но проджект в итоге оставляет тебя с распечатанной картой, и если ты простоял в пробке, свернул не туда, или решил заехать по пути в ашан, то проджект тебе ничем не поможет. Даже если ты заносишь в него выполненные действия с методичностью GPS-приёмника. Он не подскажет, куда свернуть, чтобы вернуться на маршрут, не скажет, сколько теперь осталось ехать.

Нет, такой "одноразовый навигатор" — тоже хорошо; потому что альтернатива — нудный ручной расчёт с картой и ручкой.
Но в 21-то веке почему-то люди ожидают от навигатора того, чтобы он не просто орал "вы ушли с маршрута", а предлагал варианты. Чтобы он учитывал изменение ситуации с пробками и предлагал альтернативы. Чтобы он хотя бы давал мне в каждый момент ответ "когда я приеду". Это почему-то кажется очевидным и понятным.

Но как только заходит речь о планировании коллективной работы, аналогичные ожидания внезапно вызывают оторопь. Да, я хочу, чтобы инструмент помогал мне в планировании проектных работ. Этап первоначальной подготовки проекта — самый короткий. В нём команда проводит минимум времени. Большая часть времени проходит во время выполнения проекта. И вопросы перепланирования встают многократно за время проекта. И про них почему-то ничего в "учебниках по MS Project" не пишут. А в жизни не бывает ни одного проекта, от которого к моменту окончания остаётся больше 50% первоначальных задач.

За годы знакомства у меня сложилось впечатление, что MS Project — он не для проектов, а для чего-то другого. ХЗ для чего. Потому что чего бы я от него ни хотел, он этого не умеет.

Здравствуйте, hrensgory, Вы писали:

H>Ну, вы всё верно поняли-то

Конечно не "закодить всё, протестить
H>всё", но очень coarse-grained. И после утверждения оставить только для
H>ретроспективных целей.
В том-то и дело, что все, с кем я общался, имеют ровно такой же опыт. И только гапертон внезапно проник в тайну MSProject. Ну так может быть это мы все идиоты? А он знает какой-то рецепт?

Вопрос ведь не в том, знаю ли я, что там есть Resource Leveling. Вопрос в том, чтобы из проджекта извлекать пользу.

Здравствуйте, Sinclair, Вы писали:

G>>Он предназначен для шедулинга и отслеживания ходя выполнения проекта. То есть, осмысленной деятельности с конкретной конечной целью, определенным уникальным финальным результатом, имеющей начало, и конец. А не для того, чтобы как-то спланировать процесс копания от забора до обеда.
S>Ещё раз: размер приведён просто для сопоставления масштабов. В нормальном софтостроении не бывает релизов раз в неделю. Вот, скажем, у микрософта цикл длиной в три года; у нас — примерно в год.

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

S>Когда мы готовим релиз, у которого есть конечная цель, определённый уникальный финальный результат, начало, и конец, нам надо его спланировать.
S>Основные вопросы, на которые должен отвечать тим лид, это "когда будет готово", "что именно будет готово", "почему изменились результаты", и "как скорректировать план в соответствии с новой ситуацией".
S>Для этого и нужен инструмент. Инструмент для рисования гантт-чартов — не нужен. Гантт чарт шириной в 12 месяцев и высотой в 4000 задач абсолютно неинформативен.

Во-первых, и я могу добавить — "еще раз", потому, что до тебя это почему-то упорно не доходит, MS Project — это инструмент для ресурсного планирования, а не "рисовалка Гантт-чартов". В конце концов, предлагаю поверить мне на слово.

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

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

G>>Наличие целенаправленной (проектной) деятельности (то есть, первичности цели, которую надо достичь, а не двух тысяч мелких слабосвязанных друг с другом задач, и срока взятого от балды) здесь принципиально — только в этом случае тебе интересны разнообразные "критические пути" и прочее.
S>Давайте разберёмся. Ведущие собаководы рекомендуют при оценках не делать задачи длиннее 4х часов. Иначе вы рискуете ошибиться в оценке на порядок.

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

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

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

В четвертых, собаководам известна масса интересных способов поднять точность оценок, не прибегая к нарезке на микрозадачи.

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

S>Я вам привёл пример на пальцах про копание канавы, который вы проигнорировали.

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

S>Чтобы корректно получить длительность проекта, нам нужно одно из двух:
S>а) сделать зависимость для прокладки трубы не finish-to-start, а start-to-start с задержкой в неделю (есть риск ошибиться, т.к. эта неделя взята более-менее с потолка)
S>б) поделить задачи копания канавы и укладки трубы на мелкие поздадачи, в которых уже будут честные finish-to-start зависимости.
S>Второй способ точнее, и он автоматически адаптируется к реальному прогрессу. Потому, что если в первом способе мы за первую неделю прокопали вдвое меньше, чем планировали, проджект по-прежнему будет оптимистично рапортовать, что укладку можно начинать.

а) Для грубого планирования "конвейерной" активности делают так. Ставится не только SS с задержкой, как у тебя, но и FF с задержкой. То есть, две связи, на каждой из них задержка. Никаких проблем на практике это не вызовет — не переживай, никто трубу укладывать без канавы не будет. При большом желании избежать описанной тобой логической трагедии, рытье траншеи бьется на две задачи, а не на две тысячи.
б) Требуемая длительность задач в плане определяется практически потребным интервалом контроля. А не математическим маразмом.

S>Отсюда мы и получаем порядка 2000 задач, из которых состоит проект для маленькой команды, занимающий примерно шесть месяцев.

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

S>При этом для согласования проекта нужно оценить не 2000 задач, а примерно 6000, потому что две трети в итоге будут выкинуты в результате многочисленных болезненных обсуждений. Т.к. хотят все сразу всего, а ресурсов есть только для 30%.
S>Что вы предлагаете с этим делать? Или это тоже "выходит за рамки использования MS Project"?

Да, представляете — это действие тоже выходит за рамки использования MS Project. Увольняться.

G>>И Project в этом совершенно не виноват. Этот факт, видишь-ли, не делает Project ни лучше, ни хуже. И, по идее, не должен мешать тебе понять, для каких ситуаций предназначен Project.
S>Простите, а что мне поможет понять, для каких ситуаций он предназначен?

Боюсь ничего не поможет, дружище. Предлагаю бросить эту затею. Хотя нет — можно уволиться, это вполне может помочь.

Здравствуйте, Gaperton, Вы писали:

G>Во-первых, и я могу добавить — "еще раз", потому, что до тебя это почему-то упорно не доходит, MS Project — это инструмент для ресурсного планирования, а не "рисовалка Гантт-чартов". В конце концов, предлагаю поверить мне на слово.
Что именно вы называете "ресурсным планированием"? Не надо мудрить — покажите пальцем.

G>Во-вторых, если хоть кто-нибудь из моих тим-лидов или менеджеров проектов вот так всерьез решит, что инструментом для ответа на вопрос "как скорректировать план в соответствии с новой ситуацией" должен являться не его мозг, а какая нибудь (любая) тула — он будет уволен за профнепригодность.
О, я ждал этого ответа. Надо полагать, водителя, который просит поставить ему Навител с поддержкой информации о пробках надо тоже сразу увольнять за профнепригодность?
G>Я абсолютно серьезно говорю. Ибо считаю саму постановку вопроса клинической. И, думаю, другие менеджеры со мной согласятся.
Вижу, вам очень хочется доказать абсурдность моих представлений.
Поясню: я не жду, что проджект в ответ на "Вася взял больничный на неделю" прожект мне ответит голосом "отдай задачу "написать скрипт для импорта из csv" Пете, а задачу "проверить работспособность на vmware" придётся дропнуть".
Но я жду от инструмента планирования хоть какой-то помощи в принятии такого решения. Расскажите, как именно проджект помогает вашим тим-лидерам и менеджерам в таких вопросах.

G>Во-первых, ведущих собаководов чуть больше, чем одна штука, и те, которые советуют ограничить задачи 4-мя часами, в меньшинстве.
G>Во-вторых, для того, чтобы "не ошибиться на порядок", единиц планирования должно быть достаточное количество, и задача 4-х часовой длительности обеспечивает точность короткой, примерно недельной итерации/этапа/майлстона.
Меня начинает утомлять ваша негативная позиция. Я уже понял, что делаю всё неправильно, и понимаю всё неправильно. Давайте уже что-нибудь конструктивное.
G>В четвертых, собаководам известна масса интересных способов поднять точность оценок, не прибегая к нарезке на микрозадачи.
Давайте их в студию.
S>>Я вам привёл пример на пальцах про копание канавы, который вы проигнорировали.
G>Честно говоря, я в разработке и управлении проектами куда лучше разбираюсь, чем в рытье канав. Ну ничего в канавах не смыслю. Прошу с пониманием отнестись.
Давайте прекратим обсуждать ваши (и мои) таланты, и перейдём к скучной банальщине: практике применения MS Project для проектной работы.
Проектная работа вся одинаковая — есть задачи, есть ресурсы, есть зависимости.

G>а) Для грубого планирования "конвейерной" активности делают так. Ставится не только SS с задержкой, как у тебя, но и FF с задержкой. То есть, две связи, на каждой из них задержка.
Ну вот, видите как здорово — стоит перестать надувать щёки и умничать, как сразу появляется место для конструктивной беседы.
А исходя из чего определяются величины задержек для этих FF и SS? Как они потом корректируются?
G>Никаких проблем на практике это не вызовет — не переживай, никто трубу укладывать без канавы не будет.
Я переживаю не за это. Я переживаю за то, что у нас проект начинает разьезжаться с планом, а проджект ничего "такого" не показывает.
G>При большом желании избежать описанной тобой логической трагедии, рытье траншеи бьется на две задачи, а не на две тысячи.
Почему на две? Какие две? Типа "вырыть канаву для первого сегмента трубы" и "вырыть канаву для всех остальных сегментов"?
Очень интересно. И как нам это поможет? Просирать проект мы можем начать и на второй неделе, после выполнения первой задачи.
G>б) Требуемая длительность задач в плане определяется практически потребным интервалом контроля. А не математическим маразмом.
Конкретно, как именно она определяется "практически потребным интервалом контроля"? Я понимаю, что вы мне хотите рассказать метод набегающей волны, но мне интересны не сферически обтекаемые фразы в вакууме, а практические рекомендации.
G>Да, представляете — это действие тоже выходит за рамки использования MS Project. Увольняться.

Понятно. Вы меня убедили — для планирования проектов проджект непригоден. Всё равно всю работу нужно делать руками.
G>Боюсь ничего не поможет, дружище. Предлагаю бросить эту затею. Хотя нет — можно уволиться, это вполне может помочь.
То есть у вас выбор такой — либо мучиться с проджектом, либо уволиться? Прекрасно, прекрасно. Завидую вашим тим лидам и проджект менеджерам.

Вот только мне удивительна такая позиция на форуме разработчиков. Мы обсуждаем сложную область человеческой деятельности. Для разработчика софта естественная реакция — попробовать придумать или подобрать инструменты, которые позволяют автоматизировать рутину в этой деятельности.
Но ваша позиция — "нет, нужно уволить человека, неспособного делать всё это в уме". Удивительно.

Здравствуйте, Sinclair, Вы писали:

G>>Ибо я искренне не понимаю, как тут можно ошибиться.

S>Я привёл пример ошибки вот тут: http://rsdn.ru/forum/management/4742911.1.aspx
S>Если вам непонятен пример из 2х задач — не стесняйтесь, спрашивайте.

Не понятен. Спрашиваю. Ты не стесняйся, рассказывай.

G>>В чем у тебя проблема с удалением задач и добавлением новых, и откуда они берутся — я не понимаю. У меня это никогда проблем не вызывало.
S>Проблемы — очень простые: Невозможность сравнить план с baseline. Вместе с удаленим задачи навсегда исчезает вся информация о ней.
S>То есть проджект ничего не может предложить для самого основного сценария уточняющегося планирования: берём задачу размером в человеко-неделю и режем на задачи по 2-4 часа. При этом первые шесть часов на эту задачу могут быть уже отрепорчены. Нормальная, жизненная ситуация. "Выходит за рамки вопросов использования MS Project". Отож.

Как интересно. А зачем ты удаляешь из плана задачи, на которые уже потрачено время?

G>>"Поэтому" подразумевает наличие причинно-следственной связи.
S>Ну так если из четырёх вопросов на три ответ "он не для этого", а на один — "я не понимаю, в чём проблема", то какие ещё причинно-следственные связи нужны?

Правильные.

Кашу из топора без меня кушай.

Здравствуйте, Gaperton, Вы писали:
G>Не понятен. Спрашиваю. Ты не стесняйся, рассказывай.
Не вижу вопроса.

G>>>В чем у тебя проблема с удалением задач и добавлением новых, и откуда они берутся — я не понимаю. У меня это никогда проблем не вызывало.
S>>Проблемы — очень простые: Невозможность сравнить план с baseline. Вместе с удаленим задачи навсегда исчезает вся информация о ней.
S>>То есть проджект ничего не может предложить для самого основного сценария уточняющегося планирования: берём задачу размером в человеко-неделю и режем на задачи по 2-4 часа. При этом первые шесть часов на эту задачу могут быть уже отрепорчены. Нормальная, жизненная ситуация. "Выходит за рамки вопросов использования MS Project". Отож.

G>Как интересно. А зачем ты удаляешь из плана задачи, на которые уже потрачено время?
Я не удаляю из плана задачи, на которые уже потрачено время.
Вот типичные изменения, которые нужно вносить в проект по ходу его выполнения (не считая вбивания реально потраченных часов):
1. Добавить новую задачу
2. Выбросить задачу, которую передумали делать
3. Уточнить задачу (частично выполненную), порезав её на более мелкие задачи.
Я про сценарий 3.

G>>>"Поэтому" подразумевает наличие причинно-следственной связи.
S>>Ну так если из четырёх вопросов на три ответ "он не для этого", а на один — "я не понимаю, в чём проблема", то какие ещё причинно-следственные связи нужны?
G>Кашу из топора без меня кушай.
Я на всякий случай напомню вам сюжет сказки про кашу из топора: там солдат предложил накормить хозяйку кашей из топора. В итоге оказалось, что каша из топора отлично получается, если в неё добавить крупу, масло, и соль.
Так и проджект — отлично автоматизирует планирование ресурсов, если всё планирование делать вручную. Ну так я и без проджекта могу "планировать". Голый Excel не шибко хуже получается.

Здравствуйте, Sinclair, Вы писали:

G>>Не понятен. Спрашиваю. Ты не стесняйся, рассказывай.
S>Не вижу вопроса.

Ничего страшного, я тебе помогу.

Верну контекст, который ты удалил.

S>>Если вам непонятен пример из 2х задач — не стесняйтесь, спрашивайте.
G>Не понятен. Спрашиваю. Ты не стесняйся, рассказывай.

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

Так вот, я до сих пор этого не понимаю.

Пример твой по ссылке мне непонятен. Ты сам-то не стесняйся, расскажи.

G>>Как интересно. А зачем ты удаляешь из плана задачи, на которые уже потрачено время?

S>Я не удаляю из плана задачи, на которые уже потрачено время.
S>3. Уточнить задачу (частично выполненную), порезав её на более мелкие задачи.
S>Я про сценарий 3.

То есть, у тебя есть задача, на которую ты уже потратил время (твое "частично выполненная" означает, что ты потратил на нее время). В процессе ее "уточнения" она у тебя удаляется.

Тебе мой вопрос понятен? Зачем ты трогаешь задачи, над которыми уже начата работа, по факту задним числом редактируя историю проекта?

Ты сам никакого подвоха в этом, очевидно, не видишь, да?

Хорошо, переформулируем. Зачем ты начинаешь работу над черт знает какой задачей, до того, как спланировал работу над ней, и подумал, что это, и как ты ее будешь делать? Ты считаешь, это нормально, да?

Это у тебя основной юзкейс "уточняющего планирования" такой, да?

G>>>>"Поэтому" подразумевает наличие причинно-следственной связи.
S>>>Ну так если из четырёх вопросов на три ответ "он не для этого", а на один — "я не понимаю, в чём проблема", то какие ещё причинно-следственные связи нужны?

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

А вот эта ваша лирика —
G>>Кашу из топора без меня кушай.
S>Я на всякий случай напомню вам сюжет...
— не нужна.

Здравствуйте, Sinclair, Вы писали:

H>>Ну, вы всё верно поняли-то

Конечно не "закодить всё, протестить
H>>всё", но очень coarse-grained. И после утверждения оставить только для
H>>ретроспективных целей.
S>В том-то и дело, что все, с кем я общался, имеют ровно такой же опыт. И только гапертон внезапно проник в тайну MSProject. Ну так может быть это мы все идиоты? А он знает какой-то рецепт?

А что? Вполне может быть.

А может быть и по другому. Может оказаться, что не быть идиотом — недостаточно для того, чтобы понимать принципы сетевого планирования и основы классического управления проектами.

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

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

А вот тебе и тем, с кем ты говорил, вполне модет оказаться, что и не стыдно. Кто знает?

S>Вопрос ведь не в том, знаю ли я, что там есть Resource Leveling. Вопрос в том, чтобы из проджекта извлекать пользу.

Вопрос извлечения пользы из MS Project — это вопрос в том числе и того, знаешь ли ты, что там есть левелинг, и умеешь ли им пользоваться.

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

Здравствуйте, Gaperton, Вы писали:

G>Теперь видишь? На всякий случай напоминаю — ты хотел мне показать, каким образом ты непременно ошибешься в определении даты завершения проекта, выполнив планирование, глядя на гант-чарт, где явно выделен период проекта.
Цитирую:

"укладка труб" у вас будет зависеть от "копания траншей", которое само по себе занимает шесть месяцев. А на самом деле, можно выкопать сто метров, и уже начинать укладывать трубы, пока траншеекопатель фигачит себе дальше по графику. Итого, "крупномазочный" проект покажет срок окончания в 12 месяцев там, где на самом деле должно быть семь.

S>>Я не удаляю из плана задачи, на которые уже потрачено время.
S>>3. Уточнить задачу (частично выполненную), порезав её на более мелкие задачи.
S>>Я про сценарий 3.

G>То есть, у тебя есть задача, на которую ты уже потратил время (твое "частично выполненная" означает, что ты потратил на нее время). В процессе ее "уточнения" она у тебя удаляется.

G>Тебе мой вопрос понятен? Зачем ты трогаешь задачи, над которыми уже начата работа, по факту задним числом редактируя историю проекта?
Как зачем? Для того, чтобы отразить изменения окружения.
Вот у нас была одна задача — "сделать экспорт документа Word в PDF".
Над ней начал работать разработчик. В процессе работы оказалось, что задача существенно сложнее, чем казалось вначале.
Теперь мы знаем, что экспорт различных объектов модели ворда делается более-менее независимо; с экспортом простого текста мы разобрались (считаем, что он практически готов); есть обновлённые оценки для реализации экспорта различных объектов (таблиц, хидеров/футеров, встроенных объектов).
Возникает (возможно, неверное) желание отразить эту новую информацию в виде отдельных задач. Какие-то из них, возможно, будут дропнуты или отложены на будущие версии.
Что нам нужно сделать в проджекте, чтобы эту информацию отразить?

Как нам построить два-три варианта дальнейших планов, чтобы выбрать из них наилучший?
Может быть, нам нужно привлечь ещё разработчиков из других проектов, или сократить функциональность, или перенести сроки релиза?

Может, мы с самого начала сделали что-то не так? Что именно?

А лирику про то, что должен знать и уметь каждый PMP — оставьте.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Gaperton, Вы писали:

G>>Во-первых, и я могу добавить — "еще раз", потому, что до тебя это почему-то упорно не доходит, MS Project — это инструмент для ресурсного планирования, а не "рисовалка Гантт-чартов". В конце концов, предлагаю поверить мне на слово.
S>Что именно вы называете "ресурсным планированием"? Не надо мудрить — покажите пальцем.

Ты в форуме "управление проектами" находишься. Здесь употреблять профессиональную терминологию не зазорно, это не считается "мудрить". Ну знаешь, примерно как употреблять такие слова как "класс", "объект", или "замыкание" у вас, программистов.

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

G>>Во-вторых, если хоть кто-нибудь из моих тим-лидов или менеджеров проектов вот так всерьез решит, что инструментом для ответа на вопрос "как скорректировать план в соответствии с новой ситуацией" должен являться не его мозг, а какая нибудь (любая) тула — он будет уволен за профнепригодность.
S>О, я ждал этого ответа. Надо полагать, водителя, который просит поставить ему Навител с поддержкой информации о пробках надо тоже сразу увольнять за профнепригодность?

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

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

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

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

S>Поясню: я не жду, что проджект в ответ на "Вася взял больничный на неделю" прожект мне ответит голосом "отдай задачу "написать скрипт для импорта из csv" Пете, а задачу "проверить работспособность на vmware" придётся дропнуть".
S>Но я жду от инструмента планирования хоть какой-то помощи в принятии такого решения. Расскажите, как именно проджект помогает вашим тим-лидерам и менеджерам в таких вопросах.

Изволь. Ты скорректируешь рабочий график Васи, а PM-Tool (в роли которого, например, может выступать MS Project) тебе подскажет, как это повлияет на проект и его майлстоны. После чего, ты оценишь ситуацию, и подумаешь, надо ли тебе перебалансировать нагрузку. Если захочешь, тул подскажет тебе ситуацию по загрузке ресурсов, так, чтобы ты смог принять решение. И прикинет новый план.

Не, ну конечно отважные джедаи вроде тебя умеют все это делать в уме на тысячи задач и десятках людей, там, где железный MS Project не справляется. Вы ж не идиоты какие-нибудь вроде парней из PMI, Гапертона, или авторов MS Project. А я вот точно знаю, что не умею. Тупой.

G>>Во-первых, ведущих собаководов чуть больше, чем одна штука, и те, которые советуют ограничить задачи 4-мя часами, в меньшинстве.
G>>Во-вторых, для того, чтобы "не ошибиться на порядок", единиц планирования должно быть достаточное количество, и задача 4-х часовой длительности обеспечивает точность короткой, примерно недельной итерации/этапа/майлстона.
S>Меня начинает утомлять ваша негативная позиция. Я уже понял, что делаю всё неправильно, и понимаю всё неправильно. Давайте уже что-нибудь конструктивное.

А где здесь негативная позиция? Я объясняю тебе вовсе не то, что ты делаешь "все" неправильно, а детально показываю, в каких именно посылках ты ошибаешься, и почему. Для позитивного человека это должно быть ценно, не? Ну, там можно вопросы задать, или предметно поспорить, или в конце концов погуглить?

G>>В четвертых, собаководам известна масса интересных способов поднять точность оценок, не прибегая к нарезке на микрозадачи.
S>Давайте их в студию.

PERT Estimation и его варианты для учета рисков в прогнозах — просто и тупо. Методы, принимающие во внимание прогнозы объема и корелляции время-объем. Более сложные подходы, основанные на комплексе метрик, и их статистическом анализе (яркий пример — PSP/TSP). Методы, основанные на исторической калибровке, для компенсации тенденций к систематическим ошибкам в планировании (фокус-фактор, PROBE из PSP/TSP) Отдельно стоит отметить proxy-based estimation и его варианты. Функциональные точки. Ацкие параметрические модели, вроде COCOMO. Методы, основанные на статистическом моделировании. Совсем матанистые методы, основанные на динамическом моделировании с обратными связями.

Достаточно? Я бы предложил начать с PERT Estimation, и элементарного анализа корелляций время-объем. Никому не вредило пока.

S>>>Я вам привёл пример на пальцах про копание канавы, который вы проигнорировали.
G>>Честно говоря, я в разработке и управлении проектами куда лучше разбираюсь, чем в рытье канав. Ну ничего в канавах не смыслю. Прошу с пониманием отнестись.
S>Давайте прекратим обсуждать ваши (и мои) таланты, и перейдём к скучной банальщине: практике применения MS Project для проектной работы.
S>Проектная работа вся одинаковая — есть задачи, есть ресурсы, есть зависимости.

"Проектная работа", она, к сожалению, очень разная. Например, в смешанном цикле разработки ПО поддержка-развитие она практически отсутствует, и классические проектные методы работать перестают. Что не делает MS Project плохим и бесполезным продуктом "вообще" — классику все равно надо знать.

G>>а) Для грубого планирования "конвейерной" активности делают так. Ставится не только SS с задержкой, как у тебя, но и FF с задержкой. То есть, две связи, на каждой из них задержка.
S>Ну вот, видите как здорово — стоит перестать надувать щёки и умничать, как сразу появляется место для конструктивной беседы.

Вас никто не заставлял.

S>А исходя из чего определяются величины задержек для этих FF и SS? Как они потом корректируются?

Исходя из природы этих задержек. Для FF это, очевидно, будет, время укладки одной трубы, при условии, что мы настолько смелы, что предполагаем класть трубы немедленно после отрытия канавы. А для того, чтобы их посчитать адекватно, надо хорошо разбираться в рытье канав, и связанной с этим логистикой, а вовсе не в project management.

Никто не мешает оценить задержки вероятностно, при помощи PERT Estimation.

G>>Никаких проблем на практике это не вызовет — не переживай, никто трубу укладывать без канавы не будет.
S>Я переживаю не за это. Я переживаю за то, что у нас проект начинает разьезжаться с планом, а проджект ничего "такого" не показывает.

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

G>>При большом желании избежать описанной тобой логической трагедии, рытье траншеи бьется на две задачи, а не на две тысячи.
S>Почему на две? Какие две? Типа "вырыть канаву для первого сегмента трубы" и "вырыть канаву для всех остальных сегментов"?

Да, например, так.

S>Очень интересно. И как нам это поможет? Просирать проект мы можем начать и на второй неделе, после выполнения первой задачи.

Никак. Описанная тобой трагедия сугубо логическая, и происходит только в уме. Мы делаем это, чтобы успокоить твой ум. Так проще.

G>>б) Требуемая длительность задач в плане определяется практически потребным интервалом контроля. А не математическим маразмом.
S>Конкретно, как именно она определяется "практически потребным интервалом контроля"? Я понимаю, что вы мне хотите рассказать метод набегающей волны, но мне интересны не сферически обтекаемые фразы в вакууме, а практические рекомендации.

Боже упаси, какие волны. Простое правило, что длительности задач не должны быть больше периода контроля. Логично как бы, иначе контролировать нечего будет. Иначе на графики EV Plan, Burn-up Chart, Burn-down chart, и подобные им будет смотреть не интересно — методы, связанные с ними, станут плохо работать. И не сильно меньше, ибо это нафиг не нужно. Просто, в периоде должно оказаться достаточное количество задач, чтобы начали работать законы статистики. Вот и все. Ну, то есть, десятков уже достаточно.

Например, если у нас период контроля — неделя, то надо дробить все на задачи не больше недели, и длительность 2-3 дня является нормальной. То есть, стремиться специально дробить на задачи короче дня — не нужно, это даст болше геморроя, чем пользы.

G>>Да, представляете — это действие тоже выходит за рамки использования MS Project. Увольняться.

S>Понятно. Вы меня убедили — для планирования проектов проджект непригоден. Всё равно всю работу нужно делать руками.

Описанная тобой ситуация — дикая изначально, совсем не потому, что project плохой. А потому, что описанные тобой манипуляции планами из 4-х часовых задач в масштабе полугода, из соображений высокой точности планирования — идиотизм вне контекста project-а.

Касательно Project-а — он предназначен для составления календарных планов и ресурсного планирования (в условиях наличия проектов, а не потока работ, как у тебя), что есть маленькая и сугубо техническая часть планирования проектов. А для "планирования проектов" пригодна голова, потому, что план — это твой ответ на проектные риски.

G>>Боюсь ничего не поможет, дружище. Предлагаю бросить эту затею. Хотя нет — можно уволиться, это вполне может помочь.
S>То есть у вас выбор такой — либо мучиться с проджектом, либо уволиться? Прекрасно, прекрасно.

Вообще-то я говорю о твоем выборе. Но если тебе прям так интересен мой выбор — то он таков, что у нас в R&D компании Финам MS Project для планирования не применяется.

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

S>Завидую вашим тим лидам и проджект менеджерам.

Это пожалуйста.

S>Вот только мне удивительна такая позиция на форуме разработчиков.

Мы в форуме управления проектами, если чо.

S>Мы обсуждаем сложную область человеческой деятельности. Для разработчика софта естественная реакция — попробовать придумать или подобрать инструменты, которые позволяют автоматизировать рутину в этой деятельности.

Ага. Придумать или подобрать инструмент, вместо того, чтобы попытаться эту сложную область понять.

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

Вот смотришь так, и прям думаешь иногда — хорошо, все-таки, что я не разработчик.

S>Но ваша позиция — "нет, нужно уволить человека, неспособного делать всё это в уме". Удивительно.

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

Ясен хрен, надо такого уволить. Из элементарной логики следует. Замени его скриптом — толку будет столько же, а насколько меньше гундежа!

Здравствуйте, Sinclair, Вы писали:

G>>Теперь видишь? На всякий случай напоминаю — ты хотел мне показать, каким образом ты непременно ошибешься в определении даты завершения проекта, выполнив планирование, глядя на гант-чарт, где явно выделен период проекта.
S>Цитирую:
S>

S> "укладка труб" у вас будет зависеть от "копания траншей", которое само по себе занимает шесть месяцев. А на самом деле, можно выкопать сто метров, и уже начинать укладывать трубы, пока траншеекопатель фигачит себе дальше по графику. Итого, "крупномазочный" проект покажет срок окончания в 12 месяцев там, где на самом деле должно быть семь.

Какой ужас. Грубая ошибка в составлении плана.

Менеджер проекта в твоем примере профнепригоден — он демонстрирует полное неуменее правильно пользоваться зависимостями FF и SS (скорее всего, не догадывается об их существовании), чтобы правильно выразить свой замысел в виде сетевого графика.

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

Цитируй, пожалуйста, какой-нибудь другой пример. Желательно, относящийся к MS Project (мы же о нем говорим, да?), а не косякам составления сетевых графиков. Есть хоть, что зацитировать-то?

G>>То есть, у тебя есть задача, на которую ты уже потратил время (твое "частично выполненная" означает, что ты потратил на нее время). В процессе ее "уточнения" она у тебя удаляется.

G>>Тебе мой вопрос понятен? Зачем ты трогаешь задачи, над которыми уже начата работа, по факту задним числом редактируя историю проекта?
S>Как зачем? Для того, чтобы отразить изменения окружения.

Кабздец. Историю-то за что?!

S>Вот у нас была одна задача — "сделать экспорт документа Word в PDF".
S>Над ней начал работать разработчик. В процессе работы оказалось, что задача существенно сложнее, чем казалось вначале.
S>Теперь мы знаем, что экспорт различных объектов модели ворда делается более-менее независимо; с экспортом простого текста мы разобрались (считаем, что он практически готов); есть обновлённые оценки для реализации экспорта различных объектов (таблиц, хидеров/футеров, встроенных объектов).
S>Возникает (возможно, неверное) желание отразить эту новую информацию в виде отдельных задач. Какие-то из них, возможно, будут дропнуты или отложены на будущие версии.
S>Что нам нужно сделать в проджекте, чтобы эту информацию отразить?

Задачу, над которой начали работать, не трогать, создать рядом новые задачи. Если текущая задача, на которую потратили время, потеряла смысл — завершить ее немедленно, а не удалять. Так будет методологически верно.

S>Как нам построить два-три варианта дальнейших планов, чтобы выбрать из них наилучший?

Сделать эти варианты, каждый раз выполняя leveling. Самое тупое — в разные файлы сохранить. Сравнить ключевые параметры (например, даты основных майлстонов).

S>Может быть, нам нужно привлечь ещё разработчиков из других проектов, или сократить функциональность, или перенести сроки релиза?

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

S>Может, мы с самого начала сделали что-то не так? Что именно?

Ты смеешься штоли?

Ты всерьез веришь в то, что тебе прожект поможет ответ на этот вопрос найти?

S>А лирику про то, что должен знать и уметь каждый PMP — оставьте.

Элементарные вещи, которые должен знать каждый руководитель проектов — в этом форуме не лирика. Название форума посмотри

Здравствуйте, Gaperton:

Всё, в целом, понятно. Излечитесь от звёздной болезни — приходите, пообщаемся.

S>В целом, я готов простить проджекту неумение помогать менеджеру с такими вопросами. Но никаких других инструментов я не знаю!
S>В сказки про ексель я тоже не верю. Потому что в нём ещё труднее, чем в проджекте оперативно ответить на вопрос вице-президента "а что будет с проектом, если мы по-быстрому всунем в него фичу ХХХ, которую попросил наш большой друг?".

В Excel нет никаких проблем сделать sheet, который будет на такие вопросы отвечать. Да и основная проблема будет вовсе не в том, чтобы учесть зависимости, а в том, чтобы на _раннем_ этапе оценить затраты _позднего_ внедрения какой-либо фичи.
К вам тов. Кригиш приезжал в Новосиб? Учит ~~сраму~~ SCRUM'у? Оно хоть не относится непосредственно к обсуждаемым инструментам, но дает пищу для размышлений, почему предсказанные сроки не выдерживаются. И вообще, про подход "please lie to me" в целом.

Что до MS Project, мне пока не довелось увидеть этот инструмент, используемый с толком и по назначению.

S> В нормальном софтостроении не бывает релизов раз в неделю.

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

S>Давайте разберёмся. Ведущие собаководы рекомендуют при оценках не делать задачи длиннее 4х часов. Иначе вы рискуете ошибиться в оценке на порядок.

Дело не в том, что есть риск ошибиться на порядок — он и при оценке коротких задач примерно такой же (вспоминай все тот же cone of uncertainty). Хитрость лишь в том, что при мелких задачах уровень ошибки оценок довольно быстро становится виден (в виде фокус-фактора, например), и можно уже по прошествии первых итераций уверенно оценить скорость выполнения фич. На основании чего оптом скорректировать все оценки, а также пересмотреть feature list на релиз.

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

А, ну вот, ты это уже тоже описал. Зачем тогда продолжаешь про "2000 задач"? Логично (и достаточно) принять только тот уровень детализации, который нужен на данном этапе.

S>Отсюда мы и получаем порядка 2000 задач, из которых состоит проект для маленькой команды, занимающий примерно шесть месяцев.
S>При этом для согласования проекта нужно оценить не 2000 задач, а примерно 6000, потому что две трети в итоге будут выкинуты в результате многочисленных болезненных обсуждений. Т.к. хотят все сразу всего, а ресурсов есть только для 30%.
S>Что вы предлагаете с этим делать? Или это тоже "выходит за рамки использования MS Project"?

Это у тебя специфика компании говорит

Те самые "порядка 2000 задач" в основном возникли из мегадревних документов, корни которых тянутся еще годам так 2000м

Реально на первых этапах достаточно оценить 40-50 разных крупномасштабных фич, причем оценить их относительно друг друга (ну или в ideal man hours/days/months/years, это все равно будет относительной оценкой).

S>Простите, а что мне поможет понять, для каких ситуаций он предназначен? Пока что я видел на практике только одно предназначение — один раз в начале проекта нарисовать красивый водопадный план, состоящий из псевдозадач типа "закодить всё, протестировать всё", получить аппрувал, а потом выбросить его и больше никогда не возвращаться.

Теоретически, Project может делать все то, что ты описал (в т.ч. 6000 задач и ресурсов). Практически, действительно, у меня ровно те же ощущения от того, что я видел (хотя кроме одной общей конторы я успел поработать и в других крупных местах).

G>Ты сам никакого подвоха в этом, очевидно, не видишь, да?

Это у тебя основной юзкейс "уточняющего планирования" такой, да?

Гм, а что у вас в практике такого никогда не случалсь? Что программист, начав выполнять задачу, не натыкался на неожиданные грабли со стороны библиотек/ядра ("платформы", в терминах Sinclair), и не приходилось разбивать текущую задачу на некоторое количество конечных пунктов (подзадач)?

SD>Гм, а что у вас в практике такого никогда не случалсь? Что программист, начав выполнять задачу, не натыкался на неожиданные грабли со стороны библиотек/ядра ("платформы", в терминах Sinclair), и не приходилось разбивать текущую задачу на некоторое количество конечных пунктов (подзадач)?

А, надо было сначала прочитать весь тред. На этот вопрос Gaperton уже ответил. Прошу прощения.

Вообще, мне видится, что разница в подходах Sinclair и Gaperton обусловлена разным "расстоянием" до фактических работяг.

Господа, поправьте меня, если я ошибась.
Gaperton стоит на уровень абстракции выше (мета-менеджер, гм), и работает он не непосредственно с девелоперами, а с некоторыми прокси в виде менеджеров. Соответственно, для Gaperton разработчики (и вообще люди) представляют собой обезличенные "ресурсы". Вполне, кстати, в духе классической теории.
Sinclair же непосредственно (без proxy) работает с разработчиками, тестировщика и т.п.. Посему обезличивание и "оресурсеризация" людей не происходят.

Gaperton работает с графиками, цифрами, теориями и иллюзиями. Sinclair — с конкретными планами и людьми. У вас не может быть единого представления о том, что и как правильно, потому что вы занимаетесь разными проблемами. Когда вы пытаетесь "продать" другу другу инструменты, подходящие для вашей работы, получается непонимание.

Здравствуйте, Gaperton, Вы писали:

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

Я понимаю, что вам скучно с нами общаться, но... (не нужно просить меня продолжить. Я все еще высоко ценю вас как специалиста, но последние лет 5 в общении вы совершенно несносны).

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Sinclair, Вы писали:

Привет.
Один вопрос: неужели ты ничего не вынес из этой "беседы" с Гапертоном?
ИХМО, два последних поста были хороши.

S>Излечитесь от звёздной болезни — приходите, пообщаемся.
У Гапертона давно уже такой стиль общения. Толи ему скучно азы в сотый раз рассказывать, толи время свое не хочет тратить, толи еще что. Я хз. Но то что он классный спец, эт факт

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Aikin, Вы писали:

A>Один вопрос: неужели ты ничего не вынес из этой "беседы" с Гапертоном?
A>ИХМО, два последних поста были хороши.
Почему же — вынес. Вынес две вещи:
1. с тех пор, как я бросил проджект менеджмент, люди придумали много интересных теорий (большинство из которых не очень хорошо применимы на практике).
2. MS Project для процесса собственно управления проектом полезен примерно в тех пределах, в которых я и ожидал. То есть — на этапе планирования.

Здравствуйте, Sinclair, Вы писали:

A>>Один вопрос: неужели ты ничего не вынес из этой "беседы" с Гапертоном?
A>>ИХМО, два последних поста были хороши.
S>Почему же — вынес. Вынес две вещи:
S>1. с тех пор, как я бросил проджект менеджмент, люди придумали много интересных теорий (большинство из которых не очень хорошо применимы на практике).
Это в тебе говорит запал спорщика. PERT хорош, "историческая калибровка" тоже. Это из того что я знаю.

Весь следующий кусок утянул для последующего анализа:

PERT Estimation и его варианты для учета рисков в прогнозах — просто и тупо. Методы, принимающие во внимание прогнозы объема и корелляции время-объем. Более сложные подходы, основанные на комплексе метрик, и их статистическом анализе (яркий пример — PSP/TSP). Методы, основанные на исторической калибровке, для компенсации тенденций к систематическим ошибкам в планировании (фокус-фактор, PROBE из PSP/TSP) Отдельно стоит отметить proxy-based estimation и его варианты. Функциональные точки. Ацкие параметрические модели, вроде COCOMO. Методы, основанные на статистическом моделировании. Совсем матанистые методы, основанные на динамическом моделировании с обратными связями.

Достаточно? Я бы предложил начать с PERT Estimation, и элементарного анализа корелляций время-объем. Никому не вредило пока.

S>2. MS Project для процесса собственно управления проектом полезен примерно в тех пределах, в которых я и ожидал. То есть — на этапе планирования.
Вопрос вот в чем: что в твоем понимании "этап планирования".

Если этап самом вначале работ, то я вынес другое. Вот цитата:

MS Project — это инструмент для ресурсного планирования, а не "рисовалка Гантт-чартов".

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

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

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Aikin, Вы писали:

S>>1. с тех пор, как я бросил проджект менеджмент, люди придумали много интересных теорий (большинство из которых не очень хорошо применимы на практике).
A>Это в тебе говорит запал спорщика. PERT хорош, "историческая калибровка" тоже. Это из того что я знаю.
При этом сам Гапертон PERT критикует. Вообще, PERT решает всего лишь одну проблему: убирает систематическую ошибку из оценок, связанную со степенью оптимизма оценщика. То есть если у нас есть Вася, который склонен репортить "оптимистичную" оценку, и Петя, который склонен репортить "пессимистичную" оценку, то мы можем получить различия в три раза для одного и того же проекта, в зависимости от того, кому из них мы поручим оценку. Теоретически, PERT частично решит эту проблему (хотя из-за того, что они будут указывать разные значения для M, окончательная оценка всё ещё будет различаться).
При этом PERT никак не спасает нас от ситуации, когда мы тупо забываем про какую-то часть работы. Например, про выполнение общих требований к логгированию, предъявляемых ко всем компонентам. Чтобы понять границы применимости PERT, нужно понимать, откуда вообще берётся разница между O и P оценками.

Историческая калибровка, если я правильно понимаю, опирается на данные по предыдущим проектам, где можно сравнить предварительные оценки с фактически потраченным временем.
В этом MS Project тоже нихрена никак не помогает. Нету в нём нормальных функций сравнения плана с фактом. У экономистов есть, скажем, такая штука: если я планировал купить линолеум для ремонта за 10000р, а купил за 12000р, у них есть простой способ сказать, почему так получилось. В том смысле, что они могут отделить изменения, связанные с объёмом, от изменений, связанных с ценой.
В проджекте же мы имеем один список задач на дату 1, и совсем-совсем другой список задач на дату 2.
Понять, как относятся задачи из этих списков, невозможно (то есть только вручную, долго и мучительно).
A>Вопрос вот в чем: что в твоем понимании "этап планирования".
Тот этап, когда мы рисуем гантт-чарт и пытаемся сами себя убедить, что успеваем сделать нужную функциональность в нужные даты.

A>Если этап самом вначале работ, то я вынес другое. Вот цитата:
A>

MS Project — это инструмент для ресурсного планирования, а не "рисовалка Гантт-чартов".

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

Ключевое слово выделено. В конце работ поздно предварительный вариант графика рисовать.

S>Теоретически, PERT частично решит эту проблему (хотя из-за того, что они будут указывать разные значения для M, окончательная оценка всё ещё будет различаться).
S>При этом PERT никак не спасает нас от ситуации, когда мы тупо забываем про какую-то часть работы.

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

S>Историческая калибровка, если я правильно понимаю, опирается на данные по предыдущим проектам, где можно сравнить предварительные оценки с фактически потраченным временем.

Не обязательно на предыдущие.

S>В этом MS Project тоже нихрена никак не помогает. Нету в нём нормальных функций сравнения плана с фактом.

Я бы не был столь категоричным. Может и нет, а может и есть. Я в Project не эксперт, и ты, КМК, тоже. Вот как раз тут Gaperton мог бы помочь с экспертизой, буде таковая в наличии, есть у него свободное время, и отрыв его от реальности (через прокси-менеджеров) не достиг точки невозврата.

Здравствуйте, SkyDance, Вы писали:

SD>Для решения этой проблемы используются другие методы. Их тоже легион. Например, популярные в последнее время planning poker'ы, в которых участвует вся команда разработки. Петя не вспомнит, Вася забудет, но Оля, девочка дотошная, не пропустит. Это если что-то не экстремально большое оценивается. В противном случае, опять имеем слона, которого нужно есть по частям.
Ключевой момент во всех этих покерах и прочих преферансах — отказ от "трёх цифр" и анализ состава задачи.
Именно про него я и писал, в ответ на что получил "для периода в неделю достаточно задач размером в неделю". Штоп я так жил!

SD>Не обязательно на предыдущие.
А на какие?

SD>Я бы не был столь категоричным. Может и нет, а может и есть. Я в Project не эксперт, и ты, КМК, тоже. Вот как раз тут Gaperton мог бы помочь с экспертизой, буде таковая в наличии, есть у него свободное время, и отрыв его от реальности (через прокси-менеджеров) не достиг точки невозврата.
Я буду очень рад ошибаться, но чудес не бывает. Проджект я исползал вдоль и поперёк в бытность проджект менеджером.

S>Ключевой момент во всех этих покерах и прочих преферансах — отказ от "трёх цифр" и анализ состава задачи.

Гм, а пессимистичные/оптимистичные/вероятные оценки разве не предполагают оный анализ? Я хоть и не считаю PERT сколь-нибудь серьезным способом реалистичной оценки длительности, но до абсурда-то доводить тоже не хочу.
В конце концов, может, у Gaperton'а взаимозаменяемость команд дошла до такого уровня, что у него есть команды оптимистов, пессимистов и реалистов. Он каждую просит оценить (как они там внутри сделают, их проблемы, хоть в преферанс, действительно).

SD>>Не обязательно на предыдущие.
S>А на какие?

Мы все еще про upfront plan, или про его коррекцию в дальнейшем? Для upfront вариантов не видно. Я о текущих коррекциях.

S>Я буду очень рад ошибаться, но чудес не бывает. Проджект я исползал вдоль и поперёк в бытность проджект менеджером.

Дык ведь его допиливают же. А с тех пор сколько времени уж прошло.

Здравствуйте, SkyDance, Вы писали:

G>>Ты сам никакого подвоха в этом, очевидно, не видишь, да?

Это у тебя основной юзкейс "уточняющего планирования" такой, да?

SD>Гм, а что у вас в практике такого никогда не случалсь?

Конечно случалось. И было время, когда я точно так же ничего в этом не смыслил, и планы регулярно "разъезжались". Я ведь планы далеко не с момента рождения составлять научился.

SD>Что программист, начав выполнять задачу, не натыкался на неожиданные грабли со стороны библиотек/ядра ("платформы", в терминах Sinclair), и не приходилось разбивать текущую задачу на некоторое количество конечных пунктов (подзадач)?

"Неожиданные грабли со стороны платформы" называются техническими рисками, и их наличие — это норма, то, что отличает проектную деятельность от производства. Они могут привести к увеличению времени, или даже к изменению подхода. Анализировать возможные риски заранее, и строить план с их учетом — и есть главная работа руководителя, а вовсе не рисование чартов.

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

А вот к "разбиению задачи на подзадачи" это не приводит. Я понимаю, что это сейчас для вас звучит странно. Чтобы оно было не так странно, надо понимать принцип, как правильно выделять задачи. Это, в общем, разговор долгий, но если кратко и о главном — всегда начинать надо с детального анализа критерия завершения задачи. Ответа на вопрос "как я проверю, что задача завершена". А вовсе не с фантазий о том, что ты будешь делать в процессе.

И если этот критерий звучит как "программист Вася сказал, что написал класс Х, и осталось только отладить", то такую задачу нет никакого смысла выделять.

Здравствуйте, SkyDance, Вы писали:

SD>Господа, поправьте меня, если я ошибась.

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

Не надо так делать.

Здравствуйте, Aikin, Вы писали:

A>Я понимаю, что вам скучно с нами общаться, но...

Да, скучно. Это правда.

A> (не нужно просить меня продолжить. Я все еще высоко ценю вас как специалиста, но последние лет 5 в общении вы совершенно несносны).

Опять переход наличности.

Дорогой Айкин, я вас не знаю, ваша личность меня не интересует, и мне совершенно все равно, что вы думаете по поводу моей. Как личности мне интересны те люди, кого я знаю, и не надо ко мне с этим лезть.

Я понимаю, что это для вас может быть совершенно невыносимо, но такова жизнь. Прошу понять и простить.

Здравствуйте, SkyDance, Вы писали:

SD>В конце концов, может, у Gaperton'а взаимозаменяемость команд дошла до такого уровня, что у него есть команды оптимистов, пессимистов и реалистов. Он каждую просит оценить (как они там внутри сделают, их проблемы, хоть в преферанс, действительно).

Нет, не дошла. Более того, какие команды у Гапертона — к разговору не имеет ни малейшего значения.

Что до сути PERT-подобных методов — она состоит в представлении о длительности задачи (и всего проекта) как о случайной величине, и отказе от единственной оценки длительностей в пользу рамочной "от-до".

Речь идет не о пессемизме или оптимизме, а о признании факта, что мы точно не знаем точного срока решения, и в отказе от попыток его "угадать". Вместо этого, акцент смещается на анализ факторов неизвестности (рисков), которые и дают нам в итоге вариацию оценок.

Разумеется, PERT не единственный метод, основанный на описанной выше ментальности, но он однозначно самый простой. И само собой, PERT ничего не говорит о процессе получения ошибки. Это не более чем математический прием для обработки ее результатов. Поэтому, противопоставлять "покеры" рамочным оценкам — глупо.

Здравствуйте, Gaperton, Вы писали:

G>Нет, не дошла. Более того, какие команды у Гапертона — к разговору не имеет ни малейшего ~~значения~~.
отношения.

G>Разумеется, PERT не единственный метод, основанный на описанной выше ментальности, но он однозначно самый простой. И само собой, PERT ничего не говорит о процессе получения ~~ошибки~~. Это не более чем математический прием для обработки ее результатов. Поэтому, противопоставлять "покеры" рамочным оценкам — глупо.
оценки.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Aikin, Вы писали:

S>>>1. с тех пор, как я бросил проджект менеджмент, люди придумали много интересных теорий (большинство из которых не очень хорошо применимы на практике).
A>>Это в тебе говорит запал спорщика. PERT хорош, "историческая калибровка" тоже. Это из того что я знаю.
S>При этом сам Гапертон PERT критикует.

Сам факт критики, что кто-то что-то критикует, не имеет ни малейшего значения — из него не следует ровным счетом ничего. Имеет значение — за что, и как.

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

S>Вообще, PERT решает всего лишь одну проблему: убирает систематическую ошибку из оценок, связанную со степенью оптимизма оценщика. То есть если у нас есть Вася, который склонен репортить "оптимистичную" оценку, и Петя, который склонен репортить "пессимистичную" оценку, то мы можем получить различия в три раза для одного и того же проекта, в зависимости от того, кому из них мы поручим оценку. Теоретически, PERT частично решит эту проблему (хотя из-за того, что они будут указывать разные значения для M, окончательная оценка всё ещё будет различаться).

PERT решает совсем другую проблему. Оперируя рамочной оценкой, он делает закладку оценщика на риски явной, заставляя оценщика отвечать на два понятных ему вопроса, в ответах на которые он уверен. А не играть в глупую угадайку "назови число которое мне нравится", превращая разговор о сроках в базарный торг, или азартную игру.

S>При этом PERT никак не спасает нас от ситуации, когда мы тупо забываем про какую-то часть работы.

Это вопрос формулировки самого задания, а не метода оценки его срока. PERT Estimation относится только к подходу к оценке срока.

А вот другой элемент методологии PERT — так называемые "события" (что по сути есть критерии завершения задачи), помогают "не забыть". Этот элемент PERT очень важен, но почему-то игнорируется подавляющим большинством менеджеров. 99% попросту не в курсе его существования.

Здравствуйте, Sinclair, Вы писали:

S>Всё, в целом, понятно. Излечитесь от звёздной болезни — приходите, пообщаемся.

К сожалению, я не вижу никакого "профита" для себя в общении с Вами на эти темы, уважаемый Синклер. Оно не дает мне абсолютно ничего нового. Не ставит никаких интересных вопросов, над которыми можно было подумать. Не думаете же Вы всерьез, что стенания в духе "MS Project говно", или "может быть, я идиот, а Гапертон в самом деле может что-то уметь, что не умею я" (вы когда этого говорили, видимо, считали это тонкой иронией) — это что-то новое, интересное, или конструктивное, правда?

Поэтому, мне совершенно не зачем к вам "приходить". Понимаете?

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

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

Просто всего знать в принципе невозможно, и не надо этого стесняться. Понимаете?

Вот когда поймете — приходите, пообщаемся.

Здравствуйте, SkyDance, Вы писали:

G>>Ошибаешься. Вместо того, чтобы думать о предмете дискуссии, ты переводишь разговор на личности Синклера и Гапертона.

SD>Личности здесь не при чем. Вы предмет дискуссии рассматриваете с разных сторон. Sinclair с чисто практический, без proxy, реалистичные проблемы конкретного менеджера. Gaperton — теоретический подход, явно не последнего уровня в иерархии. Иными словами, вы разные проблемы решаете.

Предметом обсуждения является использование MS Project, и стоящая за ним теория сетевого планирования. Ей, этой теории, совершенно плевать на меня с Синклером, ее не интересуют наши должности, места в иерархии, и наши проблемы с подходами. Она сама — это подход.

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

G>>Разумеется, PERT не единственный метод, основанный на описанной выше ментальности, но он однозначно самый простой. И само собой, PERT ничего не говорит о процессе получения ошибки. Это не более чем математический прием для обработки ее результатов. Поэтому, противопоставлять "покеры" рамочным оценкам — глупо.

SD>О каком противопоставлении идет речь? Как можно противопоставлять шестерню коробке передач?

О замеченном мной противопоставлении, которое идет в разговоре. Его делаете не Вы, а Синклер.

SD>Вашу статью (о модификации PERT?) не читал, извините. Поэтому не готов обсудить "два вопроса".

Моя модификация к разговору не относится. Я не про свою статью писал, а про основы общеизвестного PERT. Вопросы — "раньше точно не справлюсь", "за это время точно успею". Обсуждать, ИМХО, тут особо нечего.

Здравствуйте, Sinclair, Вы писали:

S>Вот только мне удивительна такая позиция на форуме разработчиков. Мы обсуждаем сложную область человеческой деятельности. Для разработчика софта естественная реакция — попробовать придумать или подобрать инструменты, которые позволяют автоматизировать рутину в этой деятельности.
S>Но ваша позиция — "нет, нужно уволить человека, неспособного делать всё это в уме". Удивительно.

Кстати, да, удивительно что при всех недостатках MS Project он до сих пор оастается самым популярным инструментом для планирвания. Почему до сих пор никто не сделал более удобной и функциональной альтернативы? Хотя какзалось бы business opportunity налицо.

Здравствуйте, Аноним, Вы писали:

S>>Вот только мне удивительна такая позиция на форуме разработчиков. Мы обсуждаем сложную область человеческой деятельности. Для разработчика софта естественная реакция — попробовать придумать или подобрать инструменты, которые позволяют автоматизировать рутину в этой деятельности.
S>>Но ваша позиция — "нет, нужно уволить человека, неспособного делать всё это в уме". Удивительно.

А>Кстати, да, удивительно что при всех недостатках MS Project он до сих пор оастается самым популярным инструментом для планирвания. Почему до сих пор никто не сделал более удобной и функциональной альтернативы? Хотя какзалось бы business opportunity налицо.

Почему не сделали-то?

Сделали, они есть. Под мак есть сразу две — Merlin и OmniPlan. Каждая из них — значительно лучше прожекта. Под PC альтернатив еще больше, среди них я лично смотрел как минимум два пакета российской разработки. Я лично, когда требуется прикинуть сложный календарный план, использую не Project, а OmniPlan.

Но методологии за ними всеми стоят совершенно одинаковые, и ни одна из "альтернатив" не решит проблем Синклера. Вы совершенно напрасно ждете от разных тулов какого-то чуда. Все равно надо хорошо знать сетевое планирование, чтобы извлекать из всех них пользу, и никакая волшебная тулза от необходимости его понимать не избавит. А Project, на самом деле, достаточно хорош, потому и популярен.

Здравствуйте, Gaperton, Вы писали:

A>>Я понимаю, что вам скучно с нами общаться, но...
G>Да, скучно. Это правда.
Ну вот, спасибо за честный ответ на личный вопрос

A>> (не нужно просить меня продолжить. Я все еще высоко ценю вас как специалиста, но последние лет 5 в общении вы совершенно несносны).
G>Опять переход наличности.
Да, так и есть. И что?

G>Дорогой Айкин, я вас не знаю, ваша личность меня не интересует, и мне совершенно все равно, что вы думаете по поводу моей. Как личности мне интересны те люди, кого я знаю, и не надо ко мне с этим лезть.
G>Я понимаю, что это для вас может быть совершенно невыносимо, но такова жизнь. Прошу понять и простить.
Да мне побоку. Не переживайте. Я рассматриваю вас (ну скажем ваш опыт и знания) как источник знаний для меня. Личность же ваша меня интересует исключительно в этом разрезе. Да и то потому, что выковырять из ваших постов рельно полезное стало очень сложно.

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Sinclair, Вы писали:

S>>>1. с тех пор, как я бросил проджект менеджмент, люди придумали много интересных теорий (большинство из которых не очень хорошо применимы на практике).
A>>Это в тебе говорит запал спорщика. PERT хорош, "историческая калибровка" тоже. Это из того что я знаю.
S>При этом сам Гапертон PERT критикует. Вообще, PERT решает всего лишь одну проблему: убирает систематическую ошибку из оценок, связанную со степенью оптимизма оценщика...
Нет, не оно. Систематическая ошибка устраняется как раз "исторической калибровкой". Вася обычно завышает оценку в 1,5 раза, Петя же обычно занижает ее в 2 раза -- делим Васину оценку на 1,5 , а Петину умножаем на 2.

ПЕРТ, это когда вы берете риски и вкладываете их в оценку. 1ая оценка -- риски не сыграли, 3я оценка -- риски сыграли, как получить 2ю оценку перта... я не совсем до конца понимаю (прикидываю примерно какова вероятность что риск сыграет и учитываю только эту долю риска. Это если околонаучно. Обычно же я просто оцениваю это число примерно).
В итоге получаем оценку реально учитывающую риски, а не что-то взятое с потолка. Причем у нас есть корридор оценки, а не одно число. И в отличии от одной цифры вы всегда можете ответить на вопрос в каком случае мы закончим ближе к началу корридора, а в каком случае ближе к концу.

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

A>>Вопрос вот в чем: что в твоем понимании "этап планирования".
S>Тот этап, когда мы рисуем гантт-чарт ~~и пытаемся сами себя убедить, что успеваем сделать нужную функциональность в нужные даты~~.
Мы ганчарт можем рисовать на протяжении всего проекта. Постоянно корректируя план. У нас весь провект состоит из "этапа планирования"?
S>Ключевое слово выделено. В конце работ поздно предварительный вариант графика рисовать.
Что такое конец работ и поздно?
Если мы просрочили проект, но он важен для заказчика -- вам дадум время, чтобы "поздно" стало "достаточно".
Если мы сделали 90% проекта, но до конца осталось около года -- это еще поздно или нет?

В любом случае, при изменении ситуации на проекте неплохо было бы узнать как эффективнее использовать имеющиеся ресурсы для реализации нужного функционала.
MS Project и гант чарт, ИХМО, для этого хорошо подходят. Банально потому что гант чарт нагляден, а MS Project умеет его перерисовывать если ты изменил какие-то условия (например поставил Васю делать конкретную задачу).
Чем сложнее построить гант чарт -- тем реже производится оценка текущего плана работ и его коррекция.
С этим-то ты согласен?

S>В этом MS Project тоже нихрена никак не помогает. Нету в нём нормальных функций сравнения плана с фактом.
S>В проджекте же мы имеем один список задач на дату 1, и совсем-совсем другой список задач на дату 2.
S>Понять, как относятся задачи из этих списков, невозможно (то есть только вручную, долго и мучительно).
https://www.google.ru/search?q=ms+project+diff --> http://www.techrepublic.com/i/tr/cms/contentPics/r00620001124knm01_04.gif
А чтобы дифы выдавали полезную инфу нужно менять план не "от балды", а с умом.
Это как с сорцами. Можно так менять код чтобы потом рвать на себе волосы во время мержа, а можно сделать мерж как можно проще и безопаснее. Достаточно следовать некоторым правилам.

Ты, похоже, опять хочешь от проджекта того, для чего он не предназначен.

СУВ,

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Gaperton, Вы писали:

G>А вот к "разбиению задачи на подзадачи" это не приводит. Я понимаю, что это сейчас для вас звучит странно. Чтобы оно было не так странно, надо понимать принцип, как правильно выделять задачи. Это, в общем, разговор долгий, но если кратко и о главном — всегда начинать надо с детального анализа критерия завершения задачи. Ответа на вопрос "как я проверю, что задача завершена". А вовсе не с фантазий о том, что ты будешь делать в процессе.
G>И если этот критерий звучит как "программист Вася сказал, что написал класс Х, и осталось только отладить", то такую задачу нет никакого смысла выделять.

Вот очередная жемчужина (для меня). Ответ только для того, чтобы она не затерялась.

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Sinclair, Вы писали:

S>Именно про него я и писал, в ответ на что получил "для периода в неделю достаточно задач размером в неделю". Штоп я так жил!
Не хочется быть толкователем Гапертона, но ты эту фразу ни к месту приплел.
Тебе сказали, что для составления годового плана не нужно делить задачи на таски по 4 часа. Для периода в год подходят задачи объемом в месяцах. Для месяца -- в днях и неделях.
Опять же, не нужно забывать про уточнение: год/месяц -- это не срок проекта, а период контроля (прим.: для меня это ново и требует переосмысления, но хорошо ложиться на знания и опыт).

Ясен красен, что с подходом в нарезании тасков по 4 часа ты закопался в их количестве.

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Aikin, Вы писали:

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

Например, если у нас период контроля — неделя, то надо дробить все на задачи не больше недели

A>Опять же, не нужно забывать про уточнение: год/месяц -- это не срок проекта, а период контроля (прим.: для меня это ново и требует переосмысления, но хорошо ложиться на знания и опыт).
Период контроля — не постоянная планка. У нас есть планы на три года, год, полгода, месяц, и на неделю.
Я интерпретирую идею так, что долговременные планы мы можем выражать в задачах крупного масштаба (там и неопределённость высокая), а по мере приближения мы уточняем планирование, уменьшая гранулярность планирования.
A>Ясен красен, что с подходом в нарезании тасков по 4 часа ты закопался в их количестве.
Ну конечно же я не закопался. Это был гипотетический пример, который мы обсуждали с тренером по MS Project, когда я ходил на курсы. Тренер сначала важничал (говорил, что мы пролетаем по срокам, т.к. идиоты и делаем слишком крупные задачи), потом умничал (говорил, что для избежания нарезки 2000 задач в начале надо использовать метод набегающей волны), а потом тупо соврал — сказал, что в enterprise версии MS Project есть сравнивалка проектов, которая позволяет нормально посмотреть, что изменилось за год.

Здравствуйте, Aikin, Вы писали:

G>>А вот к "разбиению задачи на подзадачи" это не приводит. Я понимаю, что это сейчас для вас звучит странно. Чтобы оно было не так странно, надо понимать принцип, как правильно выделять задачи. Это, в общем, разговор долгий, но если кратко и о главном — всегда начинать надо с детального анализа критерия завершения задачи. Ответа на вопрос "как я проверю, что задача завершена". А вовсе не с фантазий о том, что ты будешь делать в процессе.
G>>И если этот критерий звучит как "программист Вася сказал, что написал класс Х, и осталось только отладить", то такую задачу нет никакого смысла выделять.

A>Вот очередная жемчужина (для меня). Ответ только для того, чтобы она не затерялась.

Поищи у меня в блоге по "декларативное планирование", там тема раскрыта подробнее

. На этом целый метод построен. Я про него доклад делал на одном из SoftwarePeople.

Здравствуйте, Sinclair, Вы писали:

A>>Ясен красен, что с подходом в нарезании тасков по 4 часа ты закопался в их количестве.
S>Ну конечно же я не закопался. Это был гипотетический пример, который мы обсуждали с тренером по MS Project, когда я ходил на курсы.

Молодец.

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

Так держать

Здравствуйте, Aikin, Вы писали:

G> Да мне побоку.

Я знаю. Именно поэтому ты в моем журнале комментарии оставлять и не можешь.

G>>всегда начинать надо с детального анализа критерия завершения задачи. Ответа на вопрос "как я проверю, что задача завершена". А вовсе не с фантазий о том, что ты будешь делать в процессе.
A>Вот очередная жемчужина (для меня). Ответ только для того, чтобы она не затерялась.

Прочитайте книгу Agile Estimation and Planning, там довольно много про DoD (Definition of Done, не Department of Defense). Тогда, возможно, вам и вовсе откроются "тайные знания", не просто жемчужины, а таки бриллиантовая шахта.

S> а потом тупо соврал — сказал, что в enterprise версии MS Project есть сравнивалка проектов, которая позволяет нормально посмотреть, что изменилось за год.

Кстати, а она есть, сранивалка такая? Я не видел, но я, опять же, не эксперт.
Кто вас обучал проджекту?

Здравствуйте, Sinclair, Вы писали:

S>При этом сам Гапертон PERT критикует. Вообще, PERT решает всего лишь одну проблему...

И кстати, хочу обратить твое внимание на один момент.

Из всех известных человечеству на данный момент "не матанистых" методов оценки сроков, PERT — единственный, который в принципе позволяет учесть риски в прогнозе сроков. В этом его огромная практическая ценность. "Продвинутые" методы, основанные на метриках, включая их апофеоз и концентрат, доведенный до маразма — PSP/TSP, этого сделать не позволяют.

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

Огромный практический (не теоретический) плюс PERT Estimation состоит в том, что он настолько прост, что любой человек в состоянии его применить в excel или на бумажке. Это драматически увеличивает практические шансы на то, что ты его в нужный момент применишь, и применишь его правильно.

И самое главное — ты на практике сможешь его внедрить, в нужный момент объяснив подчиненным, и немедленно получив результат. С "матанистыми" методами это не пройдет — потому они и остаются теорией или игрушкой. Кому нахрен нужны точные методы, которые невозможно использовать в практической экстремальной ситуации?

Я тебе буквально как врач говорю.

А врачам надо верить, как себе

Здравствуйте, Gaperton, Вы писали:

G>Из всех известных человечеству на данный момент "не матанистых" методов оценки сроков, PERT — единственный, который в принципе позволяет учесть риски в прогнозе сроков. В этом его огромная практическая ценность. "Продвинутые" методы, основанные на метриках, включая их апофеоз и концентрат, доведенный до маразма — PSP/TSP, этого сделать не позволяют.

Впрочем, я в свое время разработал метод, который объединяет плюсы PERT Estimation и методов, основанных на метриках. Очень простой, и на практике невероятно точный — сравним с PSP/TSP. Помнится, года 4 назад докладывал его на конференции Oracle для партнеров. Вот здесь ссылки на презентации.

http://gaperton.livejournal.com/34265.html

Здравствуйте, Gaperton, Вы писали:

G>http://gaperton.livejournal.com/34265.html

Презентация, кстати, говно.

Не умел я тогда еще делать презентаций.

Здравствуйте, Gaperton, Вы писали:

G>>>А вот к "разбиению задачи на подзадачи" это не приводит. Я понимаю, что это сейчас для вас звучит странно. Чтобы оно было не так странно, надо понимать принцип, как правильно выделять задачи. Это, в общем, разговор долгий, но если кратко и о главном — всегда начинать надо с детального анализа критерия завершения задачи. Ответа на вопрос "как я проверю, что задача завершена". А вовсе не с фантазий о том, что ты будешь делать в процессе.
G>>>И если этот критерий звучит как "программист Вася сказал, что написал класс Х, и осталось только отладить", то такую задачу нет никакого смысла выделять.

A>>Вот очередная жемчужина (для меня). Ответ только для того, чтобы она не затерялась.

G>Поищи у меня в блоге по "декларативное планирование", там тема раскрыта подробнее

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

G>Я про него доклад делал на одном из SoftwarePeople.
Насколько я помню, там про виселицу было

(Вот мало что помню с тово доклада, а виселицу хорошо запомнил. Как интересно память устроена

)
Гапертон, можно ли где-то видео последнего твое доклада взять? Презентацию я уже раза три смотрел. Но хотелось бы и видео. Особенно интересую последние 2 слайда. И, кстати, в середине доклада тоже есть про такой подход, но вскользь.

По поводу конкретно этой "жемчужены".
Не могу сказать, что я о таком не читал. И декларативное планирование я читал и про "definition of done" я тоже читал. Но как-то это были теоретические знания. По принципу: в одно ухо влетело, в другое вылетело.
Тут же произошло некое озарение. То ли накопился критический объем знаний и оно "жахнуло"

То ли твое сообщение легло на нужный момент времени (я как раз тогда, и сейчас, был плотно занят анализом и оценкой задач.
В общем, спасибо!

Но, все равно, сказать по правде, я не делаю детальный анализ критерия завершения задачи. Умом понимаю, что так правильно. Но что-то (похоже лень и мысль: "сто раз так делал") мешает

Убеждаю себя что мои задачи мелкие и в них не будет неоднозначностей

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Gaperton, Вы писали:

G>> Да мне побоку.
G>Я знаю. Именно поэтому ты в моем журнале комментарии оставлять и не можешь.
Сорри. Я не пробовал. А что, действительно не могу?

По правде, я не оставляю коментарии из-за боязни спроть чушь. Т.е. "бан" у меня внутри. Не знал, что он так же есть "снаружи".
Но это фигня. Я не знаю когда дорасту до уровня, когда смогу спросить что-то действительно стоящее.

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

G>Ты хочешь, чтобы я его тебе в деталях, подробно, и по шагам воспроизвел в форуме? Зачем? Тебе что-то мешает самому нажать кнопку Help?

Извиняюсь что заползаю в дискуссию — зачем на форуме? Думаю, многие вам будут благодарные, а сами вы получите еще +20 к известности и +1 к менеджерству если создадите несколько статей на хабре. Я, например, потихоньку перевожу туда свои знания об управлении — иногда достаточно интересный фидбек всплывает. Намного более ценный, чем часы, потраченные на написание:

http://habrahabr.ru/post/126104/

G>А вот к "разбиению задачи на подзадачи" это не приводит. Я понимаю, что это сейчас для вас звучит странно. Чтобы оно было не так странно, надо понимать принцип, как правильно выделять задачи. Это, в общем, разговор долгий, но если кратко и о главном — всегда начинать надо с детального анализа критерия завершения задачи. Ответа на вопрос "как я проверю, что задача завершена". А вовсе не с фантазий о том, что ты будешь делать в процессе.

Надеюсь, никто не обидится если я и сюда заползу?

Досточтимый и многомудрый Gaperton, а почему вы считаете что для любой задачи основное — это критерий завершения? Насколько я помню, процессы обычно подгоняют под наиболее частый случай. Если у нас при копании траншей наиболее частый случай — "выкопали", то ежу понятно что основное что нам о задаче интересно — это "выкопали или не выкопали". Варинт "копали, выкопали трубопровод, теперь не знаем что делать" случается очень редко, мы его рассматриваем как исключение.

Разработка программного обеспечения — область ~~ебанутая~~ ~~сложная~~ отличная от копания траншей. И от вытачивания заготовок на станках — тоже. У нас как раз ситуации когда "копали, а ночью все само зарасло", "копали — выкопали BSOD", "копали — докопались до лавы" — это то, что случается каждый день. Очень редко случается что мы в последующем проекте применяем точно те же технологии что и в предыдущем, для решения тех же задач. Потому как у нас нулевая цена копирования и если кто-то уже выокпал траншею — нам не нужно копать следующую. Мы копируем уже выкопанную. Так что каждый следующий проект — это копание траншей новой формы на новой планете с не очень понятными физическими законами и с новым набором инструментов. И вариант что оно выкопалось — это не самый частый случай. Самый частый случай — это выкопались те или иные проблемы, с которыми мы как-то работаем дальше — начиная от разбиения задачи и заканчивая ее изменением / отменой.

Вы согласны с вышеизложенным? Или считаете что критерий "выполнено/не выполнено" основной вне зависимости ни от чего?

Здравствуйте, stranger_v, Вы писали:

C>>Project более подходит для проектов по копанию траншей. Где «могу копать. могу не копать.» и все работники взаимозаменяемы.

_>Да ну? А как хотя-бы примерно рассчитать сроки и объяснить их заказчику без подобного механизма? Я не вижу альтернативы, мы же разрабатываем софт не для себя, а для заказчика, где есть вполне конкретные бюджеты и сроки.

А если по-честному, то никак. Эстимейт проектов ПО это столь же научная задача, как предсказание курса колебания валют в течение дня. Можно сделать эстимейт, можно придумать число от балды, можно погадать на кофейной гуще.

Я работал с большой аутсорсинговой компанией (одной из крупнейших в РФ, да и в мире наверно), мы заказывали у них пару проектов. И шо вы думаете, как они работают? По принципу «главное ввязаться в бой». В первом проекте первоначальный план и эстимейт не имел ничего общего с тем, как оно в итоге оказалось. А во втором мы их просто послали, потому что они сразу выдали смехотворно нереалистично маленький эстимейт для крайне сложной задачи.

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

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

EOH>Разработка программного обеспечения — область отличная от копания траншей. И от вытачивания заготовок на станках — тоже. У нас как раз ситуации когда "копали, а ночью все само зарасло", "копали — выкопали BSOD", "копали — докопались до лавы" — это то, что случается каждый день.

После определенного срока в отрасли приходит понимание, что написанное вами — (само)обман.

EOH>>Разработка программного обеспечения — область отличная от копания траншей. И от вытачивания заготовок на станках — тоже. У нас как раз ситуации когда "копали, а ночью все само зарасло", "копали — выкопали BSOD", "копали — докопались до лавы" — это то, что случается каждый день.
SD>После определенного срока в отрасли приходит понимание, что написанное вами — (само)обман.

Какие-нибудь факты, аргументы? Если делать одинаковые веб-странички на одном и том же стеке технологий — то да, оно в целом предсказуемо и подземного стука не будет. Но, к сожалению, разработка программного обепсечения не ограничивается веб страничками и распилом "бизнес автоматизации"

EOH>Какие-нибудь факты, аргументы?

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

Здравствуйте, Sinclair, Вы писали:

S>1. с тех пор, как я бросил проджект менеджмент, люди придумали много интересных теорий (большинство из которых не очень хорошо применимы на практике).

И на что ты его поменял?

Здравствуйте, Аноним, Вы писали:

S>>1. с тех пор, как я бросил проджект менеджмент, люди придумали много интересных теорий (большинство из которых не очень хорошо применимы на практике).
А>И на что ты его поменял?
на менеджмент продуктов. Людьми я управлять не люблю. Понятия не имею, чего все так стремятся к этой "власти". Управлять требованиями гораздо интереснее.

Здравствуйте, Aikin, Вы писали:

A>Насколько я помню, там про виселицу было

Виселица была в докладе о рисках. Это о другом. Насчет видео — организаторов тряхну. По поводу декларативного планирования — помимо презентации (одной, на первом SWP) есть посты в ЖЖ, которые суть тексты, а не слайды. Ключевое слово рулит.

A>Но, все равно, сказать по правде, я не делаю детальный анализ критерия завершения задачи. Умом понимаю, что так правильно. Но что-то (похоже лень и мысль: "сто раз так делал") мешает

Убеждаю себя что мои задачи мелкие и в них не будет неоднозначностей

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

В самом деле — а как ты поймешь, что задача завершена, если не знаешь критерия ее завершения? Подумай. Это ж нонсенс. А исполнителям — как задачу выполнять, не зная, когда она завершена?

Здравствуйте, Gaperton, Вы писали:

G>Виселица была в докладе о рисках. Это о другом. Насчет видео — организаторов тряхну. По поводу декларативного планирования — помимо презентации (одной, на первом SWP) есть посты в ЖЖ, которые суть тексты, а не слайды. Ключевое слово рулит.
Та я читал. Не созрел еще. Да и не надо оно пока мне. У меня пока менеджмент на уровне6 не забыл все таски сделать. Вопрос о сроках хоть и стоит, но не так жестко.

A>>Но, все равно, сказать по правде, я не делаю детальный анализ критерия завершения задачи. Умом понимаю, что так правильно. Но что-то (похоже лень и мысль: "сто раз так делал") мешает

Убеждаю себя что мои задачи мелкие и в них не будет неоднозначностей

G>По настоящему торкнет тогда, когда ты себе запретишь ставить задачу, не имея внятного (а не булшытного) критерия ее завершения. Это просто — запрети себе писать названия задач. Полностью замени их списком критериев завершения каждой.
G>В самом деле — а как ты поймешь, что задача завершена, если не знаешь критерия ее завершения? Подумай. Это ж нонсенс. А исполнителям — как задачу выполнять, не зная, когда она завершена?
Давай попробуем, хорошо?

Вот 10 минут назад создал таску:
Название: Add configurable XXX field into YYY window for TBM
Описание: we need a new input field for TBM in the YYY window to scan xxx as briefly discussed last week
This should be configurable. when this is shown the app should not create its own barcode and take it from this input field

Ясно что 100% булшыт. Но, я полностью знаю что нужно сделать, это обсуждалось с заказчиком на прошлой недели, подводных камней тут не будет (это поле нужно для перестраховки, если автоматический сканер не сработает и ручной тоже не пашет).
Этот таск займет 2 часа от силы. Да его больше описывать, чем кодировать

Попробую:
Пользователь может ввести XXX баркод вручную в окне YYY, который будет присвоен новой детали в таблице ZZZ
Если эта функция отключена в конфигурации, то поле не показывается и новый баркод генерится программой
Достаточно или более детально?

Получилось практически то же самое, что и в описании, но человек со стороны сможет легко разобраться что же мы там "briefly discussed last week". И ему не придется думать "а может они что-то еще там надискасили, а я не знаю".
Думал я от силы 3 минуты, писал еще 3. Неплохо.
Ну и как бонус получил тестплан, съэкономлю время когда тестер не придет ко мне спрашивать что же тут тестировать.

Хмм, интересно. Надо попробовать более сложный таск "перефигачить".

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Aikin, Вы писали:

A>Получилось практически то же самое, что и в описании, но человек со стороны сможет легко разобраться что же мы там "briefly discussed last week". И ему не придется думать "а может они что-то еще там надискасили, а я не знаю".
A>Думал я от силы 3 минуты, писал еще 3. Неплохо.
A>Ну и как бонус получил тестплан, съэкономлю время когда тестер не придет ко мне спрашивать что же тут тестировать.

Вот, ты все правильно понял.

A>Хмм, интересно. Надо попробовать более сложный таск "перефигачить".

Более сложный таск ты сможешь декомпозировать на мелкие так: cмотришь на перечень критериев проверки, и задаешь себе вопрос: "что из этого я могу проверить независимо?" А потом — второй вопрос: "в каком порядке я могу это делать?" А потом, после подразбиения на задачи со связями, задаешь себе третий: "а что мне еще надо, чтобы иметь возможность все это проверить, как написано?" И дописываешь то, что забыл.

И ты получаешь мое декларативное планирование.

Здравствуйте, Gaperton, Вы писали:

G>И ты получаешь мое декларативное планирование.

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

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

Здравствуйте, Aikin, Вы писали:

Удивительно, что ты один из моих лучших "учеников".

Хотя и не работаешь со мной лично (узкий канал коммуникации) — но понимаешь с полуслова, и до кучи еще и регулярно срешься в мной комментах.

Впрочем, как говорят знающие люди, последнее качество всегда отличало годного combat officer

. Предлагаю как-нибудь лично познакомиться на каком-нибудь мероприятии, конференции например. Почта как ник в gmail, если есть желание пиши.

Здравствуйте, Aikin, Вы писали:

A>Но это фигня. Я не знаю когда дорасту до уровня, когда смогу спросить что-то действительно стоящее.

"За спрос", уважаемый Айкин, даже на зоне не бьют. Не то что в таком куда более приличном месте, как в ЖЖ.

А вот за переходы на личности...

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Аноним, Вы писали:

S>>>1. с тех пор, как я бросил проджект менеджмент, люди придумали много интересных теорий (большинство из которых не очень хорошо применимы на практике).
А>>И на что ты его поменял?
S>на менеджмент продуктов. Людьми я управлять не люблю. Понятия не имею, чего все так стремятся к этой "власти". Управлять требованиями гораздо интереснее.

О. Теперь я понимаю, почему тебя так цепанул тот мой пост.

Единственное, что я не понимал в нашей беседе.

Бывает, Синклер. Ниче, не переживай — с людьми работать, оно не каждому дано. Это куда сложнее, чем MS Project, дискуссии с безмозглыми тренерами, и "работы с требованиями".

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

Ясен хрен, надо такого уволить. Из элементарной логики следует. Замени его скриптом — толку будет столько же, а насколько меньше гундежа!

Здравствуйте, Eye of Hell, Вы писали:

G>>Ты хочешь, чтобы я его тебе в деталях, подробно, и по шагам воспроизвел в форуме? Зачем? Тебе что-то мешает самому нажать кнопку Help?

EOH>Извиняюсь что заползаю в дискуссию — зачем на форуме?

Иногда, по старой памяти, когда совсем нехер делать, я захожу сюда. Затем на этом форуме. Я его, все-таки, люблю. Где-то в глубине дущи.

EOH>Думаю, многие вам будут благодарные, а сами вы получите еще +20 к известности и +1 к менеджерству...

Нахрен не вперлось. Вы, если интересно, наберите "gaperton" в поиске по блогам, скажем, в яндексе. Мой блог в ЖЖ имеет большую аудиторию, чем этот форум. И статьи в нем сами перепечатываются туда, куда нужно.

Хабр — лишний.

Здравствуйте, Eye of Hell, Вы писали:

EOH>Надеюсь, никто не обидится если я и сюда заползу?

И тут внезапно все подумали. И половина решила обидеться.

EOH>Досточтимый и многомудрый Gaperton, а почему вы считаете что для любой задачи основное — это критерий завершения?

Опыт. Когда я говорю об этом, я действительно знаю[b/], о чем говорю. Есть вещи, в которых я не уверен, и их много — но в этом уверен как никогда. Представляете себе? Такое иногда бывает.

EOH> Насколько я помню, процессы обычно подгоняют под наиболее [b]частый случай.

Странно, а я вот такого не помню, хоть и "многомудрый" (льстите мне, льстите). Я вообще, если какой херни не помню — то не стараюсь делать вид, что помню. Советую, кстати, Вам брать с меня пример.

EOH> Если у нас при копании траншей наиболее частый случай — "выкопали", то ежу понятно что основное что нам о задаче интересно — это "выкопали или не выкопали". Варинт "копали, выкопали трубопровод, теперь не знаем что делать" случается очень редко, мы его рассматриваем как исключение.

Я по ежам не специалист. И в траншеях тоже. Ничего не могу сказать, извините. А вот в разработке софта, и харда — разбираюсь, есть грещок.

EOH>Разработка программного обеспечения — область ~~ебанутая~~ ~~сложная~~ отличная от копания траншей. И от вытачивания заготовок на станках — тоже.

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

EOH>У нас как раз ситуации когда "копали, а ночью все само зарасло", "копали — выкопали BSOD", "копали — докопались до лавы" — это то, что случается каждый день. Очень редко случается что мы в последующем проекте применяем точно те же технологии что и в предыдущем, для решения тех же задач. Потому как у нас нулевая цена копирования и если кто-то уже выокпал траншею — нам не нужно копать следующую. Мы копируем уже выкопанную. Так что каждый следующий проект — это копание траншей новой формы на новой планете с не очень понятными физическими законами и с новым набором инструментов. И вариант что оно выкопалось — это не самый частый случай. Самый частый случай — это выкопались те или иные проблемы, с которыми мы как-то работаем дальше — начиная от разбиения задачи и заканчивая ее изменением / отменой.

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

EOH>Вы согласны с вышеизложенным? Или считаете что критерий "выполнено/не выполнено" основной вне зависимости ни от чего?

Не. Я вышеизложенного тупо не понял. Тупой. Вы, пожалуйста, будьте проще, а то ведь, глядишь — не поймут вас люди. И того больше — смеяться над вами будут. Здесь ведь, всетки, не хабр.

Здравствуйте, Eye of Hell, Вы писали:

EOH>Какие-нибудь факты, аргументы?

Очень по хабровски. У нас такое поведение вт ИТМиВТ называли — "умняк накинуть". Разумеется, беседу надо понимать в контексте Вашего поста пару раз выше.

Вы этого здесь ждете, но этого здесь не будет.

EOH>>Разработка программного обеспечения — область ~~ебанутая~~ ~~сложная~~ отличная от копания траншей. И от вытачивания заготовок на станках — тоже.
G>Вы в проектах, где было точение на станках, участвовали? Вот я, например, ими руководил. И они мне очень интересны — расскажите мне про них подробнее — в чем по вашему разница?

Я ими не руководил, но я заказывал изготовление железных деталек в малых тиражаш (от 100 особей). Чем, на мой взгляд, точение заготовки отличается от разработки программного обеспечения — мы такую же или очень похожую заготовку уже сотни раз точили. Мы берем чертеж, смотрим на материал, допуски — и в большинстве случаев сразу понятно, что будет. Бывают исключения — слишком тонкие / толстые части, сложная форма, маленькие допуски — но это редко. И, замчечу — в большинстве случаев, если знаем сапромат — сразу видно.

В программном обеспечении по внешним признакам нифига не видо. Вот возьмем из практики — делали недавно MSI установщик, чтобы значит добрые дядьки админы могли его через active directory на тыщи компов ставить. Простая задача — если драйвер железки в новой версии не изменился — то его не переустанавливаем, ибо к нему могут быть подключены написанные школьниками фильтры и потрбуется перезагрузка — а мы перезагрузки не хотим и драйвер меняется нечасто. Изучив предмет, я оценил риски как средние — гугл показывает что никто про такие извращения не пишет, MSI движок наполовину декларативный, могут быть вопросы. К сожалению, пары часов на то чтобы внимательно изучить MSI API и MSI TABLES у меня не было — в проекте задачи со средними рисками хватает, если все детально изучать — то очень долго, а делать все равно надо (c). Вообщем в неделю прототип не уложился — оказалось, что мой лучший спец по инсталляторам знает об MSI не все. И авторы MSI тоже знают о нем не все. Задачу выполнили — но в три раза дольше чем планировали. Был риск эту фичу дропнуть. И так регулярно.

Как я это вижу. Смотрю на чертеж заготовки, и в большинстве случаев сразу могу сказать — будут проблемы или нет. Если будут — то какие.
Смотрю на описание фичи в большой и сложной программе — и в большинстве случаев я не могу сказать, будут ли там проблемы.

EOH>>У нас как раз ситуации когда "копали, а ночью все само зарасло", "копали — выкопали BSOD", "копали — докопались до лавы" — это то, что случается каждый день. Очень редко случается что мы в последующем проекте применяем точно те же технологии что и в предыдущем, для решения тех же задач. Потому как у нас нулевая цена копирования и если кто-то уже выокпал траншею — нам не нужно копать следующую. Мы копируем уже выкопанную. Так что каждый следующий проект — это копание траншей новой формы на новой планете с не очень понятными физическими законами и с новым набором инструментов. И вариант что оно выкопалось — это не самый частый случай. Самый частый случай — это выкопались те или иные проблемы, с которыми мы как-то работаем дальше — начиная от разбиения задачи и заканчивая ее изменением / отменой.
G>Вот именно поэтому я и не люблю хабр. Я, с Вашего позволения, не буду это комментировать. Выражаться надо проще. Тогда станет очевидно, есть вам что сказать, или нет. А вы это зачем-то глубоко прячете за своими словами.
EOH>>Вы согласны с вышеизложенным? Или считаете что критерий "выполнено/не выполнено" основной вне зависимости ни от чего?
G>Не. Я вышеизложенного тупо не понял. Тупой. Вы, пожалуйста, будьте проще, а то ведь, глядишь — не поймут вас люди. И того больше — смеяться над вами будут. Здесь ведь, всетки, не хабр.

Вижу, обидел вас хабр чем-то

. Не надо было его упоминать. Неадекватно реагируете

.

P.S. Это я все в рамках топика — о хороших программах для планирования. Бо надо — Jira хорошо автоматизирует документооборот, но вот для планирования приходится выбирать между Greenhopper и MS Project. И ни тот, ни другой мне не нравятся.

	От:	stranger_v
	Дата:	12.05.12 15:03
	Оценка:	1 (1)

	От:	Centaur
	Дата:	12.05.12 15:43
	Оценка:

	От:	Nikolay_Ch
	Дата:	13.05.12 17:53
	Оценка:

	От:	Аноним
	Дата:	14.05.12 02:41
	Оценка:

	От:	maxkar
	Дата:	14.05.12 09:15
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	18.05.12 06:45
Оценка:	+1

От:	Gaperton	http://gaperton.livejournal.com
Дата:	18.05.12 09:12
Оценка:

От:	Tom	http://www.RSDN.ru
Дата:	22.05.12 06:24
Оценка:

От:	Aikin	kavaleu.ru
Дата:	24.05.12 14:01
Оценка: