Hello, Gaperton!
You wrote on Mon, 15 Jan 2007 16:19:04 GMT:


G> Предварительная версия для первичного ознакомления. Без претензии на
G> полноту и непротиворечивость — это внутренняя версия.
G> здесь

G> Пишите, что думаете. Методика проходит сейчас обкатку в боевых
G> условиях, и требует шлифовки.

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

Я бы предложил следующий план статьи:

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

2. Потом очень желательно описать типовые проблемы при управлении проектом и
пути их решения с ипользованием вышеупомянутой методики, да так, чтобы сразу
было видно, что это (методика) является silver bullet в первом приближении.

3. Всякие приложения: типовые таблицы целей, рисков и т.д.

Итого: описание, применение, справочник.

With best regards, Yury Kopyl. E-mail: hrg@yandex.ru

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

G>Пишите, что думаете. Методика проходит сейчас обкатку в боевых условиях, и требует шлифовки.

Браво, ребята.

Опробовал на свем текущем проекте.
При этом заметил некоторые пропущенные мной ранее косяки (здесь стали видны явно).
В общем, методика достаточно интересным образом смещает фокус внимания.


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

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

AE>Возникло только одно недоумение:
AE>Сказано, что условия достижения цели пришутся справа от черты,
AE>и стрелки к подцелям — там же. Но нигде не сказано писать предусловие
AE>прямо над стрелкой. А ведь или я чего не понял, или соотношение
AE>предуслоий и подцелей должно получиться 1:1?

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

Хотя мысль с предусловиями интересная, надо о ней подумать. Можешь привести пример ситуации, когда это полезно?

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

G>Хотя мысль с предусловиями интересная, надо о ней подумать. Можешь привести пример ситуации, когда это полезно?

Приходит в голову один пример, правда тут предусловия не совсем из домена управления проектом, скорее из домена бизнес-управления.
Пример:
Цель="Написать фичу Х"
Предусловие="Удалось впарить продук клиенту N"

Маза в том что без этой фичи клиент N наш продукт не хочет. Но если он и с этой фичей не купит, то больше никому эта фича не нужна.

Собственно предусловие можно заменить на цель + зависимость от этой цели. Новая цель будет "продать продукт кленту N". Только выполнение этой цели уже не в нашей власти и потому эта цель немного выподает из общей картины.

Здравствуйте, Risk Server, Вы писали:
RS>Приходит в голову один пример, правда тут предусловия не совсем из домена управления проектом, скорее из домена бизнес-управления.

У меня кстати тоже. То есть опробовал на похожем примере.
Может быть это не случайно? (Связь предусловий с бизнес — контекстом.)

RS>Пример:
RS>Цель="Написать фичу Х"
RS>Предусловие="Удалось впарить продук клиенту N"

RS>Маза в том что без этой фичи клиент N наш продукт не хочет. Но если он и с этой фичей не купит, то больше никому эта фича не нужна.

RS>Собственно предусловие можно заменить на цель + зависимость от этой цели. Новая цель будет "продать продукт кленту N". Только выполнение этой цели уже не в нашей власти и потому эта цель немного выподает из общей картины.

А собственно почему "не в нашей власти"???
Нормальная така цель, с рисками...
Причем именно она первична. То есть верхнего уровня.

Кстати я понял — если возникают предусловия, это значит, что пропущена некая цель более верхнего уровня, для которое это ПРЕД-условие, является ПОСТ-условием, ведущим к текущей цели...

Привет,

G>Предварительная версия для первичного ознакомления. Без претензии на полноту и непротиворечивость — это внутренняя версия.
G>здесь

G>Пишите, что думаете. Методика проходит сейчас обкатку в боевых условиях, и требует шлифовки.
Когда прочитал первые 40%, попутно рисуя предложенное, появилась навязчивая мысль, что я где-то подобное видел.
Не могли бы вы вкратце рассказать чем данная методика отличается от графика СПУ с приоритетами?

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

PVA>Привет,

G>>Предварительная версия для первичного ознакомления. Без претензии на полноту и непротиворечивость — это внутренняя версия.
G>>здесь

G>>Пишите, что думаете. Методика проходит сейчас обкатку в боевых условиях, и требует шлифовки.
PVA>Когда прочитал первые 40%, попутно рисуя предложенное, появилась навязчивая мысль, что я где-то подобное видел.

