Опубликовано в Игры.
Мой первый материал на DTF. Раньше как-то не приходилось работать с платформами компании помимо VC, но здесь вышла большая оказия с анонсом крайне близкой и знакомой мне игры. Не смог сопротивляться)
Опубликовано (изменено: ) в Проектный менеджмент.
Управление ресурсами проекта – одна из десяти областей знаний управления проектами. Она включает в себя процессы, необходимые для идентификации, приобретения и управления ресурсами, необходимыми для успешного выполнения проекта. Ресурсы в этом случае включают как ресурсы материальные, так и ресурсы команды.
Цель управления ресурсами проекта – обеспечить доступность и доставку необходимых материальных ресурсов в надлежащее время и в нужном месте, а также обеспечивать эффективность и координацию работы и рост компетентности команды проекта.
Грамотное управление ресурсами проекта позволяет:
Контролировать ход проекта. В компании могут быть тысячи сотрудников, сотни проектов, десятки департаментов и офисов по всему миру. Эффективное управление ресурсами даст возможность контролировать каждый этап и шаг в реализации бизнес-планов.
Обеспечивать прозрачность рабочих процессов. Другие департаменты могут оценить загрузку вашей команды и понять, работает ли она на полную мощность либо готова взять дополнительную задачу. Также прозрачность повышает уровень доверия заказчиков и других заинтересованных лиц.
Минимизировать риски. Распределив ресурсы и спланировав их использование, вы сможете устранить недостатки или проблемы до того, как они возникнут.
Предотвратить выгорание и уход членов команды. Назначая роль и загрузку каждому сотруднику, вы можете быть уверены, что никто не работает сверх нормы и каждый занят тем, за что ему платят.
Оценить окупаемости инвестиций (ROI). Имея четкое представление, что понадобится для ведения и завершения проекта, вы можете заранее планировать и оценивать рентабельность инвестиций.
Оценить эффективность. Оценивая результаты проекта, вы можете проследить, насколько эффективна ваша команда. Это позволит делать более точные прогнозы на будущее.
Проектному менеджеру необходимо применять различные подходы к управлению ресурсами команды и управлению материальными ресурсами. К материальным ресурсам относятся оборудование, материалы, здания и сооружения, а также инфраструктура.
Ресурсы команды или персонал — это человеческие ресурсы. Персонал может иметь различные наборы навыков, полную или частичную занятость, дополнительно включаться или удаляться из состава команды по мере выполнения проекта. Процесс управления ресурсами проекта и процесс управления заинтересованными сторонами проекта частично накладываются друг на друга.
Команда проекта состоит из лиц с определенными ролями и ответственностью, которые выполняют совместную работу для достижения общей для всех цели проекта. Руководитель проекта ответственен за приобретение, управление, мотивацию и мобилизацию членов команды проекта. Важным преимуществом для проекта может стать интеграция всех членов команды в процессы планирования проекта и принятия решений. Это позволяет использовать имеющийся у персонала опыт при работе над проектом, а также укрепляет команду и направляет её на достижение результатов проекта.
Задачи управления человеческими ресурсами. Руководитель проекта должен быть одновременно лидером и руководителем команды проекта. Он отвечает также за формирование команды, способной обеспечить необходимый результат. Для этого ему необходимо знать собственный проект и проводимые в нём работы. Не поленитесь узнать следующие аспекты: среда работы команды, места нахождения членов команды, коммуникации между заинтересованными сторонами (стейкхолдерами), управление организационными изменениями, внутренние и внешние политики, отличительные особенности организации. Руководитель проекта также несет ответственность за развитие навыков и компетенций команды. Одновременно ему важно поддерживать удовлетворенность и мотивацию ее членов. Руководитель проекта должен ознакомиться и официально подтвердить согласие с правилами профессионального поведения и нормами этики, а также обеспечить, чтобы все члены команды неуклонно исполняли правила и нормы организации и среды.
Задачи управления материальными ресурсами –
I. Оптимальное планирование ресурсов
II. Управление материально-техническим обеспечением (например, материалы, оборудование и инструменты).
PMBOK Guide выделяет управление закупками как отдельную область знаний проектного менеджмента. А Шапиро определяет их как подзадачу управления материально-техническим обеспечением.
Для успешного выполнения задач управления материальными ресурсами руководителю проекта необходимо иметь актуальные и достоверные данные о потребностях в ресурсах (в данный момент времени и в обозримом будущем), о конфигурации ресурсов, которые потребуются для удовлетворения выявленных потребностей, а также об обеспеченности ресурсами организации. Ошибки при решении задач управления и контроля над ресурсами выливаются в большие риски для проекта. Вот несколько примеров:
Неспособность своевременно обеспечить наличие важнейшего оборудования или инфраструктуры может стать причиной нарушения сроков изготовления конечного продукта.
Заказ некачественного материала может привести к ухудшению качества продукта и стать причиной большого числа отзывов продукта с рынка или необходимости его доработки.
Наличие избыточных запасов может стать причиной высоких операционных затрат и снижения прибыли организации.
И, напротив, слишком низкий уровень запасов может привести к неудовлетворению спроса заказчика и, опять же, к снижению прибыли организации.
Для распределения использования ресурсов по времени используются такие инструменты, как диаграммы Гантта.
Процессы управления ресурсами проекта призваны обеспечить доступность и доставку необходимых ресурсов руководителю проекта и команде проекта в надлежащее время и в нужном месте. PMBOK Guide 6-е издание относит к этой группе процессов следующие:
Планирование управления ресурсами — это процесс, определяющий, каким образом осуществлять оценку, приобретение, управление и использование материальных и кадровых ресурсов проекта. При этом два основных метода планирования ресурсов – ресурсное планирование при ограничении по времени и планирование при ограниченных ресурсах.
Классическая аналитическая задача, с которой вы и ваша команда непременно встретитесь в каждом проекте – решение “производить или покупать”. Это довольно известная за пределами проектного менеджмента аналитическая задача.
Фрагмент из книги Хелдмана Кима “Профессиональное управление проектом”:
Выполняя анализ «производить или покупать», вы пытаетесь получить решение относительно экономической целесообразности покупки необходимых для проекта продукта или услуги либо их создания внутри организации. Стоимость должна включать как прямые затраты (другими словами, фактические затраты на покупку товаров и услуг), так и косвенные, например зарплату менеджеру, ответственному за процессы поставки, или затраты на текущее обслуживание. Затраты необязательно означают затраты на покупку. При анализе «производить или покупать» вы можете сравнить затраты на аренду продукта и затраты на его покупку. Предположим, в вашем проекте требуется специализированное ПО, которое, как вы знаете, к концу проекта устареет. В таком случае аренда — самый лучший выход из ситуации: к тому времени, когда проект подойдет к концу, выйдет новая версия ПО, и вы успеете ее протестировать и установить в процессе завершения проекта.
Другие вопросы, рассматриваемые в анализе «производить или покупать», включают такие элементы, как производственные мощности, навыки, доступность и коммерческая тайна. Для определенных процессов может потребоваться строгий контроль, поэтому они не могут быть отданы на аутсорсинг. Возможно, ваша организация имеет внутренние возможности для выполнения проекта, но из-за множества текущих незавершенных проектов вы будете ждать начала нового проекта многие месяцы, поэтому вам придется привлечь к работе подрядчика. Анализ «производить или покупать» считается методом общего менеджмента и направлен на принятие того или иного решения.
И у Хелдмана Кима, и у Мазура Ивана остальные процессы во многом включены в процесс планирования. Поэтому про них поговорим гораздо короче.
Оценка ресурсов операции — это процесс оценки ресурсов команды, типа и количества материала, оборудования и расходных материалов, необходимых для выполнения работ проекта.
Приобретение ресурсов — это процесс привлечения членов команды, средств, оборудования, материалов, расходных материалов и других ресурсов, необходимых для выполнения работ проекта.
Развитие команды — процесс совершенствования компетенций, взаимодействия членов команды, а также общих условий работы команды для улучшения исполнения проекта.
Управление командой — это процесс отслеживания деятельности членов команды, обеспечения обратной связи, решения проблем и управления изменениями в команде с целью оптимизации исполнения проекта.
Контроль ресурсов — это процесс обеспечения того, что назначенные и выделенные для проекта материальные ресурсы доступны в соответствии с планом, а также мониторинга для сравнения запланированного и фактического использования ресурсов и выполнения необходимых корректирующих действий.
Важно понимать, что на практике зачастую процессы сложно отделить друг от друга, они могут проходить параллельно или даже одновременно. Проектному менеджеру не следует создавать дополнительных препятствий развитию проекта, принудительно разделяя процессы между собой.
За хорошим обзором отдельных процессов управления ресурсами и проектного менеджмента в целом рекомендую обратиться к шестому изданию PMBok Guide.
С течением времени стили управления проектом смещаются от иерархической структуры управления и контроля в области управления проектами в сторону гибких и демократических подходов Они характеризуются большим коллективизмом и взаимной поддержкой, мобилизацией работы команды путём передачи принятия решений ее членам. Наиболее известными методиками для этого являются Agile и Scrum.
Методы управления ресурсами. Кроме этого, подходы к управлению ресурсами проекта в наши дни отличает стремление к оптимизации их использования. Мы можем наблюдать дефицит важнейших ресурсов в некоторых отраслях в последние годы, отчасти это последствие кризисов или бурного развития IT сектора. Дефицит дал толчок нескольким тенденциям экономии ресурсов. Например, методам бережливого менеджмента, производства «строго в срок» (just-in-time, JIT), кайзен (Kaizen), всеобщего обслуживания оборудования (total productive maintenance, TPM), теории ограничений (theory of constraints, TOC) и другим. Руководитель проекта должен определить, приняты ли в организации один или несколько инструментов для управления ресурсами, и соответственно адаптировать проект.
Эмоциональный интеллект (emotional intelligence, EI). Руководитель проекта должен уделять особое внимание своим личным Soft Skills, а в особенности эмоциональному интеллекту. Это включает развитие компетенций, обращенных внутрь (т. е. управление собой и самоанализ) и обращенных вовне (т. е. управление отношениями). Исследования показывают, что команды проектов, которые смогли поднять общий EI и стали эмоционально компетентной группой, работают более результативно. Кроме того, для таких команд характерна меньшая текучесть кадров.
Самоорганизующиеся команды. Распространение гибких подходов к управлению проектами, главным образом в проектах ИТ, привело к появлению понятия самоорганизующейся команды. Такой называют команду, которая работает без централизованного контроля. В таких командах роль руководителя проекта состоит в том, чтобы обеспечить команде необходимые среду и поддержку и качественно делегировать ей исполнение работы. Обычно такие команды состоят не из узких экспертов, а из специалистов широкого профиля, которые постоянно приводят работу в соответствие с трендами и активно используют обратную связь.
Виртуальные команды/распределенные команды. Пандемия и процесс глобализации проектов способствовали появлению развитию виртуальных команд, члены которых при работе над одним и тем же проектом находятся в разных местах. Работа таких команд стала возможной благодаря таким средствам коммуникации, как электронная почта, аудио-, видео-конференции, социальные сети, а также совещания, основанные на веб-технологиях. Управление виртуальными командами открывает уникальные возможности, например возможность использовать особые знания и опыт команды проекта даже в тех случаях, когда эксперты не находятся в одном регионе. Также можно вовлекать работающих на дому сотрудников, а также людей с ограниченными подвижностью или возможностями. Основные проблемы с виртуальными командами связаны с областью коммуникации, возможным чувством изолированности, пробелами в обмене знаниями и опытом между членами команды, а также трудности в отслеживании хода работ и производительности, вероятной разнице во времени по часовым поясам и культурными различиями.
Если вы хотите узнать больше об управлении ресурсами проекта, можете ознакомиться с бесплатным пособием Богомоловой А.В. и различными отечественными и международными стандартами: PMBOK Guide, стандарты IPMA, стандарты The Office of Government Commerce, стандарты APM, ГОСТ Р 52807-2007 и другими.
Подпишитесь на мой канал, если хотите узнать больше об управлении проектами.
PMBOK Guide 6th Edition. Must have Библия проектного менеджмента.
И.И. Мазур Управление проектами
Опубликовано в Проектный менеджмент. Метки: Части проекта.
Помимо уже рассмотренных нами аспектов проекта, существует важное деление на сферы знания. Что же это?
Нужно посмотреть на то, что институт управления проектом называет сферами знания управления проектом. Сферы знания — это системы процессов, которые сочетают в себе различные темы (предметы) и таким образом извлекают пользу из использования специфических знаний и умений в каждой из этих сфер.
— Профессиональное управление проектом, К. Хелдман
Или взглянем на определение, дающееся в PMBOK Guide.
Knowledge area – identified area of project management defined by its knowledge requirements and described in terms of its component processes, practices, inputs, outputs, tools, and techniques.
— PMBOK Guide 6th edition
Мой перевод, возможны ошибки принятой русскоязычной терминологии:
Сфера знания – определенная часть проектного менеджмента, определяемая её требованиями к знаниям и описываемая составляющими её процессами, практиками, вводами, выводами, инструментами и техниками.
В PMBOK Guide 6th edition выделяют десять сфер знания, о которых мы и поговорим сегодня.
1. Интеграция (Integration) – процессы и действия для поиска, определения, объединения и координирования различных процессов и деятельности в различных группах процессов.
2. Планирование (Schedule) – включает процессы, необходимые для обеспечения работы проекта в соответствии с расписанием.
3. Управление качеством (Quality Management) – включает процессы, необходимые для поддержания качества проекта в соответствии с политикой организации. Уровень качества помимо предъявления требований к самому проекту, также может распространяться на процессы планирования, управления и контроля проектом.
4. Коммуникации (Communications) – включает процессы, необходимые для координации всех работающих над проектом людей. Эти процессы направлены на работу с информацией по проекту: её планирование, сборка, создание, распределение, хранение, извлечение, управление, контроль, мониторинг и утилизация.
5. Закупки (Procurement) – процессы, необходимые для покупки или приобретения необходимых продуктов, сервисов или услуг за пределами команды.
6. Границы проекта (Scope) – процессы, которые гарантируют, что проект включает всю необходимую для своего завершения работу, и ничего лишнего.
7. Затраты (Cost) – процессы, связанные с планированием, определением, бюджетированием, финансированием, финансированием, управлением и контролем затрат. Всё это проводится с целью, чтобы проект мог быть завершен в рамках одобренного бюджета.
8. Ресурсы (Resources) – процессы по определению, приобретению и управлению ресурсами, необходимыми для успешного завершения проекта.
9. Риск (Risk) – процессы, связанные с управлением рисками, планированием, определением, анализом, планированием ответов, реализацией планов и мониторингом рисков на проекте.
10. Стейкхолдер (Stakeholder) – процессы, направленные на определение людей, групп и организаций, которые могут влиять или на которых может повлиять проект. В рамках управления стейкхолдерами анализируются ожидания стейкхолдеров, их влияние на проект, разрабатываются стратегии работы с ними.
Опубликовано в Проектный менеджмент.
PMI анонсировали, что седьмое издание книги PMBOK выйдет 1 августа 2021. PMBOK – один из самых важных ресурсов по проектному менеджменту. Большинство курсов Project Management Professional (PMP) готовят свои материалы на основе PMBOK. Потому седьмое издание PMBOK вдохнёт новую жизнь в PMP и CAPM сертификации.
До текущего момента PMBOK в основном фокусировался на технике управления проектом водопадом (waterfall). Но развитие технологий привело к ужесточению конкуренции на рынках. Жизненные циклы продуктов всё короче, а требования к проектам и продуктам могут меняться посередине проекта.
С традиционным подходом к проектному менеджменту очень сложно реагировать на постоянные изменения требований. Именно поэтому в двухтысячных активно начали развиваться методологии и подходы на основе Agile. Сейчас они наиболее распространены в IT индустрии.
Вместе с изменением динамики проектного менеджмента, трендов и фреймворков, PMBOK должен реагировать и меняться в соответствии. Именно поэтому PMBOK изменяют каждые 3-5 лет.
Если резюмировать:
Седьмое издание PMBOK будет сосредоточено на принципах, а не на процессах. А потому оно будет гораздо короче шестого издания.
В зависимости от характеристик проекта, индустрии, требований и организаций Проектные Менеджеры должны применять различные подходы к управлению проектами. Основные подходы: predictive, agile, гибридные или waterfall. Важно осознавать, что стандарты проектного менеджмента (вместе с ними и PMBOK) не должны предпочитать те или иные подходы. Стандарты должны помогать создавать успешные проекты и продукты.
Привычные проектному менеджеру процессы, инструменты, техники, вводы и выводы не будут присутствовать в седьмом издании PMBOK. Вместо них мы увидим принципы, которые в целом приняты и практикуются в проектном менеджменте. Если раньше PMBOK крутился вокруг результатов (deliverables), то теперь фокус будет на общем исходе, а не конкретных deliverables.
Поэтому в седьмом издании проекты будут не только создавать продукты (deliverables), но и общие результаты (outcomes), которые приносят ценность организации.
Если вы знаете английский, то понять общие тенденции поможет картинка:
Вместо десяти области знаний в PMBOK будут домены производительности (perfomance domains). Новые главы включат Tailoring, Models, Methods и Artifacts.
Вместо пяти групп процессов (инициирование, планирование, работа, мониторинг и контроль, закрытие) будет 12 принципов выпуска проекта (Project Delivery Principles) и система производства ценности (Value Delivery System). Value Delivery System на схеме выглядит вот так:
Седьмое издание PMBOK включает радикальные изменения, большой переход от waterfall к гибким техникам agile.
Опубликовано в Проектный менеджмент. Метки: open source, schedule management.
Иногда ради экономии ресурсов или эксперимента для управления проектами стоит попробовать что-то помимо Microsoft project. Представляю вашему вниманию подборку программ с открытым исходным кодом (значит, бесплатных) для проектного менеджмента.
Перевод статьи Франка Бергманна с сокращениями и дополнениями.
В теории подход к проектному менеджменту довольно прост. Мы создаем план проекта и дробим его на меньшие части, пока не сможем довольно точно определить стоимости, продолжительность, ресурсы и зависимости задач. Затем мы несём этот план для одобрения начальством, а потом следим за его исполнением. Когда мы распределяем все задачи проекта на шкале времени, получаем так называемую диаграмму Гантта.
Диаграммы Гантта используются очень давно для методологий водопада. Но их можно применять и для гибких методологий. Например, очень крупные проекты могут делать диаграммы Гантта для каждого спринта. Проектам поменьше лучше ограничиться диаграммами под важные релизы. В этих случаях диаграмма Гантта поможет нам отследить распределение ресурсов, времени и зависимости между разными частями. Ведь мы не можем сделать приложение раньше макетов его дизайна.
Существуют сотни программ для работы с диаграммами Гантта, от крупных и многофункциональных до мелких утилит. Наиболее известная из них – Microsoft Project. Она крайне маштабируемая и позволяет работать с проектами любой длительности и размера. Но при работе с ней зачастую непонятно, что дороже: стоимость лицензии или обучения персонала для работы с программой.
Другое ограничение MS Project – тот факт, что это десктоп-приложение. Работать с расписанием может только один человек. Иначе вам придётся доплатить за лицензии MS Project Server, Project для веба или Microsoft Planner.
Благо, вы можете серьезно сэкономить на бесплатных альтернативах с открытым исходным кодом. Все перечисленные программы включают в себя функционал по работе с диаграммами Гантта.
Проекты распределялись из соображений одного проектного менеджера с одним большим проектом. Важные критерии – функционал редактора диаграмм Гантта, кроссплатформенность, маштабируемость, импорт/экспорт и отчёты.
(Прим. переводчика: автор оригинальной статьи – создатель ]project-open[)
(Frank Bergmann, CC BY-SA 4.0)
Redmine – web инструмент для проектного управления с фокусом на agile методологии.
Стандартная установка включает диаграммы Гантта, но ей не хватает инструментов для планирования, drag&drop интерфейсов, распределения ресурсов. Вам придётся редактировать сущности одну за другой, чтобы поменять структуру дерева задач.
Для Redmine выпускали пару плагинов для редактирования диаграмм Гантта, но они либо устарели (Plus Gantt), либо проприетарны (ANKO Gantt chart).
Redmine написан на Ruby on Rails, его можно развернуть на Windows, Linux и macOS. Он идеален для IT команд, использующих гибкие методологии.
![]project-open[](https://opensource.com/sites/default/files/uploads/project-open.png "]project-open[")
(Frank Bergmann, CC BY-SA 4.0)
]project-open[ – ещё одна браузерная система управления проектами, которая отлично масштабируется на всю организацию (как ERP системы). В ней также можно управлять портфолио проектов, бюджетами, счетами, продажами, human resources и многим другим. Есть варианты использования для professional services automation (PSA) в организациях, работающих на проектной основе, PMO для стратегического управления проектами, и enterprise project management (EPM) для управления проектами отдела.
Редактор диаграмм Гантта включает иерархию задач, зависимости и планирование в зависимости от необходимой работы и выделенных ресурсов. В ]po[ нет поддержки календарей ресурсов. Система довольно сложная, а интерфейс иногда порядком староват.
]project-open[ также кроссплатформенен. Он удобен для средних и крупных организаций, которым необходимо много финансовой отчётности по проектам. Она выделяется за счёт интеграции всей компании или отдела в одну систему, что упрощает стратегическое управление и контроль.
(Frank Bergmann, CC BY-SA 4.0)
ProjectLibre – наиболее близкий по духу Microsoft Project вариант. Это десктоп-приложение, которое включает все важные функции для планирования проекта, включая календари ресурсов, baselines и управление стоимостью. Также поддерживается импорт-экспорт с MS Project.
Это идеальная система для маленьких или средних проектов. Здесь нет некоторых узких функций MS Project, а GUI не самый красивый.
ProjectLibre написан на Java и доступен на Windows, Linux и macOS. По проприетарной лицензии доступен веб клиент ProjectLibreCloud.
ProjectLibre идеально подойдёт для отдельного PM’а, управляющего небольшими проектами. Или для просмотра проекта членами команды, у которых нет лицензии MS Project.
(Frank Bergmann, CC BY-SA 4.0)
GanttProject похож на ProjectLibre своим десктоп редактором диаграм Гантта, однако функционал здесь гораздо меньше. Вы не найдёте здесь baselines или non-human resources, да и отчёты весьма ограничены.
GanntProject подойдёт разве что для построения отдельных диаграмм или изучения техник управления на их основе.
(Frank Bergmann, CC BY-SA 4.0)
TaskJuggler позволяет планировать несколько параллельных проектов в крупных организациях. Для этого здесь есть механизм автоматического разрешения конфликтов при распределении ресурсов.
Это не интерактивный редактор диаграмм. Вам придётся поработать с консолью в манере компилятора. Программа читает список задач из текстового файла и выдает серию отчётов с оптимальными началами и окончаниями каждой задачи на основании выделенных ресурсов, зависимостей, приоритетов и других параметров.
Если вы решитесь изучить специфический синтаксис TaskJuggler, то найдёте здесь весь необходимый функционал для автоматического планирования проекта. Вы можете интегрировать результаты с ]project-open[.
(Frank Bergmann, CC BY-SA 4.0)
ProjeQtOr – браузерное приложение для управления проектами, специализирующееся на IT. Тут можно управлять рисками, бюджетами, результатами и финансовыми документами, помимо привычного функционала проектов, тикетов и задач. С ProjeQtQr вы сможете интегрировать множество аспектов проектного менеджмента в одной системе.
ProjeQtQr предоставляет редактор диаграмм Гантта, особо не отличающийся в функциях от ProjectLibre. ПО написано на PHP и доступно для Windows, Linux, и macOS. В системе вы сможете сохранить множество различной информации по всем проектам отдела или компании.
В отдельных ситуациях вам может пригодиться одна из этих программ, которые заслуживают упоминания, но не вошли в общий список.
(Frank Bergmann, CC BY-SA 4.0)
Опубликовано (изменено: ) в Проектный менеджмент. Метки: Части проекта.
Группы процессов – логические группы процессов проектного менеджмента, которые направлены на достижение определенных целей проекта.
В PMBOK Guide выделяют пять групп проектов:
В дальнейшем все конкретные процессы проектного менеджмента, мы будем определять к одной из этих пяти групп.
Опубликовано (изменено: ) в Проектный менеджмент. Метки: Части проекта.
Процесс проектного менеджмента – систематическая последовательность действий, в которых вход (исходный материал) преобразуется в выход (результат процесса) при помощи инструментов и техник проектного менеджмента. Выходом может быть результат (deliverable).
Процессы связаны между собой входами и выходами и могут содержать пересекающиеся действия, которые происходят за проект. Обычно результат одного процесса становится входом другого или одним из результатов (deliverables) проекта или фазы проекта.
Все процессы проектного менеджмента попадают в одну из 5 групп:
О них подробнее в следующем посте.
Опубликовано (изменено: ) в Проектный менеджмент. Метки: Части проекта.
Фаза проекта – набор логически связанных действий в проекте, которые вместе создают один или более результат (deliverable).
Каждая из фаз проекта может быть описана рядом измеряемых атрибутов, которые зачастую уникальны для конкретной фазы.
В проектном менеджменте нет конкретного перечня фаз. Условно их можно распределить по группам: открытие проекта, организация и подготовка, выполнение работ, окончание проекта.
Примерами фаз проекта являются: разработка концепта, исследование рисков, сбор требований, разработка решения, дизайн, прототип, билд, тест, переход, сдача проекта.
Phase gate – проверка в конце фазы, в ходе которой принимается решение по продолжению, изменению или окончанию фазы проекта. Продуктивность и прогресс проекта сверяется с проектной и бизнес документацией.
Примеры phase gates: phase review, stage gate, kill points, phase exits.
Опубликовано (изменено: ) в Проектный менеджмент.
Проектный менеджмент решает вопросы применения процессов проектного менеджмента в каждом конкретном проекте. Задача проектного менеджмента – создать практический результат для компании: выпустить продукт, решить проблему, помочь достичь цели.
Программный менеджмент фокусируется на взаимосвязи между проектами и программой, чтобы вывести оптимальный подход к их управлению. Так как программа состоит из проектов и подпрограмм, управлять созданием благ к программе можно целостно, а не на уровне отдельных проектов. Цель программного менеджмента – создать ценность для организации, извлечь выгоду из проекта.
Опубликовано (изменено: ) в Проектный менеджмент.
Портфолио организации состоит из стратегии организации, которая определяет набор программ, реализуемых в компании.
Каждая из этих программ может включать один или более связанных проектов. После окончания проектов продукты уходят в подчинение операционному менеджменту.
Опубликовано (изменено: ) в Проектный менеджмент.
1) Необходимость соответствия регуляторным, юридическим или социальным требованиям
2) Необходимость удовлетворения запросов стейкхолдеров или потребности компании: запросы рынка, клиентов или стейкхолдеров, потребности общества.
3) Необходимость создания или изменения стратегий бизнеса: поддержание конкурентоспособности на рынке при изменении технологий/политической обстановки/ситуации на рынке или из соображений поддержания экосистемы (окружающая среда, персонал и т.д.).
4) Необходимость создания, улучшения или исправления продуктов, процессов или услуг бизнеса: появляется вследствие тех же причин, что и предыдущий пункт.
Опубликовано (изменено: ) в Проектный менеджмент.
Соответственно, проекты направлены на создание ценности и выгоды для компании. И управляющие компаний работают с ограниченными бюджетами, сроками, ресурсами и технологиями. И чтобы остаться конкурентоспособными, они применяют техники проектного менеджмента.
Опубликовано (изменено: ) в Проектный менеджмент.
1) Проект – временная деятельность, направленная на создание уникального продукта, услуги или результата. Имеет конкретное начало и конец, предпринимается для выполнения целей за счёт создания deliverables.
2) Deliverable (результат) – любой уникальный и тестируемый продукт, результат или возможность оказания услуг, который требуется для завершения процесса, фазы или проекта.
Опубликовано (изменено: ) в Проектный менеджмент.
Сотрудники, которые организуют команду, работают со стейкхолдерами и двигают проекты вперед
Они менеджат бюджет, сроки, цели и задачи проекта как в big picture, так и под микроскопом.
Для организации проекта они используют различные техники и методологии, делят сложные задачи на мелкие, которые можно задокументировать, отследить и проконтролировать
PMы встречаются в каждой организации нар разных позициях: сотрудники, менеджеры, консультанты и CEO.
Опубликовано (изменено: ) в Без рубрики.
Почему в Minecraft нет развитой экономики? Там нет разделения труда. У игроков нет причин для обмена товаров друг с другом, если они всё могут произвести самостоятельно с равной степенью эффективности.
Опубликовано (изменено: ) в Без рубрики, Проектный менеджмент.
Области знаний, необходимые для PMа: интеграция, scope, время, стоимость, качество, закупки, HR, коммуникации, управление рисками, управление стейкхолдерами.
Опубликовано (изменено: ) в Без рубрики, Проектный менеджмент.
Все процессы проектного менеджмента попадают в одну из 5 категорий:
Опубликовано (изменено: ) в Без рубрики.
Привет всем!
Решил присоединиться к тренду на мобильную журналистику. Я постоянный автор журнала “Системный Администратор”, также пишу для соцсетей. И следующий месяц я буду писать посты/статьи/материалы только с телефона, а об успехах и трудностях уведомлять вас.
Большой пост, будет дополняться
Опубликовано (изменено: ) в Без рубрики.
Яндекс опубликовал исследование со сравнением стоимостей владения автомобилями, каршеринга и такси в разных городах. Интересно почитать, если хотите немного больше узнать о роли такси и каршерингов в вытеснении владельцев автомобилей.
https://yandex.ru/company/researches/2020/auto-cost
Опубликовано (изменено: ) в Без рубрики.
Очередной злой инста-предприниматель, который ищет бесплатных рабов на галерах, попытался найти себе SMMщика на роль “управляющего аккаунтом”. При этом сама пишет о том, что такой специальности нет.
Скриншоты я ни у кого не воровал. Влада сама их выложила в группу SMMщиков в ВК.
Так когда же они уже все поймут, что любая работа (хоть с опытом, хоть без) будет оплачиваться. А с предложениями бесплатного труда они могут катиться ежиком в свой райский мир ванильных инста-предпринимателей. Бесплатный труд ты даже в портфолио не запишешь, потому что ты будешь недорабочим, за занятость которого никто не отвечал.
И если у вас сотрудник без почасовой, то 10к это смешно. 20к мало, но уже можно. Либо придумывайте сдельные условия, чтобы можно было совмещать несколько проектов без вопросов с чьей-либо стороны.