Менеджмент управление проектами что это такое

Топ-7 методов управления проектами: Agile, Scrum, Kanban, PRINCE2 и другие

«Из всех трудностей, с которыми столкнулись НАСА, отправляя человека на Луну, управление было наверно самой сложной задачей»

— Роджер Лаунис, историк НАСА

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

И хотя лишь единицы из нас столкнутся с задачами такого масштаба, большинство читателей этого блога так или иначе сталкивается с проектным управлением. По оценкам PMI к 2020 году появятся 15 миллионов новых позиций проектных специалистов – а многим другим профессионалам зачастую приходится руководить мини-проектами, хотя бы на личном уровне.

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

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

Разработанные подходы сильно отличаются друг от друга. Они различаются по областям применения, детализированности, самодостаточности и формализации. В заголовке мы назвали их «методами» для удобства, но на самом деле в статье представлены стандарты, концепции, методы и фреймворки, которые применяются в управлении проектами. Цель данной статьи — дать наиболее широкий обзор существующих в управлении проектами подходов.

В этой статье мы рассмотрим:

Классический проектный менеджмент
Agile
Scrum
Lean
Kanban
Six Sigma
PRINCE2

И прежде чем рассматривать конкретные методы, давайте ответим на очевидный вопрос – «А зачем вообще нужны системы и методы управления проектами?» – рассмотрим, естественно, кратко, историю управления проектами и определим базовые термины проектного управления.

Почему «управление проектами»?

Имена Нила Армстронга и Базза Олдрина навсегда войдут в историю как символы одного из величайших достижений человечества – высадке человека на Луну. Однако основной вклад в это событие внесли 400 000 сотрудников НАСА и 20 000 компаний и университетов, работавших вместе над миссией «Аполлон».

В 1961 году Джон Кеннеди поставил задачу высадить человека на спутнике Земли и вернуть его обратно – при том, что на тот момент НАСА отправляли человека в космос лишь на 15 минут. Такая амбициозная цель потребовала невероятного количества ресурсов, кооперации, инноваций и планирования.

Как говорится в книге НАСА «Managing the Moon Program», основная проблема состояла не в том, «что делать?», а в том, «как сделать столько за такой короткий срок?». По словам доктора Макса Фагета (Dr. Max Faget), главы инжиниринга в Космическом центра имени Линдона Джонсона (The Lyndon B. Johnson Space Center, JSC), тогда в НАСА не представляли, как уложить все необходимые действия в 10 лет. А потому первым шагом стало «разбить проект на управляемые этапы».

Затем важно было ускорить выполнение каждой отдельной фазы и удостовериться, что команды и компании, работающие на каждой фазе, эффективно взаимодействуют друг с другом и вовремя поставляют результаты. Эта задача была возложена на доктора Джорджа Мюллера (George E. Muller), управлявшего каждой частью проекта «Аполлон», от Белого Дома до поставщика самой мелкой детали. Чтобы контролировать проект было легче, он решил разбить проект на 5 областей: «Контроль Программы», «Системная Инженерия», «Тестирование», «Надёжность и Качество» и «Лётная эксплуатация». Схема управления программой Аполлон представлена на Рисунке 1.

Эта система из 5 этапов – названных «Этапами GEM» в честь инициалов доктора Мюллера – была разработаны «ради фокусировки на тестировании продукта, и на его разработке с учётом того, что его будут тестировать», как отмечает сам Мюллер. «Контроль Программы» определял, что нужно сделать, управлял бюджетом и требованиями, а также управлял взаимосвязями элементов программы. Область «Системная инженерия» отвечала за разработку новых устройств и узлов, «Тестирование» за то, что эти новые элементы работают, «Надёжность и Качество» проверяли разработанные элементы на соответствие требованиям и стандартам, а «Лётная эксплуатация» отвечала за то, что эти узлы будут работать во время полёта.

Многие изначально отнеслись к методу, предложенному Мюллером, со скептицизмом, но в конце концов ему удалось убедить членов программы в необходимости следования данному алгоритму. Данная система показала свою эффективность – проект был завершён успешно, и, можно даже сказать, триумфально, с опережением заявленных сроков. Это стало возможно только благодаря разбитию масштабного проекта на управляемые, повторяемые этапы, что позволило работать множеству отдельных компаний и специалистов в едином ритме. Так проектное управление доказало свою эффективность в Космической гонке.

Краткая история проектного управления

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

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

Однако, если Вы – шеф-повар, и готовите не одно блюдо, а несколько, например, салат (приготовление которого состоит из 3 этапов) и десерт (который нужно только подать), то Вам потребуется инструмент, позволяющий отслеживать временные затраты на каждый из элементов и время, когда они должны быть готовы. И тут на помощь приходит один из первых современных инструментов проектного управления: Диаграмма Гантта, представленная на Рисунке 2.

Изобретённая независимо Королем Адамеки (Korol Adamecki) и Генри Л. Ганттом (Genry L. Gantt) в начале XX в., диаграмма Гантта показывает расписание проекта основываясь на датах окончания и завершения задач. В неё вносятся задачи, их длительности и взаимосвязи, а затем высчитывается критический путь – самая длинная цепочка взаимосвязанных задач, определяющих длительность проекта. Взаимосвязи между началом и окончанием разных задач очень важны – вы же не можете подать гостям суп, пока вы его не сварили, не так ли?

Так вот, типовой проект очень похож на проект приготовления и подачи ужина, только в нём гораздо больше задач, взаимосвязей, дедлайнов и видов ресурсов. Проектам с жёсткими дедлайнами диаграмма Гантта помогает решить, когда лучше начинать те или иные задачи, чтобы сократить время реализации. А для проектов с сильными ресурсными ограничениями, диаграмма Гантта предоставляет возможность построить схему в форме событийной цепочки процессов (event-driven process chain) для планирования ресурсов.

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

Для таких проектов лучше подходят гибкие методы управления проектами Agile и связанные с ним подходы, такие как Lean, Kanban и другие. Есть и методы, позволяющие управлять как рабочим потоком, так и временем, и ресурсами – 6 Сигм и Scrum.

Классическое проектное управление

Наиболее очевидный способ сделать свой проект более управляемым – это разбить процесс его исполнения на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. В этом смысле оно напоминает компьютерную игру – нельзя перейти на следующий уровень не завершив предыдущий. Схема рабочего процесса приведена на Рисунке 3.

Данный подход ориентирован на проекты, в которых есть строгие ограничения по последовательности выполнения задач. Например, строительство дома – нельзя возводить стены без фундамента.

Обычно выделяют 5 этапов классического проектного управления, но можно добавлять и дополнительные этапы, если того требует проект.

5 этапов традиционного менеджмента:

Этап 1. Инициация. Руководитель проекта и команда определяют требования к проекту. На данном этапе часто проводятся совещания и «мозговые штурмы», на которых определяется что же должен представлять из себя продукт проекта.

Этап 2. Планирование. На данном этапе команда решает, как она будет достигать цели, поставленной на предыдущем этапе. На данном этапе команда уточняет и детализует цели и результаты проекта, а также состав работ по нему. На основании данной информации команда формирует календарный план и бюджет, оценивает риски и выявляет заинтересованные стороны.

Этап 3. Разработка. Данная стадия реализуется не для всех проектов — как правило она является частью фазы планирования. В фазе разработки, характерной для технологических проектов, определяется конфигурация будущего проекта и/или продукта и технические способы его достижения. Например в ИТ-проектах на данном этапе выбирается язык программирования. (В отечественной практике данная фаза обычно не выделяется, а термин «разработка» не используется — прим. пер.)

Этап 4. Реализация и тестирование. На этой фазе происходит собственно основная работа по проекту – написание кода, возведение здания и тому подобное. Следуя разработанным планам начинает создаваться содержание проекта, определённое ранее, проводится контроль по выбранным метрикам. Во второй части данной фазы происходит тестирование продукта, он проверяется на соответствие требованиям Заказчика и заинтересованных сторон. В части тестирования выявляются и исправляются недостатки продукта.

Этап 5. Мониторинг и завершение проекта. В зависимости от проекта данная фаза может состоять из простой передачи Заказчику результатов проекта или же из длительного процесса взаимодействия с клиентами по улучшению проекта и повышению их удовлетворённости, и поддержке результатов проекта. Последнее относится к проектам в области клиентского сервиса и программного обеспечения.

То, что описано выше – база, на которой строятся различные методы управления проектами. Разным проектам нужны различные фазы реализации – некоторым достаточно и трёх фаз, другим гораздо больше. Иногда используется так называемый «итеративный водопад», в котором каждый этап представляет собой некий подпроект, в ходе которого задачи реализуются по фиксированным итерациям. Но суть остаётся одна – проект разбит на этапы, которые исполняются в строго определённой последовательности.

Благодаря тому, что классический проектный менеджмент строго привязан ко времени исполнения задач, как правило, заранее определённому на этапе планирования, для реализации проектов в рамках данного подхода отлично подходят инструменты календарно-сетевого планирования. Самым распространённым инструментом календарно-сетевого планирования является уже упомянутая ранее диаграмма Гантта. Существует множество инструментов для её построения – от простых таблиц вроде Excel и Smartsheet до профессиональных программных пакетов вроде Microsoft Project и Primavera.

