Я,

Нет Коллега, на сегодня (да в-общем и всегда) управление проектов не требовало знаний собственно предмета. Ведь проект - если подумать - в любой сфере проект. Характеризуется

1. Начало
2. Продолжение
3. Конец

И всё . Хоть стенки ктрась, хить ERP пиши. Смысл одинаковый. Для первого пункта - разберись с заданием и имеющимися ресурсами. Для второго - следи за выполнением заданий и проектными рамками. Для третьего - не забудь всё доставить в срок. http://www.youtube.com/watch?v=IyNPeTn8fpo

Это кстати Гуглисы пригласили к себе одного из самых крутых скрамеров мира. Ну против Google и методов их проектирования нигде никто ничего сказать не может. Кстати если что либо будет непонятно в плане перевода - спрашивайте.

BelyТолько не выйдет так. Точнее - МАЛО у кого выйдет так.
Потому что ньюансы везде разные.
Чтобы эффективно управлять проектом надо эти ньюансы понимать, всетаки.
.

Да нет Коллега Bely, если правильно организовать PROCESSES, подобрать правильных PEOPLE в комманду и правильно объяснить им REQUIREMENTS я никаких различий в постройке сортира и запуске ракеты на луну не вижу. Ну там бюджет - так это мелочь... Кто же нам считает.... Поэтому подборка и подготовка руководителей должна быть особенно тщательной, Но не в плане предметной области а скорее в плане постановщика - режиссёра что ли, или там прораба на стройке. Ведь согласитесь - хороший прораб запросто вкурится - туфту ему гонят или дело говорят. На каком бы "умняке" ему эту туфту не лепили...

alexeyvg,

Product Manager / Program Manager - и Project Manager тут у нас действительно три большие функции. По моему Аффтара интересует именно Проектирование Системы - то есть именно IS Project Manager. Или я ошибаюсь?

alexeyvg REQUIREMENTS как раз управляет Product manager. И необходимость этого очень убедительно обосновывается.

Product Manager по сути своей маркетолог. Он не технарь а скорее БА. Хотя его подкованность и внимание к рынку - прежде всего технические (если мы говорим about IS) . Program Manager - я бы поставил на вторую ступень в различиях между Prouct и Project Management. Своего рода куратор проектов Ну и результирующая - как линейное звено управления будет Project Manager.

У нас в консалтинге - мы обычно справляемся одним PM .. Все проекты сам с собой и обсуждаешь.... Все задания пережёвываешь в порошок, стандарты качества определяешь Там все ворпосы и решаем. Сам с собой. Конечно замечательно если кто то есть подсобить и усмотреть ошибки... А если нет никого....

alexeyvgИзвините за любопытство - просто тема меня интересует, вот я и расспрашиваю о реальной практике...

Т.е. эта схема выглядит так:

Program Manager - это куратор где-то наверху (можно просто Бог :-) ), он раз в месяц спрашивает - "ну как там, уже всё сделали?"

Сам проект ведёт Product Manager и Project Manager

Product Manager определяет функционал, говорит, что должен представлять из себя продукт, определяет интерфейсы продукта (и расставляет всему этому приоритеты).

Project Manager определяет, что из этого функционала будет реализовано исходя из имеющегося бюджета (ресурсов) и сроков.

Разработчик (допустим, он один или это старший разработчик-лид) за уточнениями "что делать" обращается к Product Manager-у, а прогноз трудоёмкости сообщает Project Manager-у, дабы тот смог выполнять свою работу.

Правильно?


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

Итак. Давайте я проидеализирую свою "Супер Команду". примером будет Adobe - всем известная фирма по выпуску чистого софта - мало чем похожего на Системы Автоматизированного Управления Производством.

Adobe построена по принципу - 1 команда на 1 продукт. Где то 20 (в среднем) разработчиков , 30 QA, 1 ПМ. Product manager - своего рода представитель заказчика - управляет командой QА. Project Manager - функционально следит за ресурсами и работает писателем. Ему сносят заявки на ту или иную работу, функциональность, а он определяет кто именно будет этим заниматься.

Program Manager - в своём функционале ведёт контроль проектов по выпуску на Operation System. То есть есть MAC, и Windows Programs. По иерархии - у них (Seniors) есть подкоманды - Графические тулсы, текстовые Тулсы, Видео Тулсы. То есть получается матрица своего рода вокруг команд разработчиков.

Планирование ведётся системой Водопада - от релиза к релизу. Связано это с выпуском документации на каждый релиз. Устанавливается функциональности делается прототип нового релиза и потом параллельно ведётся разработка и документирование.

