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

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

Почему новомодными? Раньше код не вылизывали? А, понимаю — раньше сразу вылизанный писали

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

S>Здравствуйте, s.ts, Вы писали:

ST>>xp — это методика под лозунгами agile software development:
ST>>подробнее на http://www.xprogramming.ru/ — там и ссылки на другие сайты

S>Это называется "послать в пространство"

S>Что такое XP я знаю наверняка не хуже вас.

Немудрено. Я-то совсем почти не знаю

S>А вот о том, что в XP каким-то образом регламентирована деятельность PM услышал в первый раз и подозреваю что это неправда.

Не только в XP. Как уже было сказано, в MSF похожая ситуация.
Так что остается Вам RUP.

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


S>"Я думаю, что правда о методологиях заключается в том, что их не существует... Есть лишь УПР — удачные проектные решения — которые могут сработать (или нет) в конкретной ситуации и проекте".

S>Немножко категорично, но близко к правде.

Совершенно верно.
Вот и представители IBM, когда рекламируют свой RUP говорят: "Это всего лишь best practices".

На самом деле никто и не претендует ...

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

S>Хотите другую точку зрения? Пожалуйста. Я считаю что такой академический подход может быть неэффективным.

А никто и не обещал.

S>Допустим, я пишу еженедельный отчет по проделанной работе потому, что в "Project Management: Activity Overview" в RUP нарисовано, что я должен выполнять задачу "Report Status" и руководитель или инженер оп качеству решил, что надо работать в точности по RUP. Однако, если мой отчет никто не читает, то какой смысл делать это? Это неэффективная деятельность, которая отвлекает ресурсы, но, вероятно, не способствует успешному завершению задачи.

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

S>Стоит задача: выполнить проект. Есть риск проект не выполнить. Этот крупный риск разбивается на кучу мелких рисков: "мы можем не выполнить проект потому что..." Я как PM делаю только то, что считаю необходимым сделать, на данный момент времени, чтобы снизить риски провалить проект.

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

Например такая дициплина как управление требованиями, в которую входит например написание ТЗ или XP Stories это почти обязательное условие успешного проекта — нельзя сделать что-то не поняв что именно нужно сделать. Безусловно то что мы не понимаем что нужно сделать можно считать риском, но что делать нужно от этого не становится понятно.

Ну т.е. от того что ты чего то боишься риск меньше не становится — риски либо уменьшают по вероятности либо снижают действие risk impact. И методики здесь почти стандартные.

S>Процесс управления в моем случае заключается в постоянном мониторинге рисков. При обнаружении очередного риска я выбираю способ его разрешения по обстоятельствам. При этом могут быть заимствованы приемы из RUP, MSF, XP, FDD, ASD. Мне по барабану как называется методика. Конкретные практики из разных методик вполне могут работать вместе, давая эффективный результат. Думаю, такой подход можно охарактеризовать как risk driven management.

Вопрос: у тебя нет ТЗ и ты не знаешь что нужно делать как ты поймешь что может тебе помешать? Если у тебя все-таки есть ТЗ или требования значет у тебя есть и процесс соотвествующий. Т.е. подкова помогает вне зависимости от того верят в нее или нет

S>И напрасно вы меня со слоном сравниваете. То что я перечислил, это не просто вспомогательная дисциплина "Risk management", это принципиально другая организация процесса, когда Cost Management или Quality management — это всего лишь частные дисциплины в главной задаче — управлении рисками.

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

С какого то уровня люди не считают свою возможность выполнить проект вероятностной — и риски становятся маленькие и выражающиеся в деньгах или днях работы. Т.е. риска что проект завалится у них нету — есть например риск что они выполнят проект на 4 дня позже.

