Здравствуйте, ruk, Вы писали:
ruk>Обращаюсь к руководителям проектов (РП(, какую работу вы выполняете. Я в данный момент представляю себе следующую схему: ruk>на вход РП поступают : пожелания пользователей, баги от тестеров. ruk>на выход РП выдает : план — конкретные задачи с расстановкой времени выполнения задач. ruk>соотвественно задача РП заносить в план баги/пожеления оценивать приоритеты и сроки.
— Планирование, составление различных расписаний, "скедюлов", планов
— Разбивка проекта на стадии и определение кретериев их достижения
— Распределение заданий/обязанностей между учасниками проекта.
— Проведение совещаний, текущее оперативное управление проектом.
— Контроль выполнения стадий проекта.
— Всевозможные отчеты, диаграммы и т.д. для руководства, инвесторов ...
— Представительские функции, презентации проекта, и.т.д
По своему опыту скажу, что быть ПМ не так интересно как кажется.
Работа собачья, оплачивается обычно не очень хорошо, очень много
рутины и обязанностей. Для технаря куда как лучше быть архитектором.
ПМ — это для людей ответственных, педантичных, организованных. ПМ
может сильно уступать отдельным участникам команды технически,
главное это организаторские функции. Иногда из плохих программеров
получаются хорошие ПМ, часто наоборот — хороший программер
становится плохим ПМом.
Здравствуйте, ruk, Вы писали:
ruk>Обращаюсь к руководителям проектов (РП(, какую работу вы выполняете. Я в данный момент представляю себе следующую схему: ruk>на вход РП поступают : пожелания пользователей, баги от тестеров. ruk>на выход РП выдает : план — конкретные задачи с расстановкой времени выполнения задач. ruk>соотвественно задача РП заносить в план баги/пожеления оценивать приоритеты и сроки.
На мой взгляд, все обязанности PM-а можно свести к одной универсальной фразе: Основная задача менеджера проектов заключается в раннем распознавании, профилактике и разрешении проектных рисков.
Таким образом, обязанности менеджера зависят от того, сколько рисков он в состоянии видеть. Хороший менеджер видит больше рисков, он обнаруживает их раньше и разрешает быстрее. А вот список самих проектных рисков может быть очень обширным. Наиболее популярные риски:
1. Риск не уложиться в бюджет
2. Риск не уложиться в сроки
3. Плохая обратная связь от заказчика
4. Плохой информационный обмен внутри команды
5. Технические риски
Это далеко не полный список рисков и он может различаться от проекта к проекту. Обязанности менеджера — это все что способствует преодолению рисков. Например, для преодоления рисков 1-2 составляется план проекта. Для преодоления риска 3 (самый сложный, на мой взгляд, риск) составляются планы интервью, составляется список прототипов, которые необходимо разработать, план выпуска промежуточных билдов (с демонстрацией их заказчику), пишутся SRS (system requirements specification), UCS (use-case requirements specification). Если в команде есть аналитик, написание спецификаций — его задача, если нет, то, весьма вероятно, что это задача менеджера. Для разрешения риска 4 разрабатываются методики информационного обмена (напр. митинги, внутренние спецификации, решения сильно зависят от размера команды). Хорошо если в команде есть coach. Если такового нету, то им должен стать PM. Для риска 5 составляется план предпроектных исследований, разрабатываются прототипы.
Уже довольно много, не правда ли? А это только те риски, которые надлежит разрешить еще на этапе старта проекта.
А дальше — больше. Появляются второстепенные риски типа вероятности потерять члена команды или технологические риски:
Ошибки проектирования системы
Ошибки в планировании работ
Ошибки в управлении проектом
Ошибки при внедрении системы
Плохое качество, ненадежность системы, низкая производительность
Плохая интеграция модулей системы
И на каждый риск PM должен заранее составить себе четкий план профилактических мероприятий.
Здравствуйте, mikkri, Вы писали:
M>Здравствуйте, ruk, Вы писали:
ruk>>Обращаюсь к руководителям проектов (РП(, какую работу вы выполняете. Я в данный момент представляю себе следующую схему: ruk>>на вход РП поступают : пожелания пользователей, баги от тестеров. ruk>>на выход РП выдает : план — конкретные задачи с расстановкой времени выполнения задач. ruk>>соотвественно задача РП заносить в план баги/пожеления оценивать приоритеты и сроки.
M>ИМХО, оценки трудоемкости должна предоставлять третья сторона — либо архитектор, либо ведущие разработчики.
Есть такое понятие в менеджменте как делегирование. Это когда ты кому то даешь сделать свою работу, но отвечать за нее продолжаешь все равно ты, тот человек кому делегоровали тоже отвечает но уже перед тобой.
Так вот Estimate (и управление стоимостью вообще) это обязанность PM. Если он видит, что член его команды делает это лучше он ему ее делегирует. Но обязанность это все равно его.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, 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>"Я думаю, что правда о методологиях заключается в том, что их не существует... Есть лишь УПР — удачные проектные решения — которые могут сработать (или нет) в конкретной ситуации и проекте".
Я согласен — но из этого утверждения не следует, что главное это управление рисками. Это неправильный прием полемики "посмотрите я читал вот этого человека значит я прав"
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Spidola, Вы писали:
S>Здравствуйте, ruk, Вы писали:
ruk>>Обращаюсь к руководителям проектов (РП(, какую работу вы выполняете. Я в данный момент представляю себе следующую схему: ruk>>на вход РП поступают : пожелания пользователей, баги от тестеров. ruk>>на выход РП выдает : план — конкретные задачи с расстановкой времени выполнения задач. ruk>>соотвественно задача РП заносить в план баги/пожеления оценивать приоритеты и сроки.
S>ИМХО основная задача РП — управление ресурсами. Административными, техническими, людскими и т.п. Все остальные навыки являются инструментами обеспечения данной задачи.
А помоему основная задача Руководиталя Проекта это руководить проектом, если бы была руководить ресурсом то он так бы и назывался Руководитель ресурсов. Но вообщем управление ресурсами это тоже одна из вещей которой должен PM заниматся. Я выше по теме кидал ссылку.
BTW, крому шуток: Есть такое понятие "Матричная структура оргаанизации". В организациях с матричной структурой есть Руководители проектов(которые ведут проекты забирая для них ресурсы у отделов) и Руководители Отделов которые руководят таки ресурсами.
А вообще что то дискуссия мне начинает напоминать анекдот. "3 слепых слона-мудреца решили понять что же такое человек. Один потрогал его ногой и сказал что человек это что то маленькое и плоское. Два других потрогали и согласились с ним. "
Я про то — что вы гадаете — возьмите любую методику и посмотрите. Все же написано. Удивитесь как много обязанностей. А если например MSF посмотрите удивитесь, что там вообще роли Project Manager нету.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, slskor, Вы писали:
ruk>>Обращаюсь к руководителям проектов (РП(, какую работу вы выполняете. Я в данный момент представляю себе следующую схему: ruk>>на вход РП поступают : пожелания пользователей, баги от тестеров. ruk>>на выход РП выдает : план — конкретные задачи с расстановкой времени выполнения задач. ruk>>соотвественно задача РП заносить в план баги/пожеления оценивать приоритеты и сроки.
S>На мой взгляд, все обязанности PM-а можно свести к одной универсальной фразе: Основная задача менеджера проектов заключается в раннем распознавании, профилактике и разрешении проектных рисков.
На самом деле есть дисциплина Risk Management, но она является всего лишь одной из нескольких дисциплин Project Management.
Что касается самих дисциплин то их проще всего посмотреть в PMBOK. PMBOK это Project Management Body of Knowledge, составляет ее Project Management Institute, эта организация которая с 80 годов занимается дициплиной Project Management. И вообще на западе уже все давно знают что Project Managment это наука и ее нужно изучать — а у нас это словосочетание наверное услышали в первый раз лет 10 назад.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, ruk, Вы писали:
ruk>Обращаюсь к руководителям проектов (РП(, какую работу вы выполняете. Я в данный момент представляю себе следующую схему: ruk>на вход РП поступают : пожелания пользователей, баги от тестеров. ruk>на выход РП выдает : план — конкретные задачи с расстановкой времени выполнения задач. ruk>соотвественно задача РП заносить в план баги/пожеления оценивать приоритеты и сроки.
ИМХО, оценки трудоемкости должна предоставлять третья сторона — либо архитектор, либо ведущие разработчики.
Здравствуйте, ruk, Вы писали:
ruk>Какими навыками должен владеть РП кроме того как использовать sheduller в духе ms project и bug tracking систему. Подозреваю что есть еще такие параметры как общение , т.е. уметь вести беседу и уметь общаться с разработчиками чтобы так скажем при выдвигании требований не задеть их самолюбие и прочим образом не испортить им боевой дух. Или это слишком банально и это не оговаривается ?
Это не банально, а иногда жестокая реальность. Программисты — люди неординарные, т.к. работа творческая, и умение поддержать, воодушевить, или наоборот умерить пыл, иногда очень даже нужно. Особенно с новомодными тенденциями к рефакторингу, когда приходится пинать упрямых фанатиков, чтобы они новый код писали, а не старый вылизывали. Хотя конечно, иногда рефакторинг нужен, но в меру.
Здравствуйте, Anatolix, Вы писали:
A>Здравствуйте, slskor, Вы писали:
S>>На мой взгляд, все обязанности PM-а можно свести к одной универсальной фразе: Основная задача менеджера проектов заключается в раннем распознавании, профилактике и разрешении проектных рисков.
A>На самом деле есть дисциплина Risk Management, но она является всего лишь одной из нескольких дисциплин Project Management.
A>Что касается самих дисциплин то их проще всего посмотреть в PMBOK. PMBOK это Project Management Body of Knowledge, составляет ее Project Management Institute, эта организация которая с 80 годов занимается дициплиной Project Management. И вообще на западе уже все давно знают что Project Managment это наука и ее нужно изучать — а у нас это словосочетание наверное услышали в первый раз лет 10 назад.
У вас прямо-таки академический подоход! Все по полочкам.
Хотите другую точку зрения? Пожалуйста. Я считаю что такой академический подход может быть неэффективным. Допустим, я пишу еженедельный отчет по проделанной работе потому, что в "Project Management: Activity Overview" в RUP нарисовано, что я должен выполнять задачу "Report Status" и руководитель или инженер оп качеству решил, что надо работать в точности по RUP. Однако, если мой отчет никто не читает, то какой смысл делать это? Это неэффективная деятельность, которая отвлекает ресурсы, но, вероятно, не способствует успешному завершению задачи.
Стоит задача: выполнить проект. Есть риск проект не выполнить. Этот крупный риск разбивается на кучу мелких рисков: "мы можем не выполнить проект потому что..." Я как PM делаю только то, что считаю необходимым сделать, на данный момент времени, чтобы снизить риски провалить проект.
Процесс управления в моем случае заключается в постоянном мониторинге рисков. При обнаружении очередного риска я выбираю способ его разрешения по обстоятельствам. При этом могут быть заимствованы приемы из RUP, MSF, XP, FDD, ASD. Мне по барабану как называется методика. Конкретные практики из разных методик вполне могут работать вместе, давая эффективный результат. Думаю, такой подход можно охарактеризовать как risk driven management.
И напрасно вы меня со слоном сравниваете. То что я перечислил, это не просто вспомогательная дисциплина "Risk management", это принципиально другая организация процесса, когда Cost Management или Quality management — это всего лишь частные дисциплины в главной задаче — управлении рисками.
"Я думаю, что правда о методологиях заключается в том, что их не существует... Есть лишь УПР — удачные проектные решения — которые могут сработать (или нет) в конкретной ситуации и проекте".
Здравствуйте, slskor, Вы писали:
S>С чего ты решил что я не знаю что пишется в ТЗ? С чего ты взял, что я не фиксирую требования? Вопрос: чтобы зафиксировать требования малобюджетного проекта, обязательно ТЗ по полной программе писать? А можно просто оттуда один-два раздела выдрать?
Нет не обьязательно. Более того документов как таковых может и не быть вообще. Но процесс есть.
A>>(Конечно есть заказчики которые говорят вот тупо все перехирачить с PHP на JSP — нефиг тут думать — мы вам не за это платим. Но тогда про то что вы занимаетесь менеджментом этого проекта речи не идет.)
S>То есть если не написать ТЗ, но составить список требований, рисков и план работ, то это уже не управление?
Это управление но план работ это планирование, список требований это управление требованиями. Ни то ни другое к рискам непосредственного отношения не имеет.
A>>Ты мне сейчас скажешь ты то же самое сделаешь на рисках. Да можешь. Но во первых тебе это с твоими рисками в голову не пришло сразу.
S>Твоя проблема в том, что ты других людей за недоумков считаешь. Извини, но в SRS на мой текущий проект описаны требования и на окружение и на производительность, и на лицензии. Право же, не знаю, как оно получилось
Нет ни коим образом. Я просто не могу серьезно относиться к заявлению что все управление проектами это управление рисками. Сейчас в результате оказалось что ты и SRS пишешь, и план составляешь — и ты все еще продолжаешь утверждать что кроме рисков в менеджменте ничего нету?
S>Поэтому если ты пишешь отчеты по проекту только для того, чтобы знать, кого потом уволить — пожалуйста. Только при чем здесь проект?
Это ты их пишешь только для этого — у вас же их не читают.
S>Какой-то непродуктивный спор, пойду-ка я отсюда
Спор окончен только не понимаю зачем про риски то было столько зарубаться, чтобы после этого, порвав на груди рубашку, наконец рассказать что еще что то в проекте кроме рисков есть, что нельзя было с самого начала сказать?
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Обращаюсь к руководителям проектов (РП(, какую работу вы выполняете. Я в данный момент представляю себе следующую схему:
на вход РП поступают : пожелания пользователей, баги от тестеров.
на выход РП выдает : план — конкретные задачи с расстановкой времени выполнения задач.
соотвественно задача РП заносить в план баги/пожеления оценивать приоритеты и сроки.
28.11.04 15:04: Перенесено модератором из 'О работе' — Odi$$ey
Здравствуйте, mikkri, Вы писали:
M>Здравствуйте, ruk, Вы писали:
ruk>>Обращаюсь к руководителям проектов (РП(, какую работу вы выполняете. Я в данный момент представляю себе следующую схему: ruk>>на вход РП поступают : пожелания пользователей, баги от тестеров. ruk>>на выход РП выдает : план — конкретные задачи с расстановкой времени выполнения задач. ruk>>соотвественно задача РП заносить в план баги/пожеления оценивать приоритеты и сроки.
M>ИМХО, оценки трудоемкости должна предоставлять третья сторона — либо архитектор, либо ведущие разработчики.
Ну да, согласен, т.е. РП в нестандартных ситуациях, например новая фича которую непонятно как реализовать, советуется непосредственно с теми кто это будет делать. А в некоторых случаях может сам планировать.
Меня интересует охвачен ли весь список задач РП или что-то я упустил из виду.
Какими навыками должен владеть РП кроме того как использовать sheduller в духе ms project и bug tracking систему. Подозреваю что есть еще такие параметры как общение , т.е. уметь вести беседу и уметь общаться с разработчиками чтобы так скажем при выдвигании требований не задеть их самолюбие и прочим образом не испортить им боевой дух. Или это слишком банально и это не оговаривается ?
Здравствуйте, ruk, Вы писали:
ruk>Обращаюсь к руководителям проектов (РП(, какую работу вы выполняете. Я в данный момент представляю себе следующую схему: ruk>на вход РП поступают : пожелания пользователей, баги от тестеров. ruk>на выход РП выдает : план — конкретные задачи с расстановкой времени выполнения задач. ruk>соотвественно задача РП заносить в план баги/пожеления оценивать приоритеты и сроки.
ИМХО основная задача РП — управление ресурсами. Административными, техническими, людскими и т.п. Все остальные навыки являются инструментами обеспечения данной задачи.
Здравствуйте, Anatolix, Вы писали:
A>Здравствуйте, Spidola, Вы писали:
S>>Здравствуйте, ruk, Вы писали:
ruk>>>Обращаюсь к руководителям проектов (РП(, какую работу вы выполняете. Я в данный момент представляю себе следующую схему: ruk>>>на вход РП поступают : пожелания пользователей, баги от тестеров. ruk>>>на выход РП выдает : план — конкретные задачи с расстановкой времени выполнения задач. ruk>>>соотвественно задача РП заносить в план баги/пожеления оценивать приоритеты и сроки.
S>>ИМХО основная задача РП — управление ресурсами. Административными, техническими, людскими и т.п. Все остальные навыки являются инструментами обеспечения данной задачи.
A>А помоему основная задача Руководиталя Проекта это руководить проектом, если бы была руководить ресурсом то он так бы и назывался Руководитель ресурсов.
Логика железная Прямо как "водитель кобылы" вместо "извозчика"...
A>Но вообщем управление ресурсами это тоже одна из вещей которой должен PM заниматся. Я выше по теме кидал ссылку.
Коллега, ну так управление проектом и сводится к управлению ресурсами в рамках данного проекта
A>BTW, крому шуток: Есть такое понятие "Матричная структура оргаанизации". В организациях с матричной структурой есть Руководители проектов(которые ведут проекты забирая для них ресурсы у отделов) и Руководители Отделов которые руководят таки ресурсами.
В матричной структуре как раз функция управления ресурсами ИМХО больше всего и проявляется у РП, поскольку у руководителей отделов РП фактически выкупает нужных людей... Почти хозрасчёт.
A>Я про то — что вы гадаете — возьмите любую методику и посмотрите. Все же написано. Удивитесь как много обязанностей. А если например MSF посмотрите удивитесь, что там вообще роли Project Manager нету.
Думаю, что коллега хочет понять обязанности руководителя проектов в реальном контексте, поскольку теоретические выкладки — они конечно хороши, но только их маловато для понимания...
2RUK: рекомендую попробовать познакомиться с реальными РП более тесно и пообщаться с ними приватно — куда как больше информации получите, нежели на форуме. Познакомиться можно на какой-нибудь сходке типа конференции или вроде того...
Здравствуйте, Anatolix, Вы писали:
A>Есть такое понятие в менеджменте как делегирование. Это когда ты кому то даешь сделать свою работу, но отвечать за нее продолжаешь все равно ты, тот человек кому делегоровали тоже отвечает но уже перед тобой.
Здравствуйте, Anatolix, Вы писали:
A>Я про то — что вы гадаете — возьмите любую методику и посмотрите. Все же написано. Удивитесь как много обязанностей.
Можно поинтересоваться, о каких конкретно методиках речь, где написано?
Hello, slskor!
You wrote on Tue, 05 Oct 2004 11:08:34 GMT:
s> Здравствуйте, Anatolix, Вы писали:
A>> Я про то — что вы гадаете — возьмите любую методику и посмотрите. Все A>> же написано. Удивитесь как много обязанностей.
s> Можно поинтересоваться, о каких конкретно методиках речь, где написано?
Здравствуйте, s.ts, Вы писали:
ST>Hello, slskor! ST>You wrote on Tue, 05 Oct 2004 11:08:34 GMT:
A>>> Я про то — что вы гадаете — возьмите любую методику и посмотрите. Все A>>> же написано. Удивитесь как много обязанностей.
s>> Можно поинтересоваться, о каких конкретно методиках речь, где написано?
ST>RUP, MSF, XP...
Ну, с RUP-то все понятно, это не ново и не интересно. А где в XP описаны обязанности менеджера? Ссылка есть?
Hello, slskor!
You wrote on Tue, 05 Oct 2004 12:06:23 GMT:
s> Здравствуйте, s.ts, Вы писали:
ST>> Hello, slskor! ST>> You wrote on Tue, 05 Oct 2004 11:08:34 GMT:
A>>>> Я про то — что вы гадаете — возьмите любую методику и посмотрите. Все A>>>> же написано. Удивитесь как много обязанностей.
s>>> Можно поинтересоваться, о каких конкретно методиках речь, где s>>> написано?
ST>> RUP, MSF, XP...
s> Ну, с RUP-то все понятно, это не ново и не интересно. А где в XP описаны s> обязанности менеджера? Ссылка есть?
A>А вообще что то дискуссия мне начинает напоминать анекдот. "3 слепых слона-мудреца решили понять что же такое человек. Один потрогал его ногой и сказал что человек это что то маленькое и плоское. Два других потрогали и согласились с ним. "
Здравствуйте, ruk, Вы писали:
ruk>Обращаюсь к руководителям проектов (РП(, какую работу вы выполняете. Я в данный момент представляю себе следующую схему: ruk>на вход РП поступают : пожелания пользователей, баги от тестеров. ruk>на выход РП выдает : план — конкретные задачи с расстановкой времени выполнения задач. ruk>соотвественно задача РП заносить в план баги/пожеления оценивать приоритеты и сроки.
Здравствуйте, s.ts, Вы писали:
ST>xp — это методика под лозунгами agile software development: ST>подробнее на http://www.xprogramming.ru/ — там и ссылки на другие сайты
Это называется "послать в пространство"
Что такое XP я знаю наверняка не хуже вас. А вот о том, что в XP каким-то образом регламентирована деятельность PM услышал в первый раз и подозреваю что это неправда.
и умение поддержать, воодушевить, или наоборот умерить пыл, иногда очень даже нужно. Особенно с новомодными тенденциями к рефакторингу, когда приходится пинать упрямых фанатиков, чтобы они новый код писали, а не старый вылизывали.
Почему новомодными? Раньше код не вылизывали? А, понимаю — раньше сразу вылизанный писали
Здравствуйте, slskor, Вы писали:
S>Здравствуйте, s.ts, Вы писали:
ST>>xp — это методика под лозунгами agile software development: ST>>подробнее на http://www.xprogramming.ru/ — там и ссылки на другие сайты
S>Это называется "послать в пространство"
S>Что такое XP я знаю наверняка не хуже вас.
Немудрено. Я-то совсем почти не знаю
S>А вот о том, что в XP каким-то образом регламентирована деятельность PM услышал в первый раз и подозреваю что это неправда.
Не только в XP. Как уже было сказано, в MSF похожая ситуация.
Так что остается Вам RUP.
S>"Я думаю, что правда о методологиях заключается в том, что их не существует... Есть лишь УПР — удачные проектные решения — которые могут сработать (или нет) в конкретной ситуации и проекте".
S>Немножко категорично, но близко к правде.
Совершенно верно.
Вот и представители IBM, когда рекламируют свой RUP говорят: "Это всего лишь best practices".
Здравствуйте, 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 — это не методология, а просто набор решений на все случаи жизни. По этой же причине полный список задач, выполняемых менеджером, безусловно полезнен в общеобразовательном плане, но, трудновыполним в практическом.
Поэтому если ты пишешь отчеты по проекту только для того, чтобы знать, кого потом уволить — пожалуйста. Только при чем здесь проект?
A>>>>Ты понимаешь риск это такая штука которая либо произойдет либо нет. S>Спасибо, кстати, за откровение
прикольно получилось!
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
А это только те риски, которые надлежит разрешить еще на этапе старта проекта.
