| Результаты опроса: Должен ли руководитель проекта знать систему, которую внедряет? | |||
| Да, должен знать очень подробно |      | 32 | 28.32% | 
| Да, должен знать |      | 37 | 32.74% | 
| Да, должен знать в общих чертах, чтобы понять где ему мозги канифолят |      | 41 | 36.28% | 
| Нет, не должен |      | 3 | 2.65% | 
| Не знаю |      | 0 | 0% | 
| Голосовавшие: 113. Вы ещё не голосовали в этом опросе | |||
|  | Опции темы | 
|  22.04.2005, 15:45 | #41 | 
| Участник | 
			
			Ответил "должен знать очень подробно" Отчасти согласен и с mazzy - РП должен разбираться в людях и уметь заставить свою команду работать. Должен разделить сферы отетственности, расставить сроки, разрулить вопросы с заказчиком и пр. Но вместе с тем, считаю что РП должен быть в первую очередь архитектором системы. А для этого он должен знать функционал лучше чем кто-либо в его команде. | 
|  | 
|  22.04.2005, 15:49 | #42 | 
| NavAx | 
			
			Оч веселая ситуация получается, когда клиент предлагает ПМ'у сделать доработку, ПМ, не особо представляя, о чем речь, соглашается, а потом оказывается, что для выполнения доработки нужно долго и упорно копаться в глубине системы и доработка занимает не 2 дня, как ожидалось, а два месяца... (был такой тяжелый случай, когда в консалтинговой конторе работал)
		 
				__________________ "Моей лошадке ядрышком полмордочки снесло..." А.В.Суворов, письма к дочери | 
|  | 
|  22.04.2005, 16:03 | #43 | 
| Участник | Цитата: 
		
			Сообщение от Дуд
			
			 ПМ, не особо представляя, о чем речь, соглашается, а потом оказывается... ПМ, который не особо представляя, соглашается - отвратительный ПМ. Но чтобы разрулить такую ситуацию, не обязательно знать систему. Достаточно иметь нормальную команду и не стесняться спрашивать у специалистов. Не стесняться спрашивать, а затем принимать решения на основании полученной информации - это и есть задача ПМа. | 
|  | 
|  29.04.2005, 10:06 | #44 | 
| Участник | Цитата: 
		
			Сообщение от mazzy
			
			 Цитата: 
		
			Сообщение от Дуд
			
			  ПМ, не особо представляя, о чем речь, соглашается, а потом оказывается... Нет уж - я категорически за то, что РМ систему знать должен - и если не на супер программерском уровне, то на глубоком - точно. Кроме того, кто сказал, что консультанты - всегда круто шарят?! Если консультант предлагает решение какой либо задачи так-то и так-то - то РМ обязан понимать, что он предлагает, к каким последствиям В СИСТЕМЕ это приведет, какие есть альтернативные пути и действительно ли путь, который предлагает консультант - лучший. Тогда он в состоянии принять решение- делаем так-то или так-то. Если клиент задает РМ вопрос - "А как мы будем проводить учет вот этого?", то РМ не должен говорить - "сейчас схожу спрошу у консультантов и завтра ответчу". если так происходит то система конечно будет внедрена, только не за год, и может быть не за два - а чуть больше.... | 
|  | 
|  29.04.2005, 13:39 | #45 | 
| Участник | Цитата: 
		
			Сообщение от rov
			
			 Цитата: 
		
			Сообщение от mazzy
			
			 Цитата: 
		
			Сообщение от Дуд
			
			  ПМ, не особо представляя, о чем речь, соглашается, а потом оказывается... Если так поставил дело, что вопросы десятками валются на НЕГО.   | 