Сильные стороны классического проектного менеджмента

Сегодня довольно часто говорится о том, что классический водопадный подход устарел, но он и не думает сдавать позиции. Большим плюсом данного подхода является то, что он требует от Заказчика и руководства компании определить, что же они хотят получить, уже на первом этапе проекта. Раннее включение привносит определённую стабильность в работу проекта, а планирование позволяет упорядочить реализацию проекта. Кроме того, этот подход подразумевает мониторинг показателей и тестирование, что совершенно необходимо для реальных проектов различного масштаба.

Потенциально, классический подход позволяет избежать стрессов ввиду наличия запасного времени на каждом этапе, заложенного на случай каких-либо осложнений и реализации рисков. Кроме того, с правильно проведённым этапом планирования, руководитель проектов всегда знает, какими ресурсами он обладает. Даже если эта оценка не всегда точная.

Слабые стороны классического проектного менеджмента

Основная слабая сторона классического проектного менеджмента – нетолерантность к изменениям. Руководство компании Toyota, знаменитую созданием таких систем как Lean и Kanban, часто критикуют за то, что они применяют классический подход в разработке софта для своей компании, причём именно за недостаток гибкости.

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

Agile

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

И тут в игру вступает Agile – семейство гибких итеративно-инкрементальных методов к управлению проектами и продуктами. Согласно данному подходу, проект разбивается не на последовательные фазы, а на маленькие подпроекты, которые затем «собираются» в готовый продукт. Схема работы приведена на Рисунке 5.

Таким образом, инициация и верхнеуровневое планирование проводятся для всего проекта, а последующие этапы: разработка, тестирование и прочие проводятся для каждого мини-проекта отдельно. Это позволяет передавать результаты этих мини-проектов, так называемые, инкременты, быстрее, а приступая к новому подпроекту (итарации) в него можно внести изменения без больших затрат и влияния на остальные части проекта.

Несмотря на то, что Agile вошёл в моду относительно недавно, идея итеративной разработки не нова (об истории появления Agile можно прочесть здесь – прим.пер.). Своё нынешнее название семейство гибких методологий получило в 2001 с публикации Манифеста Agile (Agile Manifesto), закрепившем основные ценности и принципы гибкой разработки программного обеспечения, в основе которых – командная работа и адаптация, даже «любовь» к изменениям.

Сам по себе Agile – не метод управления проектами. Это скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют, фреймворки (frameworks): Scrum, Kanban, Crystal, и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам.

Сильные стороны Agile

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

Один из принципов Agile: «Реакция на изменения важнее следования плану». Именно быстрая и относительно безболезненная реакция на изменения является причиной тому, что многие крупные компании стремятся сделать свои процессы более гибкими. Кроме того, Agile отлично подходит для проектов с «открытым концом» — например, запуску сервиса или блога.

Вотчина Agile – разработка новых, инновационных продуктов. В проектах по разработке таких продуктов высока доля неопределённости, а информация о продукте раскрывается по ходу проекта. В таких условиях реализовывать проект по «водопаду» становится невозможно– нет информации для планирования.

Слабые стороны Agile

В отличие от PRINCE2 и PMBOK Agile – не является ни методологией, ни стандартом. Agile — это набор принципов и ценностей. Слабая сторона состоит в том, что каждой команде придётся самостоятельно составлять свою систему управления, руководствуясь принципами Agile. Это непростой и длительный процесс, который потребует изменений всей организации, начиная процедурами и заканчивая базовыми ценностями. Это тернистый путь и не всем организациям он под силу.

Этот путь потребует от лидера изменений не только знаний и упорства, но и серьёзных административных ресурсов, а также затрат. К счастью, существуют готовые наборы практик, которые облегчают Agile-трансформацию организации. К таким наборам относятся фреймворк Scrum, метод Kanban и многие другие – Crystal, LeSS, SAFe, Nexus.

Scrum

Гибкий фреймворк, созданный в 1986 году, считается самым структурированным из семейства Agile. Созданный в 1986 году, он сочетает в себе элементы классического процесса и идеи гибкого подхода к управлению проектами. В итоге получилось очень сбалансированное сочетание гибкости и структурированности.

Следуя заветам Agile, Scrum разбивает проект на части, которые сразу могут быть использованы Заказчиком для получения ценности, называемые заделами продуктов (product backlog). И несмотря на то, что «задел продукта» — достаточно верный перевод и используется в профессиональной литературе, в российской практике чаще всего используется просто «беклог». Затем эти части приоретизируются Владельцем продукта – представителем Заказчика в команде. Самые важные «кусочки» первыми отбираются для выполнения в Спринте – так называются итерации в Scrum, длящиеся от 2 до 4 недель. В конце Спринта Заказчику представляется рабочий инкремент продукта – те самые важные «кусочки», которые уже можно использовать. Например, сайт с частью функционала или программа, которая уже работает, пусть и частично. После этого команда проекта приступает к следующему Спринту. Длительность у Спринта фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из проекта и собственной производительности.

Чтобы удостовериться в том, что проект отвечает требованиям Заказчика, которые имеют свойство изменяться со временем, перед началом каждого Спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений. В этом процессе участвуют все – команда проекта, Scrum Мастер (Scrum Master, лидер команды проекта) и Владелец продукта. И ответственность за этот процесс лежит на всех.

Как уже говорилось, Владелец продукта является представителем Заказчика в проекте, или олицетворяет всех клиентов будущего проекта, в случае если Заказчика нет. Для этого он должен досконально знать их потребности и образ мышления, а также разбираться в продукте и технологии его изготовления. Scrum Мастер призван помочь участникам проекта лучше понять и принять ценности, принципы и нормы практики Scrum. Он лидер и посредник между внешним миром и командой. Его задача — следить, чтобы никто не мешал команде самостоятельно и комфортно работать над поставленными задачами. Команда же отвечает за то, чтобы в конце спринта все необходимые задачи были сделаны, а поставки – выполнены.

Основная структура процессов Scrum вращается вокруг 5 основных встреч: упорядочивания беклога, планирования Спринта, ежедневных летучек, подведения итогов Спринта и ретроспективы Спринта.

Встреча по упорядочиванию беклога (Backlog Refinement Meeting, «Backlog Grooming»): Эта встреча аналогична фазе планирования в классическом проектном управлении, и проводится в первый день каждого Спринта. На ней рассматривается – что уже было сделано по проекту в целом, что ещё осталось сделать и принимается решение о том, что же делать дальше. Владелец продукта определяет, какие задачи на данном этапе являются наиболее приоритетными. Данный процесс определяет эффективность Спринта, ведь именно от него него зависит, какую ценность получит Заказчик по итогам спринта.
Планирование Спринта: После того, как Владелец продукта определил приоритеты, команда совместно решает, что же конкретно они будут делать во время грядущей итерации, как достигнуть поставленной на предыдущей встрече цели. Команды могут применять различные инструменты планирования и оценки на данном этапе, лишь бы они не противоречили принципам и логике Scrum. Планирование Спринта проводится в самом начале итерации, после Встречи по упорядочиванию продукта.
Ежедневные летучки: Каждый день спринта, в идеале, в одно и то же время, члены команды тратят 15 минут на то, чтобы поделиться информацией о статусе задач и состоянии проекта. На ней не происходит обсуждений проблем или принятия решений – если после встречи возникают вопросы и конфликты, Scrum Мастер и вовлечённые участники обсуждают их отдельно. Летучка же нужна для обмена информации и поддержания всех членов команды в курсе состояния проекта.
Подведение итогов Спринта: Цель этапа – обследование и адаптация создаваемого продукта. Команда представляет результаты деятельности всем заинтересованным лицам. Основная задача – убедиться, что продукт этапа соответствует ожиданиям участников и согласуется с целями проекта.
Ретроспектива Спринта: Проводится сразу после Подведения итогов спринта и до планирования следующего спринта. На нём команда выясняет, насколько чётко и слаженно проходил процесс реализации этапа. Обследованию подвергаются возникшие проблемы в работе, методологии и взаимодействии. Именно этот этап позволяет команде провести рефлексию и следующий Спринт провести эффективнее.

Многим Scrum может показаться сложным для внедрения – новый процесс, новые роли, много делегирования и совершенно новая организационная структура. Но это гибкий и при этом структурированный подход к реализации проектов, который, в отличие от размытых и общих принципов Agile, не позволит работе пойти не в то русло.

Сильные стороны Scrum

Scrum был разработан для проектов, в которых необходимы «быстрые победы» в сочетании с толерантностью к изменениям. Кроме того, этот фреймворк подходит для ситуаций, когда не все члены команды имеют достаточный опыт в той сфере, в которой реализуется проект – постоянные коммуникации между членами командами позволяют недостаток опыта или квалификации одних сотрудников за счёт информации и помощи от коллег.

Онлайн телеканал Netflix является отличным примером быстрых поставок результатов. Сайт ресурса обновляется каждые две недели благодаря Scrum, который не просто позволяет работать с высокой скорости, но и аккумулирует пользовательский опыт и даёт возможность выявить самое главное для клиентов.