S>Вообще же я считаю себя сторонником точки зрения господина Белинского (http://www.gotdotnet.ru/LearnDotNet/Misc/55244.aspx):

S>"Я думаю, что правда о методологиях заключается в том, что их не существует... Есть лишь УПР — удачные проектные решения — которые могут сработать (или нет) в конкретной ситуации и проекте".

Я согласен — но из этого утверждения не следует, что главное это управление рисками. Это неправильный прием полемики "посмотрите я читал вот этого человека значит я прав"

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

S>>А вот о том, что в XP каким-то образом регламентирована деятельность PM услышал в первый раз и подозреваю что это неправда.

В XP она действительно не регламентирована.

ST>Не только в XP. Как уже было сказано, в MSF похожая ситуация.
ST>Так что остается Вам RUP.

В MSF нету роли PM-а там есть ролевые кластеры управление программой и управление продуктом которые делают вместе сходную работу. Можно прочитать их задачи.

В том же PMBOK можешь посмотреть — могу выслать если надо

Кроме того стандарты типа CMM неплохо описывают то что должно делаться в проекте и если посмотреть Level 2 и 3 то это почти голимые обязанности PM-а.

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

A>Вопрос: у тебя нет ТЗ и ты не знаешь что нужно делать как ты поймешь что может тебе помешать? Если у тебя все-таки есть ТЗ или требования значет у тебя есть и процесс соотвествующий. Т.е. подкова помогает вне зависимости от того верят в нее или нет

...и потому пора рубить просеки и ставить над хижинами палки...

Попробуйте составить такой список:

— Название риска для конкретной стадии конкретного проекта при конкретном составе команды
— Вероятность риска
— Уровень последствий для проекта
— Типовые методы, применяемые для разрешения данного риска.

(подобный список я начинаю составлять сразу как прочитаю то, что заказчик выдает за ТЗ)

После этого обнаружится вдруг, что из всех activities менеджера есть критически важные, а есть те, которые можно исключить без последствий. И вот так вот обнаружится вдруг, что в задаче портирования приложения с PHP на JSP as is, необходимость в задаче разработки ТЗ близка к нулю и подкова ваша нафиг не нужна, но денег/времени стоит.

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

Ну и? Делаем очередной review списка рисков и вычеркиваем ненужное, делая акцент на том что осталось, добавляя если есть что добавить. По идее, после того как 20% проекта выполнено, должно быть разрешено не менее 80% рисков.

A>С какого то уровня люди не считают свою возможность выполнить проект вероятностной — и риски становятся маленькие и выражающиеся в деньгах или днях работы. Т.е. риска что проект завалится у них нету

Возможно, что есть менеджеры, у которых рисков нету. Но это не те менеджеры, которые считают, что у них рисков нету.

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

S>После этого обнаружится вдруг, что из всех activities менеджера есть критически важные, а есть те, которые можно исключить без последствий. И вот так вот обнаружится вдруг, что в задаче портирования приложения с PHP на JSP as is, необходимость в задаче разработки ТЗ близка к нулю и подкова ваша нафиг не нужна, но денег/времени стоит.

Ну вот если ты так ведешь подобный проект то ты уже ставишь его под угрозу потому что со своими рисками ты так и не понял знаешь о том что пишется в ТЗ. Здесь дейстивтельно не будет в явной форме функциональных требований, т.к. они описываются прототипом, но будут так называемые общие требования
1) Требования к производительности. Нужно описать какая она должна быть, архитектура сильно различается. (В твоих выражениях рисков это значит например что главная страничка будет формироваться 20 секунд хотя раньше была за 0.5 т.к. архитекутра поменялась)
2) Требования к Environment, например большая часть хостинга сейчас работает на FreeBSD где Java уродская и MySQL версии 3 без поддержки UNICODE всяких. (Риск сделаете проект и не сможете его поставить у большей части клиентов). Требования к памяти опять же — Java ее любит
3) Требования к лицензиям. Например PHP бесплатен весь под Java есть весьма платные вещи нужно разбираться что можно использовать что нет.

(Конечно есть заказчики которые говорят вот тупо все перехирачить с PHP на JSP — нефиг тут думать — мы вам не за это платим. Но тогда про то что вы занимаетесь менеджментом этого проекта речи не идет.)

Так вот 3 пункта это я тебе просто процитировал не придумывая их — они обязательные для заполнения в ТЗ которая написано в соответсвии со стандартом IEEE что то там. Т.е. условно есть checklist на который можно посмотреть и выкинуть требования которые там не нужны, а остальное описать.

