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

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

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

G>А еще над методикой работал Garrr, в соавторстве. Он мой зам по организации работ. Так что это метод не только Гапертона, но и Гаррра. Вот.

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

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

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

G>> А ты когда-нибудь таблицу рисков реального проекта видел?

MP>Кстати, не могли бы вы показать пример такой таблицы? Или сказать, где посмотреть. А то нас с прописыванием рисков не очень хорошо, и у меня в голове пока только астрактные варианты типа "ведущий программист попадет под машину". А хочется более качественного понимания.

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

Таблица рисков — это то как раз касается варианта "либо". Именно так учат составлять планы в военных академиях. План, говорят там, это просто: "ситуация — твои действия. Ситуация — твои действия. Ситуация — твои действия". Обыкновенно, такие таблицы осмыслены для крупных и длительных проектов. На уровне тимлида такие таблицы редко бывают содержательными. Пример такого риска — вы построили план разработки с учетом того, что запланировали нанять, допустим, 15 человек в ближайшие полгода. Что, если вы наймете только 5 из них? Что делать будем, и как скорректируем план? Будем резать функционал? Как? Воспользуемся покупным решением вместо того, чтобы делать подсистему самим? Каким именно? Еще пример — через два месяца выяснится, что выбранная вами технология не подходит для решаемой задачи — вы чуствуете, что такое вполне может быть. Что делать будем? Жопа? Нет, проект должен продолжится, и вы внятно должны объяснить, как вы планируете привести его к успеху.

Таблица имеет колонки: Ситуация, Вероятность (Высокая, средняя, низкая — три варианта, не надо умничать), Значимость (Высокая, средняя, низкая — в какой степени это поставит под угрозу весь проект), Действия (как по предотвращению ситуации, так и в самой ситуации). И все.

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

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

Самый простой, тупой и эффективный метод количественно оценить влияние рисков на сроки — это PERT Estimation. Метод детально описан в моих ранних постах. Ну, и в литературе тоже .

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

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

G>А еще над методикой работал Garrr, в соавторстве. Он мой зам по организации работ. Так что это метод не только Гапертона, но и Гаррра. Вот.

сокращенно метод га-га. жалко, что у вас какого-нибуть булычева в тиме не было.

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

B>Кстати, некоторые и твои, и Гара сообщения, как раз таки и можно было отнести к тем сообщениям, которые я имел в виду. А вообще, сообщения и документы все мы пишем иногда лучше, иногда хуже...

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

Далее, на самом деле эта ветка — в некотором роде фальстарт. Есть желание выпустить на обсуждение общественности _всю_ методику в целом, а не только отдельные ее части, такие как:
1) Методика планирования
2) Методика контроля работ, планов и отчетности
3) Методика комплексной оценки объемов и качества работ (в том числе сбор и анализ метрик, формальные инспекции)
4) Описание сипользуемой системы groupware, ее связь с принятыми процессами разработки
5) Применяемые в коллективе процессы разработки и сопровождающие процедуры (flow, перекрестные проверки, билд-сервера и т.д.)

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

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

G>> А ты когда-нибудь таблицу рисков реального проекта видел?

MP>Кстати, не могли бы вы показать пример такой таблицы? Или сказать, где посмотреть. А то нас с прописыванием рисков не очень хорошо, и у меня в голове пока только астрактные варианты типа "ведущий программист попадет под машину". А хочется более качественного понимания.

Есть предложение почитать "Вальсируя с медведями" ДеМарко. Неплохо написано про количественную оценку рисков и сроков проекта. А также скачать их софт с www.pmo.ru/riskology/ и/или www.systemsguild.com/riskology/.

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


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

а не громко ли названо "методика"?

некоторые сообщения на этом форуме тянут на методику куда больше, чем этот документ.

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

LD>Ребят, вы про управление рисками вообще слышали?

Re: Планирование рисков

Автор: Gaperton
Дата: 17.07.03

LD>>Ребят, вы про управление рисками вообще слышали?

OE>Re: Планирование рисков

Автор: Gaperton
Дата: 17.07.03

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

Обыкновенно под риском понимается вероятность срыва графика/превышения бюджета

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

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

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

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

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

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

