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 говно", или "может быть, я идиот, а Гапертон в самом деле может что-то уметь, что не умею я" (вы когда этого говорили, видимо, считали это тонкой иронией) — это что-то новое, интересное, или конструктивное, правда?

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

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

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

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

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

Капитан, вы, как всегда, вовремя.

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

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

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

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

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

Здравствуйте, 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
А чтобы дифы выдавали полезную инфу нужно менять план не "от балды", а с умом.
Это как с сорцами. Можно так менять код чтобы потом рвать на себе волосы во время мержа, а можно сделать мерж как можно проще и безопаснее. Достаточно следовать некоторым правилам.

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


СУВ,

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

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

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

СУВ, Aikin

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

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


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

СУВ, Aikin

Здравствуйте, 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> Да мне побоку.

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