PVA>Не могли бы вы вкратце рассказать чем данная методика отличается от графика СПУ с приоритетами?
От СПУ эта штука отличается так же, как цикл разработки RUP отличается от цикла waterfall.

Глядим на цикл RUP-а:
[img]http://www.enterpriseunifiedprocess.com/images/eup_lifecycle.jpg[img/]

Чем фаза Inception принципиально отличается от фазы разработки требований? Тем, что на фазе Inception не запрещено заниматься кодированием, дизайном и отладкой. Фазы цикла "контроллируемая итерация" принципиально не привязаны к роду активности. Она заканчивается, [b] когда вся команда имеет единое понимание, что она, собственно, собирается сделать[b/]. Если для того, чтобы получить это понимание, придется немного подизайнить, покодировать — да ради бога. Главное — отдавать себе отчет, что цель на данном этапе — вовсе не код написать. Код написать — это средство. Этот факт — что RUP не борется с реальной жизнью (оказывается, бывает такое), и фазы его сформулированы в терминах exit condition, всегда меня в RUP-е восхищал.

Наш метод, с одной стороны, имеет корни из методов планирования maintenance релизов (самый хаотичный и непредсказемый с точки зрения менеджмента вид программерской деятельности, сетевое планирование для которого принципиально не подходит — maintenance), с другой стороны — вдохновлен RUP-ом. И на базе этого опыта нам надо было разработать методику планирования разработки систем на кристалле . Получили мы, в результате, очень любопытный гибрид, являющийся с одной стороны конструктором циклов разработки со свойствами RUP-овского controlled iteration, с другой — порясающе устойчивую методику планирования и контроля, которая работает в условиях хаоса, как методы управления support-ом.

Чем это отличается от сетевого планирования? Знаете, из нашего плана легко сделать сетевой график. Обратное — неверно. Принципиальное отличие объяснено во введении. Оно состоит в том, что:
1) Планируются не активности, а условия их прекращения (цели).
2) План двумерный — активности находятся как бы на пересечении компонент и целей.
3) Свойства активностей, целей, и компонент строго отделены друг от друга.

Ну, не знаю, как еще можно объяснить. Практическое отличие от СПУ — наши планы получаются понятнее, устойчивее, и составляются быстрее.

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

А можно такую же картинку для waterfall?

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

G>1) Планируются не активности, а условия их прекращения (цели).
Цели — это события в СПУ.

G>2) План двумерный — активности находятся как бы на пересечении компонент и целей.
Компоненты определены как "список составных частей конечного или промежуточных результатов".
Откуда появляется разбивка на компоненты?
Насколько я понимаю разбивка на компоненты появляется как следствие постановки промежуточных целей.
Тоесть после построения таблицы целей matrix(time, dependencies) берется верхняя строчка (там где разположены независимые цели) и определяется, что они ялвяются базовыми компонентами. Дальнейшие структурные композиции несущественны.

G>3) Свойства активностей, целей, и компонент строго отделены друг от друга.
Если не трудно — пару строк об этом.

G>Ну, не знаю, как еще можно объяснить. Практическое отличие от СПУ — наши планы получаются понятнее, устойчивее, и составляются быстрее.
Не спорю, практически очень может быть. Но перед тем как внедрять данную методику хотелось бы выяснить для себя непонятные места.

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

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

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

PVA> А можно такую же картинку для waterfall?

Да ради бога.
http://en.wikipedia.org/wiki/Waterfall_model
Отличительное свойство — фаза привязанна к активности. Ватерфол не работает на практике, его использование приводит к нереалистичным планам, которые часто расходятся с реальным ходом дел.

PVA>

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

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

G>>1) Планируются не активности, а условия их прекращения (цели).
PVA>Цели — это события в СПУ.
Это не так. Хоть и похоже. Причина объяснена выше.

G>>2) План двумерный — активности находятся как бы на пересечении компонент и целей.
PVA>Компоненты определены как "список составных частей конечного или промежуточных результатов".
PVA>Откуда появляется разбивка на компоненты?
PVA>Насколько я понимаю разбивка на компоненты появляется как следствие постановки промежуточных целей.
Разбивка на компоненты появляется в ходе работ над архитектурой. Часто примерный их список можно составить сразу.