В ходе каждой итерации, разработчики добавляют и тестируют новые функции сайта и убирают те, которыми не пользовались клиенты. По словам команды Netflix, основное преимущество Scrum в том, что он позволяет «быстро ошибаться». Вместо того, чтобы долго и с большими затратами готовить крупный релиз, поставки раз в две недели по Scrum имеют небольшой размер. Их легко отслеживать и, если что-то идёт не так, быстро исправлять.

Слабые стороны Scrum

Scrum очень требователен к команде проекта. Она должна быть небольшой (5-9 человек) и кроссфункциональной – то есть члены команды должны обладать более чем одной компетенцией, необходимой для реализации проекта. Например разработчик ПО должен обладать познаниями в тестировании и бизнес-аналитике. Делается это для того, чтобы часть команды не «простаивала» на разных этапах проекта, а также для того, чтобы сотрудники могли помогать и подменять друг друга.

Кроме того, члены команды должны быть «командными игроками», активно брать на себя ответственность и уметь самоорганизовываться. Подобрать такую зрелую команду очень непросто!

Scrum подходит не для всех команд и организаций ещё и потому, что предлагаемый процесс может не подойти для разработки конкретного продукта – например промышленного станка или постройки здания.

Lean

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

В Lean, так же, как и в Scrum, работа разбивается на небольшие пакеты поставки, которые реализуются отдельно и независимо. Но в Lean для разработки каждого пакета поставки существует поток операций с этапами, подобными тем, которые были созданы для проекта Аполлон. Как и в классическом проектном менеджменте, это могут быть этапы планирования, разработки, производства, тестирования и поставки – или любые другие необходимые для качественной реализации проектов этапы.

Этапы Lean и их гибкость позволяют быть уверенными в том, что каждая часть проекта реализуется так, как требуется. В Lean не прописаны чёткие границы этапов, как в Scrum прописаны ограничения Спринтов. Кроме того, в отличие от классического проектного менеджмента, Lean позволяет параллельно выполнять несколько задач на разных этапах, что повышает гибкость и увеличивает скорость исполнения проектов.

Как и Agile, Lean это скорее концепция, образ мышления, нежели нечто высеченное в камне. Используя идеи Lean Вы можете самостоятельно создать систему, удовлетворяющую вашим требованиям в управлении проектами.

Сильные стороны Lean

Если Вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти требования. Lean сочетает гибкость и структурированность, как Scrum, но в немного другом ключе.

Слабые стороны Lean

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

А ещё, в отличие от Scrum, Lean не предлагает чёткого рабочего процесса для реализации «кусочков» проекта, что способствует растягиванию сроков проекта. Эта проблема может быть решена при помощи эффективного руководства и чётких коммуникаций ̶ главное помнить об этом.

Kanban

Lean выглядит немного абстрактным сам по себе, но в комбинации с Kanban его становится гораздо проще использовать для построения собственной системы управления проектами. Созданный инженером компании Toyota Тайичи Оно (Taiichi Ono) в 1953 году, Kanban очень похож на схему промышленного производства. На входе в этот процесс попадает кусочек металла, а на выходе получается готовая деталь. Также и в Kanban, инкремент продукта передаётся вперёд с этапа на этап, а в конце получается готовый к поставке элемент.

Кроме того, создатель Kanban вдохновлялся супермаркетами, а именно их принципом – «держи на полках только то, что нужно клиенту». А потому в Kanban разрешается оставить неоконченную задачу на одном из этапов, если её приоритет изменился и есть другие срочные задачи. Неотредактированная статья для блога, подвешенная без даты публикации или часть кода функции, которую возможно не будут включать в продукт – всё это нормально для работы по Kanban.

Kanban намного менее строгий, нежели Scrum – он не ограничивает время спринтов, нет ролей, за исключением владельца продукта. Kanban даже позволяет члену команды вести несколько задач одновременно, чего не позволяет Scrum. Также никак не регламентированы встречи по статусу проекта – можно делать это как Вам удобно, а можно не делать вообще.

Для работы с Kanban необходимо определить этапы потока операций (workflow). В Kanban они изображаются как столбцы, а задачи обозначают специальные карточки. Карточка перемещается по этапам, подобно детали на заводе, переходящей от станка к станку, и на каждом этапе процент завершения становится выше. На выходе мы получаем готовый к поставке заказчику элемент продукта. Доска со столбцами и карточками может быть как настоящей, так и электронной – даже здесь Kanban не накладывает никаких ограничений на пользователей.

Ваша собственная система Kanban может быть настолько гибкой, насколько Вы сами того пожелаете – ведь во многом Kanban является визуализацией идеи Agile. Но у Kanban есть 4 столпа, на которых держится вся система:

Карточки: Для каждой задачи создаётся индивидуальная карточка, в которую заносится вся необходима информация о задаче. Таким образом, вся нужная информация о задаче всегда под рукой.
Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.
Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.
Постоянное улучшение («кайзен» (kaizen)): Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности.

Сильные стороны Kanban

Как и Scrum, Kanban хорошо подходит для достаточно сплочённых команды с хорошей коммуникацией. Но в отличие от Scrum, в Kanban нет установленных чётких дедлайнов, что хорошо подходит для замотивированных и опытных команд.

При правильной настройке и управлении, Kanban может принести большую пользу команде проекта. Точный расчёт нагрузки на команду, правильная расстановка ограничений и концентрация на постоянном улучшении — всё это позволяет Kanban серьёзно экономить ресурсы и укладывать в дедлайны и бюджет. И всё это в сочетании с гибкостью.

Слабые стороны Kanban

Часто можно слышать, что по Kanban, в отличие от Scrum, можно работать с практически любой командой. Но это не совсем так. Kanban лучше всего подходит для команд, навыки членов которых пересекаются друг с другом. Таким образом они могут помогать друг другу преодолевать трудности при решении задач. Без этого Kanban будет не так эффективен, как мог бы быть. Также, как уже было сказано, Kanban лучше подходит в тех случаях, когда нет жёстких дедлайнов. Для жёстких дедлайнов лучше подходит классический подход или Scrum.

6 сигм (Six Sigma)

Компания Motorola, наряду с Toyota, также внесла вклад в развитие мирового проектного управления. Инженер этой компании Bill Smith создал концепцию 6 сигм в 1986 году. Это более структурированная версия Lean нежели Kanban, в которую добавлено больше планирования для экономии ресурсов, повышения качества, также снижения количества брака и проблем.

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

Для этого было предложен процесс из 5 шагов, известных как DMEDI:

Определение (Define): Первый этап очень похож на ранние этапы других систем проектного управления. На нём определяется содержание проекта, собирается информация о предпосылках проекта, ставятся цели.
Измерение (Measure): 6 сигм ориентирована на сбор и анализ количественных данных о проекте. На данном этапе происходят определяется, какие показатели будут определять успех проекта и какие данные нужно собирать и анализировать.
Исследование (Explore): На стадии исследования менеджер проекта решает, каким же образом команда может достичь поставленных целей и исполнить все требования в срок и в рамках бюджета. На данном этапе очень важно нестандартное мышление руководителя проектов при решении возникших проблем.
Разработка (Develop): На данном этапе реализуются планы и решения, принятые на предыдущих этапах. Важно понимать, что на данном этапе необходим детальный план, в котором описаны все действия, необходимые для достижения поставленных целей. Также на данном этапе измеряется прогресс проекта.
Контроль (Control): Ключевой этап в методологии 6 сигм. Его основная задача – долгосрочное улучшение процессов реализации проектов. Данный этап требует тщательного документирования извлечённых уроков, анализа собранных данных и применения полученных знаний как в проектах, так во всей компании в целом.

6 сигм очень похожа на Kanban, только с установленными этапами реализации задач – планированием, определением целей и тестированием качества. Вероятнее всего, встреч команды при применении 6 сигм будет значительно больше, чем при Kanban, но зато процесс реализации проектов более структурирован и команде сложнее сбиться с пути. И, как и Kanban, 6 сигм можно относительно легко адаптировать к нуждам конкретной компании или команды. Жёстким требованием является лишь тщательное измерение и контроль показателей проекта на этапах реализации – без этого невозможно постоянное долгосрочное улучшение процессов реализации проекта.

Сильные стороны 6 сигм

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

6 сигм подходит для трудных проектов, в которых много новых и сложных операций. Данный подход позволяет реализовывать элементы проекта, учиться на ошибках и повышать качество в будущем.

Слабые стороны 6 сигм

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

Кроме того, основной лейтмотив 6 сигм: «Всё всегда можно сделать ещё лучше». Это может демотивировать сотрудников, не чувствующих удовлетворения от проделанной работы. Кроме того, если проект единичный и компания не планирует в будущем реализовывать подобные проекты, все затраты на анализ и извлечение уроков могут оказаться напрасными.

PRINCE2

НАСА – не единственная государственная организация, которая внесла вклад в развитие проектного управления. Британское Правительство давно оценило эффективность проектного управления, и в 1989 году была создана британская методология PRINCE2. Название произошло от акронима «PRojects IN Controlled Environments version 2», что переводится как «Проекты в контролируемой среде версия 2». В отличие от гибких методов, PRINCE2 не использует итеративный подход к проекту. Если сравнивать PRINCE2 другими продуктами, то его можно сравнить с гибридом классического подхода к проектному управлению и концентрации на качестве из 6 сигм.