RS>4. Какого рода в русском языке компоненты? Мужского "компонент" или женского "компонента"? По-моему у вас в статье и так и сяк бывает :)

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

Здравствуйте, 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 — рассуждение в терминах введенных нами понятий смещает фокус внимания в интересную и полезную, как нам кажется, сторону.

Здравствуйте, 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>Пишите, что думаете. Методика проходит сейчас обкатку в боевых условиях, и требует шлифовки.

Очень не хватает примера карты.

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

G>Ну давай, пиши комменты, штоль .

1. Маза с планированием целей вообще и концепция карты целей в частности мне понравиласть. Интуитивно я что-то похожее использовал, но у вас хорошо получилось формализовать.

2. С компонентами у меня ясности нет. Видимо потому,что последнее время работаю не над коробочными проектами а над внутренними. Тут не всегда чётко определено соответствие между целями и компоненами. Одной и той же цели можно достигнуть разными путями, зачастую через развитие разных компонент. Может ли ваша методика помочь в выявлении оптимального разбиенмя проекта на компоненты и определения какие компоненты относятся к каким целям или это вне scope (моя по-русски плохо)

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

4. Какого рода в русском языке компоненты? Мужского "компонент" или женского "компонента"? По-моему у вас в статье и так и сяк бывает

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

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

Интересный пример. Меня бы устроил

G>Чукча не читатель, чукча читатель

И правильно. Я и сам падежов не знаю.

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

OE>>Re: Планирование рисков

Автор: Gaperton
Дата: 17.07.03

LD>маленькая такая деталь... в зависимости от того, реализовался ли риск или нет, список задач сильно меняется.

Ой, свят-свят. Оказывается — из-за рисков сроки проектов предсказывать и планы составлять невозможно в принципе.

LD>>>Ребят, вы про управление рисками вообще слышали?

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

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

G> А ты когда-нибудь таблицу рисков реального проекта видел?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

I>

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

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

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

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

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

А еще над методикой работал Garrr, в соавторстве. Он мой зам по организации работ. Так что это метод не только Гапертона, но и Гаррра. Вот.

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

iT>А ничего, что это ДСП?
Древесно-Стружечная Плита? Да ничо так, нормально

iT>Еще.. эта.. картинки хочется посмотреть
Погодите, статью готовим. Разумеется, реальные планы я выложить для примера не могу.

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

iT>А ничего, что это ДСП?
Никакой не ДСП. Статья типическая. Даже аннотация есть. Вот:

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

G>здесь
Не открывается файл-то . Можно на мыло копию получить?

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

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


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

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

MP>Очень не хватает примера карты.

Делаем. Скоро выложим примеры карт и таймлайнов.

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


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

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

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


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

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

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

Хе, прикольно А я, как ты вероятно догадался, тот самый Влад.

Копию получил? Ну давай, пиши комменты, штоль .

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


G>Хе, прикольно А я, как ты вероятно догадался, тот самый Влад.
Я знал

G>Копию получил? Ну давай, пиши комменты, штоль .
Получил. Пойду читать

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

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

B>а не громко ли названо "методика"?

Хотите поговорить об этом?

B>некоторые сообщения на этом форуме тянут на методику куда больше, чем этот документ.

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

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

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

Обидчивые какие....

По существу вопроса, хотелось бы увидеть в выложеном документе существенное что-то, а пока, от вас с Гаром еще одно пафосное сообщение получилось в погоне за рейтингом.

Короче, плиз цитату в студию, тянущую на инструкцию или методику!

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

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

Кстати, некоторые и твои, и Гара сообщения, как раз таки и можно было отнести к тем сообщениям, которые я имел в виду. А вообще, сообщения и документы все мы пишем иногда лучше, иногда хуже...

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

B>По существу вопроса, хотелось бы увидеть в выложеном документе существенное что-то, а пока, от вас с Гаром еще одно пафосное сообщение получилось в погоне за рейтингом.

B>Короче, плиз цитату в студию, тянущую на инструкцию или методику!

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

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

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

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

B>Кстати, некоторые и твои, и Гара сообщения, как раз таки и можно было отнести к тем сообщениям, которые я имел в виду. А вообще, сообщения и документы все мы пишем иногда лучше, иногда хуже...