PVA>Тоесть после построения таблицы целей matrix(time, dependencies) берется верхняя строчка (там где разположены независимые цели) и определяется, что они ялвяются базовыми компонентами. Дальнейшие структурные композиции несущественны.
Не так. Примерный список компонент центрального процессора.
АЛУ
Регистровый файл
Интерфейс памяти
Управление
Кэш
Блок защищенного режима

Все эти компоненты видны как блоки на структурной диаграмме процессора в виде квадратиков. Вопрос: откуда берется структурная диаграмма процессора? Не из списка независимых целей, а из головы проектировщика.

G>>3) Свойства активностей, целей, и компонент строго отделены друг от друга.
PVA>Если не трудно — пару строк об этом.

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

Компоненты — составная часть результата, и относительно нее вы можете выдать агрегатный прогноз сроков работ на раннем этапе. Также, вы можете оценить их объем, и предплагаемую сложность и рискованность их разработки (вашу уверенность в прогнозе сложности/сроков). Это — свойства компонент. Список компонент бывает что меняется по ходу разработки, и если разбивка задач основана на компонентах (а так часто бывает), это приводит к тому, что планы плывут. Однако, цели меняются существенно реже. Явное отделение целей от компонент делает ваши планы более усточивыми — хрен с ними, компонентами, пусть меняются. Чтобы минимизировать тот фактор — в планах мы указываем только компоненты верхнего уровня декомпозиции.

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

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

Мы всегда в состоянии отследить, сколько закрытых задач у нас по каждой из целей против запланированной. Таким образом, по виду кривой Earned Value (количество закрытых и запланированных к закрытыю задач по неделям) мы в состоянии оценить не только процент выполнения, но и выловить систематическую недооценку/переоценку сложности. Изменение списка задач слабо затрагивает общий план — карту целей, это хорошо.

Ну вот, примерно так.

G>>Ну, не знаю, как еще можно объяснить. Практическое отличие от СПУ — наши планы получаются понятнее, устойчивее, и составляются быстрее.
PVA>Не спорю, практически очень может быть. Но перед тем как внедрять данную методику хотелось бы выяснить для себя непонятные места.
Да вы не торопитесь внедрять . Сначала попробуйте нарисовать в ней план своего текущего проекта. Может, понравится, может — нет.

И еще. Мы ничего особенного-то не придумали. Мы ввели набор понятий, рассуждение в терминах которых позволяет нам строить планы качественно лучше и быстрее. Никакой научной новизны тут нет, и естественно будут возникать параллели и аллюзии с классикой. Реальное отличие, как правильно заметил Alex EXO — рассуждение в терминах введенных нами понятий смещает фокус внимания в интересную и полезную, как нам кажется, сторону.

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

hrg>По стилю изложения — слишком формально, трудно воспринимается. Хотелось бы
hrg>видеть живую статью, в которой доходчиво, *простым* языком описано решение
hrg>проблем, встающих перед ПМ.

Скажем так, мне наоборот понравился стиль изложения. Кратко, без излишней воды. Да, читать тяжело, практически каждый абзац надо прокручивать в голове и примерять на свой опыт. Но как плюс — малый объём, конспективность (т.е. можно очень быстро найти заинтересовавшую идею), не нужно включать скорочтение, как у обычных бизнес-книг

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

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

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

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

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

PVA>>Насколько я понимаю разбивка на компоненты появляется как следствие постановки промежуточных целей.
G>Разбивка на компоненты появляется в ходе работ над архитектурой. Часто примерный их список можно составить сразу.
Чем эти две посылки отличаются?

PVA>>Тоесть после построения таблицы целей matrix(time, dependencies) берется верхняя строчка (там где разположены независимые цели) и определяется, что они ялвяются базовыми компонентами. Дальнейшие структурные композиции несущественны.
G>Не так. Примерный список компонент центрального процессора.
G>АЛУ
...
G> Вопрос: откуда берется структурная диаграмма процессора? Не из списка независимых целей, а из головы проектировщика.
А в голове проектировщика она откуда берется? (предполагаем, что проект новый и предыдущий опыт здесь работает только косвенно)

G>>>3) Свойства активностей, целей, и компонент строго отделены друг от друга.
PVA>>Если не трудно — пару строк об этом.
G>В описании цели вы никак не говорите, как ее можно достигнуть. Средство достижения цели — это активности, задачи, которые к ней относятся. Такое разделение позволяет строить планы в условиях, когда вы знаете, чего хотите, но пока не знаете, как этого достичь.
+