Методология PRINCE2 в отличие от, например, свода знаний PMBOK не содержит:

Специализированных аспектов управления проектом, например, отраслевых;
Конкретных практик и инструментов управления проектами, таких как диаграмма Гантта, WBS и т.п.

PRINCE2 концентрируется на управленческих сторонах проекта, выраженных в 7 принципах, 7 процессах и 7 темах проекта.

7 принципов определяют общие правила управления проектами по PRINCE2, определяют базу методологии;
7 процессов определяют шаги продвижения по проектному циклу;
7 тем – аспекты, по которым проводится контроль для достижения успеха проекта.

Кроме того, PRINCE2 рекомендует адаптировать методологию под каждую конкретную организацию.

В начале проекта PRINCE2 предлагает нам определить 3 основных аспекта проекта:

Бизнес-аспект (Принесёт ли этот проект выгоду?)
Потребительский аспект (Какой нужен продукт, что мы будем делать?)
Ресурсный аспект (Достаточно ли у нас всего, чтобы достичь цели?)

В PRINCE2 более чётко определённая структура команды проекта, чем у большинства подходов к проектному управлению. Это связано с тем, что PRINCE2 ориентирован на масштабные государственные проекты и крупные организации.

Согласно PRINCE2 у каждого члена команды есть своя чёткая роль в каждом из 7 процессов:

Начало проекта (Starting up a project):В ходе данного процесса назначается менеджер проекта и определяются общие требования к характеристикам продукта. Менеджер проекта, чья основная задача – внимание к деталям, отчитывается перед Управляющим комитетом проекта, который отвечает за общее руководство проектом. Именно Управляющий комитет следит за тем, чтобы проект не сбился с курса, и он же полностью отвечает за успех проекта.
Инициация проекта (Initiation a project):В ходе данного процесса менеджер проекта составляет «Документацию по инициации проекта», в которой содержится план проекта по стадиям. Стадии могут длиться разное количество времени, но, как и в классическом подходе, они следуют строго друг за другом.
Руководство проектом (Directing a project): Данный процесс предоставляет возможность Управляющему комитету нести общую ответственность за успех проекта, не погружаясь в детали, которые находятся в границах полномочий менеджера проекта.
Контроль стадии (Controlling a stage):При реализации проекта, даже в идеальных условиях, будут вноситься определённые изменения. Процесс «Контроль стадии» реализует один из принципов PRINCE2 – принцип управления по исключениям. В обязанности менеджера проекта входит отслеживать в ходе выполнения стадии отклонения от плановых параметров проекта по срокам, содержанию, бюджету и др. Если эти отклонения превышают данные руководителю проекта Управляющим комитетом полномочия (в терминологии PRINCE2 – допуски), менеджер проекта обязан проинформировать Управляющий комитет и предложить пути выхода из ситуации.
Управление созданием продукта (Managing Product Delivery):Процесс управления созданием продукта представляет собой взаимодействие менеджера проекта и менеджера команды по созданию одного из продуктов проекта. В обязанности менеджера проекта в данном процессе входит делегирование полномочий по созданию продукта менеджеру команды и приемка созданного продукта.
Управление границами стадии (Managing a stage boundary): В ходе данного процесса менеджер проекта предоставляет Управляющему комитету всю необходимую информацию для оценки результатов пройденной стадии и принятия решения о переходе на следующую стадию.
Завершение проекта (Closing a project):Одно из отличий PRINCE2 в том, что процесс завершения проекта не выделяется в отдельный этап или стадию, как в классическом подходе, а выполняется в рамках финальной стадии создания продукта. Цель процесса – подтвердить, что продукт проекта принят, или проект больше не может принести ничего полезного.

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

Сильные стороны PRINCE2

Адаптируемость к особенностям организации;
Наличие чёткого описания ролей и распределения ответственности;
Акцент на продуктах проекта;
Определённые уровни управления;
Фокус на экономической целесообразности;
Последовательность проектной работы;
Акцент на фиксации опыта и постоянном совершенствовании.

Слабые стороны PRINCE2

Отсутствие отраслевых практик;
Отсутствие конкретных инструментов для работы в проекте.

Лучшая система управления проектами … для Вас!

Управление проектами – это наука, но наука не самая точная. В данной области нет незыблемых основ и универсальных решений. Если вам удастся найти метод, идеально подходящий вашему проекту – считайте, что вам крупно повезло, ведь большинству менее удачливых руководителей приходится прикладывать усилия для создания и настройки собственных систем управления проектами. Эти системы могут быть составлены из элементов существующих систем или даже созданы совершенно с нуля, как в случае с миссией «Аполлон». Главное используйте что-нибудь, что даст вам хоть какую-то структуру и позволит не забыть о том, что главное для вашего проекта.

Как получить международный сертификат по Agile

Для тех, кто хочет получить систематизированное понимание Agile, разобраться с преимуществами и недостатками гибкого подхода к проектам и продуктам, найти области наилучшего применения Agile и получить международный сертификат ICAgile Certified Professional — наш тренинг «ICAgile Certified Professional»

Смотрите также:

Источник: http://zapier.com/learn/ultimate-guide-to-project-management/project-management-systems/

Проектный менеджмент в IT - как это?

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

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

Что такое проектный менеджмент

Многие компании только сейчас переходят от классической (отработанная, часто бюрократическая схема) к проектной (каждая задача отдельно, делегирование ответственности) модели управления. Общий менеджмент для предпринимателя сводился к тому, что есть руководитель и исполнитель задачи. Дисциплина взаимодействия зависела от того, как прописано в шаблоне. Шаблон же был вбит в разумы всех одинаково лет этак 20-30 назад. Только этот шаблон уже не применить к новым условиями мирового рынка.

Исторически все началось с того, что в период перестройки 90-х годов сама логика ведения бизнеса была нарушена настолько, что попытки построить новую рабочую концепцию управления в миллениум создали термин «компания-однодневка». Концепции таких компаний проверялись на прочность и только одна из 10 компаний существовала больше полугода в 2000-х. Параллельно оставались многолетние предприятия, кардинально меняясь каждые лет 5 чтобы выжить в период перемен.В 2010-х информационный взрыв интернета сделал доступной всю разрозненную базу наработок европейского и американского бизнеса. Из тонн полезной и мусорной информации вроде «что такое управление проектами и современный менеджмент», «как распределять обязанности, правильно предугадывать и сокращать риски» предприниматели до сих пор выбирают крупицы знаний, применимых именно в их компаниях.

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

В IT project management (PM) — это дисциплина, что объединяет процедуры, принципы и политику ведения бизнеса. Она руководит проектом от разработки концепции до завершения проекта.

Общий (функциональный) и проектный менеджмент отличается тем, что:

функциональный стабилен. Цель: поддержать и преумножить. Есть отработанный шаблон, он работает постоянно.
проектный изменчив. Цель: результат любой ценой. Есть deadline.

Причиной перехода от общего менеджмента к PM чаще других становится надежность — вместо относительной абстрактной перспективы к предсказуемым результатам.

Международная Ассоциация Управления Проектами (IPMA) провела исследование, по результатам которого новый подход сэкономит вам около 20-30% времени и 15-20% ресурсов.

Управление IT проектами vs другие сферы бизнеса

Чем отличаются Информационные Технологии от других отраслей? Судя по ИТ-форумам, зависимостью программистов от гаджетов, дорогого сыра и возможности поехать на Бали. Виртуальностью всей работы и ее результатов, невозможностью использования программы без электричества в городе. Важностью для будущих поколений всех научных достижений, что возможны только благодаря компьютерным инновациям.

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

Управление ИТ-проектами включает в себя курирующие задачи по установке оборудования и модернизации сети, разработке программного обеспечения, созданию виртуальной среды и облачным вычислениям, системам управления данными и бизнес-аналитике, внедрение других ИТ-услуг.

В IT проектный менеджмент может идти по трем жизненным циклам проекта:

Прогнозируемый, он же waterfall. Традиционный подход, даже в 2010-х применяется на порядок чаще других. Поэтапный линейный алгоритм.
Итерационный. Современный подход, в котором расширение функционала разрабатываемого программного обеспечения с каждым новым выпуском в рамках проекта.
Адаптивный. Agile, Scrum и другие методы. Цели компании и стратегия развития может меняться независимо от первоначального плана.

Основы управления проектами и необходимые компетенции

Составлять собственную систему или применять существующую методику к руководству проектами — решать вам.

Для начала опишите свой проект по 10 функциям управления проектами:

Интеграция структуры проекта. Ключевая проблема, которую решает проект. Его результат и этапы (сгруппируйте их по смыслу). Разделяй, объединяй и властвуй.
Масштаб и объем работ. Количество планируемых задач, потоков и приоритеты.
Время. Сроки и хронология зависимых задач, ключевые этапы.
Стоимость. Себестоимость проекта (ресурсы и человеко-часы).
Качество. Критерии и оценка.
Закупки. Ресурсы, логистика.
HR. Люди. Навыки, потенциал и продуктивность.
Коммуникация. Отчет руководству, взаимодействие между персоналом.
Риски и потери. Предусмотри и предотврати.
Заинтересованные стороны. Инвесторы, акционеры, директора и клиенты.