|  | 
|  29.04.2005, 13:56 | #46 | 
| Участник | 
			
			[quote=mazzy]  Цитата: 
		
			Сообщение от rov
			
			  [Просто это не ПМ, а именно мальчик. Если так поставил дело, что вопросы десятками валются на НЕГО.    А если вопросы валятся не на него - то он простите зачем нужен? В этом и есть роль РМ(наряду с другими) - что он служит ЕДИНОЙ точкой входа для всех стратегических и тактических(исключая совсем оперативные типа "Почему отчет не печатает?") вопросов/запросов заказчика. Глав. бух., фин. директор, нач. фин. отдела должны работать с РМ и вопросы обращать к нему. Рядовые пользователи и средний менедж. - да, они работают по оперативным задачам с консультантами. А общие вопросы должны быть прерогативой РМ - иначе, повторюсь, можно его выкинуть - и никто ничего не потеряет! | 
|  | 
|  29.04.2005, 14:08 | #47 | 
| Участник | 
			
			Хм... я так не думаю? Есть еще мнения? | 
|  | 
|  18.05.2005, 16:10 | #48 | 
| Шаман форума | 
			
			Обсуждение про то, что вообще должен делать руководитель проекта, ввиду его большого размера и самостоятельной ценности, перенесено сюда Что должен делать руководитель проекта?
		 
				__________________ All information in this post is strictly confidential. If you have read it in error, please forget it immediately. | 
|  | 
|  04.04.2007, 12:31 | #49 | 
| Участник | 
			
			А кому нибудь доводилось слышать про проекты, где ПМ от Заказчика был грамотнее и вел проект сам, используя команду Исполнителя как ресурс, и ими рулил?
		 | 
|  | 
|  04.04.2007, 13:35 | #50 | 
| Участник | 
			
			Ответил Да, должен. При ответе имел в виду руководителя проекта Navision, в котором как правило роль РП совмещается с ролью архитектора и консультанта. А так же бывает и разработчика. При этом время на управление проектом составляет около 20% всего рабочего времени одного человека. При подобных объемах выделять на роль РП чистого управленца неэффективно. Т.е. на мой взгляд, требования по знанию системы зависят от величины проекта, структуры и величины команды. Если говорить о самой роли РП, то естественно для ее выполнения знания системы не обязательно, а иногда даже вредно. | 
|  | 
|  20.04.2007, 15:11 | #51 | 
| Участник | 
			
			Смотрю на статистику этого опроса и вот этого  Тусовка для Руководителей проектов и получается очень интересная картина. Руководят проектами - консультанты, причем их этому никто не учит и они сами занимаются изобретением велосипедов! Так что удивляться - что по статистике только 16% проектов успешные - то есть уложились в срок и бюджет. То есть почти все компании, внедряющие от коробки 1С, NAV и до SAP и OEBS - делают все кое как, на коленке. А не напрашивается ли очевидный вывод, что мнение большенства, высказавшегося в опросе - полный вздор? И грамотный ПМ, вместо того что бы вникать во внедряемую систему - занимается совсем другими вещами, нам , смертным, недоступным.  Может он там в одиночку шаманские пляски устраивает, а уж совсем не штудирует на скорую руку юзер гувайд. Лично меня радует, что правильные примеры все же есть! Вот например такие: "Руководитель проекта, один из ведущих консультантов, был назначен на период выполнения проекта вице-президентом компании заказчика с исключительными полномочиями. Таким образом, у консультантов появилась возможность управления всеми необходимыми ресурсами и проведения реальных изменений, в результате которых были достигнуты установленные целевые показатели." (ц) с сайта iteam Или вот примеры проектов PM-Expert http://www.pmexpert.ru/services/outsourcing/projects/ | 
|  | 
|  26.07.2007, 23:24 | #52 | 
| Участник | 
			
			Хм не понятен конечно ваш ответ egen.  Так вы считаете что не должен знать систему? Или должен? Уложиться в рамках бюджета и сроков, это главная задача PM. НО встает вопрос - если правильно оценен бюджет и сроки. И на мой взгляд в самом начале проекта, это и есть самое главная задача PM, оценить бюджет и сроки. И для этого он должен знать хорошо систему. Но мое мнение тоже основывается на внедрении Navision. Если система большая, то наверно PM не нужно знать систему, а есть архитектор системы, который и выполнит главную задачу в начале проекта, правильно оценит бюджет и сроки. Тут действительно вопрос в определении - что такое PM. Если PM со стороны внедренца не большой системы - то должен знать, чтобы правильно оценить бюджет и сроки, и как вывод в них после уложиться. Если PM большой системы, то наверно не должен. Если PM со стороны клиента, тоже не должен. Вообщем просто они действительно выполняют разные задачи. | 
|  | 
|  27.07.2007, 15:46 | #53 | 
| Участник | 
			
			Ответ проще: Есть роль ПМа в проекте и есть роль ГИП в проекте. У них совершенно разные задачи и требования к их знаниям. Путаница происходит из-за того, что проекты внедрения - очень маленькие по сложности и задачам (я не про деньги  ) - поэтому эти роли обычно совмещены в одном человеке. Вот именно поэтому, конкретный пм по имени "Вася", знает и методологию управления проектами и сам составляет список задач, которые надо сделать на проекте. | 
|  |