G>Компоненты — составная часть результата, и относительно нее вы можете выдать агрегатный прогноз сроков работ на раннем этапе. Также, вы можете оценить их объем, и предплагаемую сложность и рискованность их разработки (вашу уверенность в прогнозе сложности/сроков).
У вас есть черный ящик. Я не совсем понимаю каким образом вы делаете количественные оценки его содержимого не предполагая что там внутри.

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

G>Мы всегда в состоянии отследить, сколько закрытых задач у нас по каждой из целей против запланированной. Таким образом, по виду кривой Earned Value (количество закрытых и запланированных к закрытыю задач по неделям) мы в состоянии оценить не только процент выполнения, но и выловить систематическую недооценку/переоценку сложности. Изменение списка задач слабо затрагивает общий план — карту целей, это хорошо.
Для СПУ это значило бы изменение названия и веса ребра графа.

G>Ну вот, примерно так.
Спасибо за разьяснения.

G>Да вы не торопитесь внедрять . Сначала попробуйте нарисовать в ней план своего текущего проекта. Может, понравится, может — нет.
Обязательно попробую — как раз новый проект стартует.

G>И еще. Мы ничего особенного-то не придумали. Мы ввели набор понятий, рассуждение в терминах которых позволяет нам строить планы качественно лучше и быстрее. Никакой научной новизны тут нет, и естественно будут возникать параллели и аллюзии с классикой. Реальное отличие, как правильно заметил Alex EXO — рассуждение в терминах введенных нами понятий смещает фокус внимания в интересную и полезную, как нам кажется, сторону.
Присоединяюсь к этой заметке
Я не пытаюсь закидать методику камнями. Проводя параллели легче прийти к пониманию. А вот аллюзии в этом контексте мне не нравятся

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

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

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

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

Цель — зафиксировать систему команд. Зависимая от нее цель — зафиксировать и отладить высокоуровневую поведенческую модель микропроцессора — это мы никак не сможем закончить раньше, правда?

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

PVA>Хотя не буду возражать против того, что в большинстве случаев планирования на таком уровне достаточно.
А весь фокус в том, что делаю это не я. Задачи и активности планируют в основном инженеры и частично руководители групп. Один человек принципиально не способен распланировать крупный проект, в планировании должна участвовать вся команда, включая инженеров. Мой уровень как руководителя отдела не опускается ниже уровня целей внутри фаз, от вникания в активности у меня распухнет голова. Уровень руководителей групп — детализация фаз и постановка промежуточных целей, и контроль уровня задач. Уровень инженера — сами задачи.

PVA>>>Насколько я понимаю разбивка на компоненты появляется как следствие постановки промежуточных целей.
G>>Разбивка на компоненты появляется в ходе работ над архитектурой. Часто примерный их список можно составить сразу.
PVA>Чем эти две посылки отличаются?
Лады, по существу ничем . Только следствием не постановки целей, как у вас написано, а следствием их достижения

PVA>>>Тоесть после построения таблицы целей matrix(time, dependencies) берется верхняя строчка (там где разположены независимые цели) и определяется, что они ялвяются базовыми компонентами. Дальнейшие структурные композиции несущественны.
G>>Не так. Примерный список компонент центрального процессора.
G>>АЛУ
PVA>...
G>> Вопрос: откуда берется структурная диаграмма процессора? Не из списка независимых целей, а из головы проектировщика.
PVA>А в голове проектировщика она откуда берется? (предполагаем, что проект новый и предыдущий опыт здесь работает только косвенно)
Это отдельная тема . Отвечу позже

G>>Компоненты — составная часть результата, и относительно нее вы можете выдать агрегатный прогноз сроков работ на раннем этапе. Также, вы можете оценить их объем, и предплагаемую сложность и рискованность их разработки (вашу уверенность в прогнозе сложности/сроков).
PVA>У вас есть черный ящик. Я не совсем понимаю каким образом вы делаете количественные оценки его содержимого не предполагая что там внутри.
Это та же отдельная тема . Отвечу позже

G>>Это — свойства компонент. Список компонент бывает что меняется по ходу разработки, и если разбивка задач основана на компонентах (а так часто бывает), это приводит к тому, что планы плывут. Однако, цели меняются существенно реже. Явное отделение целей от компонент делает ваши планы более усточивыми — хрен с ними, компонентами, пусть меняются. Чтобы минимизировать тот фактор — в планах мы указываем только компоненты верхнего уровня декомпозиции.
PVA>Я вам немного завидую. Делать оценку на основании первичной декомпозиции я еще не умею.
Никто не умеет. Это всегда пляски с бубном. Позже отвечу