Вот как управлять проектами в IT правильно: обозначьте функции, составьте схемы и таблицы всего предприятия и каждого проекта, выберите методику опираясь на свои приоритеты. И пользуйтесь сервисом по управлению проектами, вроде Worksection, где все это можно будет контролировать, соблюдать и совершенствовать.

Методологии управления IT проектами

Главный выбор предпринимателя при разработке программ и приложений — это подходящая методология управления. Их действительно много, на 2017-й год существуют:

Традиционные методики:

PMI / PMBOK «Метод». Инициирование, планирование, исполнение, контроль и закрытие. Инструкция, не метод по сути.

Гибкая методология:

Методики по управлению изменениями:

Процессно-ориентированные методики:

Lean.
Six Sigma.
Lean Six Sigma.
Процессно-ориентированная PM.

Другие индивидуальные методики и гибридные подходы:

Все названные методы управления проектами мы детально опишем в последующих статьях.

Процесс управления проектами в IT

Разрабатывать и внедрять PM в компании стоит постепенно, проверяя на практике каждый этап и взаимодействие.

За один день перейти на новые стандарты — нереально. Даже чтобы внедрить новый органайзер нужно: обучить команду пользоваться, перенести дела и задачи в такс-менеджер, назначить ответственных и дедлайны, настроить баг-трекеры. Обычно коллективу тяжело привыкнуть к изменениям, да и интеграция баз данных занимает время. Хотя в Worksection уже давно есть функционал для переноса данных из других сервисов, а гайд для новичков и сама система настолько интуитивно понятны, что это отмечают наши постоянные клиенты в отзывах.

Все процессы управления проектами также происходят постепенно и проходят 5 этапов:

Разработка концепции, инициирование.
Определение и планирование.
Запуск работы и воплощение задуманного.
Контроль и наблюдение.
Закрытие проекта.

Организация управления IT-проектом

Здраво налаженный процесс управления распределяет не только функции, методы и алгоритмы, но и ответственность за результат. Существуют роли в каждом проекте, независимо от его специфики и конечного продукта.

Самое грубое деление классической модели ролей:

Владельцы.
Исполнители.
Потребители.

В коммерческих компаниях выделяют такое понятие как заинтересованная сторона. Все, кто влияет на результат и прибыль. Это стейкхолдеры (stakeholders).

Внутренние:

Учредители.
Инвесторы.
Персонал.

Внешние:

Поставщики.
Посредники.
Потребитель (клиенты).

Для организации управления проектом в ИТ такое разделение слишком топорно, здесь нужна другая градация полномочий.

Все участники проекта, причастные к его созданию и потреблению, разделяются на:

Заказчик. Главный. Принимает все ключевые решения.
Собственник. Владелец всех прав собственности на продукт проекта. Часто — заказчик.
Инициатор. Его идея становится проектом. Любой участник проекта может им быть. Права у заказчика.
Родительская (головная, материнская, постоянная) организация. Организация, в которой возник и будет проект.
Спонсор. Предоставляет финансирование. Обеспечивает материальные ресурсы.
Инвестор. Вкладывает финансирование ради личной прибыли от реализации проекта.
Управляющий (менеджер проекта). Лично ответственный за проект перед заказчиком. Имеет право принимать решения сам.
Команда управления. Руководители среднего звена.
Команда. Исполнители. Создают продукт.
Контрактор, Субконтрактор, Подрядчик. Исполнитель по контракту.
Клиент. Потребитель продукта.

Инструменты для управления IT проектами

В Америке сервисы для ведения бизнеса существуют с 1987 года, у нас же заветная 1С появилась лишь в 1991 году. Развитие технологий от автоматизированного бухгалтерского учета и CRM для call-центров до полноценной виртуальной среды централизованного контроля и взаимодействия в компании было долгим, но плодотворным.

На 2017 год инструменты управления проектами стали распространенным явлением. Развился очень разнообразный рынок сервисов, что отличаются отраслевым софтом, функциями и наличием интеграции с другими программами. Теперь они могут быть с расширениями и мобильными версиями.

Самые популярные конкуренты среди сервисов в странах СНГ Bitrix24, Trello, Asana, Basecamp и Worksection.

Изюминка разных технологий в том, что в них можно найти:

Диаграмму Ганта для определения дедлайнов и связанных временем задач, как реализовано в Worksection.
PERT диаграмму для оценки и анализа алгоритмов и способов реализации проекта.
Автоматические отчеты, канбан-доски, встроенные файловые системы и многое другое.

Отдельно рекомендуем для комфортного управления ИТ-проектом использовать структурную декомпозицию работ в виде блок-схем.

Вердикт

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

Только практика покажет, насколько удачной была ваша стратегия. Напомним, что проблемы есть всегда и это естественно. Разделить их можно на внешние и внутренние.

Внешние — форс-мажоры.

Принятый невыгодный закон в стране, стихийное бедствие или закрытие границ со страной-поставщиком сырья.

Внутренние — поломки внутри компании, которые на уровне управления сводятся к трем выводам:

Никто не знает, чего хочет, пока не попробует это. Даже самое точное ТЗ не отразит все ожидания. Даже лучший продукт найдет недовольного пользователя.
Попробовав, мы хотим изменить. Многие идеи возникают только в процессе личного опыта и экспериментов. Помните: если мишень движется, стоит сдвигать прицел.
Даже самому большому проекту будет брошен вызов конкурентом. Чем крупнее проект, тем легче ему провалиться. Сегментируйте, дробите, детализируйте.

Короткие итерации с фиксированным дедлайном легче контролировать, выполнить и исправить.

Управление проектами

Направление подготовки: 38.03.02 Менеджмент Квалификация выпускника: бакалавр

Бакалаврская программа «Управление проектами» имеет своей целью подготовить новое поколение высококвалифицированных менеджеров, отвечающих динамично изменяющимся требованиям на современном рынке труда и международному уровню профессионального образования; управленцев для практической деятельности в сфере менеджмента, владеющих современными методиками эффективного управления организациями различных организационно-правовых форм, подразделениями, группами сотрудников, проектами и сетями, а также систематизированными представлениями, знаниями, умениями и навыками в области менеджмента организаций.

Объекты профессиональной деятельности выпускника

Объектами профессиональной деятельности бакалавров являются: департаменты управления проектами проектно-ориентированных организаций и предприятий любых форм собственности, сфер и отраслей деятельности; организации, специализирующиеся на профессиональном управлении проектами (управляющие компании), консалтинге и аудите; инвестиционно-строительные компании и организации, занимающиеся развитием объектов недвижимости, экспертно-аналитические отделы, службы управления проектами, а также отделы организации конкурсов и тендеров государственных и муниципальных органов управления, предпринимательская деятельность по созданию и развитию малого бизнеса.

Получив квалификацию бакалавра по направлению «Менеджмент», профиль «Управление проектами», Вы будете готовы к следующим видам профессиональной деятельности:

а) в организационно-управленческой деятельности:

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

б) в информационно-аналитической деятельности:

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

в) в предпринимательской деятельности:

разработка бизнес-планов и обоснование бизнес-проектов создания нового бизнеса;
организация управления проектами предпринимательской деятельности.

Перечень дисциплин профильной направленности:

Управление проектами
Антикризисное управление
Инновационный менеджмент
Логистика
Исследование систем управления
Управленческие решения
Управление качеством
Управление продажами
Организационное поведение
Поведение потребителей
Управление персоналом
Коммуникационный менеджмент
Налоги и налогообложение
Организационная культура
Документирование управленческой деятельности

Менеджмент управления проектами: основы проектного менеджмента

С течением развития менеджмента управления проектами, было разработано много инструментов и методик в помощь руководителям проектов. Так, например, для контроля времени используют календарные графики работ, а чтобы управлять деньгами эффективнее пользуются методами формирования финансового плана проекта. Для управления материальными и человеческими ресурсами используется, например, диаграммы загрузки ресурсов или матрица ответственности. Нельзя терять бдительность при контроле результатов проекта, ведь зачастую задания часто трудно и формулировать, и контролировать. Поэтому тут необходимо прибегнуть к методам управления качеством работ.

Чем характеризуется проект?

Во-первых, направленностью на достижение цели.

Во-вторых, проект состоит из взаимосвязанных действий.

В-третьих, проект всегда уникален.

В-четвертых, проект имеет ряд ограничений, например, по времени, средствам, ресурсам и т.п.

А под управлением проектом мы зачастую подразумеваем, совокупность действий, которые имеют четкую направленность в сторону качественной реализации проекта, учитывая при этом ограниченность в денежных средствах, во времени, в ресурсах.

Что такое менеджмент управления проектами? Чем он отличается от традиционного менеджмента?

Сравним ряд признаков, которые характерны традиционному и проектному менеджменту сегодня.

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

На сегодняшний день многие организации и компании привыкли работать с традиционным менеджментом, в то время как при таком менеджменте очень трудно набрать качественную проектную команду из сотрудников, работающих изо дня в день в традиционной обстановке. И тогда выходом становится привлечение внешних участников и руководителей проекта.

