Если же вы говорите о PMBoK — попробуйте хоть что-то сделать на основе подходов зафиксированных в нем, разгоните непонятную дымовую завесу и вы увидете за ней Небоскреб.
А мы не говорим про других руководителей проектов, именно по этому толковых руководителей проектов мало. А если заниматься проектом всесторонне, квалификацию не потеряешь, а только прокачаешь.
Теория штука такая, пока не будешь применять на практике, она работать не будет. Попробуйте, увидете.
Я не сказал, что проектный подход не нужен, он необходим, но не достаточен.
Этому слову в разработке IT в России, как минимум 15 лет, в мире же в IT проекты появились начиная с 50х годов. Сам руковожу проектами разработки уже более 10 лет, и поверьте именно такой подход наиболее эффективен для создания продуктов, программ и игр.
А вот методик разработки много, и в каждом проекте есть свои наиболее эффективные.
Я отвечу коротко и ёмко, если руководитель проекта не понимает в своём проекте и не знает его сути, не приносит ему пользу — это не руководитель проекта.
Я описал не классического руководителя, а тех людей которые проходят успешно у меня собеседование. Это минимальный набор требований к специалисту для работы на этой позиции.
За этими словами находится огромный пласт работ =) Если будет интересно — попробую отразить в одной из следующих статей свои подходы в управлении при разработке программных продуктов, с раскрытием каждого из этих пунктов.
Если же говорить, что делает Петр — он как минимум обеспечивает проектную деятельность (управление интеграцией проекта), участвует в согласовании постановок с клиентом (контроль содержания проекта), планирует будущие активности, генерирует отчетность перед заказчиком и руководством, контролит ход выполнения проекта (в том числе и с помощью EVM), обеспечивает должное исполнение контрактных обязательств и выполнение требований контракта (в том числе и формальных вех)… и многое-многое другое, если интересно — напишем и про это, что он должен делать… но это уже совсем другая тема.
А еще, если ему руководство доверяет, он может делать пре-сейлы, сейлы и ап-сейлы по другим проектам =)
Ваш кейс — это развитие продукта, которое включает элементы проектного управления. Наличие только проектной деятельности возможно — но это будет совершенно не эффективно, необходимо использовать эффект синергии от схожих проектов и централизованного развития продукта.
Мы говорим о проектной деятельности, не операционной.
Развитие продукта подразумевает выполнение нескольких проектов / проведение операционной деятельности. То что вы написали — развитие продукта, здесь нужна другая компетенция, конечно компетенция проектного управленца нужна, но её не достаточно, для этого дополнительно необходимо еще навыки стратегического менеджмента и операционного управления.
Без отсылки к стандартам:
— управление стоимостью проекта
— управление сроками проекта
— управление рисками проекта
— управление заинтересованными сторонами проекта
— управление поставками/закупками проекта
— управление содержанием проекта
— управление интеграцией проекта
— управление качеством проекта
— управление человеческими ресурсами проекта
— управление коммуникациями проекта
Именно по этому ракеты летят в космос, запускаются крупные информационные системы, и появляются уникальные продукты на рынке, в том числе и на рынке IoT.
Есть такое понятие проектное управление, включающее в себя как минимум 10 областей знаний =) в каждой из областей есть определенные мероприятия для качественного исполнения процесса. По этому вопросу могу посоветовать литературу в виде проектных стандартов, кстати ГОСТа по управлению проектами.
Но самое главное — Иван первый кто берет на себя ответственность за успех проекта, в том числе, первый кто попадет под санкции.
Это не схема управления проектом. Управление проектом — это комплекс мероприятий и действий. Здесь же приведена методика контроля хода проекта, позволяющая делать прогноз по ходу проекта о его завершении с учетом финансовой составляющей.
Попробуйте привести еще пару методик позволяющую строить такой прогноз =) и вы ответите на свой вопрос.
При должном уровне компетенции, проектирования решений, наличии опыта, построить такие модели по проектам IT индустрии не представляет сложностей.
Иерархия описывает не систему, а структуру работ — классическое понимание WBS или ИСР. Подробней можно прочитать в стандартах по управлению проектов от ведущих проектных институтов (как пример IPMA, PMI).
Вообще проекты в IT — это темные лошадки с многими неизвестными.
Топовые способы разработки и управления командой разработчиков можно пересчитать по пальцам двух рук) Но конечно нужно не забывать, что в жизни может случается все что угодно, и молния может ударить в одно место =) нужно быть готовым во все оружии.
В этом случае я бы Ивану посоветовал задуматься о мотивации, не в классическом её бехевиаристском понимании, а в новых трендах — Мотивации 2.0 и коррекции окружения команды под идеологию "человеческого фактора" (есть такой замечательный труд Т.Листера и Т.ДеМарко)
Да, развитие идет, подходы применяются. Сейчас все больше маленьких компаний (с количеством сотрудников до 100-150) более зрелые, нежели гиганты (с точки зрения того же OPM3). Перестроить годами отработанный механизм сложно, если нет на то поддержки руководства, с этим у нас проблем нет =)
Все зависит от Ивана, того, как он ведет внешние коммуникации и управление требованиями. Думаю, у него с этим проблем нет, знающий EVM знает правила эффективных коммуникаций и верные подходы и механики управления изменениями и требованиями.
С точки зрения EV — выполнен ровно тот объем, который равен объему по затраченному времени. Вопрос действительно важный)
Если с первого раза не получиться применить технологию, обращайтесь, поможем.
Предлагаю ознакомиться с классикой — "Мифический человеко-месяц, или Как создаются программные системы", Брукса выпуском 1975 года — об управлении проектами в разработке IT. Кстати о распределении денег там нет)
К слову о серебряной пуле, на это тоже есть интересный труд — «Как успешно руководить проектами. Серебряная пуля» Ф. О'Коннэл об этом говорил в 2002, и тоже про IT и разработку.
Если же вы говорите о PMBoK — попробуйте хоть что-то сделать на основе подходов зафиксированных в нем, разгоните непонятную дымовую завесу и вы увидете за ней Небоскреб.
А мы не говорим про других руководителей проектов, именно по этому толковых руководителей проектов мало. А если заниматься проектом всесторонне, квалификацию не потеряешь, а только прокачаешь.
Теория штука такая, пока не будешь применять на практике, она работать не будет. Попробуйте, увидете.
Я не сказал, что проектный подход не нужен, он необходим, но не достаточен.
Этому слову в разработке IT в России, как минимум 15 лет, в мире же в IT проекты появились начиная с 50х годов. Сам руковожу проектами разработки уже более 10 лет, и поверьте именно такой подход наиболее эффективен для создания продуктов, программ и игр.
А вот методик разработки много, и в каждом проекте есть свои наиболее эффективные.
Я отвечу коротко и ёмко, если руководитель проекта не понимает в своём проекте и не знает его сути, не приносит ему пользу — это не руководитель проекта.
Я описал не классического руководителя, а тех людей которые проходят успешно у меня собеседование. Это минимальный набор требований к специалисту для работы на этой позиции.
Если же говорить, что делает Петр — он как минимум обеспечивает проектную деятельность (управление интеграцией проекта), участвует в согласовании постановок с клиентом (контроль содержания проекта), планирует будущие активности, генерирует отчетность перед заказчиком и руководством, контролит ход выполнения проекта (в том числе и с помощью EVM), обеспечивает должное исполнение контрактных обязательств и выполнение требований контракта (в том числе и формальных вех)… и многое-многое другое, если интересно — напишем и про это, что он должен делать… но это уже совсем другая тема.
А еще, если ему руководство доверяет, он может делать пре-сейлы, сейлы и ап-сейлы по другим проектам =)
Развитие продукта подразумевает выполнение нескольких проектов / проведение операционной деятельности. То что вы написали — развитие продукта, здесь нужна другая компетенция, конечно компетенция проектного управленца нужна, но её не достаточно, для этого дополнительно необходимо еще навыки стратегического менеджмента и операционного управления.
— управление стоимостью проекта
— управление сроками проекта
— управление рисками проекта
— управление заинтересованными сторонами проекта
— управление поставками/закупками проекта
— управление содержанием проекта
— управление интеграцией проекта
— управление качеством проекта
— управление человеческими ресурсами проекта
— управление коммуникациями проекта
Но самое главное — Иван первый кто берет на себя ответственность за успех проекта, в том числе, первый кто попадет под санкции.
Попробуйте привести еще пару методик позволяющую строить такой прогноз =) и вы ответите на свой вопрос.
При должном уровне компетенции, проектирования решений, наличии опыта, построить такие модели по проектам IT индустрии не представляет сложностей.
Иерархия описывает не систему, а структуру работ — классическое понимание WBS или ИСР. Подробней можно прочитать в стандартах по управлению проектов от ведущих проектных институтов (как пример IPMA, PMI).
Топовые способы разработки и управления командой разработчиков можно пересчитать по пальцам двух рук) Но конечно нужно не забывать, что в жизни может случается все что угодно, и молния может ударить в одно место =) нужно быть готовым во все оружии.
В этом случае я бы Ивану посоветовал задуматься о мотивации, не в классическом её бехевиаристском понимании, а в новых трендах — Мотивации 2.0 и коррекции окружения команды под идеологию "человеческого фактора" (есть такой замечательный труд Т.Листера и Т.ДеМарко)
С точки зрения EV — выполнен ровно тот объем, который равен объему по затраченному времени. Вопрос действительно важный)