Это один из традиционных методов ведения софтверного бизнеса.

Совершенно не пригоден к САУП.

:А почему у вас вместо этого один PM? Вышеупомянутая схема чем-то плоха?

теперь берём традиционный ERP (ну или АСУП) . Главным заказчиком выступает бизнес. Он диктует свои законы и комманда вся целиком подчиняется бизнесу. Внутри комманды -по новым стандартам работает так называемый SCRUM. Это термин Agile Development. Всё разбивается на маленькие итерации и De facto Project manager становится Мастером. Он следит за всем - чтобы SCRUM имел цель и результат - хоть маленький - но результат. Чтобы Бизнес - Пусть даже сам Product manager - обычно величина достаточно солидная - присутствовал на основных митингах и тем более приемке итерации и координировал обратную связь - нравится бизнесу то что получилось или нет. То есть функции Product Manager могут быть в конце концов переданы project manager если результат удовлетворительный после первых двух трёх итераций. program manager как единица координирующая всех Project managers - просто свой SCRUM MUSTER в комманде PM - а если по времени проект ограничен и не надо распылять на две - три операционки - то Program Manager просто не нужен - внутри комманды - он был и остаётся мастером. Вот такие "идеализированные" картинки получились. Вопросы?

BelyВот только что делать, если туфту начнет гнать прораб с умным видом?
Кто его отсеет и остановит?
Для прораба надо знать одно - цену сметы и количество людей на единицу траншеи. Если и надо "гнать туфту" то по делу - не хватает денег или "Вася совсем спился" - надо бы полечить. И диалог этот будет не в комманде а гораздо выше.


Bely
Я не говорю, что PM должен быть ЛУЧШИМ програмистом в команде, но ИМЕТЬ ПРЕДСТАВЛЕНИЕ и ПОНИМАТЬ как происходит процесс создания ПО - надо иметь.
Получить такой опыт не проработав ни минуты разработчиком - проблематично.

Я когда то имел честь работать с PM не технарями. Сам я технарь как Вы понимаете и меня провести сложнее. PM - не технарь собирает информацию внутри по принципу "расскажи как бы ты сделал этот проект" и так каждому. Задаёт удивительные по простоте и очень точные по содержанию вопросы. К Концу такого опросного дня он уже далеко не профан в предметной области. К Концу недели он даже сможет курировать выполнение стандартов. Хороший PM на мой взгляд - половина успеха проекта.

alexeyvdИ разработка проектов в Microsoft тоже укладывается.

Ну вот about Microsoft ничего пок асказать не могу. Мелкомягкие всё больше и больше внедряются в бизнес практику. Ещё восемь-десять лет назад от них отмахивались как от мух. Сегодня существует и отлично работает целая отрасль Microsoft Consulting services. Они сначала ставили документацию на основе MS Office, Sharepoint, Visio... etc. Потом пробивали всезде где можно SQL Server за ними пришёл BizTalk и MS Dynamics А сегодня нет отрасли в бизнес ориентированных проектах где бы не было Microsoft PM с целым пакетом стандартов от которых не так просто отказаться - отлично наработанные и поставленные процессы.

alexeyvg,

Одной из самых квалифицированных на мой взгляд Project Manager была и остаётся именно девочка из MSF. Профессионал высокого порядка. Вела 4 года проект внедрения в крупной всемирной страховой компании технологий MSF. Долгое время там был бардак и никакой логики. Все существующие платформы, все существующие системы автоматизации.. масса передублированных функций и проектов связанных с внутренней гравитацией. Одни и те же отчёты делались на 6 языках программирования из 15 различных систем. К Концу проекта всё стало на свои места. Работа велась малыми итерациями в которых строились команды PM для начала. Она их - этих project menegers научила SCRUM и вела их и ещё один на уровне Executives. Стала по функциональности Program manager. Ну ещё и mentor (толкователь) . В течение года 15 проектов по переводу систем из не-MSF в MSF системы благополучно завершились. Были созданы все процессы, набраны правильные люди, созданы и задокументированы все процедуры, введены самые современные стандарты, проведена полная реорганизация... На мой взгляд это был ее полный успех, а она даже не обратила на это внимание. Кстати съездила в Россию и удочерила девочку из Иваново. Никакого отношения к программированию не имела. но имела квалификацию PMI Institute - Модератору: - не сочтите за рекламу. Это всемирная PM организация. Кстати всё более и более на больших проектах требуются именно эта аккредитация.