Ну, короче понятно — КГ/АМ . Bralgin, в аттаче головного письма находится слегка подправленная внутренняя инструкция нашего отдела, по которой наш отдел уже работает. У нас не литературный кружок — извини, у нас все инструкции краткие и коспективные, фиксирующие основные моменты и определения. В ней пока не хватает примеров планов (картинок) — так мы не можем здесь наши реальные планы выкладывать, причину, я надеюсь, ты понимаешь? Гар сейчас их рисует, и мы выложим.

А вообще прав был Гар, нефиг было выкладывать. Так меня Локотков попросил в соседнем треде, я и выложил, по доброте душевной .

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

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

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

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

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

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

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

А>Скажем если вы сертифицируетесь на CMMI,
А>то вы обязаны описать весь процесс на бумаге.
А>Включая то, как вы планируете проекты.
А это интересная мысль!

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

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

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

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

А>Скажем если вы сертифицируетесь на CMMI,
А>то вы обязаны описать весь процесс на бумаге.
А>Включая то, как вы планируете проекты.
Ну народ — вы даете. Да, да. То же самое относится к сертификации по ISO. Однако, мы не можем показывать эти материалы наружу, и выкладывать их на форум — в любом случае. Точное описание процессов и процедур компании покрывается условиями неразглашения. Точное описание оргструктуры и должностных инструкций — тоже покрывается условиями неразглашения.

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

А>Конечно интересно почитать как это делается в других конторах,
А>даже если материал и сыроват.

Детальных пошаговых инструкций (process scripts) вы не получите в любом случае. По озвученным мной причинам. Прошу отнестись с пониманием.

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

RS>1. Маза с планированием целей вообще и концепция карты целей в частности мне понравиласть. Интуитивно я что-то похожее использовал, но у вас хорошо получилось формализовать.
Мы долго думали над формами планирования и отчетности. Предыстория такова, что ранее использовались другие подходы, но они в процессе работы свелись именно к карте целей + timeline. Нам оставалось только обобщить опыт одного успешного проекта

RS>2. С компонентами у меня ясности нет. Видимо потому,что последнее время работаю не над коробочными проектами а над внутренними. Тут не всегда чётко определено соответствие между целями и компоненами. Одной и той же цели можно достигнуть разными путями, зачастую через развитие разных компонент. Может ли ваша методика помочь в выявлении оптимального разбиенмя проекта на компоненты и определения какие компоненты относятся к каким целям или это вне scope (моя по-русски плохо)
Оптимальное разбиение продукта на компоненты могут сделать только инженеры. Они больше в теме. Определение связей "компонент-цель" происходит само-собой, когда карта целей уже готова — глядя на нее правильные ответы приходят в голову сами собой.

RS>3. Хорошо бы пример помасштабнее чем тот что есть с тремя целями. Понимаю что внутренние проекты разглашать нельзя, а выдуманные примеры редко хорошо отражают реальность,но тем не менее без примеров читателям не так хорошо понятна маза как писателям
Думаем. Работы много, руки не доходят до отвлеченного примера. Вас бы устроил план превращения команды бывших студентов в высокоорганизованную группу программистов, работащих с использованием формальных процессов? Мы планируем построить наш поясняющий пример именно на этой ситуации.

RS>4. Какого рода в русском языке компоненты? Мужского "компонент" или женского "компонента"? По-моему у вас в статье и так и сяк бывает
Чукча не читатель, чукча читатель

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

RS>1. Маза с планированием целей вообще и концепция карты целей в частности мне понравиласть. Интуитивно я что-то похожее использовал, но у вас хорошо получилось формализовать.

Мы сами протащились. Карты целей особенно круты при планировании архитектурной фазы, где планирование от активностей сосет с причмокиванием — такие планы всегда расходятся. Второй плюс такого подхода — карта целей может применяться как для описания шаблона development flow, т.е. процесса, так и для плана работ. А это — то, о чем я долго мечтал. Это позволяет планировать те области деятельности, для которых процесса разработки не существует вообще — так как метод позволяет тебе конструировать этот процесс заново для каждого конкретного случая. А это незаменимо для исследовательских и высокорискованных проектов.