G>>Мы всегда в состоянии отследить, сколько закрытых задач у нас по каждой из целей против запланированной. Таким образом, по виду кривой Earned Value (количество закрытых и запланированных к закрытыю задач по неделям) мы в состоянии оценить не только процент выполнения, но и выловить систематическую недооценку/переоценку сложности. Изменение списка задач слабо затрагивает общий план — карту целей, это хорошо.
PVA>Для СПУ это значило бы изменение названия и веса ребра графа.
Не могли бы вы пояснить?

PVA>p.s. В той же классике по анализу рекомендуется постоянно возвращаться к вопросам о поставленных целях, потому как технические специалисты склонны увязать в анализе активностей, забывая о целях.

+1. Поэтому мы поступили радикальнее — убрали активности нафик с верхнего уровня планирования . Теперь технические специалисты никуда не денуться — как забудешь о целях, если в плане ничего кроме них нет, а планы требует начальство?!

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

G>Не совсем так. Есть активности, итеративные по своей природе, и влиюящие друг на друга. В том и проблема ватерфольного подхода, что он такой факт не учитывает. Пример из жизни — разработка системы команд микропроцессора
Ну вот так бы сразу На системы с обратной связью я не обратил внимания.

...
G>Это отдельная тема . Отвечу позже
Буду с нетерпением ждать!

G>>>Мы всегда в состоянии отследить, сколько закрытых задач у нас по каждой из целей против запланированной. Таким образом, по виду кривой Earned Value (количество закрытых и запланированных к закрытыю задач по неделям) мы в состоянии оценить не только процент выполнения, но и выловить систематическую недооценку/переоценку сложности. Изменение списка задач слабо затрагивает общий план — карту целей, это хорошо.
PVA>>Для СПУ это значило бы изменение названия и веса ребра графа.
G>Не могли бы вы пояснить?
Постараюсь, по крайней мере (я только учусь). В СПУ активности являются ребрами направленного ациклического графа (в целом это уже противоречит возможности обратной связи). Берем пару целей (вершины u, v). Из u в v будет идти несколько ребер с различными весами, определяющих множество вариантов решения задачи, а веса — соответсвтенно коэффициенты сложности работ. Изменение списка задач не влияет на вершины, но влияет на выбор определенного ребра.
Хм, вот тут подумал, что если добавить в этот граф ребра обратной связи, которые могли бы влиять на сложность других работ — получилась бы интересная среда для моделирования выбора определенных решений и числа итераций.

G>+1. Поэтому мы поступили радикальнее — убрали активности нафик с верхнего уровня планирования .
+1

Hello, Bor-ka!
You wrote on Wed, 24 Jan 2007 08:10:03 GMT:

hrg>> По стилю изложения — слишком формально, трудно воспринимается.
hrg>> Хотелось бы видеть живую статью, в которой доходчиво, *простым*
hrg>> языком описано решение проблем, встающих перед ПМ.

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

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

imho текст в статье написан неструктурированно. Описание методики
перескакивает на детали (до черты, сверху черты), не давая цельной концепции
методики.

Я специально не стал критиковать текст по смыслу, т.к. он не доработан до
конца. Вот выйдет полный вариант — будем обсуждать.

Bk> Но как плюс — малый объём, конспективность (т.е. можно очень быстро
Bk> найти заинтересовавшую идею), не нужно включать скорочтение, как у
Bk> обычных бизнес-книг

Достаточно писать в стиле analytical writing, когда можно пропускать
ненужные блоки текста (например — примеры )

Bk> В общем, для обкатки идей — самое оно. А вот потом из этого можно
Bk> сделать книжку. А, может, даже две Одну обычную, а вторую в стиле
Bk> романов Гольдратта или ДеМарко

Не, я этого точно не выдержу

PS Кстате, верстка в pdf кривая — у меня некоторые буквы слипаются.

With best regards, Yury Kopyl. E-mail: hrg@yandex.ru

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

hrg>Hello, Bor-ka!
hrg>You wrote on Wed, 24 Jan 2007 08:10:03 GMT:

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