Любой менеджмент будет неэффективным без хорошей системы управления проектами. Например, CRM-система «Простой бизнес», которая имеет и полностью бесплатную версию, поможет организовать управление не только проектной деятельностью, но и всей организацией. Чтобы попробовать программу в действии, зарегистрируйтесь, пожалуйста, в бесплатной версии.

Попробовать бесплатно

Зачем учиться управлению проектами — Промо на vc.ru

Студенты, преподаватель и эксперт делятся мыслями о специализации project-менеджера.

Материал подготовлен при поддержке Skillbox

В серии публикаций #skillbox студенты образовательной онлайн-платформы рассказывают о том, что подтолкнуло их к освоению новой специальности, преподаватели защищают методики, а эксперты объясняют, зачем такие специалисты вообще нужны.

Алексей Пименов — генеральный директор ScrumTrek

Кому нужны специалисты по управлению проектами

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

Project-менеджер — тот специалист, который направляет все свои ресурсы и знания на то, чтобы проект достиг финальной реализации. Ему напрямую никто не подчиняется, но от него зависит конечный результат.

Почему вообще возник вопрос, что проектами кто-то должен управлять? Любая классическая организация имеет иерархическую структуру с разными департаментами, а любой проект проходит через все эти подразделения. Для его выполнения нужен специалист, который сможет скоординировать действия всех отдельных направлений.

Главные знания таких специалистов лежат в области менеджмента. Я бы разделил навыки, которыми они должны обладать, на hard skills и soft skills.

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

Project-менеджер — это бешеный веник, который постоянно мечется между большим количеством функциональных подразделений и пытается сделать так, чтобы все со всеми договорились. Он умеет пробивать головой стены, организовать себя и других сотрудников.

Руководитель проекта не привязан к специфике бизнеса, в котором работает. Сама по себе процедура управления проектами — универсальна и оторвана от той или иной сферы. Но если говорить про digital-направление, то важно, чтобы специалист понимал программистов и мог с ними общаться, что называется, на одном языке.

Я не проводил анализ рынка, поэтому не могу сказать, насколько ощущается спрос на таких специалистов. Но однозначно, что цифровизация проникла во все сферы — сейчас не существует компаний, которые работают без нее. Поэтому можно сказать, что project-менеджеры в digital-отрасли нужны, а потребность в них постоянно растет. Также есть запрос на специалистов, которые сами по себе обладают вышеперечисленными навыками и умеют работать со scrum и kanban.

Дмитрий, 43 года — студент, который захотел сменить род деятельности

Зачем записался на курс

Я всю жизнь занимаюсь управлением проектами, но не в ИТ, а торговле, производстве и других отраслях. Захотелось принципиально сменить профессиональное направление, можно сказать — судьбу, и попробовать свои силы в новой области. А для этого надо было закрыть некоторые пробелы. Мне нужны были вводные данные о digital-отрасли, чтобы ориентироваться в ситуации и изучать то, что действительно пригодится на деле.

Я не рассматривал вариант высшего образования в сфере управления проектами, если этому вообще учат в вузах. В моем случае важную роль играл фактор времени, а полноценная учеба — это долго и дорого.

ИТ — такая отрасль, в которой изменения происходят быстро, и никакое базовое образование за ними не успевает. Меня интересовал курс от практиков, а не теоретиков.

Конечно, можно было и самостоятельно изучить эту тему, но не понимая digital-отрасли в целом, можно потратить время не на то, что действительно нужно.

Мнение о Skillbox

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

Материал в курсе подается интересно, последовательно и системно, студентам предлагаются соответствующие практические задания.

Екатерина Мамонтова — преподаватель курса, исполнительный директор «Сибирикс»

Что нужно знать об управлении проектами

Управление проектами — моя сфера с 2010 года. Я прошла путь через все стадии развития, начиная с работы тестировщиком. В этой специализации можно «прокачиваться» бесконечно и во все стороны.

Любой специалист, который идёт в управление проектами, будет прокачиваться в технической сфере. Нельзя управлять разработчиками и общаться с ними на разных языках.

Коммуникация с людьми и умение преодолевать сложности — важное направление работы. Проджект-менеджеры постоянно оказываются в стрессовых ситуациях, получают негатив и от клиентов, и от команды. Важно эффективно работать и не выгореть.

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

Менеджеру не стоит рассчитывать, что ему будут раскладывать всё по полочкам. Специалисту предстоит полагаться на себя.

Как устроен курс по управлению проектами

У нас читают курс только те специалисты, задачи которых основаны на реальном опыте. Есть и теоретическая база, но она тоже соотносится с ситуациями из практики.

Например, если мы изучаем Scrum, то мы не только рассматриваем мировой опыт использования, но и рассказываем, как внедряли его у себя в компании и с чем столкнулись по ходу.

Мы обучаем дистанционно, работа ведется с презентациями. Необходимо доносить информацию максимально ясно: нужно понять, в каком порядке студентам будет проще изучать материал.

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

Например, отработка возражений и провокаций в сервисе «Провокатор». В нем представлены ролики, которые провоцируют пользователей. Домашним заданием студентов было записать видео на тему, как они отработали возражения.

По окончанию курса предусмотрен необязательный дипломный проект. Некоторые учащиеся предпочитают просто получить сертификат с отметкой о завершении программы.

Мы рады, когда студенты идут на диплом, так как для них это вызов.

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

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

Игорь, 26 лет — студент, который решил систематизировать знания

Зачем записался на курс

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

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

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

Мнение о Skillbox

Главная ценность курса — это системный подход к получению знаний: подробно расписано, как, где и какие навыки и инструменты применять.

Кроме того, «Сибирикс» делился с нами внутренними документами и сведениями из своей рабочей практики. Это важно. Например, у нас была тема «Агрегация требований». В моей компании этот подход почти не применялся, а после прохождения курса удалось его внедрить.

Знания не уникальные, но организаторы и авторы правильно их собрали и подали — от базовых понятий к конкретике, применяемой на практике.

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

Единственное, что расстроило — отсутствие активности в Facebook-группе, посвященной курсу. Ее создали сотрудники «Сибирикса», чтобы публиковать в ней сопутствующие материалы и отвечать на вопросы студентов.

Я пытался раскачать группу и предложил всем участникам назвать три самые эффективные книги по менеджменту, которые пригодились в работе. Но ответили только я и три сотрудника «Сибирикса». Преподаватели оказались активнее и заинтересованнее студентов.

Курс «Управление проектами» выстроен на опыте основателя «Сибирикс» Владимира Завертайлова и ведущих менеджеров компании. Более 85 видеоуроков направлены на развитие управленческих навыков руководителей digital-проектов по методологиям agile, scrum, lean, kanban.

Образовательный курс подойдет директорам, руководителям, продюсерам, менеджерам по проекту или продукту в сфере digital. Также знания пригодятся заказчикам цифровых решений.

32 часа теории и 16 практических заданий.
Живая обратная связь с преподавателями.
Неограниченный доступ к материалам курса.
Стажировка в компаниях-партнёрах.
Дипломный проект от реального заказчика.
Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы.

Управление проектами

Как известно, каждый проект – это уникальное мероприятие, не поддающееся стандартизации. Однако процессы управления проектами поддаются стандартизации и документы, которые формализуют эти процессы, получили название методологий управления проектами. Рассмотрим ниже наиболее часто применяемые методологии.

Традиционная (Каскадная) методология управления проектами

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

• Определение требований

• Проектирование

• Реализация (строительство, производство)

• Внедрение

• Тестирование и отладка

• Установка

• Эксплуатация и сопровождение

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

Однако с другой стороны, каскадная модель управления проектом требует инвестиций в планирование. Обычно первые две фазы занимают от 20 до 40% от всего времени выполнения проекта по данной методологии. Вследствие структурированного подхода, внесение изменений в содержание работ происходит медленно, что делает методологию не гибкой и не подходящей в случаях, если клиент не уверен, какой результат он хочет получить.

Методология управления проектами PRINCE2

PRINCE2 (Projects in Controlled Environments) – это процессно-ориентированная проектная методология, которая фокусируется на процессах верхнего уровня (управление, организация, контроль). Методология PRINCE2 базируется на семи принципах, семи темах и семи процессах. Принципы являются центральным элементом методологии: если хотя бы один из них не выполняется, то нельзя говорить о том, что проект выполняется в рамках PRINCE2.

Принципы методологии PRINCE2:

• Постоянная оценка экономической необходимости — остается ли неизменной экономическая выгода от проекта на протяжении всего жизненного цикла проекта.

• Обучение на опыте – команда проекта должна постоянно искать и изучать опыт предыдущих проектов.

• Определение ролевой модели – команда проекта должна иметь ясную организационную структуру и вовлекать подходящих людей для решения нужных задач.

• Управление по этапам – необходимо, чтобы проекты были спланированы, а также подвергались мониторингу и контролю на каждом этапе выполнения.

• Управление по отклонениям – следует четко обозначить допустимые границы отклонений в проекте, чтобы установить границы ответственности.

• Фокус на продуктах – необходимо концентрироваться на определении и достижении качества продуктов (результатах проекта).

• Адаптация к проектной среде – следует адаптировать процессы и инструменты управления проектом к требованиям проектной среды, а также к масштабу работ, их сложности, важности, квалификационным требованиям и степени риска.

