основы, сущность, принципы, функции и процессы
Бизнес как поступательная деятельность до момента окончания фазы зрелости находится одновременно в двух агрегатных состояниях. Первое состояние связано с обычными процедурами производства продукта, непрерывно или регулярно выдаваемого в окружающий мир. Второе состояние – импульсное, уникальное, продвигающее и развивающее. Такое состояние сопровождается особой формой развития – проектами. Каждая организация накапливает опыт и знания реализации уникальных проектных задач. Управление проектами опирается на богатый мировой и собственный опыт этого непростого дела.
Сущностные моменты управления проектами
Проекты преследуют конкретные цели. Вместе с тем, существуют такие задачи, цели которых и сформулированные ранее результаты уточняются по ходу реализации. Уникальность как черта проектного действия – зачастую явление относительное. Не вызывает ни малейшего сомнения временный характер такой деятельности, которая как подлинная задача имеет начало и точно намеченную временную точку своего завершения.
Трудно не согласиться с позицией В.И. Либерзона, президента Московского отделения Института PMI, что сущность управления проектами связана с явлением проекта как временного предприятия, предназначенного для создания уникальных продуктов и услуг. Руководство производится на основе использования знаний, навыков, методов, средств и технологий в проектной сфере. Данный инструментарий уже долгие десятилетия накапливается в национальных и международных стандартах. Институт PMI в PMBOK дает следующее определение понятию «управление проектом».
Управление проектами осуществляется с целью достигнуть или превысить в результате ожидания участников. Следует признать, что вполне логично к явлению управления применять процессную методологию, подразумевающую регламенты как системные аккумуляторы прошлого опыта. Проектное управление находится в непрерывном развитии. Передовой опыт, который нарабатывают менеджеры-пионеры, апробируется, обобщается, переводится в форму стандартов. Затем стандарты проходят стадию адаптации к различным вариантам проектных решений в практической плоскости. И так происходит по спиральному циклу развития.
Сущностными управленческими аспектами являются содержание, ограничения и риски проектов. Управленческую среду определяет ряд опорных явлений, обладающих классификационными признаками. К ним относятся:
- окружение;
- заинтересованные стороны как индивидуализированные позиции окружения;
- типы проектов;
- принципы управления;
- процессы управления проектами;
- функции управления проектами;
- модели управления проектами;
- организационная структура;
- организационная культура;
- ресурсная платформа;
- экономическая эффективность инвестиций;
- комплексное управление проектами.
Комплексное управление проектами в компаниях с большим объемом работы и значительным числом одновременно реализуемых уникальных задач становится возможным с момента внедрения корпоративной системы управления проектами (КСУП). Введение в действие КСУП позволяет систематизировать накопленный опыт в сфере проектных разработок. Принятие решений в сфере project management становится существенно более упорядоченным. Риски и проблемы выявляются значительно раньше, а значит, вовремя минимизируются и выводятся с орбиты регуляционного цикла.
Основные принципы проектного управления
В качестве результата обобщенного опыта и системного явления управление проектами руководствуется определенными принципами. Как основные правила принципы управления проектами вытекают из закономерностей, которые в свое время привели к успеху многочисленные решения. Имея специфические особенности, они также ориентированы и на общеуправленческие принципы. Далее представлен состав основных принципов.
- Принцип дифференцированного подхода. При координации и регулировании обязательно следует учитывать и использовать разнообразные стороны проектной инфраструктуры. К ним относятся ожидания и вклады участников, специализированные стандарты project management и особенности реализации проектов по их типам и т.
- Принцип экономической целесообразности. Данный принцип предполагает опережающий рост отдачи от реализации всего портфеля проектов компании в сравнении с совокупностью бюджетов на их реализацию и расходами на содержание проектного офиса. Все ресурсы, задействованные в реализации, находятся под контролем благодаря описанным в процессах процедурам. Действия вне будущей экономической целесообразности в рамках проектной деятельности не допустимы.
- Принцип гибкости. Предполагается оперативное и гибкое реагирование команды на все вызовы и изменения внутренней и внешней ситуации по отношению к проекту. В отдельных случаях руководство уникальной задачей гибко реагирует и на изменения в компании в целом. При этом гибкость нисколько не исключает достаточное жесткое соблюдение процессуальных процедур проектной деятельности.
- Принцип конкурентоспособности. В условиях ограниченности трудовых и финансовых ресурсов направления реализации задач подлежат ранжированию и отбору на конкурсной основе во внутрикорпоративной конкурентной среде. Выбор проектов производится, исходя из условий важности (соответствия стратегии), проблемности и ресурсообеспеченности.
- Принцип разделения полномочий. Процессная концепция менеджмента, которая применяется при управлении проектами, требует соблюдения принципа принадлежности каждого процесса единственному владельцу. Владелец процесса отвечает за этапы внутрипроцессных работ и достижение итогового результата.
- Принцип открытости. Стандарты project management не являются догмой. Допускается, что текущая проектная практика может не соответствовать предписаниям стандартов. В таком случае предполагается и рекомендуется перепроверить основные положения процедур. В этом заключается открытость стандартов управления проектами для их развития.
- Принцип best practices. Руководство компании обязано поощрять своих менеджеров, команды на применение лучшего отечественного и мирового опыта в сфере управления проектами. Основные аспекты лучших практик подлежат заимствованию из всех доступных источников.
Процессно-функциональная модель управления проектами
Система project management обладает определенной объемностью элементов, представляя своеобразную изометрическую конфигурацию. Мы же, знакомясь с проектным управлением, представим лишь ее двухмерный вариант, включающий процессы и функции управления проектом в их тесной взаимосвязи. Процессы управления проектами детально описаны в PMI. В руководстве PMBOK они консолидированы в пять полноценных групп, которые представляют собой этапы, реализуемые последовательно и параллельно. Группы процессов предложены вашему вниманию далее:
- инициация;
- планирование;
- исполнение;
- мониторинг и контроль;
- закрытие.
График-диаграмма взаимодействия групп процессов в рамках фазы или проекта
На представленном выше графике-диаграмме визуально изображены событийные этапы проектного развертывания. Они же, как процессные группы, обладают определенным уровнем согласования, взаимодействия и длительностью. С данного ракурса проект – это совокупность взаимосвязанных процессов. Основные области project management раскрыты в руководстве PMBOK. При этом признается, что ключевые нюансы по разнообразию способов управления остаются в головах выдающихся практиков.
Это действительно так и вполне естественно. Но и той базы, которую предоставляет институт PMI уже более, чем достаточно, чтобы опереться на предложенную модель процессов и начать применять данную управленческую технологию. Особенности процесса мониторинга и контроля как «фоновой» группы организационной архитектуры являются одной из ценных ремарок руководства.
Место мониторинга и контроля в группах процессов управления проектом
Подчеркивается, что процессы управления проектами не являются фазами жизненного цикла проектной задачи. Более того, они могут повторяться и входить в цикл практически на каждой ее фазе. В этом смысле понятия группы процессов, этапы и фазы не тождественны друг другу. Процессы и этапы могут рассматриваться в качестве синонимов лишь условно.
Матрица процессно-функциональной модели управления проектом
Процессы являются совокупностями взаимосвязанных работ с четко заданными результатами и установленными сроками реализации. В то же время функциональные области представляют составы действий и компетенций, не имеющих конкретной временной привязки. Многие процессные операции вполне могут быть переведены в задачную форму, а области функций определяются лишь управленческой зоной компетенций.
Первые четыре функциональные области основные, потому что они отрабатывают три главных аспекта project management: содержание, ограничения (стоимость и время) и риски. Последние пять областей являются дополнительными. Управление персоналом применяется к ближайшему окружению и команде, а управление поставками касается внешнего окружения. Управление коммуникациями, качеством и интеграцией – отдельные специфические контуры управления.
PM должен понимать, что управление проектной задачей – не только и не столько ситуационное воздействие на команду и других участников. Это состав выверенных мероприятий, которые проект-менеджер и вышестоящие руководители осуществляют, опираясь на формализованный опыт поколений специалистов в проектной области не только компании, но и всего мирового делового сообщества. Управление проектами подразумевает владение руководством специальными инструментами, методами, навыками и носят процессуальный характер. Такой подход обеспечивает надежность получения результата.
ФУНКЦИИ УПРАВЛЕНИЯ ПРОЕКТАМИ — Энциклопедия по экономике
Существуют и другие модели, по-иному классифицирующие функции управления проектом. При этом неизменной составляющей процесса управления проектом остается управление его качеством. [c.8]Все функции управления проектом связаны между собой, и эффективно управлять качеством проекта невозможно, не затрагивая других составляющих управления проектом. Рассмотрим, например, управление персоналом проекта. Для такого управления необходима определенная организационная структура, которая позволит распределить общие задачи проекта по различным исполнителям (в том числе по организациям-соисполнителям) и регулировать их совместную работу. При этом организационная структура проекта накладывается на существующую организационную структуру организации-исполнителя проекта, фактически приводя к матричной структуре управления. При всем разнообразии возможных видов организационных структур проектов, необходимо соблюдение следующих основополагающих принципов [c.10]
Можно назвать восемь основных функций управления проектами [c.24]
В числе функций управления проектом очень важными являются [c.382]
Функции управления Блок 1 Определение целей и функций управления проектов [c.443]
Команда проекта — специфическая организационная структура, возглавляемая руководителем проекта и создаваемая на период осуществления проекта. Задача команды проекта состоит в осуществлении функций управления проектом до эффективного достижения целей проекта. [c.202]
МЕНЕДЖЕР ПРОЕКТА — лицо, выполняющее функции управления проектом, призванное обеспечить эффективное выполнение всех работ по данному проекту. Функции менеджера проекта может выполнять заказчик, подрядная строительная организация (фирма), проектная организация, консалтинговая или инжиниринговая фирма. [c.542]
Экспертная оценка состояния методов и средств по основным функциям управления проектом для трех типов проектов отражена на рис. 5.13. [c.210]
Основные функции управления проектами [c.210]
Руководитель проекта Это главная фигура в процессе проекта. В зависимости от варианта организационной формы осуществлять функции управления проектом может руководитель проекта (в системах широкого управления или ускоренного строительства) или сам заказчик (в варианте основной системы). [c.324]
Традиционная схема взаимодействия участников международного нефтегазового проекта, изображенная на рис. 2.2, сложилась еще в советский период, когда единственным инвестором и заказчиком в экономике было государство. Характерная черта этой схемы состоит в том, что функции управления проектом разорваны между заказчиком и генеральным подрядчиком. Данная схема хорошо работает только в случае, когда целью проекта является лишь строительство, но если в качестве объекта управления берется весь инвестиционный проект — возникают существенные проблемы. Сегодня эта схема используется в международных проектах, но при условии, что в качестве инвесторов не выступает партнер из дальнего зарубежья. К сожалению, инвесторам из развитых зарубежных стран такой подход не импонирует. [c.58]
Основными функциями управления проектами сооружения объектов трубопроводного транспорта являются [c.17]
Функции управления проектами [c.42]
Функции управления проектом осуществляются на всех этапах и фазах управления проектом и включают планирование (гл. 13), контроль проекта (гл. 15), анализ (гл. 12 и 17), принятие решений (гл. 15), составление и сопровождение бюджета проекта (гл. 15), организацию осуществления (гл. 17), мониторинг (гл. 15), оценку (гл. 13), отчетность (гл. 17), экспертизу (гл. 10), проверку и приемку (гл. 16), бухгалтерский учет, администрирование. [c.59]
Отличие подсистем от функций управления проектом заключается в том, что подсистемы ориентированы на предметную область, а функции нацелены на специфические процессы, процедуры и методы. Управление подсистемой включает выполнение практически всех функций. Так, планирование расходов и контроль расходов базируются на одной и той же предметной области — затратах, а планирование расходов и планирование качества базируются на одинаковых процедурах составления планов, сетевом моделировании и пр. [c.60]
Перечислите основные функции управления проектом. [c.63]
В рамках схемы управление — функция управляющей фирмы Заказчик поручает функции по управлению проектом управляющей фирме, специализирующейся исключительно на управлении проектами. Управляющая фирма оставляет за собой самые важные функции управления проектом, разрабатывает организационную структуру управления проектом и реализует управление, при этом не выполняя никаких работ по проекту и передавая их для реализации подрядным организациям. Такая схема может иметь следующую разновидность управляющая фирма передает все работы по проекту генеральному подрядчику, который является ответственным исполнителем всех работ и может привлекать к выполнению отдельных комплексов работ субподрядные организации (рис. 5.2.8). [c.115]
ФУНКЦИИ УПРАВЛЕНИЯ ПРОЕКТАМИ [c.352]
Функциями управления проектами являются [32, 92] планиро- [c.17]
Функциями управления проектами являются [131] планирова- [c.15]
В учебном пособии системно рассмотрен комплекс вопросов, в совокупности составляющих сущность синтетической дисциплины управление проектами (Proje t Management). Освещены все элементы управления проектами знакомство с миром управления проектами разработка проекта функции управления проектами подсистемы управления проектами. Широко испоыльзованы методологические приемы, обеспечивающие эффективное усвоение читателями материалов примеры из практики, упражнения, тесты, анализ ситуаций и др. [c.2]
Функции управления проектом включают планирование, контроль, анализ, принятие решений, составление и сопровожде- [c.43]
Страница не найдена
Согласие на обработку персональных данныхНастоящим в соответствии с Федеральным законом № 152-ФЗ «О персональных данных» от 27.07.2006 года свободно, своей волей и в своем интересе выражаю свое безусловное согласие на обработку моих персональных данных АНО ДПО «ИНСТИТУТ СОВРЕМЕННОГО ОБРАЗОВАНИЯ» (ОГРН 1143600000290, ИНН 3666999768), зарегистрированным в соответствии с законодательством РФ по адресу:
УЛ. КАРЛА МАРКСА, ДОМ 67, 394036 ВОРОНЕЖ ВОРОНЕЖСКАЯ ОБЛАСТЬ, Россия (далее по тексту — Оператор).
Персональные данные — любая информация, относящаяся к определенному или определяемому на основании такой информации физическому лицу.
Настоящее Согласие выдано мною на обработку следующих персональных данных:
— Телефон.
Согласие дано Оператору для совершения следующих действий с моими персональными данными с использованием средств автоматизации и/или без использования таких средств: сбор, систематизация, накопление, хранение, уточнение (обновление, изменение), использование, обезличивание, а также осуществление любых иных действий, предусмотренных действующим законодательством РФ как неавтоматизированными, так и автоматизированными способами.
Данное согласие дается Оператору для обработки моих персональных данных в следующих целях:
— предоставление мне услуг/работ;
— направление в мой адрес уведомлений, касающихся предоставляемых услуг/работ;
— подготовка и направление ответов на мои запросы;
— направление в мой адрес информации, в том числе рекламной, о мероприятиях/товарах/услугах/работах Оператора.
Настоящее согласие действует до момента его отзыва путем направления соответствующего уведомления на электронный адрес [email protected]. В случае отзыва мною согласия на обработку персональных данных Оператор вправе продолжить обработку персональных данных без моего согласия при наличии оснований, указанных в пунктах 2 – 11 части 1 статьи 6, части 2 статьи 10 и части 2 статьи 11 Федерального закона №152-ФЗ «О персональных данных» от 27. 06.2006 г.
Scrum, Kanban, PRINCE2 и другие
08 Июл 2016
«Из всех трудностей, с которыми столкнулись НАСА, отправляя человека на Луну, управление было наверно самой сложной задачей»
— Роджер Лаунис, историк НАСА
У человечества за всю историю накопился внушительный список успешно реализованных сложных проектов. От строительства Пирамид в Гизе до отправки человека на Луну, самые смелые человеческие начинания требовали слаженной работы тысяч людей. А это подразумевает сложную систему управления проектами.
И хотя лишь единицы из нас столкнутся с задачами такого масштаба, большинство читателей этого блога так или иначе сталкивается с проектным управлением. По оценкам 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.
Популярные системы управления проектами
За всю историю проектного управления было создано множество различных методов управления проектами под практически любые нужды. Даже если Вы не собираетесь отправлять человека на Луну и не располагаете аналогичным количеством ресурсов, Вы всё равно найдёте подходящий для себя инструмент. Главное понять, что самое важное для Вашего проекта – дедлайны, ресурсы, соблюдение процесса, или сразу несколько факторов – а затем выбрать метод управления проектом, ориентированный на достижение этого показателя.
Прежде чем приступить к рассмотрению самых популярных методов, определим некоторые ключевые термины.
Базовые термины проектного управления
Agile: Гибкий итеративно-инкрементальный подход к управлению проектами и продуктами, ориентированный на динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует множество методов, базирующихся на идеях Agile, самые популярные из которых – Scrum и Kanban.
Критический путь: Непрерывная последовательность работ и событий от начального до конечного события, требующая наибольшего времени для её выполнения.
Событийная цепочка процессов (EPC-диаграмма): диаграмма, отображающая последовательность реализации работ проектов основываясь на доступности и загруженности ресурсов
Резерв времени: Время, на которое может быть отложено начало работы без влияния на общую продолжительность проекта. Таким образом, у работ на критическом пути резерв будет равняться нулю.
Веха (контрольная точка, milestone): Ключевое событие, обозначающее, например, конец этапа. На диаграмме Гантта обозначается задачей с нулевой длительностью.
Менеджер проекта (руководитель проекта, project manager, PM): Руководитель команды проекта, ответственный за управление проектом (планирование, реализацию и закрытие проекта).
Ресурсы: Элементы, необходимые для реализации проекта. Ресурсами являются время, оборудование, материалы, сотрудники и прочее.
Содержание проекта (Scope): Описание работ, которые необходимо выполнить, чтобы получить продукт.
Спринт (Sprint): Итерация (рабочий цикл) в Scrum, длящаяся от недели до месяца, в ходе которой создаётся рабочая версия продукта или его элемент, представляющий ценность для заказчика.
«Классическое» или «традиционное» проектное управление: Наиболее широко распространённый метод управления проектами, основанный на так называемом «водопадном» (Waterfall) или каскадном цикле, при котором задача передаётся последовательно по этапам, напоминающим поток.
Далее мы рассмотрим различные подходы к управлению проектами более подробно. Мы начнём с Классического проектного управления и Agile, а затем рассмотрим Scrum, Kanban, 6 сигм и другие.
Классическое проектное управление
Наиболее очевидный способ сделать свой проект более управляемым – это разбить процесс его исполнения на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. В этом смысле оно напоминает компьютерную игру – нельзя перейти на следующий уровень не завершив предыдущий. Схема рабочего процесса приведена на Рисунке 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»
Смотрите также:
Источник: https://zapier. com/learn/ultimate-guide-to-project-management/project-management-systems/
Функции и подсистемы управления проектами
Опыт ФРГ, Японии, Кореи, США и других развитых стран свидетельствует о том, что система управления проектами – мощное средство выхода из экономического кризиса и метод решения крупных научных, производственных и социальных проблем. Именно этот метод является средством управления в изменяющихся условиях и развивающихся системах, в условиях нестабильности и неопределенности, когда недостаточно проработаны вопросы законодательства, в условиях слабо контролируемого роста цен и дефицита ресурсов, отказа государства от непосредственного руководства производственно-хозяйственной деятельностью предприятий, в условиях появления собственников и частных инвесторов, нестабильной налоговой системы и др. В странах с традиционно рыночной экономикой к началу XXI в. управление проектами (УП) перестало быть только средством управления последовательностью и темпом выполнения работ с целью их своевременного завершения. УП стало чем-то вроде корпоративного голоса заказчика/клиента, побуждающего оптимизировать все усилия по проекту/продукту, предпринимаемые командами, интегрируясь с производителями, поставщиками, системой послепродажного обслуживания. Такой подход, помимо прочего, позволяет теперь с высокой степенью точности определять (и, соответственно, снижать) предстоящие затраты по проекту.
Компании и эксперты, работающие в этой области, образовали необходимые профессиональные структуры и создали «Мир управления проектами», куда входят национальные и международные организации – инвестиционные, промышленные, строительные, консалтинговые и инжиниринговые фирмы, где проводятся конгрессы и симпозиумы, где издаются журналы, книги и учебники, где имеется свой рынок программного обеспечения.
Крупнейшей международной организацией в области управления проектами является ИПМА (IPMA – International Project Management Association) – Международная ассоциация управления проектами, объединяющая более 20 национальных обществ Европы, а также других стран.
Управленческие функции включают основные, базовые виды деятельности, которые должны осуществлять управляющие работники на всех уровнях и во всех предметных областях по проекту.
Функции управления проектом осуществляются на всех этапах и фазах управления проектом и включают:
- планирование,
- контроль проекта,
- анализ,
- принятие решений,
- составление и сопровождение бюджета проекта,
- организацию осуществления,
- мониторинг,
- оценку,
- отчетность,
- экспертизу,
- проверку и приемку,
- бухгалтерский учет,
- администрирование.
Подсистемы управления проектами формируются в зависимости от структуры предметных областей и управляемых элементов проекта, относительно самостоятельных в рамках проекта. Предметные области и управляемые элементы в рамках проекта в самом общем виде включают: сроки, трудовые ресурсы, стоимость и издержки, доходы, закупки и поставки ресурсов и услуг, ресурсы (уже закупленные), изменения по проекту, риски проекта, информацию и коммуникации, качество и пр. Эти подсистемы присутствуют практически в любом проекте. В каждом конкретном проекте могут добавляться специфические подсистемы.
Отличие подсистем от функций управления проектом заключается в том, что подсистемы ориентированы на предметную область, а функции нацелены на специфические процессы, процедуры и методы. Управление подсистемой включает выполнение практически всех функций. Так, планирование расходов и контроль расходов базируются на одной и той же предметной области – затратах, а планирование расходов и планирование качества базируются на одинаковых процедурах составления планов, сетевом моделировании и пр.
Подсистемы системы управления проектом по основным предметным областям подразделяются на: управление содержанием проекта, объемами работ, управление временем, продолжительностью, управление стоимостью, управление качеством, управление закупками и поставками, управление распределением ресурсов, управление человеческими ресурсами, управление рисками, управление запасами ресурсов, интеграционное (координационное) управление, управление информацией и коммуникациями.
Управление проектами :: Федеральный образовательный портал
Предисловие
Часть I. Знакомство с миром управления проектами
Глава 1. Концепция управления проектами
1.1. Что такое проект и управление проектами
1.2. Зачем нужно управлять проектами
1.3. Взаимосвязь управления проектами и управления инвестициями
1.4. Взаимосвязь управления проектами и функционального менеджмента
1.5. Предпосылки развития методов управления проектами экономикой
1.6. Перспективы развития управления проектами
1.7. Переход к проектному управлению: задачи и этапы решения
Резюме
Контрольные вопросы и задания
Литература
Глава 2. Основы управления проектами
2.1. Классификация базовых понятий управления проектами
2.2. Классификация типов проектов
2.3. Цель и стратегия проекта
2.4. Результат проекта
2.5. Управляемые параметры проекта
2.6. Окружение проектов
2.7. Проектный цикл
2. 8. Структуризация проектов
2.9. Функции и подсистемы управления проектами
2.10. Методы управления проектами
2.11. Организационные структуры управления проектами
2.12. Участники проекта
Резюме
Контрольные вопросы и задания
Литература
Часть II. Разработка проекта
Глава 3. Разработка концепции проекта
3.1. Формирование инвестиционного замысла (идеи) проекта
3.2. Предварительная проработка целей и задач проекта
3.3. Предварительный анализ осуществимости проекта
3.4. Ходатайство (Декларация) о намерениях
Резюме
Контрольные вопросы и задания
Литература
Глава 4. Начальная (прединвестиционная) фаза проекта
4.1. Прединвестиционные исследования
4.2. Проектный анализ
4.3. Оценка жизнеспособности и финансовой реализуемости
проекта
4.4. Технико-экономическое обоснование (проект) строительства
4.5. Бизнес-план
Резюме
Контрольные вопросы и задания
Литература
Глава 5. Организационные структуры управления проектами
5.1. Общие принципы построения организационных структур
управления проектами
5.2. Организационная структура и система взаимоотношений
участников проекта
5.3. Организационная структура и содержание проекта
5.4. Организационная структура проекта и его внешнее окружение
5.5. Общая последовательность разработки
и создания организационных структур управления проектами
5.6. Современные методы и средства организационного моделирования проектов
Резюме
Контрольные вопросы и задания
Литература
Глава 6. Организация офиса проекта
6.1. Понятие офиса проекта
6.2. Основные принципы проектирования и состав офиса проекта
6.3. Основные принципы организации виртуального офиса проекта
Резюме
Контрольные вопросы и задания
Литература
Глава 7. Проектное финансирование
7.1. Источники и организационные формы финансирования
проектов
7.1. 1. Общие положения
7.1.2. Источники финансирования
7.1.3. Организационные формы финансирования
7.2. Организация проектного финансирования
7.2.1. Основные определения
7.2.2. Особенности системы проектного финансирования в развитых странах
7.2.3. Преимущества и недостатки проектного финансирования
7.2.4. Перспективы использования метода проектного финансирования
Резюме
Контрольные вопросы и задания
Литература
Глава 8. Маркетинг проекта
8.1. Современная концепция маркетинга в управлении проектами
8.2. Маркетинговые исследования
8.3. Разработка маркетинговой стратегии проекта
8.4. Формирование концепции маркетинга проекта
8.5. Программа маркетинга проекта
8.6. Бюджет маркетинга проекта
8.7. Реализация маркетинга проекта
8.8. Управление маркетингом в рамках управления проектами
Резюме
Контрольные вопросы и задания
Литература
Глава 9. Разработка проектной документации
9. 1. Состав и порядок разработки проектной документации
9.2. Управление разработкой проектно-сметной документации
9.3. Функции менеджера проекта
9.4. Автоматизация проектных работ
Резюме
Контрольные вопросы и задания
Литература
Глава 10. Экспертиза проекта
10.1. Общие положения
10.2. Экспертиза строительных проектов
10.2.1. Общие положения
10.2.2. Экспертиза проектно-сметной и проектной документации
10.2.3. Порядок проведения экспертизы
10.3. Экологическая экспертиза проектов
10.3.1. Основные понятия и принципы
10.3.2. Государственная экологическая экспертиза
10.3.3. Общественная экологическая экспертиза
Резюме
Контрольные вопросы и задания
Литература
Глава 11. Торги и контракты
11.1. Основные положения и законодательное обеспечение
11.1.1.Закупки и торги
11.1.2. Основные понятия и определения
11.1.3. Законодательно-нормативное обеспечение торгов
11. 1.4. Классификация торгов
11.2. Функции участников торгов
11.3. Порядок проведения подрядных торгов
11.3.1. Организационная подготовка
11.3.2. Разработка тендерной документации
11.3.3. Предварительная квалификация претендентов
11.3.4. Разработка оферты претендентом
11.3.5. Приемка и регистрация оферт
11.3.6. Обеспечение заявки на участие в торгах
11.3.7. Процедура торгов
11.3.8. Утверждение результатов торгов
11.3.9. Завершение торгов
11.3.10. Особенности торгов на закупку услуг
11.4. Договоры и контракты
11.4.1. Виды и структура договоров
11.4.2. Заключение, исполнение и завершение договора
Резюме
Контрольные вопросы и задания
Литература
Глава 12. Оценка эффективности инвестиционных проектов
12.1. Основные принципы оценки эффективности инвестиционных
проектов 275
12.2. Исходные данные для расчета эффективности проекта
12.3. Основные показатели эффективности проекта
12. 4. Оценка эффективности инвестиционного проекта
12.5. Влияние риска и неопределенности при оценке эффективности
проекта
Резюме
Контрольные вопросы и задания
Литература
Часть III. Функции управления проектами
Глава 13. Планирование проекта
13.1. Основные понятия и определения
13.2. Процессы планирования
13.3. Уровни планирования
13.4. Структура разбиения работ (СРР)
13.5. Назначение ответственных
13.6. Определение основных вех
13.7. Типичные ошибки планирования и их последствия
13.8. Детальное планирование
13.9. Сетевое планирование
13.10. Связь сметного и календарного планирования
13.11. Ресурсное планирование
13.12. Документирование плана проекта
Резюме
Контрольные вопросы и задания
Литература
Глава 14. Управление стоимостью проекта
14.1. Основные принципы управления стоимостью проекта
14.2. Оценка стоимости проекта
14. 3. Бюджетирование проекта
14.4. Методы контроля стоимости проекта
14.5. Отчетность по затратам
Резюме
Контрольные вопросы и задания
Литература
Глава 15. Контроль и регулирование проекта
15.1. Цели и содержание контроля проекта
15.2. Мониторинг работ по проекту
15.3. Измерение прогресса и анализ результатов
15.4. Принятие решений
15.5. Управление изменениями
Резюме
Контрольные вопросы и задания
Литература
Глава 16. Завершение проекта
16.1. Пусконаладочные работы
16.2. Приемка в эксплуатацию законченных строительством объектов
16.3. Закрытие контракта
16.4. Выход из проекта
Резюме
Контрольные вопросы и задания
Литература
Часть IV. Подсистемы управления проектами
Глава 17. Управление работами по проекту
17.1. Основные понятия
17.2. Цели, задачи, содержание проекта
17.3. Взаимосвязь объемов, продолжительности и стоимости работ
17. 4. Методы управления содержанием работ
17.5. Структура и объемы работ
17.6. Принципы эффективного управления временем
17.7. Состав и анализ факторов потерь времени
17.8. Формы контроля производительности труда
Резюме
Контрольные вопросы и задания
Литература
Глава 18. Менеджмент качества проекта
18.1. Современная концепция управления качеством
18.2. Менеджмент качества проекта
18.3. Стандартизированные системы менеджмента качества
18.4. Обеспечение функционирования и совершенствования системы
менеджмента качества
18.5. Сертификация продукции проекта
Резюме
Контрольные вопросы и задания
Литература
Глава 19. Управление ресурсами проекта
19.1. Процессы управления ресурсами проекта
19.1.1. Ресурсы проекта
19.1.2. Процессы управления ресурсами
19.2. Основные принципы планирования ресурсов проекта
19.3. Управление закупками ресурсов
19.3.1. Основные задачи закупок и поставок
19. 3.2. Правовое регулирование закупок и поставок
19.3.3. Организационные формы закупок
19.3.4. Основные требования к управлению закупками и
поставками
19.4. Управление поставками
19.4.1. Типы товарных рынков
19.4.2. Договоры на поставку материально-технических ресурсов
19.4.3. Планирование поставок
19.4.4. Поставки материально-технических ресурсов
19.5. Управление запасами
19.5.1. Основные понятия
19.5.2. Виды запасов
19.5.3. Затраты на формирование и хранение запасов
19.5.4. Оптимизация размера запаса
19.6. Новые методы управления материально-техническим обеспечением логистика
19.6.1. Основные понятия
19.6.2. Концепция логистики в управлении проектами
Резюме
Контрольные вопросы и задания
Литература
Глава 20. Управление командой проекта
20.1. Формирование и развитие команды
20.1.1. Основные понятия
20.1.2. Основные характеристики команды проекта
20. 1.3. Принципы формирования команд
20.1.4. Организационные аспекты формирования команды
20.1.5. Эффективность команды проекта
20.1.6. Методы формирования команды проекта
20.1.7. Примерный состав команды и требования к менеджерам
проекта
20.2. Организация эффективной деятельности команды
20.2.1. Организация совместной деятельности команды проекта
20.2.2. Организационная культура команды
20.2.3. Принятие решений
20.3. Управление персоналом команды
20.3.1. Основные принципы управления персоналом
20.3.2. Менеджер по персоналу в команде проекта
20.3.3. Специфика команды проекта как человеческого ресурса
20.3.4. Стратегия формирования команды проекта
20.3.5. Кадровое планирование команды
20.3.6. Привлечение, отбор и оценка персонала проекта
20.3.7. Обучение и развитие персонала проекта
20.4. Психологические аспекты управления персоналом
20.4.1. Основные психологические характеристики команды
проекта
20. 4.2. Мотивация и стимулирование персонала
20.4.3. Конфликты
Резюме
Контрольные вопросы и задания
Литература
Глава 21. Управление рисками
21.1. Основные понятия
21.1.1. Риск и неопределенность
21.1.2. Управление рисками
21.2. Анализ проектных рисков
21.2.1. Сущность анализа рисков проекта
21.2.2. Качественный анализ рисков
21.2.3. Количественный анализ рисков
21.3. Методы снижения рисков
21.4. Организация работ по управлению рисками
Резюме
Контрольные вопросы и задания
Литература
Глава 22. Управление коммуникациями проекта
22.1. Основные положения
22.2. Управление коммуникациями проекта
22.3. Информационные технологии управления проектами
22.4. Интегрированные информационные системы поддержки
принятия решений
22.5. Сравнительный анализ программного обеспечения для управления проектами
22.5.1. Критерии анализа программного обеспечения
22. 5.2. Обзор программного обеспечения по управлению проектами, представленного
на российском рынке
22.6. Особенности внедрения информационных систем управления
проектами
Резюме
Контрольные вопросы и задания
Литература
kursy-upravleniya-proektami — Управление проектами
- Длительность 4 дня (32 акад. часа)
- Может проводиться очно и дистанционно
- Проводиться на примере реальных проектов компании
- Более 12 деловых командных игр
- Программа может быть изменена под требования заказчика
Базовый тренинг по обучению профессии менеджер проекта позволяет получить знания в сфере управления проектами, отработать полученные навыки на практике, а также систематизировать и структурировать накопленный опыт.
Результаты тренинга:- Целостное видение своего проекта: цели, сроки, бюджет, команда, риски.
- Знание ключевых алгоритмов управления проектами.
- Понимание своей роли, как руководителя проекта.
- Знание инструментов управления командой проекта.
- Опыт заполнения основных документов управления проектами.
Программа тренинга “Практикум управления проектами”
ДЕНЬ 1ВВЕДЕНИЕ, СУБЪЕКТЫ, ОБЪЕКТЫ, ПРОЦЕССЫ
- ВВЕДЕНИЕ В УПРАВЛЕНИЕ ПРОЕКТАМИ
- Зачем и кому потребовалось управлять проектами. Роль и место проектного управления в современном мире.
- Международные ассоциации и стандарты в управлении проектами.
- Основные причины проблем реализации крупных проектов.
- ОБЪЕКТЫ УПРАВЛЕНИЯ В ПРОЕКТНОЙ ДЕЯТЕЛЬНОСТИ. ПРОЕКТ, ПРОГРАММА, ПОРТФЕЛЬ.
- Отличие проекта от операционной (постоянной) деятельности.
- Что такое проект? Определение проекта.
- Проект, программа, портфель проектов. Признаки, отличительные черты, задачи управления.
- Проектная деятельность в организации. Проекты и программы как инструмент реализации стратегии компании.
- Классификация проектов.
- Жизненный цикл проекта.
- СУБЪЕКТЫ УПРАВЛЕНИЯ ПРОЕКТАМИ
- Участники проекта и заинтересованные стороны. Основные роли и интересы.
- Заказчик проекта. Роль и основные функции.
- Руководитель проекта. Ответственность, полномочия и функции.
- Куратор проекта. Задачи и функции куратора.
- Принципы формирования организационной структуры проекта.
- Типы организационных структур проекта. Функциональная, проектная и матричная структуры. Достоинства и недостатки. Конфликт интересов в матричной структуре и пути его минимизации.
- ПРОЦЕССЫ И ФУНКЦИИ УПРАВЛЕНИЯ ПРОЕКТАМИ
- ДЕЛОВАЯ ИГРА:Управление проектом – основные шаги (здравый смысл + рекомендации профессионалов).
- Основные группы процессов управления проектом: группа процессов инициации, группа процессов планирования, группа процессов организации исполнения, группа процессов контроля, группа процессов завершения проекта.
- Взаимосвязь процессов управления и фаз жизненного цикла проекта.
- Обзор основных функциональных областей управления проектами: управление содержанием, управление сроками, управление стоимостью, управление рисками, управление персоналом, управление коммуникациями, управление поставками, управление качеством, управление интеграцией проекта.
- Использование процессной модели в управлении проектом.
ИНИЦИАЦИЯ ПРОЕКТА. СТРУКТУРНОЕ, СТРАТЕГИЧЕСКОЕ И ОРГАНИЗАЦИОННОЕ ПЛАНИРОВАНИЕ.
- ИНИЦИАЦИЯ ПРОЕКТА. ПОДГОТОВКА ЭФФЕКТИВНОГО СТАРТА.
- Инициация проекта. Основные задачи и возможные трудности.
- Рекомендуемая структура Устава проекта.
- Определение проекта, как объекта управления. Миссия, цели, ограничения и допущения проекта.
- Уровни целеполагания. Результаты и продукт проекта.
- Критерии успеха проекта.
- ДЕЛОВАЯ ИГРА: Разработка и согласование устава проекта.
- ОСНОВНЫЕ ПРИНЦИПЫ ПЛАНИРОВАНИЯ ПРОЕКТА
- Основные задачи планирования в проекте. Перечень разрабатываемых планов.
- Алгоритм разработки календарного плана.
- СТРУКТУРНОЕ ПЛАНИРОВАНИЕ
- Иерархическая структура продукта проекта. Назначение и способ построения.
- Иерархическая структура работ проекта. Принципы разработки. Глубина детализации работ. Определение полноты декомпозиции.
- ДЕЛОВАЯ ИГРА: Разработка иерархической структуры работ проекта.
- СТРАТЕГИЧЕСКОЕ ПЛАНИРОВАНИЕ ПРОЕКТА
- Контрольные события в проекте.
- План проекта по вехам. Принципы определения и формулировки вех проекта.
- ДЕЛОВАЯ ИГРА: Разработка плана проекта по вехам.
- ОРГАНИЗАЦИОННОЕ ПЛАНИРОВАНИЕ ПРОЕКТА
- Формирование организационной структуры проекта
- Проектные роли. Функции, полномочия, ответственность, требуемые компетенции.
- Назначение сотрудников в проект. Матрица ответственности. Правила формирования матрицы ответственности.
КАЛЕНДАРНОЕ ПЛАНИРОВАНИЕ ПРОЕКТА. ПЛАНИРОВАНИЕ ЗАТРАТ. УПРАВЛЕНИЕ ПЕРСОНАЛОМ И КОММУНИКАЦИЯМИ ПРОЕКТА.
- КАЛЕНДАРНОЕ ПЛАНИРОВАНИЕ ПРОЕКТА
- Определение последовательности выполнения работ. Сетевая диаграмма проекта. Назначение и способы построения сетевой диаграммы.
- Оценка длительности работ в проекте. Основные методы оценки длительности и рекомендации по их практическому применению.
- Календарный план проекта как инструмент прогнозирования и своевременного принятия управленческих решений. Признаки грамотно разработанного календарного плана проекта.
- Оптимизация календарного плана проекта. Метод критического пути. Принципы практического применения метода критического пути для временной оптимизации календарного плана проекта. Анализ временных резервов работ.
- Ресурсное планирование проекта. Типы ресурсов. Учет ресурсов в проекте.
- Ресурсные конфликты и способы их разрешения. Ресурсная оптимизация календарного плана проекта.
- ПЛАНИРОВАНИЕ ЗАТРАТ. РАЗРАБОТКА БЮДЖЕТА ПРОЕКТА.
- Алгоритм разработки бюджета проекта
- Стоимостная оценка плановой операции. Диапазоны точности и методы стоимостной оценки.
- Проектные сметы. Назначение и виды смет.
- Разработка бюджета проекта. Основные способы согласования объемов и графика финансирования проекта.
- УПРАВЛЕНИЕ ПЕРСОНАЛОМ И КОММУНИКАЦИЯМИ ПРОЕКТА
- Признаки успешной команды проекта. Концепция Т.Е.A.M.
- Цели команды. Механизм мотивации членов проектной команды. «Мифы» и принципы мотивации. Как обеспечить требуемую мотивацию участников проекта. Теория мотивации Абрахама Маслоу. Теория мотивации Дэвида Макклелланда.
- ДЕЛОВАЯ ИГРА: Определение доминирующих потребностей сотрудника и подбор стимулов для его мотивации.
- Стадии развития проектной команды. Способы управления командой на каждой из стадий.
- Ситуационный менеджмент. Принципы практического применения ситуационного лидерства в проекте.
- Состав успешной команды (по Р. Белбину). Процессные роли участников команды. Способы практического применения теории Белбина.
- Важность управления коммуникациями в проекте. Виды коммуникации.
- План управления коммуникациями. Схема коммуникационных каналов проекта. Лист контактов. Матрица согласования проектных документов.
- Совещания в проекте. Виды и назначение совещаний. Проектное совещание: модель Дж.Тропмана.
- ДЕЛОВАЯ ИГРА: Стартовое совещание по проекту. Приоритеты и конфликты.
- Структура архива проекта.
УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА. КОНТРОЛЬ И ЗАВЕРШЕНИЕ ПРОЕКТА. УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА
- Определение риска, как рискового события. Риски и неопределенность. Границы управления рисками в проекте.
- Процессы управления рисками. Дополнительные роли в проекте по управлению рисками.
- Методы и средства идентификации рисков. Мозговой штурм. Метод Делфи. Формулировка последствий, причины риска и рискового события.
- ДЕЛОВАЯ ИГРА: Идентификация рисков проекта.
- Качественная оценка рисков. Определение последствий и вероятности риска. Матрица оценки степени воздействия риска. Экспертная оценка вероятности риска.
- ДЕЛОВАЯ ИГРА: Определение вероятности и последствий рисков. Ранжирование реестра рисков проекта.
- Матрица вероятность\воздействие. «Карта» рисков.
- Разработка плана реагирования на риски. Методы реагирования: избежание, минимизация, передача, принятие рисков.
- ДЕЛОВАЯ ИГРА: Разработка плана реагирования на риски.
КОНТРОЛЬ ПРОЕКТА. AGILE – ГИБКОЕ УПРАВЛЕНИЕ ПРОЕКТАМИ
- КОНТРОЛЬ ИСПОЛНЕНИЯ И ЗАВЕРШЕНИЕ ПРОЕКТА
- Процессы контроля проекта.
- Принципы построения системы контроля проекта. Контроль сроков, контроль стоимости и контроль содержания проекта. Сбор отчетной информации.
- Управление изменениями в проекте. Запрос на изменение. Уровни принятия решений.
- ДЕЛОВАЯ ИГРА: Принятие решения по запросу на изменение в проекте.
- Завершение проекта. Процессы завершения проекта. Подведение итогов и анализ результатов проекта. Итоговый отчет по проекту
- КРИТИЧЕСКИЕ ФАКТОРЫ УСПЕХА ПРОЕКТА
- Наиболее часто называемые причины неудач реализации проектов
- Критические факторы успеха проекта
- ДЕЛОВАЯ ИГРА: Оценка проекта по 10-ти ключевым факторам успеха.
- AGILE – ГИБКОЕ УПРАВЛЕНИЕ ПРОЕКТАМИ
- Сравнение классического и гибкого подхода управления проектами.
- Итеративная и инкрементальная разработка. Преимущества и недостатки.
- Роли в Agile команде.
- История Agile и манифест гибкой разработки (Agile Manifesto).
- Методология Scrum — роли, артефакты, встречи участников
- Практики для совместной командной оценки
- Уровни планирования в Agile, оценка сроков проекта и мониторинг его текущего состояния.
Методология управления проектами: определение, типы, примеры
Без сомнения, правильно определенная и строго соблюдаемая методология управления проектом дает твердую гарантию того, что работа будет выполнена вовремя, в рамках бюджета и в соответствии с требованиями клиента.
Что такое методология управления проектами ? Как это можно определить? Проще говоря, это , которое необходимо иметь , чтобы избежать сбоев и снизить риски, потому что это один из важнейших факторов успеха, а также основная компетенция управленческой команды.Это простой способ направить команду через разработку и выполнение фаз, процессов и задач на протяжении всего жизненного цикла управления проектом.
Что такое методология? Определение в управлении проектами
Термин « методология управления проектами » был впервые определен в начале 1960-х годов, когда различные коммерческие организации начали искать эффективные способы, которые могли бы упростить реализацию бизнес-преимуществ и организовать работу в структурированный и уникальный объект (который назывался « проект »позже).Коммуникация и сотрудничество были ключевыми критериями для установления продуктивных рабочих отношений между командами и отделами одной и той же организации.
С тех пор термин изменялся и модифицировался много раз, создавались новые определения, добавлялись новые элементы и функции. Сегодня мы рассматриваем методологию управления проектами как набор общих принципов и правил для управления конкретным проектом, имеющим определенное начало и конец.Ниже приводится текущее определение методологии .
Методология управления проектом — это строго определенная комбинация логически связанных практик, методов и процессов, которые определяют, как лучше всего планировать, разрабатывать, контролировать и реализовывать проект на протяжении всего процесса непрерывной реализации до успешного завершения и прекращения. Это научно подтвержденный, систематический и дисциплинированный подход к разработке, реализации и завершению проекта.
Цель методологии проекта — позволить контролировать весь процесс управления посредством эффективного принятия решений и решения проблем, обеспечивая при этом успех конкретных процессов, подходов, техник, методов и технологий.
Как правило, методология обеспечивает основу для подробного описания каждого шага, чтобы менеджер проекта знал, что делать, чтобы выполнить и выполнить работу в соответствии с графиком, бюджетом и спецификацией клиента.
Ссылаясь на указанное определение, правильно выбранная методология управления проектами открывает путь к достижению следующих достижений:
- Определены потребности заинтересованных сторон
- Команда установила и понимает общий «язык», поэтому они знают, чего от них ждут.
- Смета расходов полная, точная и достоверная
- Каждая задача выполняется единым методическим подходом
- Большинство конфликтов обнаруживаются и разрешаются в начале
- Ожидаемые результаты выполнены и переданы
- Уроки извлечены, решения быстро внедряются
Методология в PM Framework
Управление проектами (аббревиатура «PM») обеспечивает основу для планирования, выполнения и реализации проектов любого типа, размера, характера и типа.Концепция PM направлена на реализацию желаемых изменений в соответствии с выбранным методологическим подходом. На самом деле изменения — это ключевой аспект, которым нужно управлять. Структура PM определяет и определяет, как лучше всего управлять изменениями. Методология служит «способом» для систематического осуществления изменений с точки зрения времени, стоимости и качества.
Управление проектами означает описание и выполнение действий, необходимых для достижения конкретных целей внесения изменений.
Например, написание книги — это своего рода проект, цель которого — написать книгу.Эта цель может быть достигнута с помощью ряда действий, включая определение темы, сбор материала, создание черновика, набор текста, корректуру и другие. Итак, с точки зрения управления проектом, автору необходимо определить и затем выполнить все необходимые действия, чтобы написать книгу (что означает внести изменения).
СтруктураPM представляет собой структурированный набор всех необходимых знаний о том, как вносить изменения методологически. Он не описывает точный алгоритм управления конкретным проектом, но предоставляет широкий обзор различных методов, правил, процессов и стандартов.В этом отношении методологию управления проектами можно определить как уровень структуры PM.
Вот упрощенный пример того, как методология проекта может быть представлена в иерархической структуре управления:
PM Framework предшествует методологии, которая, в свою очередь, предшествует этапам жизненного цикла и определяет процессы, задачи и действия управления проектом
Типы методологии управления проектами
В управлении проектами существует множество подходов и методов, которые можно использовать для управления проектами разных типов.Все типы проектной методологии условно можно разделить на традиционных и современных подходов.
Традиционный подход
Традиционный подход включает в себя ряд последовательных этапов в процессе управления проектом. Это пошаговая последовательность действий по проектированию, разработке и доставке продукта или услуги. Это влечет за собой преемственность в процессе реализации и дает преимущества планирования на основе этапов и создания команды.В ИТ и разработке программного обеспечения этот тип методологии называется « Waterfall » — одна часть работы следует за другой в линейной последовательности.
В традиционную методологию управления проектами входят следующие этапы:
- Инициирование (ТЗ)
- Проектирование и дизайн
- Исполнение (конструкция и кодировка)
- Управление и интеграция
- Валидация (тестирование и отладка)
- Затвор (установка и обслуживание)
Современные подходы
Современные методологии не фокусируются на линейных процессах, но предоставляют альтернативный взгляд на управление проектами.Некоторые методы лучше всего подходят для ИТ и разработки программного обеспечения, тогда как другие могут быть реализованы в производстве, улучшении процессов, разработке продукта и т. Д. Современные подходы к управлению проектами используют разные модели процесса управления.
Примеры методологии управления проектами
Выбор правильной методологии зависит от типа, размера и характера проекта. Вот самые популярные методики PM:
Направляющая PMBOK®
Хотя Руководство по своду знаний по управлению проектами НЕ ЯВЛЯЕТСЯ методологией PM в его « чистом состоянии », многие люди считают его методологическим подходом к планированию, выполнению, контролю и завершению различных проектов.Между тем, PMBOK® Guide представляет собой обширный перечень лучших практик и идей по планированию и реализации проектов. Обратите внимание, что это всего лишь руководство, а не методология управления проектами.
PRINCE2
PRojects IN Controlled Environments 2 (PRINCE2) представляет собой набор методов, ориентированных на процессы, и подходов, ориентированных на документацию, которые позволяют управлять различными проектами в частном секторе. Он был разработан правительством Великобритании, и сегодня этот прекрасный пример методологии управления проектами используется как в Великобритании, так и за рубежом.
CPM
Методкритического пути (CPM) исследует наиболее важные или критических задач проекта путем определения возможных последовательностей действий и оценки максимальной продолжительности каждой последовательности. Это помогает выяснить, сколько времени потребуется на выполнение работы и какие задачи войдут в объем.
Постное
Методология Lean PM направлена на максимальное увеличение ценности для клиентов и минимизацию потерь ресурсов. Экономичное управление проектами позволяет организациям создавать более высокую ценность для своих клиентов с меньшими ресурсами.Такой подход позволяет достичь совершенства в удовлетворении запросов потребителей и создании ценности за счет реализации оптимизированного технологического процесса, который исключает отходы в продуктах, услугах, транспортировке, запасах и т. Д.
Шесть сигм
Метод «Шесть сигм» был первоначально разработан Motorola для улучшения производственных процессов за счет устранения дефектов (определяемых как «несоответствие продукта или услуги его спецификациям»). Сегодня «Шесть сигм» — один из самых популярных и пользующихся доверием во всем мире примеров методологии управления проектами для обеспечения точности и скорости реализации процесса за счет устранения или минимизации потерь.
CCPM
Critical Chain Project Management (CCPM) — это способ планировать, реализовывать и анализировать различные виды работ в средах с одним и несколькими проектами. Эта методология управления использует Theory of Constraints (TOC) и концепцию буферов для определения улучшенной продолжительности задач и управления ресурсозависимыми задачами и действиями.
SCRUM
SCRUM — это пример методологии Agile PM, которая вовлекает команды в создание программного продукта в течение 30 дней « спринтов » и ежемесячных « scrum-сессий ».В проекте, управляемом SCRUM, результаты разбиты на 30-дневные интервалы. Этот пример методологии является специфическим и применим, главным образом, к совместным, на 100% преданным делу командам, без сильно ограниченного бюджета по времени и материалам.
15 Методологий управления проектами, о которых вам нужно знать
Для тех из вас, кто не бредят фанатами регби, схватка — это клубок тяжелых людей, которые напрягаются друг против друга, чтобы получить маленький продолговатый белесый мяч. Поскольку бизнес-менеджеры считают такое поведение нежелательным в производственных командах, они используют метод управления проектами Scrum.
Скрам-команды встречаются на ежемесячных Скрам-сессиях, на которых они разбивают свои проекты и результаты на 15- или 30-дневные части, называемые «спринтами». Работая над этими небольшими приращениями, команды избегают перегрузки процесса, типичного для других методологий PM. Ежемесячно меняя приоритеты своих усилий для удовлетворения потребительского спроса, они могут оставаться гибкими и мотивированными, повышая как производительность, так и удовлетворенность клиентов!
Команды разработчиков часто применяют популярный Scrum-вариант Agile Project Management.Менеджеры считают Scrum простым в реализации и очень эффективным в решении проблем, влияющих на группы разработчиков программного обеспечения.
Члены команды получают удовольствие от того, как Scrum помогает им распутывать сложные циклы разработки, переопределять конечные цели в течение проектного цикла и очень быстро выводить на рынок качественные продукты.
В этой системе никто не имеет звания «менеджер проекта». Вместо этого они разделяют свои обязанности, взяв на себя определенные роли: Скрам-мастер, владелец продукта и член команды:
Скрам-мастер
Скрам-мастер (несмотря на свое впечатляющее название) не берет на себя титул менеджера или лидера команды.Этот человек наблюдает за процессом Scrum, а не за самой работой. Они гарантируют, что каждый в команде хорошо общается по повседневным проектам, устраняет отвлекающие факторы и устраняет препятствия на пути группы.
Владелец продукта
Этот человек, либо ключевой пользователь, либо эксперт по маркетингу, дает команде последовательное видение их первоначальной цели: удовлетворить потребности клиентов. Поскольку концепция конечного продукта в команде может меняться в процессе работы, владелец продукта выполняет жизненно важную функцию «заземления».
Член команды
Команды встречаются ежедневно, чтобы обсудить выполненную работу и выявить любые препятствия на пути дальнейшего прогресса. Скрам-мастер соглашается разобраться с этими препятствиями; Владелец продукта сотрудничает с командой для оптимизации таргетинга на продукт.
Метод Scrum лучше всего подходит для небольших команд, которые работают вместе в одной среде и сосредоточены только на одном проекте за раз. Это способствует открытому общению и творчеству, а также быстрым циклам разработки / тестирования.
Scrum работает особенно хорошо, когда команды получают существенную поддержку со стороны высшего руководства в виде открытых финансовых и временных бюджетов.
9 из самых популярных методологий управления проектами стали проще
Как выбрать правильную методологию управления проектами
Выбор правильной методологии важен, потому что она определяет то, как мы работаем. Он предоставляет структуры, которые могут вести нас к успеху или неудаче проекта. А поскольку вы уже знаете, что не существует универсального метода, подходящего для всех типов, размеров и отраслей бизнеса, важно, чтобы вы потратили некоторое время и усилия на выбор правильной методологии управления проектами для вашего контекста.
Вот несколько шагов, чтобы решить, какую методологию управления проектами использовать в вашем проекте:
1. Рассмотрите факторы вашего проекта по их простоте или сложности.
Это включает в себя сам проект, а также клиента, наши доступные ресурсы и ограничения проекта (включая аппетит к изменениям и риску), сроки, инструменты и людей. Перечислите эти факторы и обозначьте их в соответствии с их простотой или сложностью.
2. Определите жесткость или гибкость вашей рабочей среды.
Если вы работаете в динамичной среде, где есть стремление к развитию и изменениям, вам может подойти методология Agile. Если вы работаете в рамках очень фиксированных требований, сроков и бюджета, вам может быть лучше использовать водопадный подход. Наряду с рассмотрением вашей гибкости обратите внимание на свои ограничения и риски. Как вы можете внедрить процессы, которые минимизируют ваши ключевые риски и помогают вашим командам аккуратно вписать свои проекты в рамки ваших организационных ограничений?
Независимо от того, являетесь ли вы более гибким (представьте себе проворную дизайн-студию, где большинство членов команды носят несколько головных уборов) или более жесткой (подумайте о внутреннем агентстве, деятельность которого должна соответствовать множеству внутренних правил) сейчас это также хорошее время, чтобы спросить себя, должна ли ваша организация оставаться такой же жесткой или гибкой.Вы можете выбрать методологию или гибридную методологию, которая подтолкнет вашу организацию в том направлении, в котором вы хотите двигаться, — просто будьте осторожны, выбирая методы, которые действительно реалистичны для реализации вашими командами в том виде, в каком они есть сейчас.
3. Определите, что приносит наибольшую пользу.
Спросите, что приносит наибольшую пользу клиенту (или заинтересованной стороне, или конечному пользователю). Составьте список их потребностей и используйте его, чтобы выбрать способ работы, который лучше всего отвечает этим потребностям.
Например, если ваши клиенты обычно делают постоянные запросы и ожидают постоянных обновлений и изменений, то итеративная методология с короткими циклами поможет клиенту почувствовать, что они получают большую ценность.Использование этой методологии поможет вам приносить пользу и поддерживать позитивные отношения с клиентами.
4. Используйте свои организационные цели.
Используйте цели или задачи проекта, которые вы уже создали как команда или организация, чтобы руководствоваться при выборе методологии проекта. Ясно, что ваши методы должны быть средством достижения ваших целей — лучший метод — это тот, который направляет вас непосредственно к вашим стратегическим целям с наибольшей выгодой и наименьшим негативным воздействием.
5. Перечислите свои организационные и командные ценности.
Наконец, что важно, глубоко погрузитесь в свои ценности. В конце концов, методики разрабатываются людьми — людьми с привычками, мнениями и ценностями. Вместо того, чтобы использовать модную методологию и навязывать ее своим людям, используйте способы их мышления, взаимоотношений и работы, чтобы разработать методологию, которая вам подходит.
Ценности вашей организации и команды могут придать форму действительно устойчивой методологии, которая в меньшей степени является теоретическим стандартом (который вы никогда не встретите на самом деле), а в большей степени способом систематического воплощения жизненных, дыхательных процессов, которые легче поддерживать в долгосрочной перспективе.
Помните, что нет методологии лучше, чем другие. Все зависит от того, насколько хорошо он соответствует целям и ценностям организации, от ограничений, с которыми приходится иметь дело команде проекта, от потребностей заинтересованных сторон, связанных с этим рисков, а также от размера, стоимости и сложности проекта.
Какая лучшая методология для цифровых агентств?
Короткий ответ?
Это зависит. Нет правильного или неправильного. Это зависит от вашего клиента, вашей команды и проекта. Вот подробное описание некоторых распространенных методологий и того, какие преимущества и проблемы они приносят.
У меня есть целая статья, посвященная дебатам Agile vs. Waterfall, но ниже я резюмирую несколько основных моментов, которые следует учитывать при размышлениях о лучшем подходе для цифровых агентств.
Плюсы и минусы Waterfall в цифровых агентствах
Практически всегда, когда в агентстве поднимают голову над парапетом и предполагают, что Waterfall может быть хорошим подходом для проекта, равносильно рисованию большой мишени на себе. Waterfall — это то, что не хочет слышать ни один клиент или команда — мы все хотим, чтобы нас считали передовыми, а Waterfall определенно не крутой.
Мало того, что это не круто, но Waterfall сложен, потому что требует тщательного предварительного планирования проекта до того, как будет выполнена какая-либо работа по созданию ценности. Иногда планирование необходимо, потому что клиенты должны утвердить стоимость, сроки и объем. Но клиенты обычно неохотно платят за планирование, и даже в тех случаях, когда агентства успешно переводят клиентов с Waterfall на более гибкие контракты, что произойдет, если ваше планирование не на должном уровне?
По правде говоря, в цифровом мире нам постоянно трудно делать точные оценки.Обычно мы работаем с новыми технологиями, над неопределенными проектами. Часто, как только вы начинаете свой проект, ваш план уже устарел. Таким образом, хотя клиентам нравится предсказуемость результатов, бюджета и сроков, водопадный подход по своей сути негибкий.
Так что насчет вкуса Agile?
Плюсы и минусы Agile в цифровых агентствах
Агентства и клиенты, как правило, довольно плавно понимают Agile.
Agile широко хвалят за то, что он «не является водопадом», и его часто неправильно понимают как «делать больше, с меньшими затратами, быстрее и дешевле, чем когда-либо прежде».
Почему бы вам этого не захотеть?
Клиентам, как правило, нравится идея Agile из-за ее очевидной гибкости для поворота проекта, предоставляя им больше возможностей постоянно менять свое мнение на протяжении всего проекта.
Они часто думают, что это означает, что они выполнят больше работы с меньшими затратами или что им никогда не придется принимать окончательное решение по чему-либо, потому что они могут изменить свое мнение вплоть до последней минуты.
В некотором роде это правда, но не вся история.По правде говоря, Agile может быть лучше, но Agile не бывает дешевым и простым.
Уловка и остальная часть истории в том, что такой уровень гибкости стоит дорого. Да, вы можете передумать, но это отнимает время, а время стоит денег.
Другая проблема заключается в том, что для того, чтобы быть успешными и по-настоящему гибкими, клиенты должны быть доступны и иметь возможность принимать решения (что редко бывает в иерархических организациях и организациях, ориентированных на совет директоров). Им необходимо оперативно предоставлять обратную связь и расставлять приоритеты, чтобы проект продолжал развиваться, что часто бывает очень непросто.
Основные факты о лучшей методологии агентства
По сути, агентства хотят получать деньги за свою работу, а клиенты хотят, чтобы агентства делали свою работу наилучшим образом, правильно, с первого раза. Должна быть какая-то золотая середина.
Во многом все сводится к доверию. Действительно ли клиенты верят, что агентство приносит пользу, и готовы ли они платить за неудачи на пути к успеху?
Делать больше с меньшими затратами и устранять потери — отличный принцип бережливого производства, но проблема с этим подходом часто возникает из-за того, что агентства успешно перевели клиентов с Waterfall на более гибкие контракты.Клиенты могут привести к большим потерям, и без действительно встроенного, доверяющего клиента, который дает реальную власть принимать решения, никакая методология Agile-проекта не может исправить этот недостаток в отношениях.
Но там, где агентства успешно переводят клиентов с Waterfall на более гибкие контракты и желание экспериментировать, происходит волшебство. От наших клиентов требуется зрелость, чтобы понять, что мы не можем точно определить, что и когда они получат, но, обладая некоторым здоровым доверием, мы будем работать вместе, чтобы делать все, что в наших силах.
Обзоры 9 самых популярных методологий управления проектами
Ниже я составил список методологий управления проектами, в котором описаны наиболее популярные подходы к управлению проектами. В каждом разделе есть ссылки, чтобы узнать больше о каждом подходе.
Лучшие методы, подходы, приемы управления проектами
Частые посетители этого раздела блога, должно быть, слышали, что термины Prince2, Scrum, Agile… используются довольно случайно; Это лишь некоторые из методов управления проектами или установленных процедур для успешного выполнения проекта.
Некоторые из вас могут быть хорошо знакомы с этими методологиями управления проектами, в то время как другие могут все еще пытаться ориентироваться в сложном, но захватывающем мире управления проектами, и эти термины могут показаться вам немного чуждыми. Ничего страшного, поэтому цель этого поста — полностью погрузить вас в методологии управления проектами, на которые на протяжении десятилетий так часто полагаются руководители проектов. Для опытного менеджера проекта это еще одна прекрасная возможность напомнить себе о некоторых из лучших техник и методологий, которые привели к появлению лучших в мире продуктов.
Почему методы управления проектами?
Ответ — почему бы и нет? Подумайте об этом на секунду: в какой-то момент вашей жизни вы, должно быть, разместили заказ на оборудование или инструмент с большим количеством отсоединенных частей, которые невозможно правильно собрать с помощью инструкции по эксплуатации. То же самое и с управлением проектами. Есть много взаимосвязанных и взаимозависимых задач; следовательно, потребность в наборе общепринятых инструкций, служащих руководством для управления деятельностью проекта.
8 Общие методологии управления проектами
1. Гибкость
Agile Project Management Process — это метод управления проектами, ориентированный на ценность, который позволяет выполнять проекты в небольшие фазы или циклы. Методология является чрезвычайно гибкой, и проекты, демонстрирующие динамические черты, выиграют от этого процесса, поскольку вы обнаружите, что менеджеры проектов, работающие в этой среде, рассматривают вехи как «спринты»; цель — постоянно адаптироваться к резким изменениям на основе отзывов клиентов.Он лучше всего подходит для небольших программных проектов, состоящих из очень совместной команды, или для проекта, требующего частых итераций.
2. Водопад
Методология водопада, с другой стороны, представляет собой традиционный подход к управлению проектами и чаще используется в производственном или строительном секторах. Многие эксперты считают, что это первая модель, которая была принята в программной инженерии. Модель использует линейный подход к управлению проектами, когда проект разбивается на последовательности, причем начало фазы зависит от завершения предыдущей.
Этот метод состоит из 5 этапов:
Разработка идей — Проектирование системы — Внедрение — Тестирование и проверка — Техническое обслуживание
3. Скрам
Метод традиционного водопада раскрывает более длительный процесс, когда только планирование может занять пару месяцев, прежде чем перейти к следующему этапу — проектированию. Этап проектирования также может занять пару месяцев; это может привести к выпуску продукта, который на текущем рынке можно назвать устаревшим.
В Scrum, однако, планирования достаточно, чтобы запустить проект, поскольку он основан на структуре Agile, о которой говорилось ранее. Это отличный способ предотвратить задержки с запуском продукта, потому что весь процесс сосредоточен на совместной работе команды. Скрам-мастер способствует проведению скрам-сессий (спринтов), которые происходят в течение 1-3 недель. В результате получается повторяющийся процесс, который значительно экономит компании время и деньги.
4. PRINCE2
PRINCE2 — это аббревиатура от PRojects IN Controlled Environments; он зародился в Великобритании и стал принят в Великобритании как лучшая практика управления проектами благодаря своей очень гибкой природе.С Prince2 результаты четко определены, и для каждого проекта есть бизнес-обоснование.
Зарегистрируйтесь и наслаждайтесь Бесплатным управлением проектами и отслеживанием времени для вас и вашей команды!
Для этого метода управления проектами также характерны продукты, которые доставляются вовремя и в пределах сметы. Роли заранее определены до начала проекта, и каждый участник проекта хорошо осознает свою ответственность за успешное выполнение проекта.
5. PERT
PERT расшифровывается как Project Evaluation Review Technique; в более ранней публикации мы заявили, что чаще всего он сочетается с методом критического пути. Этот метод управления проектами является любимым для большинства производственных компаний, поскольку он учитывает время, необходимое для выполнения задачи. Время является важным фактором в управлении проектом, так как оно также определяет бюджет проекта.
6. Адаптивная структура проекта
Роберт К. Высоцкий является авторитетом в области адаптивного управления проектами, и в своей книге Adaptive Project Framework: Managing Complexity in Face of Uncertainty он говорит об открытии новых приложений, для которых традиционный линейный подход может не подходить. .Он идет дальше, чтобы определить «… трудность определения полных требований в начале проекта» как главную причину, по которой современные проекты не соответствуют требованиям традиционного подхода к управлению проектами.
Решение этой дилеммы заключается в адаптивной структуре проекта; процесс, который был создан из необходимости адаптироваться к постоянно меняющимся фазам проекта.
7. Экстремальное программирование (XP)
Эта методология, которая также имеет свои корни в гибкой среде, была разработана в 1990-х годах Кентом Блэком.Основная цель этого метода короткого жизненного цикла — улучшение качества продукции и удовлетворение запросов клиентов. Его характеристики и принципы делают команду управления проектами, которая стремится к совершенству в процессе разработки. В своей книге «Объяснение экстремального программирования» Кент объясняет, что методология становится все более заметной, потому что «… XP особенно хорошо подходит для помощи небольшой команде разработчиков программного обеспечения».
8. Канбан
Процесс управления проектами Канбан устраняет спринты и вехи, которые приписываются схватке и традиционным методам управления проектами соответственно.Что вы найдете, так это более наглядный подход к управлению временем, масштабом проекта и бюджетом; эти 3 фактора определяют успех любого проекта.
Канбан, метод управления проектами с бережливым планированием, был разработан японской корпорацией Toyota, основанной в 1940-х годах. Идея Канбана — это непрерывная доставка, особенно в сочетании с методологией схватки. Он использует систему визуальных подсказок, которые позволяют команде проекта узнать, что ожидается от задач в рамках проекта в отношении количества и качества, а также того, когда задачи должны быть выполнены.
Выбор правильного метода управления проектом
Описанные выше методы управления проектами ни в коем случае не являются исчерпывающими; Есть довольно много ответвлений и гибридов, которые дали фантастические результаты. Проблема, однако, заключается в определении подходящего подхода для управления вашими проектами, потому что эти подходы служат в качестве схем, а используемый подход может означать разницу между неудачей или успехом проекта, поэтому вот несколько моментов, которые помогут вам.
- Узнайте у членов команды, что работало в прошлом — это поможет сузить круг вариантов
, которые вам нужно сделать. - Четко определите потребности или ожидания ваших клиентов. Помните, что требования могут быть фиксированными или динамическими.
- Обозначьте цели организации, учитывая также стоимость проекта.
- Обдумайте структуру команды — они виртуальные или физические? Часть работы передается на аутсорсинг?
- Наконец, вам не нужно выбирать универсальный подход; имейте в виду, что совершенно приемлемо выбирать различные положительные элементы из всех отдельных методологий, чтобы создать процесс, который мог бы прекрасно работать для вашей команды.
Методологии, методы и основы управления проектами
Успешное завершение проектов можно обеспечить различными способами. Но лучшие и самые популярные методологии, методы и основы управления проектами постоянно меняются. Все время появляются новые концепции. За всеми успешными проектами стоит целый ряд методов, инструментов и техник. Фактически, как специалист по управлению проектами, вы, вероятно, сможете использовать в своей жизни больше, чем один из них.
Однако методологии, методы и рамки управления проектами предназначены не только для руководителей проектов. Вся команда проекта должна понимать их использование, цель и основные термины. Это гарантирует, что весь процесс пройдет гладко, независимо от вашего выбора. Помните, что нет одинаковых проектов или команд. Методология или структура, которые сработали для кого-то другого, могут не подойти вам. Вот почему лучше всего проверить, как вы можете использовать их в своих проектах. Если вы управляете одной или несколькими небольшими командами и ищете наиболее часто используемый инструмент управления проектами для веб-проектов, мы написали эту статью с обзором простых инструментов управления проектами.
Мы создали это обширное руководство для начинающих, чтобы помочь вам выбрать методологии, методы и рамки управления проектами, которые будут соответствовать всем вашим потребностям в соответствии с вашей отраслью и целями проекта. В последней части статьи мы упомянули некоторые методы управления проектами, методологии, структуры, руководства и другие подходы, которые иногда обсуждаются в контексте управления проектами, но неправильно обозначены как методологии управления проектами. Мы также обратились к нескольким экспертам по управлению проектами, чтобы поделиться с вами мнением о них.
Мы разделили статью на три отдельных раздела. Вы можете щелкнуть по каждому из них, чтобы сразу перейти к нему:
Определения
Методы, методологии и основы управления проектами
А как насчет Agile, Scrum и других?
Определения
Разница между методологиями, фреймворками и методами всегда была предметом горячих споров, даже в таких областях, как исследования и архитектура.Чтобы помочь вам понять эти термины, давайте сначала взглянем на следующие определения:
Метод
Словарь Мерриам-Вебстера определяет метод как «процедуру или процесс для достижения цели: например, систематическую процедуру, технику или способ исследования, применяемые или относящиеся к определенной дисциплине, или систематический план, которого следует придерживаться при представлении материала для обучения. ».
Другими словами, метод относится к отдельному действию, инструменту, технике, процессу или способу выполнения чего-либо.
Методология
Еще раз взглянув на Словарь Мерриама-Вебстера на предмет последовательности, можно сказать, что методология — это «совокупность методов, правил и постулатов, применяемых в дисциплине; конкретная процедура или набор процедур ».
По сути, методология — это совокупность методов, практик, процессов, техник, процедур и правил. В управлении проектами методологии являются конкретными, строгими и обычно содержат серию шагов и действий для каждой фазы жизненного цикла проекта.Это определенные подходы, которые показывают нам, какие именно шаги нужно предпринять дальше, мотивацию каждого шага и то, как следует выполнять этап проекта.
Рамка
Согласно Словарю Мерриам-Вебстера, структура — это «совокупность методов, правил и постулатов, используемых дисциплиной: конкретная процедура или набор процедур» или «анализ принципов или процедур исследования в конкретной области. ».
Точно так же Бизнес-словарь определяет структуру как «общий обзор, схему или скелет взаимосвязанных элементов, который поддерживает конкретный подход к конкретной цели и служит руководством, которое может быть изменено по мере необходимости путем добавления или удаления элементов». .
В случае управления проектами, структура — это обзор того, как должны быть реализованы ее руководящие принципы. В то время как методологии предлагают строгие принципы и практики для выполнения проекта, структуры более гибкие, поскольку они могут адаптироваться к меняющимся ситуациям или к собственным потребностям компании, оставляя место для ответственного лица, чтобы найти лучший способ завершения проекта. Вы также можете добавить новые существующие методы или практики в структуру, с которой вы работаете.
Методы, методологии и основы управления проектами
PRINCE2 (ПРОЕКТЫ В контролируемых средах)
PRINCE2 — это метод управления проектами, который требует разделения ответственности за проект между советом директоров и менеджером проекта.В то время как правление отвечает за привлечение необходимых ресурсов и сосредоточение внимания на бизнес-обосновании, менеджер проекта выполняет все задачи и управляет командой на ежедневной основе.
PRINCE2 предлагает лучший контроль над вашими ресурсами, улучшенное управление рисками, определенные командные роли и обязанности, упор на конечного пользователя и конечный продукт, последовательный подход к анализу циклов, организованных планов и контролируемых этапов управления проектами. Этот метод управления проектами содержит все необходимые инструменты, практики и процедуры, которые положительно повлияют на проект от начала до конца.
Подходит для: Строительство и архитектура, маркетинг, но работает и в других отраслях.
Используемые инструменты: Microsoft Project, in-STEP BLUE, P2ware
Ресурсы:
Информация о сертификации PRINCE2
PRINCE2 за 100 секунд
Ключевые преимущества PRINCE2
Управление успешными проектами с PRINCE2
Управление проектами критической цепочки (CCPM)
Метод управления проектами критической цепи фокусируется на сроках проекта, сокращении оценок продолжительности, вычислении буферов, уведомлении о завершении деятельности, измерении прогресса и установке приоритетов.Любая проектная группа, использующая CCPM, начинает с создания первоначального расписания проекта. Затем, в зависимости от доступности ресурсов, они устанавливают зависимости задач и действия, которые должны быть выполнены, чтобы остальная часть проекта могла быть успешно завершена без каких-либо задержек. Это «Критическая цепь». Это самый длинный путь до конца проекта после того, как вы выполнили выравнивание ресурсов. Все задачи, входящие в его состав, требуют специальных резервов ресурсов и планов резервного копирования, чтобы ничто не откладывало их.Расписание, составленное с использованием этого метода, позволяет размещать свободные временные интервалы (известные как буферы проекта) между этими важными (критическими) задачами, чтобы сроки соблюдались эффективно.
«CCPM включает в себя много передовой практики, но основополагающая разработка касается управления изменчивостью с использованием агрегированных буферов и использования инструмента сигнализации управления (управление буфером). Эта разработка по управлению проектами является естественным продолжением разработок в области управления системами на основе потоков в производстве, таких как Kanban и Drum-Buffer-Rope.», — отмечает Рой Страттон, автор книги« Теория и практика управления проектами критических цепочек ».
Подходит для: Производство, строительство.
Используемые инструменты: Aurora CCPM, A-dato, ProChain
Ресурсы:
Сводка видео — Управление проектами критической цепочки
Теория и практика управления проектами критической цепочки, Рой Стрэттон
Метод критического пути (CPM)
Метод критического пути может использоваться для определения приоритета деятельности проекта, переназначения командных ролей, оценки рисков и соответствующего распределения ресурсов.Этот метод помогает группам с легкостью определять вехи, зависимости задач и сроки. Для начала создадим модель проекта и добавим четыре элемента:
- Список задач, которые необходимо выполнить
- Продолжительность каждой задачи
- Зависимости между действиями
- Конечная точка задачи
Критический путь — это последовательность критических действий (зависимых или плавающих) в проекте, которая определяет самую длинную последовательность задач, которые должны быть выполнены вовремя, чтобы проект уложился в срок.Критические действия не всегда являются самыми важными, сложными или дорогостоящими в проекте. Задача считается «критической», если ее задержка влияет на время завершения проекта.
Система автоматически рассчитает и укажет, какие действия являются «критическими», а какие не зависят от их продолжительности, и как она изменяется с течением времени. Метод критического пути основан на представлении о том, что работа над новой задачей не может начаться, пока вы не выполните свои предыдущие обязанности. Таким образом, CPM помогает команде быстрее выполнять работу, правильно и равномерно распределять ресурсы и выявлять узкие места, чтобы вовремя избежать дальнейших проблем.
Подходит для: Производство, наука, строительство и архитектура, инженерия, но также может быть адаптирована для других отраслей.
Используемые инструменты: Lucidchart, Microsoft Project, Smartsheet
Ресурсы:
Что такое критический путь в управлении проектами
Метод критического пути (CPM) — обучающее видео
Изучите критический путь PMP за 17 минут без изменений
Адаптивная платформа проекта (APF)
Адаптивная структура проекта (APF) заимствует некоторые элементы и процессы из других методологий, методов и структур управления проектами.Вы можете использовать их в своих проектах индивидуально. APF отличает способ создания проекта. Сначала принимается решение выбрать наиболее подходящий существующий подход и адаптировать его к собственному проекту.
Затем проекты делятся на меньшие группы задач и выполняются разными командами. Последние отвечают за оценку результатов каждой проектной группы и определение возможных способов повышения эффективности. Заказчик также участвует в процессе разработки проекта, чтобы быть уверенным в том, что он полностью осведомлен о вносимых в него изменениях.
Нет похожих проектов. Вот почему эта структура помогает вам адаптировать проект к подходу и уравновесить его с вашими собственными целями, выявленными рисками и изменяющимися требованиями клиентов.
Подходит для: Информационные технологии, охрана окружающей среды.
Используемые инструменты: Paymo
Ресурсы:
Введение в адаптивную структуру проекта: управление сложностью в условиях неопределенности, Роберт К.Высоцкий
Adaptive Project Framework: новый уровень гибкой разработки
Экстремальный менеджмент проектов (XPM)
«Важно отметить, что eXtreme Project Management — это не методология. Скорее, это гибкая структура управления проектами и набор методов лидерства для создания ценности в условиях нестабильности ». — говорит Дуг ДеКарло, автор книги «Экстремальное управление проектами: использование лидерства, принципов и инструментов для создания ценности в условиях нестабильности».
Работа с XPM выполняется в быстром темпе и с несколькими поворотами и поворотами.Экстремальное управление проектами требуется проектам с непредсказуемым развитием или проектами, которые претерпевают значительно больше изменений, чем традиционные проекты. Дуг также заявляет, что «Он применяется в сложных проектных средах, когда:
- Отказ не вариант
- Скорость, инновации и прибыльность в счетах
- Качество жизни важно ».
В XPM планы перестали быть надежными. Ситуация может меняться каждую секунду. Члены проектной группы могут свободно вносить свой вклад в проект или задачу, за которую они несут полную ответственность.Произойдет радикальный сдвиг в том, как ваша команда думает и относится к проекту.
Хаотичные потребности и задачи клиентов, спонтанность, неуверенность и меньший контроль над проектами теперь стали обычным явлением, к которому им придется адаптироваться. Это потому, что в основе XPM лежит вера в то, что работать над более сложными проектами можно только методом проб и ошибок. Таким образом, любая непредвиденная ошибка или баг будет исправлена на ходу.
Подходит для: Разработка программного обеспечения.
Ресурсы:
Экстремальное управление проектами: использование лидерства, принципов и инструментов для создания ценности перед лицом волатильности, Дуглас ДеКарло
XPM — от идеи до реализации
PRiSM (Проекты, использующие устойчивые методы)
Как вам нравится экологическое управление проектами? Если вы ищете надежный способ управления своими проектами, попробуйте PRiSM.
Эта методология управления проектами основана на факторах окружающей среды и их влиянии на развитие процесса управления проектами. Это помогает проектным командам устранять загрязнения или отходы и экономить энергию. Поскольку PRiSM также занимается вопросами прав человека, трудовых ценностей и предотвращения коррупции, это гораздо больше, чем просто подход к тому, как вы обращаетесь с природой.
Подходит для: Строительство, архитектура, ландшафт и любые другие работы, которые могут повлиять на окружающую среду.
Ресурсы:
Обзор управления проектами экологичности / устойчивого развития
Справочное руководство GPM® по устойчивому развитию в управлении проектами
Управление реализацией выгод (BRM)
Управление реализацией выгод — это структура, которая гарантирует заинтересованным сторонам, что проект достиг желаемых выгод. Проекты завершаются, когда реализованы все преимущества.
«Надежное управление преимуществами — критически важный аспект любой программы.Многие программы предоставляют большие возможности, но не могут реализовать преимущества из-за недостаточности или отсутствия мер, обеспечивающих реализацию преимуществ. Управление реализацией выгод относится к методам, инструментам и образцу мышления, которые направлены на обеспечение того, чтобы бизнес-инициативы приносили ожидаемые бизнес-выгоды. Это дисциплина, которая направлена на то, чтобы желаемые изменения в бизнесе или результаты политики были четко определены, измеримы и служат убедительным аргументом в пользу инвестиций. В конечном итоге это гарантирует, что изменения или результаты политики действительно достигнуты.- говорит Алекс Антар, автор книги «Основное руководство по управлению реализацией выгод: искусство BRM».
BRM требует найти все преимущества в начале проекта и убедиться, что все задачи выполняются и оцениваются, чтобы помочь бизнесу их достичь. Менеджер по изменению бизнеса помогает в этом владельцу льгот. В то время как последний должен определить выгоды для бизнеса и установить методы их обработки, менеджер по изменениям в бизнесе отвечает за оценку прогресса проекта в достижении этих целей.
Конечной целью остается повышение окупаемости инвестиций на основе стратегии организации.
BRM выполняет проект в 3 этапа:
- Определите преимущества: определение и категоризация выгод бизнеса или проекта, а также людей, которые будут нести ответственность за их обработку
- Осуществление управления выгодами: надзор за управлением выгодами, чтобы избежать рисков и найти новые возможности
- Устойчивая реализация преимуществ: отслеживание эффективности преимуществ проекта и обеспечение их ценности даже после реализации
Подходит для: Информационных технологий, но подходит для любой другой работы, ориентированной на получение выгоды.
Ресурсы:
Структура управления реализацией выгод, объясненная в PMI
Управление реализацией выгод: стратегическая ценность портфелей, программ и проектов, Карлос Эдуардо Мартинс Серра
Основное руководство по управлению реализацией выгод: искусство BRM, Алекс Антар
Кристалл
Мы связались с доктором Алистером Кокберном, разработчиком методологии Crystal и одним из инициаторов Agile Movement, чтобы он кратко изложил эту методологию: «Crystal — это семейство связанных гибких методологий, основанных на идеях. что:
- Ни одна методология не подходит для всех проектов
- Они должны быть настроены участниками проекта под себя,
- Они должны быть легкими и ориентированными на общение.
Три элемента, общих для всех членов семейства Crystal, — это частые роды, тесное общение и улучшение рефлексии. Crystal Clear, Yellow и Orange использовались в проектах размером от трех до 50 человек, неформальных проектах и проектах ISO 9001 ».
При такой гибкой методологии люди являются наиболее важной частью проекта. Все процессы должны быть адаптированы к их потребностям. В то время как книги, описывающие Crystal, предоставляют ресурсы для детальной настройки методов вашей команды, в них нет специально необходимых методов или инструментов.То, как вы используете Crystal, полностью зависит от вашего проекта и команды.
Например, Crystal Clear обычно используется для проектов, которыми занимаются небольшие группы или те, кто работает из одного места. Crystal Sapphire, с другой стороны, предпочтительнее для крупных проектов, которые могут представлять опасность для жизни человека. Благодаря этой способности адаптироваться к различным типам проектов Crystal фокусируется на 6 основных элементах: людях, взаимодействии, сообществе, общении, навыках и талантах.
Члены семейства методов имеют цветовую кодировку в зависимости от того, сколько людей координируются (прозрачный, желтый, оранжевый, красный и т. Д.).В книгах описано несколько версий Crystal Clear, Yellow и Orange.
Подходит для: Разработка программного обеспечения.
Ресурсы:
Crystal Clear: человеческая методология для небольших команд: человеческая методология для небольших команд, Алистер Кокберн
А как насчет Agile, Scrum и других?
Существуют и другие популярные методы, методологии, структуры, подходы, руководства и т. Д., Которые не являются методологиями, методами или структурами управления проектами.
Основная проблема заключается в том, что люди не понимают разницы между проектом и продуктом. Они часто используются как взаимозаменяемые, но в проектной работе важно точно понимать, что они из себя представляют.
Проект — это разовое мероприятие с целью создания продукта или услуги. У него есть дата начала и окончания, а также четко определенный результат. Обычно он проходит пять этапов — инициирование, планирование, исполнение, мониторинг и контроль и закрытие.
Продукт может быть чем угодно: от физического продукта до программного обеспечения или услуги, удовлетворяющей потребности группы пользователей. Он проходит через жизненный цикл, разрабатывается и выводится на рынок, получает признание до тех пор, пока не созреет, и списывается, когда он больше не нужен.
В отличие от проекта, продукт — это не временное занятие. Он развивается и адаптируется к потребностям текущего пользователя, чтобы доказать свою полезность и избежать выхода на пенсию. Следовательно, он может включать несколько проектов, направленных на его поддержание, улучшение или диверсификацию.
Короче говоря, проект — это временная инициатива по созданию продукта, а продукт — это то, что приносит пользу в результате проекта.
Мы уже обсуждали разницу между менеджерами проектов и продуктами, если вы хотите взглянуть на их основные обязанности.
Проворный
«Как и его название, Agile означает способность адаптироваться — способность изящно адаптироваться к быстро меняющимся потребностям клиентов», — говорит Камлеш Равлани, Agile Coach и Scrum-тренер в Agile For Growth.
Сначала мы должны различать понятия «гибкость» и «гибкость». В то время как «гибкость» относится к способности быстро реагировать на изменения, Agile — это образ мышления или набор принципов и практик, которые изначально были упомянуты в Agile Manifesto. Он лучше всего подходит для продуктов и инициатив, которые претерпевают разнообразные изменения в процессе своего развития.
Agile-разработка основана на коротких циклах доставки (известных как спринты), тесно связанных с регулярными сессиями обратной связи. Чтобы процесс был гибким, рабочая среда должна способствовать непрерывному и интенсивному сотрудничеству с коллегами и клиентами.Сильная коммуникация способствует регулярной обратной связи, которая позволяет вам изменять эволюцию продукта во время каждого спринта. Затем заинтересованные стороны рассмотрят каждый шаг и предложат соответствующие улучшения.
Используя эти принципы, вся команда берет на себя ответственность за разработку и успех продукта. Вот почему каждый человек отвечает за задачи, которые способствуют планированию, разработке и реализации проекта. Agile-команды не используют четко установленные дорожные карты и не сосредотачиваются на мониторинге, потому что весь этап планирования является повторяющимся и гибким.Все цели определены перед началом работы, но вы всегда можете изменить конечные или окончательные результаты.
Подходит для: Разработка программного обеспечения.
Используемые инструменты: Jira, Agile Manager, Planning Poker
Ресурсы:
Масштабируемая среда Agile
Манифест для гибкой разработки программного обеспечения
Блог Майка Кона по Agile и Scrum для индустрии программного обеспечения
Глоссарий Agile
Схватка
«Фреймворк Scrum используется в основном для разработки продуктов или программного обеспечения.Эта методология хороша тем, что вы можете использовать Scrum не только для разработки лучшего программного обеспечения, но и, например, для управления маркетинговым отделом медиа-компании или создания лучшего мобильного телефона.
Scrum может быть даже полезен при написании книги. Этот фреймворк не просто очень эффективен. Это продуктивный и творческий способ создания ценных конечных продуктов. Он подходит для сложных сред, где командам необходимо быстро реагировать и адаптироваться к новым ситуациям в системе.Это не очень подходящая структура для простой, очевидной, легкой и предсказуемой среды ». — отмечает Луис Гонсалвес, консультант по вопросам управления и основатель Evolution4All.
Через структуру Scrum небольшие, кросс-функциональные и самоорганизующиеся группы работают в тесном контакте с владельцем продукта. Последний отвечает за развитие продукта и, в конечном итоге, за успех. Также есть Скрам-мастер, который обслуживает команду, устраняя любые проблемы во время выполнения проекта, проводя встречи и готовя бэклог продукта для следующих спринтов.
Эта структура разделена на более мелкие циклы (известные как спринты) — обычно это временной интервал в 2 недели. Во время ежедневных встреч команда анализирует, что они сделали и над чем будут работать в течение дня во время ежедневных встреч, а также раскрывает трудности, с которыми они столкнулись или с которыми могут столкнуться в будущем. Иногда команды предпочитают проводить эту встречу еженедельно.
Подходит для: Разработка программного обеспечения.
Используемые инструменты: OrangeScrum, Scrumwise, Axosoft
Ресурсы:
Сертификаты Scrum
Блог Натали Уорнерт: Признания скрам-мастера
Скрам: искусство делать двойную работу за половину времени, Джефф Сазерленд
Канбан
Канбан — это метод производства на основе вытягивания, который был принят ИТ-командами в последние годы.Применительно к управлению проектами это метод и визуальный инструмент, который дает вам быстрое представление обо всех мероприятиях проекта и их развитии.
Типичный подход заключается в использовании физической или виртуальной доски с тремя столбцами по умолчанию (To Do, In progress, Done). Задачи в форме карточек затем перемещаются из одного столбца в другой, когда работа будет выполнена или пока они не будут официально завершены и утверждены.
Kanban фокусируется на непрерывной доставке и способности всей группы эффективно сотрудничать.Это также может помочь вам лучше организовать рабочий процесс и выявить узкие места до возникновения проблем.
Подходит для: разработки программного обеспечения, но он также хорошо работает для любых других отраслей, таких как цифровой маркетинг, архитектура и строительство, право, образование, поддержка, дизайн и даже в личных целях.
Используемые инструменты: Инструмент Канбан, Канбанери
Ресурсы:
12 примеров канбан-досок для начинающих
Обучающее видео по созданию физического и личного Канбана
Скрамбан
Если вы хотите получить лучшее от Scrum и Kanban одновременно, попробуйте Scrumban.Это гибридное альтернативное решение для команд, которые хотят перейти со Scrum на Kanban. Вот почему он сочетает в себе ежедневные встречи и демонстрации Scrum с ограничениями Kanban WIP (Work in Progress) и непрерывным рабочим процессом.
Scrumban используется для разработки программного обеспечения и продуктов, которые часто прерываются или сталкиваются с регулярными изменениями или обновлениями, когда дело касается действий и их приоритетов. Планирование выполняется только по требованию, а оценки не являются обязательными. Подобно Канбану, это визуальный метод, использующий доску и вытягивающую систему для управления задачами.Использование спринтов в Scrumban остается очень обсуждаемой темой. Когда спринты не используются во время проекта, изменения могут произойти в любое время, пока есть доступные ресурсы.
Подходит для: Разработка программного обеспечения, маркетинг, операции, производственная поддержка, обслуживание.
Используемые инструменты: GetScrumban, Kanban Tool, SwiftKanban
Ресурсы:
Эволюция Scrumban [R]: получение максимальной отдачи от Agile, Scrum и Lean Kanban, Аджай Редди
Scrumban — Очерки канбан-систем для экономичной разработки программного обеспечения, Кори Ладас
Введение в Scrumban — обучающее видео
Экстремальное программирование (XP)
Эта среда Agile была создана, чтобы помочь вам улучшить общее качество гибкой разработки программного обеспечения.«Каждой agile-команде следует рассмотреть возможность использования технических приемов, составляющих часть экстремального программирования». — говорит Майк Кон из Mountain Goat Software. Будучи разработанной для разработки программного обеспечения, XP поставляется с набором инженерных принципов, которые вы можете навязать для улучшения качества вашего продукта, таких как разработка через тестирование, модульное и автоматическое тестирование, непрерывная интеграция, парное программирование, рефакторинг и многое другое.
Обычно команды экстремального программирования работают в итерациях, которые занимают одну или две недели (в зависимости от спецификации проекта).Как и Scrum, он полагается на быстрые спринты, постоянные релизы и частое сотрудничество с заинтересованными сторонами для повышения уровня производительности. XP может помочь вам избежать выгорания сотрудников и повысить качество вашей работы. Результаты предоставляются только тогда, когда они необходимы, и не зависят от установленного срока, что помогает вам эффективно удовлетворять потребности клиентов и повышать их удовлетворенность.
Подходит для: Разработка программного обеспечения.
Используемые инструменты: Targetprocess
Ресурсы:
Extreme Programming (XP) — обучающее видео от Udacity
Нежное введение в экстремальное программирование
Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series), Кент Бек с Синтией Андрес
Руководство PMI PMBOK®
Руководство PMBOK®PMI отличается от других способов управления проектами, упомянутых в этом списке.Это набор стандартов или, проще говоря, совокупность знаний, руководство, содержащее структурированную информацию по управлению проектами. Созданный Институтом управления проектами (PMI), он делит вашу работу над проектом на пять отдельных, но связанных групп процессов:
- Инициирование: Проведение первых встреч с клиентом и получение разрешения на начало работы
- Планирование: постановка целей, определение объема и создание плана проекта
- Выполнение: Завершение работы над задачами и подготовка результатов
- Мониторинг: наблюдение за развитием проекта и анализ его эффективности
- Закрытие: завершение всех контрактов и предоставление окончательных результатов
PMI PMBOK® Guide используется в основном в США, Канаде и на Ближнем Востоке.Он устанавливает основу для процессов и методов управления проектами. Его статус как методологии спорен, потому что это действительно справочное руководство, устанавливающее универсальные критерии управления проектами, а не реальная методология.
В ходе этой дискуссии Дмитрий Нижебецкий из PM Basics отмечает, что «Подход, описанный в руководстве PMI PMBOK® Guide, не является методологией. В реальной жизни реализовать такой подход в полной мере было бы неэффективно. Реальная ценность заключается в видении PMI объема управления проектом и обязанностей менеджера проекта.В нем объясняется, что вам может понадобиться, чтобы вести проект. Он научит вас выбирать подходящие инструменты и методы для текущего проекта. Более того, он показывает, что нужно для интеграции всех процессов вместе ».
Подходит для: Строительство и архитектура, финансы, консалтинг, управление, обеспечение качества и многое другое.
Используемые инструменты: Easy Project, OpenProject, Microsoft Project
Ресурсы:
Руководство и стандарты PMBOK®
Что такое PMI®? — Академия Paymo
Постное
Lean изначально был методом производства продукта и до сих пор используется для разработки продукта.Если вы хотите снизить уровень потерь в проекте и в конечном итоге полностью их устранить, попробуйте Lean. Это помогает доставить очень ценные продукты за счет использования меньшего количества людей и ресурсов за гораздо меньшее время. Упор на желания клиента, устранение проблем и возможных рисков или опасностей, а также частое улучшение систем могут сократить потери времени и затрат.
Использование бережливого производства помогает небольшим командам прогрессировать и добиваться более высоких результатов за короткий промежуток времени, без чрезмерных затрат на материалы.При использовании этого метода основное внимание уделяется доставке ценных продуктов и увеличению прибыли организации с меньшими затратами ресурсов. Lean также помогает компаниям быстро адаптироваться к постоянно меняющимся стандартам, потребностям и действиям клиентов.
Подходит для: Производство, строительство и любые другие ситуации, в которых основной задачей является устранение отходов.
Используемые инструменты: LeanKit, Kanban Tool, Kanbanize
Ресурсы:
Институт бережливого строительства
Как внедрить бережливое производство, Лонни Уилсон
Путь Toyota: 14 принципов управления от величайшего производителя в мире, Джеффри Лайкер
Шесть сигм
Six Sigma — это подход и методология устранения дефектов и повышения качества ваших процессов и результатов.Его принципы также могут быть применены к управлению проектами и разработке продуктов. Используя контроль качества, Six Sigma (6σ) подчеркивает необходимость минимизировать ошибки, дефекты и ошибки до тех пор, пока они не перестанут влиять на проект или его результаты. Прежде чем возникнут дальнейшие проблемы, необходимо проанализировать существующие данные и отчеты об ошибках. Это поможет вам найти несоответствия проекта, которые не соответствуют первоначально утвержденным требованиям к продукту.
Томас Пиздек, автор «Руководства по шести сигмам», отмечает: «В отличие от большинства методологий управления проектами, преподаваемых на курсах управления в университетах,« Шесть сигм »не сосредотачиваются на чистой прибыли.Скорее, он рассматривает чистую прибыль как результат работы, проделанной внутри организации для добавления ценности. Этот подход учит людей, как анализировать и улучшать процессы, чтобы лучше работать над добавлением ценности. Проекты «Шесть сигм» — это основной способ достижения анализа и улучшения процессов ».
С «Шесть сигм» любое решение принимается на основе имеющихся данных и статистики. Цель состоит в том, чтобы производить эффективные, однородные и бездефектные конечные продукты. Для этого «Шесть сигм» использует шесть отдельных шагов:
- Определите: установление требований клиента и целей проекта, назначение членов команды и руководителей, а также установление руководящих принципов проекта и правил группы
- Мера: сбор данных о производительности, определение показателей процесса и результатов, а также определение ряда причин и их результатов
- Анализ: оценка и сравнение существующих данных и определение взаимосвязи между причинами и следствиями
- Улучшение: постоянно оптимизирует процессы и находит новые решения существующих или возможных проблем
- Контроль: создание долгосрочного плана контроля для контроля всех процессов
- Synergize: делится результатами команды и приобретенными знаниями со всей организацией, чтобы использовать их в будущих проектах
Подходит для: Производство, проектирование, здравоохранение, исследование рынка и любая другая ситуация, когда основной целью является предоставление высококачественного продукта.
Используемые инструменты: KPI Fire, XMind, Microsoft Project
Ресурсы:
Путь шести сигм: как GE, Motorola и другие ведущие компании повышают свою эффективность, Питер С. Панде, Роберт П. Нойман, Роланд Р. Кавана
Руководство по шести сигмам, Томас Пиздек
Простое руководство по решению проблем с использованием метода Six Sigma DMAIC — Creately
Бережливое производство и шесть сигм
Lean Six Sigma — это комбинация Lean и Six Sigma, направленная на сокращение потерь и дефектов одновременно.Этот гибридный результат позволяет создавать более эффективные проекты, отвечающие требованиям клиентов, с меньшими ресурсами и меньшим бюджетом. Команды сотрудничают, чтобы устранить потери, когда дело доходит до дефектов, времени ожидания, запасов, перепроизводства, неиспользованных кадров, транспортировки, движения и дополнительной обработки.
Следовательно, использование «бережливого производства и шести сигм» поддерживает одновременное развитие вашего бизнеса, продуктов и людей. Внедрение этой интеграции может изменить способ, которым вся ваша компания обрабатывает свои проекты, видит дефекты и относится к качеству.
Подходит для: Производство, транспортировка и логистика, обслуживание и любые другие ситуации, когда целью является устранение отходов и создание большей стоимости.
Используемые инструменты: KPI Fire, TRACtion, XMind
Ресурсы:
Что такое бережливое производство и шесть сигм, Майкл Л. Джордж, Дэвид Роулендс, Билл Кастл
Институт бережливого производства и шести сигм
Водопад
Waterfall — это традиционный подход, который разделяет процесс разработки продукта на группы связанных задач, которые необходимо выполнить перед переходом к следующей группе или этапу.Следовательно, это требует обширного планирования. Выполнение всех шагов до того, как вы начнете работать над разработкой продукта, поможет свести к минимуму опасности и дальнейшие ошибки. Благодаря этому ваша команда всегда знает, над чем им следует работать дальше и чего ожидать в будущем.
В Waterfall обычно используются 5 основных фаз:
- Требования: выяснение и анализ потребностей клиента и того, что должен делать конечный продукт
- Дизайн: Выбор правильной технологии и создание макетов продукта и детальной архитектуры
- Внедрение: решение проблем, реализация решений и выполнение задач
- Проверка (тестирование): выяснение соответствия продукта установленным требованиям к рабочим характеристикам и обеспечение качества
- Техническое обслуживание: исправление ошибок и недочетов, чтобы продукт можно было легко использовать без перебоев
Специалисты Waterfall считают, что уделение большего количества времени и усилий первым этапам разработки продукта может предотвратить возникновение рисков и сэкономить вам часы времени на обслуживание.Waterfall также предоставляет четкие и подробные сроки и затраты. Это поможет вашей команде стать более продуктивной.
Обратной стороной Waterfall является то, что он довольно устарел для требований современной разработки программного обеспечения. Написание кода и одновременное выполнение контроля качества довольно сложно, поскольку каждый этап этой методологии зависит от предыдущего и никакие действия не перекрываются. В Waterfall командам приходится ждать, пока те, кто отвечает за предыдущие шаги, закончат свою работу.Если последние опоздают, все остальные задачи могут быть отложены.
Подходит для: Строительство, производство и производство средств массовой информации.
Ресурсы:
Waterfall Process — Обучающее видео от Udacity
Понимание плюсов и минусов водопадной модели разработки программного обеспечения
Быстрая разработка приложений (RAD)
Быстро меняющиеся рынки побуждают организации активизировать процессы доставки продукции, чтобы не отставать от конкурентов.Итерационный процесс Rapid Applications Development был создан именно для этого: ускорить разработку и доставку высококачественных продуктов.
RAD был первым процессом разработки программного обеспечения, решившим то, чего не могли решить предыдущие процессы. Для полной разработки приложений требовалось много времени. Их требования так часто менялись перед завершением, что иногда становились нестабильными и непригодными для использования. Благодаря подходу RAD приложения можно было разрабатывать вовремя и в рамках бюджета.
Несмотря на быстрый темп, метод RAD обеспечивает правильную работу всех основных функций.Он помогает создавать продукты на основе объектно-ориентированного программирования и потребностей пользователей с точки зрения пользовательского интерфейса. Прототипы используются вместо любых задокументированных проектных спецификаций. Перед началом разработки продукта очень мало (иногда вообще не проводится) планирования, с упором на сам процесс разработки и прототипирования.
Подходит для: Разработка программного обеспечения.
Используемые инструменты: OutSystems, FileMaker, Mendix, Nintex, Salesforce Lightning, ViewFlux, InVision
Ресурсы:
Rapid Development: Taming Wild Software Schedules, Стив МакКоннелл
Быстрая разработка приложений, Джеймс Мартин
Метод разработки динамических систем (DSDM)
Метод разработки динамических систем впервые был использован как метод разработки программного обеспечения.Он был создан в 1994 году (до официального Agile Manifesto) после того, как менеджеры проектов, которые использовали дорогостоящий подход быстрой разработки приложений, захотели улучшить структуру своей работы.
DSDM принес им большую организованность, оперативность, надежность, проактивность и итеративный подход к задачам и проектам. В методе MoSCoW также отдается приоритет расписанию и качеству над функциональностью (должно быть, должно быть, могло быть и не будет). Этот метод использует взаимодействие с заинтересованными сторонами для определения порядка и важности их требований.
DSDM четко определяет все роли, обязанности и методы коммуникации для членов команды. Этот метод также поможет вам установить стратегические цели и получить ценные преимущества за меньшее время без превышения вашего бюджета. Эта философия позволяет командам сохранять фокус и достигать целей проекта, если они следуют восьми основным принципам:
- Ориентация на потребности бизнеса
- Своевременная доставка
- Сотрудничество
- Качество не компромисс
- Построить поэтапно на прочном фундаменте
- Итерационная разработка
- Непрерывная и четкая связь
- Продемонстрировать контроль
Подходит для: Разработка программного обеспечения.
Ресурсы:
DSDM: Метод разработки динамических систем: метод на практике, Дженнифер Стэплтон, Питер Констебль
DSDM: Разработка, ориентированная на бизнес, консорциумом DSDM, Дженнифер Стэплтон
Рациональный унифицированный процесс (RUP)
Rational Unified Process — это структура процессов, которая, как и экстремальное программирование, предоставляет соответствующие передовые методы, стандарты, шаблоны и образцы для разработки программного обеспечения. Он также предлагает более организованный способ распределения действий и ролей.Целью этого процесса является разработка высококачественного программного обеспечения, которое своевременно и в рамках бюджета удовлетворяет требованиям клиентов и потребностям будущих пользователей.
RUP поддерживает продуктивность команды, предлагая всем членам группы доступ к области знаний, содержащей всю информацию и инструменты, необходимые для помощи в выполнении задач разработки.
Rational Unified Process не имеет фиксированного набора процессов, которому вы должны следовать любой ценой. Его можно адаптировать и настроить под требования любого проекта.Каждый этап этого процесса разделен на отдельные итерации, которые необходимо выполнить перед переходом к следующему этапу. RUP выполняет проект в четыре этапа:
- Начало: создание идеи, лежащей в основе проекта, и проверка того, есть ли у вас необходимые ресурсы для ее реализации и соответствует ли она потребностям вашей организации
- Разработка: моделирование архитектуры программного обеспечения на основе доступного бюджета и ресурсов и оценка опасностей и возможностей, чтобы увидеть, как изменения или новые технологии могут быть добавлены в проект по мере его продвижения
- Строительство: занимается разработкой программного обеспечения, начиная с его дизайна, заканчивая кодированием и тестированием.
- Переход: доставка окончательной версии программного обеспечения и внесение изменений для улучшения результатов или исправления любых проблем
Подходит для: Разработка программного обеспечения.
Ресурсы:
Rational Unified Process — Лучшие практики для команд разработчиков программного обеспечения
Rational Unified Process — Обучающее видео от Udacity
Разработка на основе функций (FDD)
Feature Driven development — это итеративный и поэтапный процесс разработки и доставки программного обеспечения. Команды обычно используют FDD для долгосрочной разработки продукта, который требует регулярных и повторяющихся изменений. Целью FDD является создание характеристик продукта на основе потребностей и требований клиента.
Чтобы помочь вам достичь этой цели, процесс FDD включает в себя ряд передовых методов разработки программного обеспечения и продуктов. Теперь команда будет работать над разработкой функций, которые имеют наибольшую ценность для клиента и соответствуют ожиданиям конечных пользователей продукта.
Используя Feature Driven Development, инженеры-программисты разрабатывают функциональные функции каждые две недели (обычно) и контролируют их производительность с помощью ряда стандартных отраслевых процедур, таких как моделирование предметных областей, владение индивидуальным кодом, регулярные сборки, управление конфигурацией и многое другое.
В рамках этого процесса команды посвящают начало проекта четкому пониманию того, над чем они будут работать. Это делается без дополнительных затрат времени на оценку проекта или мозговой штурм его дизайна.
Есть 5 основных действий, которые являются частью процесса разработки на основе функций:
- Разработка общей модели: предлагает модели предметной области, которые будут добавлены к общей модели, чтобы лучше описать проект в целом
- Создание списка функций: определение наиболее ценных функций для клиентов с использованием следующих функций: «действие — результат — объект»
- Планирование по функциям: упорядочивает функции и процедуры их подачи и назначает людей, которые будут за них отвечать
- Проектирование по функциям: определение приоритетности функций, поиск проектных решений для них и оценка результатов
- Сборка по функции: начало сборки и тестирования кода на основе проверенной функции
Подходит для: Разработка программного обеспечения.
Используемые инструменты: SpiraTeam
Ресурсы:
Практическое руководство по разработке, основанной на функциях, Стивен Р. Палмер, Джон М. Фелсинг
Джефф ДеЛука о разработке, управляемой функциями — Подкаст
Итак, что дальше?
В этой статье мы дадим вам лишь базовое введение в методологии, методы и рамки управления проектами.
Прежде всего, важно определить, в каком типе проектов вы участвуете, затем выбрать подходящий метод, методологию или структуру, которые вам следует изучить, и попытаться понять их досконально.
Поскольку они более строгие и имеют четко определенные процессы и принципы, методологии могут больше подходить для более крупных проектов и для начинающих менеджеров проектов. Между тем, фреймворки лучше для тех, кто уже набрался опыта работы над несколькими проектами и пробовал разные методы.
Если вы хотите узнать больше об управлении проектами, ознакомьтесь с этими списками лучших курсов по управлению проектами и учебных ресурсов, доступных независимо от вашего опыта.
Вы нашли эту статью полезной? Пожалуйста, поделитесь знаниями и поделитесь ими со своими товарищами по команде и последователями.
7 Популярные методологии управления проектами
Каждый руководитель проекта знает, что выбор правильной методологии имеет решающее значение для получения правильной работы. Хотя существует множество методологий управления проектами, мы сузили его до семи популярных и тех, для которых они лучше всего подходят.
Давайте начнем с определения методологии управления проектами, чтобы мы все были на одной странице:
Согласно Институту управления проектами (PMI), методология определяется как «система практик, техник, процедур и правил, используемых теми, кто работает в определенной дисциплине.Бережливые практики, Канбан и Шесть сигм — примеры методологий управления проектами ».
По сути, это процессы, которые направлены на то, чтобы помочь менеджерам проектов руководить проектом на протяжении всего проекта и предпринимать шаги для выполнения задач. У разных методологий есть разные стратегии, которые помогают решать проблемы, если они возникают во время реализации проекта.
Итак, что выбрать?
Существует множество методологий на выбор, каждая из которых имеет свой набор правил, принципов, процессов и практик.Какую методологию вы должны реализовать, полностью зависит от типа проекта, за который вы возьметесь. Смысл выбора методологии управления проектом заключается в максимальном использовании ресурсов и времени.
Следует иметь в виду, что, хотя существует ряд методологий на выбор, не существует такой вещи, как «правильная» методология. Это означает, что не будет единой методологии, которая идеально подходила бы для каждого отдельного проекта. Проекты различаются по объему и требованиям, что означает, что правильная методология реализации также будет разной.
Теперь давайте взглянем на некоторые из наиболее популярных методологий и сравним наши собственные методологии управления проектами.
1. Гибкость
Agile, одна из наиболее узнаваемых методологий управления проектами, лучше всего подходит для итеративных и инкрементных проектов. Это тип процесса, в котором потребности и решения развиваются в результате совместных усилий самоорганизующихся и кросс-функциональных команд и их клиентов. Первоначально созданный для разработки программного обеспечения, он был создан как ответ на недостатки метода водопада (информация о нем ниже), процессы которого не отвечали требованиям высококонкурентного и постоянного движения индустрии программного обеспечения.
Agile-менеджмент проектов основан на ценностях и принципах Agile Manifesto. Декларация, принятая в 2001 году 13 лидерами отрасли, ее цель — раскрыть лучшие способы разработки программного обеспечения путем предоставления четкой и измеримой структуры, которая способствует итеративной разработке, командному сотрудничеству и признанию изменений.
Состоит из четырех основных ценностей и 12 ключевых принципов, вот что они собой представляют:
Значения
- Люди и взаимодействия важнее процессов и инструментов
- Рабочее программное обеспечение поверх обширной документации
- Сотрудничество с клиентами в рамках переговоров по контракту
- Реагирование на изменение в соответствии с планом
Принципы
- Удовлетворенность клиентов за счет своевременной и непрерывной поставки программного обеспечения
- Учет меняющихся требований на протяжении всего процесса разработки
- Частая поставка рабочего ПО
- Сотрудничество между заинтересованными сторонами бизнеса и разработчиками на протяжении всего проекта
- Поддерживать, доверять и мотивировать вовлеченных людей
- Разрешить личное общение
- Работающее программное обеспечение — главный показатель прогресса
- Гибкие процессы для поддержки постоянного темпа разработки
- Внимание к техническим деталям и дизайну повышает маневренность
- Простота
- Самоорганизующиеся команды поощряют отличные архитектуры, требования и проекты
- Регулярные размышления о том, как стать эффективнее
Благодаря своей адаптивности методология Agile обычно используется для реализации более сложных проектов.Он использует шесть основных результатов для отслеживания прогресса и создания продукта: заявление о видении продукта, дорожная карта продукта, невыполненная работа по продукту, план выпуска, невыполненная работа Sprint и приращение. Благодаря этим функциям он зарекомендовал себя как методология, делающая упор на сотрудничество, гибкость, постоянное совершенствование и высокое качество результатов.
Лучше всего подходит для: Проектов, требующих гибкости и имеющих определенный уровень сложности или неопределенности. Например, продукт или услуга, которые не были созданы командой.
Agile — это методология, которая имеет внутри себя методологии, такие как Scrum и Kanban. Хотя некоторые могут утверждать, что их следует рассматривать скорее как фреймворки, они используются для разработки и предоставления продукта или услуги и несут свой собственный набор характеристик и терминологию, что, на мой взгляд, делает их достаточно достойными для включения в этот список.
2. Скрам
Scrum состоит из пяти ценностей: приверженность, смелость, сосредоточенность, открытость и уважение. Его цель — разрабатывать, предоставлять и поддерживать сложные продукты за счет сотрудничества, подотчетности и непрерывного прогресса.Что отличает Scrum от других методологий управления проектами Agile, так это то, как он работает с использованием определенных ролей, событий и артефактов.
Роли в команде Scrum
- Владелец продукта : Эксперт по продукту, который представляет заинтересованные стороны и является голосом клиента.
- Команда разработчиков : Группа профессионалов, поставляющих продукт (разработчики, программисты, дизайнеры).
- Мастер Скрама : Организованный служащий-лидер, обеспечивающий понимание и выполнение Скрама.
События Scrum
- Sprint : Итерационные временные рамки, в которых достигается цель. Сроки не превышают одного календарного месяца и согласованы на протяжении всего процесса разработки.
- Планирование спринта : где вся команда Scrum собирается — в начале каждого спринта — для планирования предстоящего спринта.
- Daily Scrum : 15-минутная встреча с ограничением по времени, проводимая в одно и то же время каждый день спринта, на которой обсуждаются достижения предыдущего дня, а также ожидания на следующий день.
- Обзор спринта : Неформальная встреча, проводимая в конце каждого спринта, на которой команда Scrum представляет свой приращение заинтересованным сторонам и обсуждает отзывы.
- Ретроспектива спринта : Встреча, на которой команда Scrum размышляет о ходе предыдущего спринта и вносит улучшения для следующего спринта.
Артефакты Scrum
- Журнал отставания по продукту : управляемый владельцем продукта, именно здесь в порядке приоритета перечислены все требования, необходимые для жизнеспособного продукта.Включает в себя функции, функции, требования, улучшения и исправления, которые разрешают вносить любые изменения в продукт в будущих выпусках.
- Журнал спринта : список задач и требований, которые необходимо выполнить во время следующего спринта. Иногда сопровождается доской задач Scrum, которая используется для визуализации хода выполнения задач в текущем спринте и любых изменений, которые вносятся в формате «To Do, Doing, and Done».
Лучше всего подходит для: Проекты, состоящие из групп менее семи человек, которым требуется гибкий подход к предоставлению продукта или услуги.
3. Канбан
Kanban — еще одна популярная среда Agile, которая, как и Scrum, ориентирована на ранние версии с совместными и самоуправляемыми командами. Концепция, которая была разработана на производственной линии заводов Toyota в 1940-х годах, представляет собой очень наглядный метод, направленный на получение высококачественных результатов путем рисования картины рабочего процесса, чтобы узкие места можно было выявить на ранней стадии процесса разработки. Он работает с шестью врачами общей практики, а именно:
- Визуализация
- Ограничение незавершенного производства
- Управление потоками
- Четкое определение политик
- Использование контуров обратной связи
- Совместная или экспериментальная эволюция
Канбан обеспечивает эффективность за счет использования визуальных сигналов, которые сигнализируют о различных этапах процесса разработки.В этом процессе используются канбан-доска, канбан-карточки и даже канбан-дорожки для тех, кто ищет дополнительную организацию.
- Канбан-доска : Канбан-доска, которая используется для визуализации процесса разработки, может быть физической (доска, стикеры и маркеры) или цифровой (например, онлайн-инструмент управления проектами Zenkit).
- Канбан-карты : каждая Канбан-карта отображает рабочий элемент / задачу в рабочем процессе. Используемый для сообщения вашей команде о ходе выполнения, он представляет такую информацию, как статус, время цикла и приближающиеся сроки.
- Канбан-дорожки : Канбан-дорожки, расположенные по горизонтали, представляют собой визуальный элемент на доске, который позволяет дополнительно различать задачи / элементы путем их категоризации. Их цель — предложить лучший обзор рабочего процесса.
Несмотря на отсутствие установленных правил для Канбана как такового, он работает с использованием доски Канбан для представления этапов разработки от начала, когда появляются идеи, до незавершенной работы и до ее завершения. Основная структура доски состоит из трех столбцов, помеченных как «To-Do, Doing и Done», что не требует пояснений.
Если Канбан является предпочтительной методологией управления проектами, вы можете использовать одну из них!
Как и большинство Agile-фреймворков, Kanban получил признание в индустрии разработки программного обеспечения. Однако из-за своей гибкости он получил распространение в других отраслях и является одной из немногих методологий управления проектами, которые можно применить к любому проекту, требующему постоянного улучшения в процессе разработки.
Лучше всего подходит для: Как и Scrum, Канбан подходит для проектов с небольшими командами, которым требуется гибкий подход к доставке продукта или услуги.Канбан также отлично подходит для повышения личной продуктивности.
4. Постное
Методология бережливого производства способствует увеличению ценности для клиентов при минимизации потерь. Он направлен на создание большей ценности для клиента за счет использования меньшего количества ресурсов. Основанный на японской обрабатывающей промышленности, его ценности предполагают, что «по мере устранения отходов качество улучшается, а время и стоимость производства сокращаются».
Он определяет три типа отходов; муда, мура и мури, также известные как 3М.
МудаMuda — это избавление от отходов и относится к деятельности или процессу, которые не добавляют ценности. Это может быть либо физическая трата вашего времени, либо пустая трата ваших ресурсов. Классифицируются как семь исходных отходов, их количество:
- «Транспортировка: перемещение продукции между операциями и местами.
- Запасы: Незавершенное производство (НЗП) и запасы готовой продукции и сырья, которыми владеет компания.
- Движение: Физическое движение человека или машины во время проведения операции.
- Ожидание: ожидание завершения работы машины, прибытия продукта или по любой другой причине.
- Перепроизводство: чрезмерное производство продукта сверх того, что заказал клиент.
- Чрезмерная обработка: выполнение операций, выходящих за рамки тех, которые требуются заказчику.
- Дефекты: Продукт отбраковывается и переделывается в рамках ваших процессов ».
Mura — это устранение отклонений в рабочем процессе на уровне планирования и операций, так что все идет равномерно.Например, при публикации журнала, если редактор тратит слишком много времени на редактирование статьи, это означает, что у команды дизайнеров будет меньше времени на создание разворота до наступления крайнего срока публикации. Таким образом, вы сократите время редактирования и обеспечите одинаковое время, затрачиваемое на статью всеми отделами.
МуриMuri — это устранение перегрузки, чтобы ничто не тормозило. Это относится к менеджерам и владельцам бизнеса, которые создают ненужную нагрузку на своих сотрудников и процессы из-за таких вещей, как плохая организация, нечеткие методы работы и использование неправильных инструментов.
Вместо реализации определенных процессов, бережливое производство больше связано с соблюдением набора принципов. Пять основных принципов: определять ценность для клиента, определять шаги в потоке создания ценности, обеспечивать непрерывный поток продукта, позволять клиентам извлекать ценность из следующего восходящего действия и управлять удалением ненужных шагов.
Лучше всего подходит для: Методология бережливого производства, которую часто ошибочно принимают за специализацию в обрабатывающих отраслях, идеально подходит для любого бизнеса или организации, которые не ищут процесс как таковой, но заинтересованы в изменении способов ведения бизнеса.
5. Водопад
Одна из наиболее традиционных методологий управления проектами, Waterfall — это линейный, последовательный подход к проектированию, при котором прогресс течет вниз в одном направлении — как водопад. Возникнув в производственной и строительной отраслях, он не обладает гибкостью при внесении изменений в конструкцию на ранних этапах процесса разработки из-за того, что он становится чрезмерно дорогим из-за своей структурированной физической среды.
Методология была впервые представлена в статье, написанной в 1970 году Уинстоном У.Ройса (хотя термин «водопад» не использовался) и подчеркивает, что вы сможете перейти к следующему этапу разработки только после завершения текущего этапа. Фазы выполняются в следующем порядке:
- Системные и программные требования
- Анализ
- Типовой проект
- Кодирование
- Тестирование
- Операции
Waterfall — это методология управления проектами, в которой подчеркивается важность документации.Идея состоит в том, что, если работник должен был уйти в процессе разработки, его замена может начаться с того места, где он остановился, ознакомившись с информацией, представленной в документах.
Pre-Agile видел, что методология Waterfall использовалась для разработки программного обеспечения, но возникло много проблем из-за ограничений ее неадаптивного дизайна, отсутствия отзывов клиентов в процессе разработки и отложенного периода тестирования.
Лучше всего подходит для: Более крупных проектов, требующих соблюдения строгих стадий и сроков, или проектов, которые были реализованы разное время и для которых вероятность неожиданностей в процессе разработки относительно низка.
6. Шесть сигм
Six Sigma — это методология управления проектами, впервые представленная инженерами Motorola в 1986 году. Она направлена на повышение качества за счет уменьшения количества ошибок в процессе путем выявления того, что не работает, и последующего удаления этого из процесса. Он использует методы управления качеством, которые в основном являются эмпирическими и статистическими, а также опыт людей, которые являются специалистами в этих методах.
Существуют две основные методологии Шести Сигм, которые выполняются Зелеными Поясами Шести Сигм и Черными Поясами Шести Сигм, и контролируются Мастерами Черных Поясов Шести Сигм.Это DMAIC, который используется для улучшения бизнес-процессов, и DMADV, который больше предназначен для создания новых процессов, продуктов или услуг. Буквы обозначают:
‘ D Определить проблему и цели проекта
M Детально проанализировать различные аспекты текущего процесса
A проанализировать данные, среди прочего, найти основные дефекты в процессе
I mprove процесс
C контроль, как процесс будет выполняться в будущем ‘
‘ D Определите цели проекта
M Оцените критически важные компоненты процесса и возможности продукта
A проанализируйте данные и разработайте различные конструкции процесса, в конечном итоге выбрав лучший
D Разработка и тестирование подробности процесса
V обновить дизайн, запустив моделирование и пилотную программу, а затем передать процесс клиенту ‘
Существует также методология бережливого производства и шести сигм, которая направлена на повышение производительности команды путем систематического устранения потерь и уменьшения вариативности.
Лучше всего подходит для: Более крупных компаний и организаций, которые хотят повысить качество и эффективность с помощью методологии, основанной на данных.
7. PMI / PMBOK
PMI означает Институт управления проектами, который является некоммерческой членской ассоциацией, сертификационной организацией по управлению проектами и организацией по стандартам. Через PMI появляется PMBOK, который является не совсем методологией, а руководством, детализирующим набор стандартов, характеризующих управление проектами.
PMBOK расшифровывается как «Свод знаний по управлению проектами» и представляет собой набор стандартной терминологии и рекомендаций по управлению проектами. В нем говорится, что есть пять групп процессов, которые преобладают почти в каждом проекте. Они есть;
- Запуск : определение начала нового проекта или новой фазы существующего проекта.
- Планирование : Где объем проекта, цели и способы их достижения.
- Выполнение : Фактическое выполнение работы, определенной в плане управления проектом.
- Мониторинг и контроль : Когда вам нужно отслеживать, проверять и регулировать прогресс и производительность.
- Закрытие : Завершение всех действий во всех группах процессов для формального закрытия проекта или фразы.
Наряду с этим он включает в себя лучшие практики, соглашения и методы, которые считаются отраслевым стандартом. PMBOK регулярно обновляет свое руководство, чтобы оно отражало самые современные практики управления проектами, и в настоящее время готовится к шестому изданию, которое было опубликовано в печати и в Интернете в 2017 году.
Лучше всего подходит для: Поскольку это скорее справочное руководство, чем реальная методология управления проектами, вы не можете внедрить PMI / PMBOK в проект. Однако его можно использовать, когда вы хотите взвесить лучшие практики для своего проекта.
Вы можете обнаружить, что более чем одна из вышеупомянутых методологий управления проектами кажется идеальной для вашего проекта, или же ни одна из них не будет работать. Мы предоставили упрощенное руководство, которое поможет вам сделать первые шаги по выбору наилучшей методологии для вашего будущего проекта.Следующим шагом является дальнейшее исследование, а затем, когда вы найдете лучший вариант, соедините его с отличным инструментом управления проектами (кхм, например, Zenkit), и все готово.
Не забудьте сообщить нам, какая методология управления проектами работает лучше всего для вас!
Ура,
Динни и команда Zenkit
Была ли эта статья полезной? Пожалуйста, оцените это![Всего: 65 Среднее: 4,6 / 5]
Что такое методологии управления проектами?
Методологии содержат руководящие процессы для тех, кто занимается управлением проектами.Истинное определение заключается в том, что методологии не зависят от конкретного инструмента, однако в сегодняшнем мире, основанном на программном обеспечении, реальность такова, что методология и программный инструмент управления проектами организации часто сильно взаимосвязаны.
Почему методологии управления проектами?
Управление проектами играет решающую роль в достижении целей и реализации планов и ожиданий. Однако зачастую легче сказать, чем сделать, чтобы ваша команда была организована вокруг проекта. Следование методологии управления проектами может помочь вам организовать ваш проект в структурированный, оптимизированный процесс.Это делает командную совместную работу более эффективной, а проекты — более организованными.
Но не все методологии управления проектами подходят для всех типов проектов. Чтобы понять, какой метод лучше всего подходит для вашего проекта, вам необходимо ознакомиться с этими общими проектными методологиями и их различиями.
Введение в методологии управления проектами
Несмотря на то, что доступны десятки методов управления проектами, соответствующие методы управления проектами могут помочь вашей команде гораздо более эффективно управлять своим проектом.Бизнес может варьироваться в зависимости от типа, размера, отрасли и многих других факторов. Вместо того, чтобы искать лучшую методологию, предприятиям следует изучить эти методологии, как они используются и как их можно применять.
Давайте кратко рассмотрим широко используемые методы ниже:
Проворный
Гибкие методологии возникли в результате того, что использование водопадной модели считалось бюрократическим, негибким, медленным и несовместимым с тем, как разработчики программного обеспечения фактически выполняют эффективную работу.Agile-метод ориентирован на людей и коммуникации, гибкий (готов адаптироваться к ожидаемым изменениям в любое время), быстрый (поощряет быструю и итеративную разработку продукта небольшими выпусками), бережливый (фокусируется на сокращении сроков и затрат и на улучшении качество), отзывчивый (адекватно реагирует на ожидаемые и неожиданные изменения) и обучающийся (фокусируется на улучшении во время и после разработки продукта)
Agile-процессы обычно поощряют частые проверки и адаптацию, философию лидерства, которая поощряет командную работу, самоорганизацию и подотчетность, набор передовых инженерных практик, предназначенных для быстрой доставки высококачественного программного обеспечения, и бизнес-подход, который согласовывает разработку с потребителями потребности и цели компании.Метод Agile пытается обеспечить быструю и непрерывную доставку продукта клиенту. В то время как традиционные методологии, такие как метод водопада или другие линейные процессы, требуют подробных предварительных требований, определенных на начальном этапе проекта.
Водопад
МетодологияWaterfall является наиболее часто используемой во всех отраслях и очень распространена при разработке и создании программного обеспечения. Модель водопада — это последовательный (неитеративный) процесс проектирования, используемый в процессах разработки программного обеспечения, в котором прогресс рассматривается как неуклонно нисходящий (как водопад) через фазы концепции, инициирования, анализа, проектирования, построения, тестирования и т. Д. производство / внедрение и обслуживание.Существует много версий метода водопада, но исходная включала в себя следующие фазы высокого уровня:
- Технические требования
- Типовой проект
- Конструкция (кодировка)
- Интеграция
- Тестирование и отладка (Validation)
- Установка
- Техническое обслуживание
Адаптивный
Адаптивное управление проектами делает именно то, что предлагает название: оно адаптируется. При адаптивном управлении проектами объем данного проекта может варьироваться.Хотя время, необходимое для завершения проекта, и его стоимость являются постоянными, объем проекта можно корректировать по мере его выполнения. Компании обычно делают это, чтобы получить максимальную отдачу от каждого проекта, например, когда в процессе разработки проекта открываются новые идеи или возможности.
Скрам
Scrum — это гибкий фреймворк для выполнения сложных проектов. Изначально Scrum был формализован для проектов разработки программного обеспечения, но он подходит для любых сложных инновационных задач.Возможности безграничны. Фреймворк Scrum обманчиво прост.
Scrum пытается справиться с тем фактом, что требования могут быстро измениться или не будут полностью известны в начале проекта. Требования низкого уровня определяются только в то время, когда они действительно будут реализованы. В Scrum изменения и оптимизация продукта, требований и процессов являются неотъемлемой частью всего инженерного цикла. Таким образом, процесс разработки Scrum — это тип гибкой методологии, которая фокусируется на коротком цикле спринтов и ежемесячных сессиях Scrum, где результаты проекта разбиваются на интервалы от 2 до 4 недель.
Scrum применим только в определенных типах сред — в основном, в тех, где находятся вместе, 100% преданные члены команды (нелегко работать с несколькими проектами), с целенаправленной поддержкой членов команды проекта.
RAD (быстрая разработка приложений)
Rapid Application Development (RAD) описывает метод разработки программного обеспечения, в котором большое внимание уделяется быстрому созданию прототипов и итеративной доставке. Он был рожден из-за разочарования по поводу водопадного подхода, который часто приводил к тому, что продукты уже устарели к моменту их фактического выпуска.RAD — это тип инкрементальной модели, компоненты или функции которой разрабатываются параллельно в виде мини-проектов. Разработки упаковываются по времени, доставляются, а затем собираются в рабочий прототип. Это может быстро дать заказчику что-то посмотреть и использовать, а также высказать свое мнение о доставке и его требованиях.
PMBOK
PMBOK ® — это не совсем методология, а скорее обширный набор передовых практик для управления проектами, который быстро разросся и распространился по всему миру, и теперь рассматривается во всем мире как признанная и стратегическая компетенция, карьерный путь и предмет для обучения и воспитания.PMBOK — это сокращение от «Свод знаний по управлению проектами». Структура PMBOK состоит из пяти групп процессов, десяти областей знаний и 47 процессов управления проектами. Области знаний группируют процессы PM по содержанию управления проектами.
PMBOK — это самый широкий и наиболее широко используемый стандартный справочник лучших практик для PM. В нем изложены передовые методы и рекомендации, применимые к широкому кругу отраслей и рынков и охватывающие несколько отделов, от ИТ до производства.Различные отрасли могут использовать разные аспекты PMBOK в соответствии со своими потребностями.
Группы процессов
Пять групп процессов:
- Инициирование: процессы, выполняемые для определения нового проекта или новой фазы существующего проекта путем получения разрешения на запуск проекта или фазы.
- Планирование: те процессы, которые необходимы для установления объема проекта, уточнения целей и определения курса действий, необходимых для достижения целей, для достижения которых был предпринят проект.
- Выполнение: те процессы, которые выполняются для завершения работы, определенной в плане управления проектом, в соответствии со спецификациями проекта.
- Мониторинг и контроль: процессы, необходимые для отслеживания, анализа и регулирования прогресса и эффективности проекта; определить любые области, в которых требуются изменения в плане; и инициируйте соответствующие изменения.
- Закрытие: процессы, выполняемые для завершения всех действий во всех группах процессов с целью формального закрытия проекта или фазы.
Области знаний
Десять областей знаний, каждая из которых содержит некоторые или все процессы управления проектом:
- Управление интеграцией проекта : процессы и действия, необходимые для идентификации, определения, объединения, унификации и координации различных процессов и действий по управлению проектами в группах процессов управления проектами.
- Управление содержанием проекта : процессы, необходимые для того, чтобы гарантировать, что проект включает в себя всю работу, и только работу, необходимую для успешного завершения проекта.
- Управление сроками проекта : процессы, необходимые для управления своевременным завершением проекта.
- Управление стоимостью проекта : процессы, связанные с планированием, оценкой, составлением бюджета, финансированием, финансированием, управлением и контролем затрат, чтобы проект мог быть завершен в рамках утвержденного бюджета.
- Управление качеством проекта : процессы и действия исполняющей организации, которые определяют политику качества, цели и обязанности, чтобы проект удовлетворял потребности, ради которых он был предпринят.
- Управление человеческими ресурсами проекта : процессы, которые организуют, управляют и руководят командой проекта.
- Управление коммуникациями проекта : процессы, необходимые для обеспечения своевременного и надлежащего планирования, сбора, создания, распространения, хранения, извлечения, управления, контроля, мониторинга и окончательного удаления информации о проекте.
- Управление рисками проекта : процессы планирования управления рисками, выявления, анализа, планирования реагирования и контроля рисков по проекту.
- Управление закупками проекта : процессы, необходимые для покупки или приобретения продуктов, услуг или результатов, необходимых не для проектной группы. Процессы в этой области включают в себя планирование закупок, планирование запроса, запрос, выбор источника, администрирование контракта и закрытие контракта.
- Управление заинтересованными сторонами проекта : процессы, необходимые для выявления всех людей или организаций, на которые оказывает влияние проект, анализа ожиданий и влияния заинтересованных сторон на проект, а также разработки соответствующих стратегий управления для эффективного вовлечения заинтересованных сторон в решения и исполнение проекта.
Каждая из десяти областей знаний содержит процессы, которые необходимо выполнить в рамках ее дисциплины для достижения эффективного управления проектами. Каждый из этих процессов также попадает в одну из пяти групп процессов, создавая матричную структуру, так что каждый процесс может быть связан с одной областью знаний и одной группой процессов.
PRINCE2
PRINCE2 (аббревиатура от PR ojects IN C ontrolled E nvironments) — это де-факто процессный метод эффективного управления проектами.Это и методология, и стандарт де-факто, широко используемый правительством Великобритании, широко признан и используется в частном секторе как в Великобритании, так и за рубежом. Он обеспечивает согласованность процесса, подхода и языка, поэтому его можно применять практически к любому типу проекта. PRINCE2 — это методология управления проектами, основанная на принципах, основанная на семи принципах, семи темах и семи процессах.
Семь принципов:
- Обоснование продолжения деятельности
- Учитесь на опыте
- Определенные роли и обязанности
- Управление по этапам
- Управление исключением
- Продукты в фокусе
- Подходят для условий проекта
Семь тем:
- Бизнес-кейс
- Организация
- Качество
- Планы
- Риск
- Изменить
- Прогресс
PRINCE2 — это не методология «водопада», не «серебряная пуля» или решение «под одну гребенку»; это структура управления проектами, которую можно легко адаптировать к любому размеру или типу проекта.Таким образом, это как идеальный готовый метод для сложных проектов, так и отличная основа для адаптации к менее сложным проектным средам.
Канбан
В Канбане прогресс проекта отображается на доске. Примечания (также называемые наклейками) очень распространены в этом отношении, которые обычно перемещаются слева направо. Они классифицируются как выполняемые, недавно завершенные и находящиеся в очереди. Канбан позволяет легко визуализировать, какая работа выполняется и что будет дальше. Канбан-методика лучше всего подходит для небольшой команды.Также люди считают использование личных досок Канбан эффективным методом.
Преимущество заключается в визуальном отображении того, что будет дальше, и упрощении смены приоритетов. Канбан-диаграммы обычно состоят из общих категорий проектов или задач «To-Do», «Doing» и «Done». Когда приходит менеджер проекта, чтобы положить работу на доску, ему легко показать, какая работа идет и что приближается, и как «новая работа» повлияет на всю команду. Это особенно хорошо работает для небольших совместных проектных групп.Многие люди также продвигают использование личных досок Канбан.
Шесть сигм
Six Sigma — это упорядоченный продукт, управляемый данными, и методология улучшения процессов, изначально разработанная Motorola. Идея заключалась в улучшении процессов путем устранения дефектов, которые определяются как «несоответствие продукта или услуги его спецификациям». Те из нас, кто занимается управлением проектами, обычно не думают об этом как о методологии управления проектами.
Шаги процесса обозначаются аббревиатурой DMAIC, что означает «Определение, Измерение, Анализ, Улучшение, Контроль, и когда это делается для Синергии в организации».
DMAIC
DMAIC является частью методологии шести сигм, но также часто используется как самостоятельный метод. DMAIC (сокращение от Define, Measure, Analyze, Improve and Control) относится к управляемому данными циклу улучшения, используемому для улучшения, оптимизации и стабилизации бизнес-процессов и проектов. Его можно использовать в качестве основы для проектов по улучшению за пределами Шести сигм.
Краткое описание фреймворка:
- Определите — кто клиенты и каковы их потребности.Определите цель и объем проекта. Определите текущий процесс и то, что от него хочет клиент.
- Мера — как выполняется процесс и как он измеряется. Сбор данных о том, насколько хорошо текущий процесс удовлетворяет потребности клиентов
- Проанализируйте — каковы наиболее важные причины проблем. Определите основные причины недостатков производительности и подтвердите данными.
- Улучшение — как устранить причины проблем? Планируйте, тестируйте и внедряйте решения, устраняющие основные причины (используйте данные для оценки как решений, так и планов, используемых для их выполнения).
- Control — как мы можем поддерживать улучшения? Поддерживайте прибыль за счет стандартизации методов или процессов работы. Предвидьте будущие улучшения и сохраните уроки из этих усилий.
Адаптивная в сравнении с прогнозирующей
Два самых популярных решения для управления проектами, внедряемые сегодня, — адаптивное и прогнозирующее. Адаптивная технология широко известна как гибкая, а прогнозирующая также называется водопадом или традиционной методологией.
Чтобы избежать ограничений каскадного подхода, Agile-метод нацелен на то, чтобы стать гибким и итеративным методом управления проектами, позволяющим справляться с быстро меняющимися требованиями клиентов.С другой стороны, методология управления водопадными проектами детализирует планирование и предварительные требования до начала реализации проекта. Шаги и зависимости явно отображаются, и проект переходит к следующему этапу только тогда, когда предыдущий уже завершен. Это решение хорошо работает для проектов с определенными задачами и последовательностями, и когда вы точно знаете, каким должен быть конечный результат.
Адаптивный или прогнозирующий?
Основываясь на этих приблизительных рекомендациях, вы можете увидеть, что и гибкость, и водопад имеют свое применение, поэтому утверждение, что гибкость лучше, чем водопад — или наоборот, в этом отношении — совершенно неточно.Все сводится к пониманию того, какой подход лучше соответствует потребностям вашего проекта и команды, с которой вы работаете.
Выберите правильную методологию управления проектами
Поскольку все проекты различаются и предъявляют разные требования, не может быть никакого метода управления проектами, который был бы «лучшим» и применим ко всем предприятиям. Таким образом, методологии управления проектами определенно не универсальны для всех, даже в рамках одной компании, типа проекта или отрасли. В одной ситуации конкретная методология может работать лучше всего, а в других может оказаться более подходящей использовать другую или даже гибридную методологию.Одна и та же методология вряд ли будет работать в одной организации для всех проектов. Мы можем рассмотреть некоторые из этих факторов, чтобы определить, какая методология может вам подойти:
- Организационные цели
- Основные ценности
- Ограничения проекта
- Участники проекта
- Размер проекта
- Стоимость проекта
- Умение рисковать
- Потребность в гибкости
Методология управления проектами необходима для современного бизнеса.Приняв соответствующий метод для вашего проекта, вы можете изменить способ общения вашей проектной группы, работу над задачами и выполнение основных этапов проекта вовремя и в рамках бюджета.
Как организовать работу с Visual Paradigm
Независимо от того, полностью ли вы применяете один из вышеперечисленных методов управления проектами или вам нужно настроить конкретный метод в соответствии с вашими конкретными потребностями, использование процесса Just-in-Time PMBOK Visual Paradigm значительно повысит продуктивность и эффективность вашей команды.
Компании, использующие описанный выше метод управления проектами, с гораздо большей вероятностью добьются успеха с Visual Paradigm. Visual Paradigm позволяет вашей команде работать совместно, а также управлять, назначать и делегировать задачи, автоматически обмениваться файлами, другими ресурсами и многим другим. Кроме того, Visual Paradigm достаточно гибок, чтобы его можно было настроить, добавляя или удаляя работы или результаты из любых методов управления проектами точно в срок и в нужное время!
Карты процессов визуальной парадигмы
В Visual Paradigm мы предоставляем следующие шаблоны методов, и ожидается, что новые шаблоны будут представлены в следующих нескольких выпусках.
Что такое «Визуальная парадигма» точно в срок?
Универсальное решение не всегда применимо в современном сложном и быстро меняющемся мире. Такие процессы, как Rational Unified Process (RUP), считаются тяжелыми, им не хватает гибкости для работы в динамических ситуациях, поэтому они не подходят для гибкой командной разработки. Предварительное выявление требований не предполагает изменений и может привести к большим потерям времени, усилий и затрат на начальном этапе разработки.
Карта процессовVisual Paradigm Just-in-Time (JIT) позволяет разработчикам определять и настраивать процесс точно в срок и достаточно точно, чтобы справиться с быстро меняющейся бизнес-средой, сводя к минимуму потери для всего процесса. Вы можете настроить такой процесс, как PMBOK, PRINCE2, или даже изобрести свой собственный процесс для своего предприятия гибким способом.
Visual Paradigm предоставляет вам огромную коллекцию шаблонов и форм со встроенными инструкциями и примерами для создания пользовательских процессов, соответствующих вашим конкретным потребностям.Кроме того, есть готовые рабочие элементы, которые вы можете добавить в свои процессы. Эти рабочие элементы варьируются от базового анализа и сводной таблицы до серии шагов для создания значимого исследования различных аспектов архитектуры предприятия, управления проектами или действий ITSM, таких как шаблоны встреч, журналы обзора и т. Д.
Готовые к использованию своевременные шаблоны
В Visual Paradigm включен набор готовых к использованию шаблонов процессов JIT для управления проектами и архитектуры предприятия.Для шаблонов управления проектами существует 4 разных уровня сложности для разных типов проектов, которые можно использовать. Кроме того, предоставляется шаблон процесса управления проектами в стиле PMBOK, а также формы и инструкции. Что касается архитектуры предприятия, шаблон проекта TOGAF ADM включен в ArchiMate для моделей диаграмм в результатах. Вы можете сразу же принять эти шаблоны или немного настроить процесс, добавив свои собственные формы и т. Д. В соответствии с потребностями вашего конкретного проекта.
Своевременная карта процесса
Just-in-Time Process Map позволяет проектировать широкий спектр процессов разработки и управления, таких как TOGAF ADM, PMBOK , PRINCE2 и многие другие. Кроме того, вы можете использовать его для моделирования множества различных аспектов деятельности процессов, начиная от управления событиями и задачами (представление участников, представление проекта или представление результатов) до разработки продукта или гибкого управления процессами, настраивая заголовки столбцов как этапы, элементы, проекты, результаты и т. д.Например, вы можете представить такой процесс, как PMBOK, с фазами разработки в виде столбцов и областей знаний в виде строк.
Композитор в нужный момент PMBOK TOGAF Полный набор управления проектами Умные формы и инструкции Встроенное пошаговое руководство по Заполните формы и отметьте как завершенные .
Добавить комментарий