hrg>Написать доходчиво и кратко — это тяжелый труд, приходиться переписывать по
hrg>нескольку раз (угу, рефакторинг в ворде) Писать формально, в стиле
hrg>"дадим определение..." гораздо проще.

hrg>imho текст в статье написан неструктурированно. Описание методики
hrg>перескакивает на детали (до черты, сверху черты), не давая цельной концепции
hrg>методики.


В своё время меня организовала (и продолжает организовывоваы... тьфу, в общем, направлять) книжка Минто "Золотые правила Гарварда и МакКинси". В которой, кстати, совершенно идиотский перевод названия, но вполне сносный — текста (в оригинале "The Pyramid Principle").

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

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

hrg>Написать доходчиво и кратко — это тяжелый труд, приходиться переписывать по
hrg>нескольку раз (угу, рефакторинг в ворде) Писать формально, в стиле
hrg>"дадим определение..." гораздо проще.

Я уже говорил, что у нас не литературный кружок? Мы заняты другим тяжким трудом, за который нам зарплаты платят. Внутренний материал с описанием я выложил сюда вовсе не для того, чтобы инициировать обсуждение стиля, размеров шрифтов, литературных особенностей, и т.п. Читать и понимать суть материала — тяжкий труд. Давать советы по форме не касаясь сути гораздо проще.

hrg>imho текст в статье написан неструктурированно. Описание методики
hrg>перескакивает на детали (до черты, сверху черты), не давая цельной концепции
hrg>методики.

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

Hello, Gaperton!
You wrote on Thu, 25 Jan 2007 09:33:03 GMT:

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

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

hrg>> Написать доходчиво и кратко — это тяжелый труд, приходиться
hrg>> переписывать по нескольку раз (угу, рефакторинг в ворде)
hrg>> Писать формально, в стиле "дадим определение..." гораздо проще.

G> Я уже говорил, что у нас не литературный кружок? Мы заняты другим
G> тяжким трудом, за который нам зарплаты платят. Внутренний материал с
G> описанием я выложил сюда вовсе не для того, чтобы инициировать
G> обсуждение стиля, размеров шрифтов, литературных особенностей, и т.п.
G> Читать и понимать суть материала — тяжкий труд. Давать советы по
G> форме не касаясь сути гораздо проще.

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

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

hrg>> imho текст в статье написан неструктурированно. Описание методики
hrg>> перескакивает на детали (до черты, сверху черты), не давая цельной
hrg>> концепции методики.

G> "Конструктивно" означает применимость на практике. Уже несколько
G> человек здесь смогли это сделать. Цельной концепции методики пока не
G> существует в природе — методика проходит обкатку сейчас. И нам на
G> данном этапе нужны консультации по сути вопроса, а не рассуждения о
G> том, как нужно писать книги и статьи о менеджменте.

Ну хорошо. Помолясь, приступим

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

В начале статьи дается описание проблем. Вкратце:

1. Трудности с декомпозицией
2. Change management
3. Estimation problem
4. Task tracking problem
5. Communication problem
6. Создание сводных отчетов

"Предлагаемая методика призвана эти проблемы решить."

Ок. Смотрим дальше:

Пробуем найти решение для проблемы 1.

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

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

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

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

"Для определения реалистичности плана работа должна быть разбита на мелкие
задачи. Каждая задача относится к одной цели и, возможно, нескольким
компонентам. Списки задач составляются инженерами, и проверяются
руководителями групп. Все задачи подлежат регистрации в системе JIRA.
Руководители проверяют порядок работ и соответствие задач целям, и
контроллируют достижение целей через закрытие задач. Для контроля
выполнения задач применяется агрегированные графики EV-Plan и средства
системы JIRA.
Также руководители групп целиком ответственны за составление карты
промежуточных целей, и поддержании ее в актуальном состоянии. Руководители
групп еженедельно уточняют прогноз дат выполнения целей на основании
поступающей информации."

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

Вижу, что надо делать. "Сначала ...., потом..., руководитель должен....".
Не вижу — зачем, как, почему? Это регламент, а не методика

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

И самое главное — кто ставить цели? Кто устанавливает приоритеты целей? В
конце концов — dealline'ы ?

Почему в методике переплелись описание решения и указания инструментов
(jira, etc).

----
По вопросу 2.

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