Ты мне сейчас скажешь ты то же самое сделаешь на рисках. Да можешь. Но во первых тебе это с твоими рисками в голову не пришло сразу. Во вторых [jnz для рисков тоже есть стандартные наборы рисков. Но вот чего нибудь подобного ты там не найдешь — т.к. это не совсем из той области.


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

A>>С какого то уровня люди не считают свою возможность выполнить проект вероятностной — и риски становятся маленькие и выражающиеся в деньгах или днях работы. Т.е. риска что проект завалится у них нету

S>Возможно, что есть менеджеры, у которых рисков нету. Но это не те менеджеры, которые считают, что у них рисков нету.

Скажем так есть менеджеры которые написание ТЗ не считают на столько рискованным мероприятием чтобы им как риском управлять.

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

S>>После этого обнаружится вдруг, что из всех activities менеджера есть критически важные, а есть те, которые можно исключить без последствий. И вот так вот обнаружится вдруг, что в задаче портирования приложения с PHP на JSP as is, необходимость в задаче разработки ТЗ близка к нулю и подкова ваша нафиг не нужна, но денег/времени стоит.

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

С чего ты решил что я не знаю что пишется в ТЗ? С чего ты взял, что я не фиксирую требования? Вопрос: чтобы зафиксировать требования малобюджетного проекта, обязательно ТЗ по полной программе писать? А можно просто оттуда один-два раздела выдрать?

A>(Конечно есть заказчики которые говорят вот тупо все перехирачить с PHP на JSP — нефиг тут думать — мы вам не за это платим. Но тогда про то что вы занимаетесь менеджментом этого проекта речи не идет.)

То есть если не написать ТЗ, но составить список требований, рисков и план работ, то это уже не управление?

A>Ты мне сейчас скажешь ты то же самое сделаешь на рисках. Да можешь. Но во первых тебе это с твоими рисками в голову не пришло сразу.

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

Кстати, мне бы и вправду в голову не пришло, что кто-то станет хостить Java-приложение на FreeBSD. Пусть сперва хостера-камикадзе найдет. И мне как-то в голову не пришла мысль о том, что можно использовать в проекте платные продукты без согласования с заказчиком. И, по секрету скажу, голый PHP от голого JSP мало чем отличается.

A>>>Ты понимаешь риск это такая штука которая либо произойдет либо нет.

Спасибо, кстати, за откровение

A>>>С какого то уровня люди не считают свою возможность выполнить проект вероятностной — и риски становятся маленькие и выражающиеся в деньгах или днях работы. Т.е. риска что проект завалится у них нету

S>>Возможно, что есть менеджеры, у которых рисков нету. Но это не те менеджеры, которые считают, что у них рисков нету.

A>Скажем так есть менеджеры которые написание ТЗ не считают на столько рискованным мероприятием чтобы им как риском управлять.

Эк тебя на ТЗ переклинило. Речь-то не об этом была.

Скажем так, есть менеджеры, которые понимают, что из ~50 RUP-овских шаблонов на большинство проектов среднего уровня сложности хватит 5-6 документов. И количество разделов в этих документах можно очень сильно сократить, потому что RUP — это не методология, а просто набор решений на все случаи жизни. По этой же причине полный список задач, выполняемых менеджером, безусловно полезнен в общеобразовательном плане, но, трудновыполним в практическом.

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

Какой-то непродуктивный спор, пойду-ка я отсюда

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

S>С чего ты решил что я не знаю что пишется в ТЗ? С чего ты взял, что я не фиксирую требования? Вопрос: чтобы зафиксировать требования малобюджетного проекта, обязательно ТЗ по полной программе писать? А можно просто оттуда один-два раздела выдрать?

Нет не обьязательно. Более того документов как таковых может и не быть вообще. Но процесс есть.

A>>(Конечно есть заказчики которые говорят вот тупо все перехирачить с PHP на JSP — нефиг тут думать — мы вам не за это платим. Но тогда про то что вы занимаетесь менеджментом этого проекта речи не идет.)

S>То есть если не написать ТЗ, но составить список требований, рисков и план работ, то это уже не управление?

Это управление но план работ это планирование, список требований это управление требованиями. Ни то ни другое к рискам непосредственного отношения не имеет.

A>>Ты мне сейчас скажешь ты то же самое сделаешь на рисках. Да можешь. Но во первых тебе это с твоими рисками в голову не пришло сразу.

S>Твоя проблема в том, что ты других людей за недоумков считаешь. Извини, но в SRS на мой текущий проект описаны требования и на окружение и на производительность, и на лицензии. Право же, не знаю, как оно получилось

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

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

Это ты их пишешь только для этого — у вас же их не читают.

S>Какой-то непродуктивный спор, пойду-ка я отсюда

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

A>>>>Ты понимаешь риск это такая штука которая либо произойдет либо нет.
S>Спасибо, кстати, за откровение
прикольно получилось!