Здравствуйте, 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

Автор: Sinclair
Дата: 18.05.12

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

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

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

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


СУВ, Aikin

Здравствуйте, 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

Здравствуйте, 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 мог бы помочь с экспертизой, буде таковая в наличии, есть у него свободное время, и отрыв его от реальности (через прокси-менеджеров) не достиг точки невозврата.
Я буду очень рад ошибаться, но чудес не бывает. Проджект я исползал вдоль и поперёк в бытность проджект менеджером.