"Руководитель группы ответственнен за еженедельное обновление линеек своей
группы, и составление письменного еженедельного отчета. Руководители
еженедельно информируют руководителя отдела о:
1. Изменении карты целей.
2. Изменении прогнозируемых сроков достижения целей и этапов.
3. Достигнутых и не достигнутых в срок целях и этапах.
4. Изменении рисков, функциональности и/или прочих свойств компонент и
решения в целом.
5. Прочих факторов, которые могут повлиять на планы и их выполнение."

Описание, как методика помогает change management'у не вижу. "на основании
поступающей информации." — от кого? От заказчика? Программистов?

Т.е. все сводиться к тому, что руководитель получил информацию и
отрапортовал ее наверх?

----
Вопросы 3-6 — не раскрыты


ЗЫ Если посмотреть на RUP, то там все пляски с бубном идут вокруг goals и
busines-cases (суть, процессов), так что пока ничего революционного нового
не увидел. Но с нетерпением жду новой редакции методики.

With best regards, Yury Kopyl. E-mail: hrg@yandex.ru

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

hrg>Ну хорошо. Помолясь, приступим

Ну вот, сразу бы так .

hrg>Самое главные замечания:
hrg> — эта методика применима в проекте только начиная с этапа разработки
hrg>(+должна закончиться фаза дизайна в черновом варианте, чтобы получить список
hrg>компонентов), т.к. для составления карты планов нужен список компонентов и
hrg>пройдет этап составления таблицы рисков.
Ну, на самом-то деле, это не так. Она применима и обладает наибольшей пользой на самом раннем этапе, когда списка компонент не существует. В этом случае мы должны убедится, что на архитектурном этапе присутствует цель — стабильная декомпозиция верхнего уровня.

Однако я понимаю, откуда берется такое впечатление. Этот момент показан в тексте смутно и противоречиво — поправим и продумаем.

hrg> — не очерчены границы применения.
Границы применения . Назовите границы применения для сетевого планирования, плз. Чтобы я лучше понял, что вы имеете в виду.

hrg>В начале статьи дается описание проблем. Вкратце:

hrg>1. Трудности с декомпозицией
hrg>2. Change management
hrg>3. Estimation problem
hrg>4. Task tracking problem
hrg>5. Communication problem
hrg>6. Создание сводных отчетов

hrg>"Предлагаемая методика призвана эти проблемы решить."

hrg>Ок. Смотрим дальше:

hrg>Пробуем найти решение для проблемы 1.
хъ
hrg>Это я пытался сделать выжимку из методики, где дается описание, как нужно
hrg>создавать иерархию целей.

hrg>Вижу, что надо делать. "Сначала ...., потом..., руководитель должен....".
hrg>Не вижу — зачем, как, почему? Это регламент, а не методика
Зачем — чтобы означенная проблема не возникала. Как — вроде написано, но очень кратко. Почему — вообще не написано. Это "методичка" — она близка к process script, рассчитана на чтение тимлидом и служит в качестве справочника. За регламентом, безусловно, стоит методика.

hrg>Как выбирать названия целей?
Чтобы было просто и понятно, и отражало суть. Как выбирать названия функций и переменных?

hrg>Какие они бывают в принципе?
Вопрос меня изумляет. Вы не знаете, какие у вас бывают в принципе цели вашей деятельности? Вы предлагаете мне это людям объяснять?

Ладно. В качестве примера приведем цикл контроллируемая итерация. Чтобы было понятно, какие цели бывают в принципе при разработке софта.

hrg>Какой критерий
hrg>правильности разбиения на подцели?
Он дан в определении зависимых целей. Если условия зависимой цели нельзя достичь без достижения цели, от которой мы зависим.

hrg>Как такой подход к целеполаганию снижает
hrg>трудность планирования и кол-во ошибок? Вопросов море, ответов пока не вижу.
Чтобы узнать вкус блюда, самый простой способ — его попробовать, а не рассуждать о нем над тарелкой. Мы — практики, теоретических доказательств не даем.

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

hrg>И самое главное — кто ставить цели?
Ответ, на мой взгляд, очевиден. Цели ставят руководители. Тимлиды, руководители структурных подразделений, топменеджмент. Каждый — на своем уровне.

hrg>Кто устанавливает приоритеты целей? В
hrg>конце концов — dealline'ы ?
Очевидно — те, кто ставят цели, занимаются и расстановкой приоритетов.

hrg>Почему в методике переплелись описание решения и указания инструментов
hrg>(jira, etc).
Потому, что вы смотрите на внутреннюю инструкцию для тимлидов. Написал же, что это внутренняя версия "альфа" для первичного ознакомления.