Аспекты представляют собой направления проектного управления, на которые следует обращать внимание в течение длительности всего проекта.

Аспекты методологии управления проектами PRINCE2:

• Обоснование проекта: какую ценность проект принесёт организации?

• Организация: каким образом необходимо распределить роли и ответственность между членами проектной команды для того, чтобы эффективно управлять проектом

• Качество: какие имеются требования и критерии к качеству и каким образом можно их обеспечить

• Планы: шаги, требуемые для разработки плана, и инструменты PRINCE2, необходимые к использованию

• Риски: каким образом менеджмент проекта будет разрешать проблему наличия неопределённостей в плане проекта и во внешней среде

• Изменение: как руководство проекта будет оценивать влияние непредвиденных задач и изменений, и реагировать на них

• Прогресс: реализуемость проекта, выполнение планов и дальнейшее развитие проекта

Наконец, семь процессов разбивают жизненный цикл проекта на различные фазы, для каждой из которой имеются свои рекомендуемые к принятию действия, получаемые продукты и зоны ответственности.

PRINCE2 подразумевает следующие процессы управления проектом:

• запуск проекта

• руководство проектом

• инициация проекта

• контроль этапов

• управление созданием продукта

• управление границами этапов

• закрытие проекта

PRINCE2 позволяет стандартизировать процедуры управления проектами, улучшить координацию деятельности, а также помогает понять, каким образом следует планировать проект и осуществлять мониторинг его выполнения, что следует делать, если план проекта не выполняется. Однако методология PRINCE2 не является лучшим выбором для проектов небольшого масштаба или для проектов с большей степенью вероятности изменений объема работ и требований к ним.

Гибкая методология управления проектом (Agile Project Management)

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

В соответствии с данной методологией управления проектами, ответственность за результат делится между тремя ролями:

• Владелец продукта – определяет проектные цели, разрабатывает оптимальный график при заданных проектных параметрах, адаптирует процесс выполнения проекта к изменившимся требованиям и устанавливает приоритеты в характеристиках продукта

• Scrum мастер – устанавливает приоритеты в выполнении задач командой проекта и устраняет возникающие затруднения, препятствующие этому

• Члены команды – выполняют большинство поставленных задач, осуществляют ежедневный менеджмент, создают отчеты о ходе выполнения проекта, контролируют качество продукта

Методология Agile является гибкой и позволяет легко изменить параметры проекта, что является значимым для таких сервисно-ориентированных проектов, как разработка программного обеспечения или графический дизайн. Но это методология не подходит для проектов со строго заданными параметрами и требованиями.

Методология быстрой разработки приложений (Rapid Application Development — RAD)

Быстрая разработка приложений (RAD) – это проектная методология, чаще всего используемая в проектах по разработке ПО, основной целью которых является быстрое и качественное создание приложения. Данная методология управления проектами выделяет 4 стадии проекта:

• Планирование

• Пользовательское проектирование

• Быстрое конструирование

• Переключение

Методология быстрой разработки приложений, с одной стороны, помогает улучшить показатели результативности проекта и повысить качество риск-менеджмента. Но с другой стороны, данная метрология не подходит для масштабных IT проектов, может привести к низкому качеству кода и требует постоянного вовлечение клиента в процесс исполнения всего проекта.

Управление проектами: игнорировать или внедрять?

История и современность

Управление проектами (проектный менеджмент, Project Management) как управленческая методология впервые прменено в аэрокосмической отрасли США в 60-х годах прошлого века и использовалось при реализации военных мегапроектов. Благодаря своим неоспоримым преимуществам эта методология стала стремительно распространятся на все отрасли экономики.

За последние тридцать лет Управление проектами сформировалось как новая культура управленческой деятельности и стало своеобразным культурным мостом в цивилизованном бизнесе и деловом сотрудничестве стран разных континентов с разной историей развития, традициями, экономикой и культурой.

Сейчас уже трудно назвать хотя бы один проект мирового значения, который осуществлялся бы вне рамок идеологии и методологии Управления проектами. Трудно также назвать хотя бы одну известную в мире компанию, не использующую в своей практике методы и средства Управления проектами.

Причина успеха

Управление проектами продолжает овладевать умами людей. Все больше организаций осознают, что этот раздел менеджмента является основополагающим для реализации стратегии бизнеса.

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

Аргументы и факты «за»

· В сентябре 2012 г. введен в действие международный стандарт ISO -21500 – Руководство по управлению проектами, который был построен на базе стандарта PMI ® PMBOK ® .

· В настоящее время ISO работает над стандартами «Управление программами и портфелями» и «Управление рисками».

· 13 стран (США, Великобритания, Германия, Китай, Япония, Корея, Россия, Швейцария, Индия и др.) имеют национальные стандарты по управлению проектами.

· Компании, использующие принципы управление проектами, портфелями и программами, подвергаются риску финансовых потерь в 14 раз меньше.

· Применение инструментария Управления проектами позволяет обычно сэкономить порядка 20-30 процентов времени и около 15-20 процентов средств, затрачиваемых на осуществление проектов и программ.

· Президент Сбербанка РФ Герман Греф: дополнительная минута, потраченная на начальной стадии подготовки проекта, экономит 10 минут при его реализации, каждый рубль, вложенный в проектирование, сохранит 5-8 рублей.

· Игнорирование проектного управления порождает целый комплекс проблем в компании: проекты выполняются нескоординировано; отсутствует общая терминология (сотрудники общаются на разных «языках»); нет единого понимания принципов управления проектами; нет подробного описания процессов управления проектом; нет четкого разграничения зон ответственности участников проектной деятельности.

· 67% организаций, переживших финансовый кризис 2007-2009 гг., имели офис управления проектами.

· К концу 2020 года на программы и проекты будет расходоваться около 30% мирового бюджета или $ 45 трлн.

Профессия менеджер проектов

Менеджер проекта (руководитель проекта или Project manager) — это специалист, отвечающий за успешное выполнение проекта:

· в указанные заказчиком сроки;

· с необходимым качеством;

· при фиксированном бюджете и ограниченных человеческих ресурсах;

· при необходимых требованиях со стороны заказчика.

В итоге, главный результат работы данного управленца — это удовлетворенность заказчика.

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

Профессия руководителя проектов высоко востребована во многих отраслях:

· информационные технологии (программирование, автоматизация, создание сайтов);

· строительство;

· финансы;

· страхование

· фармацевтика;

· организация мероприятий;

· спорт.

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

Обязанности менеджера проектов

Должностные обязанности менеджера проектов сильно зависит от сферы деятельности компании, но при этом имеют общий набор задач:

· ведение проектов (контроль качества, сроков, бюджетов и рисков);

· коммуникации с заказчиком (согласование планов, сроков, требований, бюджетов);

· руководство проектной командой;

· ведение проектной и технической документации:

o календарные планы;

o технические задания;

o функциональные требования;

o финансовые отчеты;

o и так далее.

· участие в процессе продажи и заключении договоров (в том числе участие в тендерах);

· постпроектное ведение заказчиков и дополнительные продажи.

Иногда функции руководителя проектов включают задачи менеджера по продажам: активный поиск клиентов, подготовку коммерческих предложений, переговоры, заключение договоров и т.п.

Требования к менеджеру проектов

Требования к менеджерам проектов зависят от сферы деятельности компании. На стройке одно нужно, в ИТ — другое, в банковской сфере — третье. Средний набор требований таков:

· Высшее образование (желательно по профилю работы компании);

· Опыт работы от 1 года (серьезные должности требуют более 3-х лет);

· Хорошее знание сферы деятельности и ее рынка;

· Умение составлять документацию (техническую и проектную);

· Опыт руководства (в рамках проектных команд);

· Отличные коммуникативные навыки.

Иногда среди требований к руководителям проектов можно встретить:

· знание MS Project;

· разговорный и письменный английский язык;

· понимание принципов управления проектами (например, PMI)

· готовность к командировкам.

Что такое проект? Какое отношение проекты имеют к программам и портфелям?

Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов.

Программа – это группа связанных проектов и отдельных работ, соответствующих стратегическим целям или целям более низкого уровня.

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

Как управлять проектом?

Управление проектами – это приложение знаний, навыков, инструментов и методов к операциям проекта для удовлетворения требований, предъявляемых к проекту.

Проекты состоят из процессов. Процессы – это серия действий, приводящая к результату. Это любая деятельность, в которой используются ресурсы для преобразования входов в выходы.

Все процессы объединены в группы. Их пять: инициация, планирование, исполнение, мониторинг и контроль исполнения, завершение. В каждой группе – от двух и более процессов, а всего процессов – 47.

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

Стандарты управления проектами

Проектная деятельность с 1987 года стандартизирована. Именно в этом году увидел свет первый и до сих пор наиболее востребованный стандарт в этой области – Руководство к своду знаний по управлению проектами ( a Guide to the Project Management Body of Knowledge , PMBOK ® Guide ). Этот стандарт разработал и предложил миру Институт проектного управления США (Project Management Institute, PMI ). Данное Руководство является одновременно национальным стандартом Америки. PMBOK постоянно обновляется с учётом новых веяний, появляющихся и закрепляющихся в Управлении проектами на практике. С января 2013 года действует уже пятая версия стандарта.

