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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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