hrg>----
hrg>По вопросу 2.

hrg>Описание, как методика помогает change management'у не вижу. "на основании
hrg>поступающей информации." — от кого? От заказчика? Программистов?
Не от заказчика — на основании фактического прогресса работ, и обнаруживающихся сложностях/деталях. Почему план более устойчив к изменениям — сказано в первой части — вводной. Отделение целей и компонент от активностей, раз. Отказ от древовидной декомпозиции активностей — два. Перенос активностей на нижний уровень планирования, где им и место — три. Все.

hrg>Т.е. все сводиться к тому, что руководитель получил информацию и
hrg>отрапортовал ее наверх?
Руководитель группы отслеживает работу группы в соостветствии с планом, следит за приоритетами, и меняет план при необходимости. При изменении планов ставит начальство в известность. Ничего феерического и специфичного тут нет — описана обычная работа тимлида. Методика регламентирует формат отчетности, решая проблему переходя от мелких деталей на крупный уровень. Чтобы понять, как то делается, надо приложить пример статус-репорта тим-лида и руководителя направления. Сделаем.

hrg>----
hrg>Вопросы 3-6 — не раскрыты
Возможно, и не раскрыты. Но решены .

hrg>ЗЫ Если посмотреть на RUP, то там все пляски с бубном идут вокруг goals и
hrg>busines-cases (суть, процессов), так что пока ничего революционного нового
hrg>не увидел. Но с нетерпением жду новой редакции методики.

Угумс. Мы не ставим задачу придумать революционно новое — этим пусть теоретики занимаются. Я писал рядом, что в основу методики легли идеи RUP + методы управления для процесса поддержки софта. Нам надо, чтобы планы у нас составлялись быстро и просто, чтобы по плану было ясно, что и зачем люди делают, без плясок с бубном, чтобы репланнинги не убивали разработку на длительный срок, чтобы состовление отчетов о статусе уровня топменеджмента на основании отчетов тимлидов не являлось головной болью с медитацией на несколько часов. Методики, которая все решает эти проблемы — на данный момент не существует. Ну, или она нам неизвестна. Мы, решая свои проблемы, содаем методику (в основном для себя). Если вы знаете, как решаются перечисленные проблемы на практике — вэлкам, расскажите нам.

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


G>Предварительная версия для первичного ознакомления. Без претензии на полноту и непротиворечивость — это внутренняя версия.
G>здесь

G>Пишите, что думаете. Методика проходит сейчас обкатку в боевых условиях, и требует шлифовки.

Компоненты — список составных частей конечного или промежуточных
результатов. Каждая цель относится к одной или нескольким компонентам. Цель,
которая должна быть выпонена для каждой из компонент, помечается признаком
*. Например, “все компонеты успешно проходят автоматические тесты”. Всегда
присутствует компонента ALL — она означает результат в целом. Пример —
“успешно проходят системные тесты”. Список компонент может корректироваться
по ходу работ, не сильно затрагивая структуру плана.

вот этот пункт не очень понятен Не введено понятие цели. И как то все сложно описано

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

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


G>>Предварительная версия для первичного ознакомления. Без претензии на полноту и непротиворечивость — это внутренняя версия.
G>>здесь

G>>Пишите, что думаете. Методика проходит сейчас обкатку в боевых условиях, и требует шлифовки.

I>

I>Компоненты — список составных частей конечного или промежуточных
I>результатов. Каждая цель относится к одной или нескольким компонентам. Цель,
I>которая должна быть выпонена для каждой из компонент, помечается признаком
I>*. Например, “все компонеты успешно проходят автоматические тесты”. Всегда
I>присутствует компонента ALL — она означает результат в целом. Пример —
I>“успешно проходят системные тесты”. Список компонент может корректироваться
I>по ходу работ, не сильно затрагивая структуру плана.

I>вот этот пункт не очень понятен Не введено понятие цели.

Введено выше. Цель — это почти что "событие" в сетевом планировании.

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

I>И как то все сложно описано
Ну, в общем, да. Описано в духе математических статей. Читать надо медленно, вдумчиво — лишнего ничего нет. Сделано так специально — чтобы исключить двойное и неправильное толкование. Этот документ служит в качестве нашего внутреннего справочника, а не обучающего материала. И еще — он не дописан .