Ещё 12 государств мира приняли свои национальные стандарты по проектному управлению. Огромное количество стран использую PMBOK . Спросом пользуются также Стандарты оценки компетенции менеджера проекта Международной Ассоциации Управления Проектами (Швейцария) (International Project Management Association, IPMA) и японский стандарт – Руководство по управлению инновационными проектами и программами предприятий (а Guidebook of Project and Program Management for Enterprise Innovation, P2M).

Золотые правила Управления проектами

1. Правильный старт. При запуске проекта обязательно необходимо установить порядок исполнения проекта и те рамки, в которых проект будет осуществляться.

2. Работа с заинтересованными лицами проекта. Необходимо установить, в чьих интересах выполнение проекта и, в частности, кто его финансирует. Как правило, это не одни и те же люди. Менеджер проекта обречен на неудачу, если он не осознает цели, мотивы и направления деятельности всех вовлеченных в проект сторон.

3. Определение области применения проекта. Надо понять, каким образом область, в которой работает исполнитель, связана с бизнес-целями заказчика и какие основные выгоды получит заказчик при их реализации. Чёткое определение области работ и взятых обязательств позволит контролировать изменения в проекте.

4. План. Важно наряду с полным планом проекта иметь микропланы на текущий этап, поскольку только ближайшее будущее может быть предсказано с определенной степенью точности.

5. Управление рисками. Крайне важно в любом проекте определить основные риски, проанализировать их воздействие и разработать стратегию по их сдерживанию и реагированию на них. Если риски по проекту не отслеживаются, то, как правило, возникает ситуация, когда на первые 90% работ по проекту приходится 10% затрат, а последние 10% работ требуют 90% затрат.

6. Подбор команды. Надо определить оптимальную конфигурацию команды и включить в нее тех, кто «вписывается» в состав или имеет большие потенциальные возможности. При подборе людей необходимо руководствоваться их профессиональными качествами, умением быстро адаптироваться и умением работать в команде.

7. Поддержка командного духа. Никогда не существует отдельного «я» в проекте, всегда есть «мы», как в случае успеха, так и в случае неудачи. Необходимо разъяснять цели проекта и как эти цели связаны с намерениями заказчика. Надо четко представлять, как эти цели будут достигнуты командой проекта. Следует акцентировать внимание на персональной ответственности, но в то же время каждый член команды проекта должен четко знать, что от него ожидают и по каким показателям будет оцениваться выполненная работа. Необходимо создавать рабочую среду, наиболее подходящую для команды, находить время для того, чтобы поблагодарить людей, особенно, если это касается выполнения работы, выходящей за круг их обязанностей.

8. Искренность и уверенность в общении. Нужно договориться о стандартах и принципах общения и твердо придерживаться этих принципов. В общении важна искренность. Желательно свести конфликты к минимуму, но поскольку избежать их полностью вряд ли удастся, нужно быть готовыми к возникновению таких ситуаций и уметь их разрешать.

9. Использование плана качества работ по проекту. В плане качества работ по проекту должны быть описаны процедуры и стандарты, которые будут использованы в проекте и на основе которых будет проводиться аудит качества. Из этого следует, насколько важно утверждение данного документа со стороны заказчика.

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

11. План завершения проекта. Завершение проекта – заключительный этап процесса вносимых изменений. Планировать завершение проекта нужно заранее. Заключительное впечатление о проекте остается в памяти людей. Необходимо подготовить отчет об окончании проекта, в котором должно быть отражено: что было сделано хорошо, что было сделано плохо, что можно было бы сделать лучше. Такая самооценка необходима и тем, кто будет осуществлять будущие проекты, и как инструмент самосовершенствования.

Как освоить технологию Управления проектами?

Компания, которая приняла решение повысить квалификацию сотрудников в сфере проектного управления, должна знать, что существуют уровни проектной зрелости организации.

Первый уровень. Сотрудники, работающие в проектах, обучены методологии УП и могут применять его инструментарий в повседневной деятельности.

Второй уровень. Наряду с обученным персоналом организация внедрила Корпоративную систему управления проектами.

Третий уровень. Имея обученный персонал и внедрив КСУП, организация создала Офис управления проектами.

Безусловно, достичь компании даже первого уровня самостоятельно чрезвычайно сложно. Сделать это помогут профессиональные организации, занимающиеся обучением и консалтингом в сфере управления проектами, например Союз проектных менеджеров Республики Казахстан, который и подготовил этот материал.

Самые распространенные проблемы, возникающие в процессе управления бизнесом и способы их решения

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

Причины возникновения проблем в управлении:

- неправильные критерии оценки возможностей компании и ее работников;

- ошибочные принципы и методы деятельности работников;

- неверно сформулированные цели организации, способы и сроки их достижения;

- умышленные нарушения в финансах, поставках, технике, технологии;

- перемены в государственной политике и экономике;

Классификация управленческих проблем по признакам:

- степень важности и срочности.

- возможность решения проблемы с наименьшими затратами и в оптимальные сроки;

- степень риска, связанного с решением данной проблемы, и возможность возникновения новых проблем на этой основе;

- масштабы последствий, в случаях принятия или непринятия решений, и численность организаций и лиц, которых затрагивают данные проблемы;

Виды проблем рассматриваются по следующим критериям:

Ø стратегические, направленные на формирование базы стратегических данных, их уяснение, изучение, оценку и практическое использование;

Ø тактические, разрешение которых происходит в более короткие сроки, чем стратегические;

Ø долгосрочные, среднесрочные и краткосрочные, текущие;

Ø по уровням руководства — высшего, среднего и низового звеньев управления.

Решение проблем в зависимости от их вида, признаков и критериев

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

Решение тактических проблем — это дело средних звеньев руководства; на основе предписаний «сверху» они планируют решения проблем в среднесрочных планах и выполняют краткосрочные задачи. Низовые звенья управления решают проблемы исходя из устных распоряжений, указаний или письменных приказов.

Текущие проблемы каждодневного характера, так называемая рутинная работа, занимают основное время низовых звеньев управления.

Решения проблем классифицируются по ряду признаков.

1. По степени обязательности решения могут быть директивными; они принимаются высшим руководством и обязательны к исполнению для нижестоящих управленческих структур. Рекомендательные решения разрабатываются совещательными органами. Их исполнение желательно, но не обязательно. Ориентирующие решения принимаются руководством для координации работы нижестоящих управленческих структур, которые действуют автономно.

2. По функциональному назначению выделяют организационные, координирующие, регулирующие, активизирующие и контролирующие ход выполнения решения. Например, предписывающие способ действия и методы решения проблем; распределяющие работу между исполнителями, по проведению контроля, проверок, подготовке нормативных документов и др.

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

Решения классифицируются также на принятые единолично или коллективно, на общие и специальные, на запрограммированные и незапрограммированные, на закрытые и для общего пользования.

Менеджмент управление проектами что это такое

Топ-7 методов управления проектами: Agile, Scrum, Kanban, PRINCE2 и другие

Почему «управление проектами»?

Краткая история проектного управления

Популярные системы управления проектами

Классическое проектное управление

Agile

Scrum

Lean

Kanban

6 сигм (Six Sigma)

PRINCE2

Лучшая система управления проектами … для Вас!

Как получить международный сертификат по Agile

Проектный менеджмент в IT - как это?

Что такое проектный менеджмент

Общий (функциональный) и проектный менеджмент отличается тем, что:

Управление IT проектами vs другие сферы бизнеса

В IT проектный менеджмент может идти по трем жизненным циклам проекта:

Основы управления проектами и необходимые компетенции

Для начала опишите свой проект по 10 функциям управления проектами:

Методологии управления IT проектами

Традиционные методики:

Гибкая методология:

Методики по управлению изменениями:

Процессно-ориентированные методики:

Другие индивидуальные методики и гибридные подходы:

Процесс управления проектами в IT

Все процессы управления проектами также происходят постепенно и проходят 5 этапов:

Организация управления IT-проектом

Самое грубое деление классической модели ролей:

Внутренние:

Внешние:

Все участники проекта, причастные к его созданию и потреблению, разделяются на:

Инструменты для управления IT проектами

Изюминка разных технологий в том, что в них можно найти:

Вердикт

Внешние — форс-мажоры.

Внутренние — поломки внутри компании, которые на уровне управления сводятся к трем выводам:

Управление проектами

Менеджмент управления проектами: основы проектного менеджмента

Зачем учиться управлению проектами — Промо на vc.ru

Алексей Пименов — генеральный директор ScrumTrek

Кому нужны специалисты по управлению проектами

Дмитрий, 43 года — студент, который захотел сменить род деятельности

Зачем записался на курс

Мнение о Skillbox

Екатерина Мамонтова — преподаватель курса, исполнительный директор «Сибирикс»

Что нужно знать об управлении проектами

Как устроен курс по управлению проектами

Игорь, 26 лет — студент, который решил систематизировать знания

Зачем записался на курс

Мнение о Skillbox

Управление проектами

Управление проектами: игнорировать или внедрять?

Смотрите также

Рубрики

Отзывы

Свежие записи