еще полгода и я сам стану таким человеком!

коллеги в прошлом году спрашивали про ПМа который ведет проект и при этом не знает хорошо предметную область. Исходя из собств опыта могу сказать, что хорошее знание предм области не обязательно, но это при условии, что у ПМа есть возможность обращаться к экспертам в этих областях. Моя компания занимается разработкой ПО, но я ранее не работал в софтовом бизнесе, но успешно реализовал полугодичный проект. Программка получилась со множеством ошибок, но здесь на себя не беру - такой в нашей компании подход к разработке и качеству. Кстати я разделяю подход PMI к управлению проектами: ПМ должен рулить проектом, но не функциональной работой.

Если все так и было - мое почтение!
А можно подробности о ведении проектом? Чем приходилось заниматся, а что делегировалось спецам?

Много времен уходило на общение с Заказчиком: планирование работ/бюджета, согласование договора (уже 1,5 месяца работали а договор еще не подписали), согласование ТЗ, оформление протоколов встреч, определение спецов от Заказчика кто будет бумаги подписывать, согласовывать.Подбор ресурсов в команду. А спецы занимались собственно написанием ТЗ, непосредственно согласовывали технич. сторону дела, кодили, а я в это время оформлял официальные результаты таких встреч.

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

Распределение по спецам задач по разработке делал начальник отдела разработчиков: кто умнее - тому и задача сложнее. Я не спец в разработке, поэтому ориентировался на сроки которые фиксировал линейный руководитель разработчиков.

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

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

ЗЫ Я об этом говорил и ранее в теме Основные проблемы управления проектами

Ну почему же не бывает.
До сего дня я трудился на проектах только финансовой направлености, а сейчас руковожу проектом где автоматизируется в основном SCM и WMS. Знаний предметной области практически не имею. Знания по реализации этих БП в системе тоже имею весьма поверхностные.
Про успешность пока судить рано, так как проект пока не закончился, но вроде как пока все более менее успешно.
Как завершу проект то напишу свои ощущения
P.S. Проект не по SAP, а по Axapta. Хотя думаю разницы не какой нет.

Я посмотрел Ваши ответы в теме "Основные проблемы управления проектами" и сложилось впечатление, что Вы не совсем понимаете для чего существуют ПМы и в чем их назначение.
Фраза про "администратора проекта" просто не корректна. Посмотрите структуру штата американской проектной команды - там существуют ПМы нескольких категорий (I, II, III), а про сопутствующий персонал - различные ролевые помощники и т.п. я и не говорю. Во всех проектах, где я участвовал, функции админа проекта были различны. Это не панацея сказать "используйте работника с таким-то названием должности". На каждый чих человека не наймешь, особенно если проект малобюджетный.
Про "картину действительности" - так это Вы в негативе видите, попробуйте с другой стороны посмотреть. В РФ растущий бизнес и все проходят через ошибки роста, тут нечего на зеркало пенять...

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

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

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

Единственное, что несколько выравнивает картину - малобюджетный проект, о котором Вы ранее не упоминали.


Добавил: заранее извините за резкость, все что я написал про реализацию Вашего проекта верно только, если ранее написанный объем выполненных Вами работ был полон.
Некоторые проблемы бытия и сущности воспринимаются мной слишком близко. Данная тема входит в их число, потому как когда-то давно меня обучали управлять промышленными предприятими...
И по той методологии люди должен пройти свой путь от простого инженера до руководителя предприятия (набираясь тем самым опыта и знаний). А сейчас в рыночных условиях мне неоднократно встречаются PM возрастом 23, 24, 25 с полным непониманием происходящего в проекте и говорящих на заумном птичьем языке...

+1.
Сам с таким работал. "Ну вы тут ребято что-нибудь поделейт, потом мне скажите когда к клиенту идти". Выходит, а ему вслед все палец кажут.
Горе это а не РП и будещего у таких в любом случае нет. Есть разница , когда ты умеешь рулить и не знаешь предметной области, но начиная проект начинаешь изучать все что касается проекта (методология, программирование, администрирование) хотя бы на уровне понимания и возможности ответить перед заказчиком на любой вопрос так или иначе связанный с проектом, и когда РП ходит дуб дубом и просто кидается умными, заучиными словами, за которыми не стоят знания, ой чуть не забыл ещё в MS Projects график ведет. Вот у таких РП и существует проблема "как оценивать эффективность работы членов команды, в своей компании я не нашел пока хорошего арбитра, который бы сказал что в целом работы выполнены эффективно". РП и должен являться арбитром.

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

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

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