RS>2. С компонентами у меня ясности нет. Видимо потому,что последнее время работаю не над коробочными проектами а над внутренними. Тут не всегда чётко определено соответствие между целями и компоненами. Одной и той же цели можно достигнуть разными путями, зачастую через развитие разных компонент.

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

RS> Может ли ваша методика помочь в выявлении оптимального разбиенмя проекта на компоненты и определения какие компоненты относятся к каким целям или это вне scope (моя по-русски плохо)

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

Смысл выделения компонент вообще — следующий:
1) Пересечение компонент и целей формирует задачи.
2) Есть свойства, принадлежащие именно копонентам. Без выделения компонент сложно запланировать объем работ и оценить риски — это свойства именно компонент, а не целей.
3) Методика позволяет определить, какие компоненты/фичи/функциональные блоки включать в релиз, а какие нет — на основе анализа рисков и важности. Это описано в документе. Это влияет на приоритетность целей.

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

В качестве примера мы хотим привести наш план внедрения формализованного процесса. Не совсем разработка, но тем прикольнее. И еще — план работы над одним исследовательским проектом. Хотя тебе, дорогой друг, на условиях NDA я могу выслать реальные планы. Мне действително важно твое мнение.

RS>4. Какого рода в русском языке компоненты? Мужского "компонент" или женского "компонента"? По-моему у вас в статье и так и сяк бывает

Да хрен его знает . Надо подумать об этом.

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

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

Неразглашение могу обещать. Так что шли планы.

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

RS>>4. Какого рода в русском языке компоненты? Мужского "компонент" или женского "компонента"? По-моему у вас в статье и так и сяк бывает

G>Да хрен его знает . Надо подумать об этом.

А это как комплексный и комплексный. Первое — норма, второе — математический жаргон. Так и с компонентами: у вектора компонента, а у всего остального компонент.

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

B>>а не громко ли названо "методика"?

G>Хотите поговорить об этом?

B>>некоторые сообщения на этом форуме тянут на методику куда больше, чем этот документ.

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

Ребят, вы про управление рисками вообще слышали?

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

BK>Здравствуйте, Mikhail Polykovsky, Вы писали:

G>>> А ты когда-нибудь таблицу рисков реального проекта видел?

MP>>Кстати, не могли бы вы показать пример такой таблицы? Или сказать, где посмотреть. А то нас с прописыванием рисков не очень хорошо, и у меня в голове пока только астрактные варианты типа "ведущий программист попадет под машину". А хочется более качественного понимания.

BK>Есть предложение почитать "Вальсируя с медведями" ДеМарко. Неплохо написано про количественную оценку рисков и сроков проекта. А также скачать их софт с www.pmo.ru/riskology/ и/или www.systemsguild.com/riskology/.

Спасибо, почитаю.

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

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

G>>> А ты когда-нибудь таблицу рисков реального проекта видел?

MP>>Кстати, не могли бы вы показать пример такой таблицы? Или сказать, где посмотреть. А то нас с прописыванием рисков не очень хорошо, и у меня в голове пока только астрактные варианты типа "ведущий программист попадет под машину". А хочется более качественного понимания.

G>Таблица имеет колонки: Ситуация, Вероятность (Высокая, средняя, низкая — три варианта, не надо умничать), Значимость (Высокая, средняя, низкая — в какой степени это поставит под угрозу весь проект), Действия (как по предотвращению ситуации, так и в самой ситуации). И все.

G>По заполненной таблице вы в состоянии проверить адекватность выбранной вами стратегии разработки — для этого в основном таблица и нужна. Таким образом — в основном это полезно разработчикам стратегии.

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

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". Только выполнение этой цели уже не в нашей власти и потому эта цель немного выподает из общей картины.

Привет,

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

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

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

Здравствуйте, 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, Вы писали:

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 — она означает результат в целом. Пример —
“успешно проходят системные тесты”. Список компонент может корректироваться
по ходу работ, не сильно затрагивая структуру плана.

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

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

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

Ну, примерно так, штоли.
http://rsdn.ru/Forum/Message.aspx?mid=2341277&only=1

Автор: Gaperton
Дата: 08.02.07