Кстати о возрасте, ранее работал с ИКТ, у них был отличный ПМ лет 25. и работал с др компанией, дак там ПМ был в возрасте 50 с кандидатской, опытом работы в IT с советских лет, но за год работы проект (один и самых крупных в РФ) не сдвинулся с места, только разговоры ..вот и глубокое знание предм. области.

Я поддержу.

Сейчас я работаю на проекте, где часть работы делаю как аналитик. И стоит только туда влезть с головой как проект практически падает, ибо я из своего "окопа" не вижу что вокруг творится.
Да, хорошо если ты знаешь больше чем надо, но знания предметной области - это лишний груз на плечах.

К сожалению, эта безобразная картина сплошь и рядом...

Это точно, без такого груза гораздо легче давать обещания о сроках, не понимая какие объемы работы за этим стоят (а при отстутсвии знания предметной области объемы знать не возможно, и специалиста не возможно спросить---сидишь на совещании, а над тобой нависли--скажи срок и всё), а потом после обьявления сроков проектной команде(когда тех. спецы скажут что это не реальный срок), разводить руками и говорить -вот такие они плохие заказчики . Ведь про то что ты сам назвал этот срок или подвердил это срок они не узнаю . И ты будешь хорошим для заказчика, но ровно до того как подойдут эти самые сроки, а потом начинают трести - почему неукладываетесь в сроки , вы обещали и т.д. , как результат у проектной команды исчезают выходные и т.д и т.п. Уважаемые коллеги, ведь описаная ситуация всем знакома. Совсем не обьязательно, что вы этот ПМ, но вы могли работать у него или видели такого))
По-мойму о квалификации ПМ, приведшего проект к такому состоянию стоит усомниться.

Все это говорит исключительно о невысокой компетенции РП как РП, то есть как специалиста по управлению проектами. К его компетенции как специалиста в предметной области или функциональности это не имеет ни малейшего отношения. Его задача именно как руководителя проекта - не обещать сроки без экспертных оценок, не поддаваться когда "над тобой нависли" и т.д. Знания в предметной области тут совершенно ни при чем.
Кроме того, есть мнение, что руководитель-специалист может быть даже вреден. Становясь руководителем, человек начинает меньше времени уделять своей специализации и больше - своей работе как руководителя. Это приводит к тому, что руководитель начинает устаревать как специалист, его знания постепенно становятся не актуальными. Плохо, если он сам это плохо понимаем и по-прежнему продолжает считать себя специалистом. Это опасно, поскольку у руководителя есть власть, и он может навязывать с помощью нее свои, "устаревшие" и неэффективные решения как специалиста.
Кроме того, как только руководитель становится руководителем, резко расширяется круг знаний, которыми по идее он должен обладать, чтобы разбираться во всех вопросах.
Логист стал РП проекта FI/CO/MM/SD, что ему теперь, FI/CO учить срочно?
Нет. Он просто был специалистом по логистике, а теперь должен стать другим специалистом - специалистом по управлению проектами.

Имхо

С уважением.

Для того чтобы навязывать свою глупую точку зрения вообще не обьязательно быть специалистом. Есть и такие начальники, что неразбираясь навязывают свое мнени и требуют чтобы было так!!! Взгляните на совещание со своими заказчиками, какую только ерись они там не несут)))). А убежденность в их глазах!!))). Так что это зависит от человека, умения объективна себя оценивать и слушать других.



Когда он был логистом были изучены---Бухгал. кредиторов/дебиторов, план счетов, проводки, места отпуска материалов (МВЗ, заказы, коллектора, СПП), счета-фактуры, договора, расчет себестоимости материалов, ну вообщем если подумать ещё много чего написать можно))). Так что знания FI/CO у него есть))). Я здесь и не говорил, что надо знать все до ноты или галок в SPRO. Другое дело когда человек приходит из сетевиков(не самый худший вариант) или вовсе гуманитрай (без обид, сам работал с философом) и начинает рулить проектом. Я понимаю, что можно и так и даже получиться, но сколько проблем может избежать команда, если человек с опытом в предметной области и понимает что у него на проекте происходит не на уровне сетевых графиков.