Методы организации проектов помогают корректировать ошибки

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

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

Чтобы перейти к универсальной методологии организации проектов, необходимо выяснить, что же такое проект. Это понятие интегрирует различные виды деятельности, объединённых рядом признаков, которые характеризуются:

1. Направленностью на достижение определенных целей и конкретных результатов;
2. Координированным выполнением разнообразных, взаимосвязанных действий;
3.  Ограниченной протяженностью во времени (определено начало и конец проекта, его основные фазы).

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

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

Простые Мысли. ВТОРОЙ МОЗГ, который будет думать за вас. Зеттелькастен метод

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

Механизм теории заговоров. Михаил Величко

Структурирование проекта

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

Почему просрачиваются сроки?

Методы организации проектов

1. Методы организации проектов помогают:
2. обозначить его цели и провести обоснование необходимости проекта;
3. обозначить структуру данного проекта, выделить необходимые подцели и важнейшие этапы работы, необходимые для его эффективного выполнения;
4. выявить нужные объемы и источники для финансирования проекта;
5. утвердить  ответственных исполнителей;
6. разработать и заключить контракты;
7. рассчитать сроки выполнения данного проекта и предусмотреть график для его реализации, определить необходимые ресурсы; 7.распланировать бюджет и смету проекта;
8. запланировать  возможные риски;
9. обеспечить необходимый контроль над процессом исполнения проекта. Методы организации проекта включают также сетевой планиринг, календарный, стандартный, структурный, ресурсный  планиринги и имитационное моделирование на ЭВМ, логистику и прочее.

Участники организации проекта

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

1. Организация содержания и объема работ (то есть организация целей проекта);
2. Организация временных сроков выполнения проекта;
3. Организация стоимости получившегося продукта;
4. Организация качественного выполнения продукта;
5. Организация материально-технического обеспечения (материальных ресурсов);
6. Организация управления человеческими ресурсами (персоналом);
7. Организация управления рисками;
8. Организация управлением информацией и коммуникациями;
9. Организация интеграционного управления.

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

 Осуществление проекта

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

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

Организация контроля за исполнением проекта

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

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

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

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

1. Наличие пошагового плана проекта. Для осуществления контроля он должен иметь конкретное содержание, быть четко структурирован и зафиксирован. Когда планирование проекта изменяется довольно часто и без выполнения процедур контроля за внесёнными изменениями, то контроль над осуществлением проекта может быть фактически утерян;
2. Наличие понятной системы отчетов. Отчетность должна показывать состояние проекта по сравнению с заданными планами на основании единых требований и критериев. Процедуры изготовления и доставки отчетности должны быть ясно определенными и достаточно простыми в исполнении;
3. Наличие успешной системы анализов фактических показателей и тенденций. По результатам сбора анализов полученных данных, руководители проекта определяют соответствие текущей ситуации и запланированной, в случае несоответствия, они рассчитывают размер и серьезность возникших последствий при отклонении. Два базовых показателя хода реализации работ — временные и стоимостные показатели. Для прогнозирования тенденций в этих оценках могут быть использованы только специальные отчеты;
4. Наличие успешной системы реагирования. Финальным шагом процесса организации контроля являются действия, направленные на исправление отклонений, возникших в ходе работ проекта. Эти действия могут быть нацелены на устранение образовавшихся недостатков и преодоление отрицательных тенденций в рамках реализации проекта. Иногда в ряде случаев может быть потребован пересмотр плана проекта. Перепланирование  и корректировка могут потребовать проведения дополнительного анализа типа «Что, если…», который обеспечит расчет и прогноз последствий запланированных действий.

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

Александр Палиенко. Интервью с Раминой Эсхакзай «Реализация Потенциала, Рождение Детей и Человечность».

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

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

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

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

 Waterfall – каскадная модель

Каскадная модель или модель «водопад», – это вариант классического поэтапного планирования. 

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

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

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

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

Реализация и тестирование. На этой фазе происходит основная работа – строители закладывают фундамент, возводят стены и крышу, проводят коммуникации. 

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

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

Ограничения Waterfall-модели

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

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

Поздно находят проблемы. Классический проектный подход в менеджменте опасен поздним обнаружением проблем. Тестирование – один из последних этапов, на котором ищут все ошибки проекта. Часто на их исправление не хватит времени и бюджета. Остается «сглаживать углы»: заделывать дыры в доме монтажной пеной, исправлять косметические недочеты. 

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

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

Подробнее о каскадной модели читайте в статье «Как устроена каскадная модель управления проектами».

Вам подойдет каскадная модель, если:

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

• нужна детальная документация по всем процессам разработки;

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

Agile – гибкое управление проектом

Agile
  – это система ценностей, помогающая создавать новые продукты. 

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

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

«Люди и взаимодействия важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

Создатели воспринимали Agile  как философию, которую можно адаптировать под конкретные задачи. Современные модели проектного менеджмента, например, Scrum и Kanban, основаны на философии Agile.

Рассмотрим преимущества и недостатки Agile.

Особенности Agile

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

Разработка небольшими итерациями. Продукт или проект разбивается на ценные части, каждая из которых разрабатывается в отдельный временной промежуток – 
итерацию
. За один такой интервал времени разрабатывают новую версию продукта или перерабатывают уже существующий. В итоге после итерации получается новый продукт или новая версия, готовая к выпуску. Продукт выпускают, собирают обратную связь и в следующую итерацию улучшают и дорабатывают. Иногда итерации называют agile-спринтами, но это не совсем верно. Спринт – термин из Scrum-подхода.

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

Результат важнее документации. От плана можно отступать, если это принесет пользу проекту. 

Ограничения Agile

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

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

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

Легко сбиться с пути. Суть аджайла – в гибкости и возможности подстраиваться под постоянно меняющиеся условия. Иногда если обратная связь заказчика не ясна, разработчик может сфокусироваться на работе в неправильном направлении. Есть опасность впустую тратить деньги, постоянно меняя продукт. 

Гибкий подход подойдет, если:

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

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

• запросы пользователей и ситуация на рынке постоянно меняются.

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

Компании, которые работают по Agile: Spotify, Microsoft, Google, Netflix, Ericsson, Dell, Adobe, Accenture, WordPress, Riot Games, CH Robinson, Magna International, Scrum Alliance, Intronis, General Electric, John Deere.

Подробно о том, что такое аджайл и как он появился, читайте в нашей статье «Agile – новый Lean?».

Scrum – инструкция по запуску нового продукта

Scrum
 – это способ организации рабочего процесса. Скрам помогает проверять идеи, тестировать новые решения, выпускать инновационные продукты.

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

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

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

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

Подробнее об организации работы по Scrum читайте в статье «Agile по правилам Scrum».

Особенности Scrum-подхода

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

• Фокусировка на пользе для потребителя. Методология Scrum и agile-принципы заточены на то, чтобы изучать потребности пользователей, улучшать их опыт использования продукта. А не на то, чтобы сделать продукт в срок и согласовать его с заказчиком. 

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

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

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

Ограничения Scrum

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

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

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

Скрам подойдет, если:

• вы разрабатываете новый продукт, аналогов которого нет на рынке;

• у вас есть возможность собрать команду сотрудников, которые будут заниматься только этим проектом. 

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

Артемий Анцупов 

agile-coach, партнер «Скрамтрэк» 

Компании, которые используют Scrum: Google, Apple, Facebook, Spotify, AirBnB, Salesforce, «Промсвязьбанк».

Kanban – инструменты для улучшения рабочих процессов

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

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

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

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

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

Поэтому в канбане есть принцип «перестаньте начинать [новые задачи], начните завершать [задачи, которые уже в работе]»

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

Доска – это лишь один из инструментов, который помогает увидеть проблемы. Чтобы оптимизировать работу, существуют другие инструменты: ограничение количества задач в работе, управление потоком, 
каденции
 и так далее.

Особенности канбана

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

• Главный показатель эффективности в Kanban – это среднее время прохождения задачи по доске. Если задача прошла быстро – все хорошо. Если время выполнения затянулось, нужно думать, где и почему возникли проблемы.

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

• Вся команда едина – нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Сделать», «В процессе», «Тестирование», «Согласование» и др.

Ограничения канбана

У канбана широкая область применения. Можно сравнить его с ящиком инструментов. Для каждой задачи можно что-то подобрать. При этом каждый будет пользоваться инструментами по-своему. Поэтому канбан можно применить везде, где у вас есть поток задач. Однако, метод будет неэффективен, если нужно разработать новый сложный продукт, для этого лучше подойдет скрам.

Канбан подойдет:

• если у команды много задач и заказов: канбан поможет выявить проблемы и оптимизировать работу;

• для отделов, которые поддерживают операционную деятельность: бухгалтерия, финансовый отдел;

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

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

Компании, которые используют канбан: «Альфа-Банк», «Хоум Кредит Банк», «Почта Банк», «Додо Пицца», HeadHunter, Wargaming, Microsoft, Siemens и другие.

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

Артемий Анцупов 

agile-coach, партнер «Скрамтрэк» 

Отличия Scrum и Kanban

Скрам и канбан часто сравнивают, но сравнение не всегда имеет смысл – они не конкурируют и не исключают друг друга. Скрам поможет решить большую сложную задачу, а канбан – оптимизировать работу с потоком задач.

Артемий Анцупов: «Скрам помогает решить конкретную задачу – разработать новый продукт, как можно быстрее и так, чтобы он был нужен пользователям. Для этой задачи скрам эффективен. Если у вас есть внутренний или внешний сервис – вам пригодится канбан. Отдельные практики канбана могут пригодиться и для других случаев – они помогут разобраться, где конкретно у вас проблема».

Lean Startup – бережливый стартап

Бережливый стартап – это способ разработать и вывести на рынок новый продукт. Концепция сочетает исследование пользователей и итеративный подход.

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

Базовые этапы Lean Startup:

1. Построить минимально жизнеспособную версию продукта;

2. Выпустить ее и оценить метрики;

3. Сделать выводы и собрать идеи для улучшения продукта.

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

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

Бережливый стартап подойдет для:

• снижения рисков при запуске стартапа. Основатель Zappos не знал , готовы ли люди покупать обувь по интернету. Чтобы проверить гипотезу, он сфотографировал обувь в местных магазинах и загрузил фото на сайт. Если обувь заказывали, он покупал ее в магазине и отправлял. Теперь Zappos – большой онлайн-ретейлер обуви.

• оценки жизнеспособности нового продукта, модели, версии. Например, General Electric разработали новую модель холодильника при помощи бережливого стартапа. Они прошли 18 итераций разработки и обратной связи от пользователей перед выпуском финального продукта. 

Компании, которые используют Lean Startup: Dropbox, Zappos, General Electric, Slack, «Модульбанк».

Подробнее о применении бережливого стартапа читайте в статье «Бережливый стартап».

Главное о методах управления проектами в компании

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

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

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

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

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

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

Коротко о главном

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

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

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

Задачи, которые решает эффективное управление проектами

Управление проектами — инструмент достижения стратегических целей. Грамотное управление проектами помогает:

• выделить важные задачи;

• распределить задачи между людьми с подходящими компетенциями;

• разделить рабочий процесс на подзадачи, а подзадачи — на этапы;

• контролировать результаты, дедлайны и бюджет на каждом этапе;

• упорядочить, а иногда и автоматизировать рутинные процессы;

• оценить результативность работы и команды в целом, и каждого сотрудника в отдельности.

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

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

• Частные стандарты. Разрабатываются в компании для проектов определенного типа, например, один стандарт для проектов по созданию сайтов, другой — по их продвижению, третий — по запуску рекламных кампаний в «Яндекс.Директе».

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

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

• Международные стандарты. Это стандарты управления проектами, созданные в какой-то одной стране, но благодаря высокой эффективности применяемые во многих странах. Пример такого стандарта — пожалуй, самый известный — PMBOK (Project Management Body of Knowledge). А его современная и нестандартная альтернатива — SCRUM.

Стандарт управления проектами РМВОК

Стандарт РМВОК был принят Американским национальным институтом стандартов для обеспечения управления проектами в космической отрасли и оборонной промышленности еще в 70-х годах прошлого века. Сегодня стандарт получил мировое признание — он используется в 160 странах, в том числе и в России. РМВОК описывает полный жизненный цикл проекта, разбирает его на процессы, а процессы делит на группы. Вот такие:

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

• Планирование. Этап определяет, как именно будет реализован проект. Утверждается перечень работ, расставляются приоритеты, определяются критерии для оценки эффективности работы, распределяется бюджет. Собирается команда, распределяются обязанности, и для каждой задачи внутри проекта назначается дедлайн (срок выполнения).

• Исполнение. Здесь все очевидно — это реализация всех операций, занесенных в план. Начиная от знакомства проектной команды до определения системы мотивации участников.

• Мониторинг и управление. Суть процессного подхода РМВОК — контроль каждого этапа, а не только конечного итога работы. Такой подход позволяет быстро выявлять ошибки, видеть узкие места, и корректировать действия команды или отдельных сотрудников.

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

Читайте также:
7 советов для тех, кто ищет проджект-менеджера, отвечающего за сайт компании

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

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

В команде в этом случае обязательно участвует SCRUM-мастер. Он следит за реализацией проекта, проводит короткие собрания (Scrum meetings) на которых выявляет проблемы, ктуальные здесь и сейчас, и помогает найти пути их решения. На экспресс-собрании каждый член команды отвечает на три вопроса:

• Что ты делал вчера, чтобы помочь команде успешно завершить спринт?

• Что ты будешь делать сегодня, чтобы помочь команде успешно завершить спринт?

• Какие препятствия ты видишь на пути команды прямо сейчас?

Что важно сделать проджект-менеджеру чтобы проект был успешным

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

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

У любого проекта есть цель — она конкретна, измерима, достижима и имеет срок. Варианты «Мы запускаем новый инструмент, который поможет заказчику проекта получать больше прибыли» — не цель, а намерение. Цель может быть сформулирована так: «Мы разрабатываем интернет-магазин, с помощью которого заказчик будет напрямую продавать свою продукцию в розницу и повысит доходность бизнеса на 5-7 %».

Понимая цель, проджект-менеджер определяет задачи, например:

• собственно разработка сайта;

• прикручивание к нему платежных систем с возможностью сразу оформить и оплатить заказ,

• подключение систем сбора статистики;

• подготовка к продвижению сайта с помощью SEO и контекстной рекламы;

• передача сайта заказчику.

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

Определить этапы реализации проекта

Если вновь обратиться к стандарту управления проектами РМВОК, то каждый проект разбивается на этапы для удобства контроля эффективности: инициация, планирование, исполнение, мониторинг/управление и завершение проекта. Проджект-менеджер определяет конкретное наполнение каждого этапа. Например, в случае с разработкой сайта он расписывает, на каком этапе будет проводиться разработка SEO-оптимизированного контента для всех страниц, включая страницы товарных карточек, а на каком — тестирование, выявление и устранение недочетов. Понятно, что при строительстве торгового центра, или при создании новостного портала, или при выводе на рынок нового продукта наполнение каждого этапа будет совершенно разным.

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

Распределить ключевые роли

По данным исследования FinancesOnline от 2022 года больше 39 % проектных команд состоят из 6-10 человек, и еще 30 % — более, чем из 10 человек.

Скрин-выдержка из исследования

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

• Проджект-менеджер. Отвечает за все — качество, сроки, ресурсы, расходование бюджета, взаимодействие и взаимоотношения в команде.

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

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

• Участники проектной команды. Специалисты в разных сферах, которые привлекаются к реализации проекта — либо полностью, либо на каких-то его этапах. Это могут быть и штатные сотрудники, и фрилансеры, и привлеченные консультанты. Каждый их них предоставляет экспертизу в своей области. В частности, нужных людей на проекты в сфере digital можно найти в специализированном каталоге WorkSpace, где представлены почти 9 000 специалистов.

• SCRAM-мастер. Назначается при выборе системы управления проектами SCRUM.

Добиться согласованности действий и взаимопонимания в команде

Группа коллег — это еще не команда. В команду она превращается при определенных условиях:

• каждый понимает объем и характер работы по проекту;

• каждый готов и способен планировать выполнение своих задач с учетом бюджета и сроков;

• каждый вовремя сообщает проджект-менеджеру о проблемах, рисках, отклонениях от плана;

• каждый сотрудничает с другими членами команды и понимает, что они делают общее дело.

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

Вести документацию и учет всех работ по проекту

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

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

Такие возможности серьезно облегчают контроль для проджекта

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

Читайте также:
Топ-6 планировщиков задач, разработанных в России для российского бизнеса

Прислушиваться к мнению всех участников проектной команды

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

Брейнштормы — это и командообразование, и поиск эффективных решений

Поддерживать конструктивные отношения с заказчиками проекта

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

Читайте также:
Как выявить потребности клиентов: 6 проверенных способов

Мотивировать участников команды

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

Действовать без фанатизма

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

Серьезно готовиться к презентации проекта

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

Читайте также:
Как собрать фидбэк с клиента после проекта

Делаем выводы

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

• Определили цели и задачи проекта.

• Разбили проект на этапы.

• Распределили роли в команде с учетом личностных и профессиональных особенностей каждого участника команды.

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

• Ведете документацию и учет всех действий по проекту с помощью современных таск-менеджеров.

• Проводите брейнштормы и прислушиваетесь к идеям всех участников команды.

• Поддерживаете здоровые рабочие отношения с заказчиками проекта.

• Используете инструменты материальной и нематериальной мотивации.

• Относитесь к проекту ответственно, но без усложняющего всем жизнь фанатизма.

• Рассматриваете презентацию проекта заказчику как важный этап реализации проекта.

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

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

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

Как и любая бизнес-модель или подход, методологии управления проектами имеют ряд преимуществ и недостатков. Некоторые методологии направлены на скорость реализации проекта. Другие больше ориентируются на охват составляющих проекта или управление сотрудничеством. Большинство руководителей проектов считают такие методологии, как Kanban, Agile и Waterfall, основой для разработки проектов, а другие рассматривают их лишь как отправную точку. В данном руководстве мы рассмотрим 7 подходов и методологий:

1. Водопадная модель
2. Agile
3. SCRUM
4. Lean
5. Kanban
6. Prince2
7. Six Sigma

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

Водопадная модель

Водопадная модель, возможно, самая старая из существующих. Уинстон У. Ройс представил ее еще в 1970 году. Он придумал эту методологию как ответ на быстрое развитие отрасли разработки программного обеспечения. Модель является одной из наиболее традиционных и, возможно, наиболее распространенных. На наш взгляд, водопадная модель — самая простая методология для понимания и оптимальная отправная точка для изучения методологий управления проектами. Водопадная модель была основой управления ИТ-проектами в течение многих десятилетий, но и многие другие отрасли, такие как производство или строительство, также ее используют. В основе водопадной модели лежит последовательное планирование этапов работ, с последующим разбиением этапов на задачи. Началом проекта, в соответствии с данной методологией, является сбор требований к проекту, формирование подходов, решений и этапов реализации.

СТАДИИ

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

СИЛЬНЫЕ И СЛАБЫЕ СТОРОНЫ

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

ПРИМЕНЕНИЕ МЕТОДОЛОГИИ

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

Agile

Методология Agile – средство обхода слабых мест водопадной модели. Хотя некоторые концепции Agile используются уже давно, эта методология управления проектами была официально представлена в 2001 году в «Agile Manifesto». Публикация, написанная ведущими экспертами по разработке программного обеспечения, призывала к альтернативе, которая противостояла бы тяжеловесным, ориентированным на документацию, подходам к управлению проектами. Методология фокусируется на проектах, требующих скорости и адаптивности. Гибкое управление проектами основано на краткосрочных «спринтах», а также высокой степени интерактивности и сотрудничества.

ЦЕННОСТИ AGILE

Методология Agile основана на четырех основных ценностях: То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева этих четырех утверждений.
Причина, по которой Agile открыла новые горизонты в управлении проектами, кроется в ее революционной идеологии. Гибко управляемые проекты сумели создать веху, с точки зрения адаптивности, сотрудничества с клиентами и предоставления ценности. Откровенно говоря, Agile, это не методология. Это идеология и подход, которая находит свое отражение в таких методах как: Scrum, Adaptive Project Framework (APF) и Extreme Programming. Основной смысл заключается в следующем: проект может развиваться и изменяться с течением времени, соответственно продукт, решение или результат проекта, также могут меняться вместе с ним.

КЛЮЧЕВЫЕ ПРИНЦИПЫ

В манифесте Agile перечислены двенадцать основных принципов:

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм. Agile помогает наладить устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

УРОВНИ ПЛАНИРОВАНИЯ

В дополнение к вышеприведенным принципам Agile использует шесть уровней планирования:

1. Видение — планирование видения, смысла проекта.
2. Дорожная карта — карта этапов работ, с указанием функционала, который будет реализован в данном этапе.
3. План релиза — каждый этап из карты работ разбивается на релизы.
4. Бэклог — перечень задач, который нужно реализовать, чтобы разработать продукт.
5. Бэклог спринта — перечень задач, который должен быть реализован в конкретном спринте.
6. Приращение функциональности продукта — планирование функциональности, которая будет добавлена продукту, по результатам спринта.

СИЛЬНЫЕ И СЛАБЫЕ СТОРОНЫ

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

ПРИМЕНЕНИЕ МЕТОДОЛОГИИ

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

Scrum

Многие считают Scrum самым простым и наиболее широко используемым методом, связанным с Agile. Он основан на спринтах, которые длятся от двух недель и до тридцати дней. Этот подход служит для определения приоритетов задач, делая акцент на команде. Во время спринтов участники команды проводят 15-минутные встречи, чтобы пересмотреть свои результаты. Вот как работают спринты:

• Команда использует доску для отслеживания списка задач.
• Задачи разделены на несколько списков.
• Люди могут получать задания с доски и приступать к работе.
• Каждое законченное задание проверяется на качество.
• После владельцем продукта задача помечается как выполненная.

Цель – избежать переутомления и истощения. Методология Scrum направлена на стимулирование гибкости, креативности и предоставление высококачественных результатов. В отличие от руководителя проекта, в данном подходе используется понятие «scrum master». Эта роль состоит в том, чтобы устранить любое препятствие и тем самым повысить производительность для самоуправляемой команды. Scrum заимствует многие процессы и принципы из Agile, но использует особый набор тактик и ценностей. Вот пять основных ценностей Scrum, которые фокусируются на человеке и команде:
В соответствии с этими принципами методология Scrum направлена на содействие сотрудничеству, успешной реализации и устойчивости сложных продуктов. И точно так же, как другие подходы Agile, она поощряет итеративное развитие.

РОЛИ, АРТЕФАКТЫ И СОБЫТИЯ

Успешная реализация Scrum зависит от сочетания следующих компонентов:

1. Роли – Владелец продукта, Команда разработки, Scrum-мастер
2. События – Спринт, Планирование спринта, Ежедневный Scrum, Анализ, Ретроспектива
3. Артефакты – Список невыполненных работ по продукту, Список невыполненных работ по спринту.

СИЛЬНЫЕ И СЛАБЫЕ СТОРОНЫ

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

ПРИМЕНЕНИЕ МЕТОДОЛОГИИ

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

Lean

Корни методологии бережливого производства уходят в 1950-е годы, когда ее принципы были применены в производстве Toyota. Этот подход оказал существенное влияние на производство физических товаров, а затем был внедрен в интеллектуальную работу. Бережливое производство использовалось организациями для сокращения производственных отходов, то есть нерелевантных процессов или видов деятельности, и многие говорят, что оно фокусируется на принципе «меньше, значит больше». По сути, методология бережливого производства пытается максимизировать ценность за счет совершенствования и устранения посторонних операций или процессов. Lean — подход к управлению и оптимизации бизнес-процессов, тем не менее, принципы, подходы и инструментарий бережливого производства активно используются в управлении проектами.

ТРИ «M»

Как и Agile, этот подход вращается вокруг принципов и ценностей, а не фиксированной методологии и строгих процессов. Принципы Lean касаются трех основных форм отходов, или трех «M».

• Muda (потери) – Lean определяет семь различных видов потерь, которые могут быть искоренены. Некоторые из них включают транспортировку продукта, перемещение работников или машин, чрезмерную переработку и перепроизводство.
• Mura (нерегулярность) — этот принцип направлен на оптимизацию рабочего процесса за счет уменьшения отклонений и устранения накладных расходов.
• Muri (напряжение) – относится к устранению переутомления, стресса и перегрузки сотрудников. Это может быть результатом неадекватной организации, обучения или неправильных инструментов.

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

ПРИНЦИПЫ

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

СИЛЬНЫЕ И СЛАБЫЕ СТОРОНЫ

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

ПРИМЕНЕНИЕ МЕТОДОЛОГИИ

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

Kanban

Ключевое отличие Kanban заключается в его сильном акценте на визуализацию в процессе разработки. Этот термин относится к 1940-м годам и означает к «сигнальная карта». Сначала карты Kanban использовались Toyota для реорганизации ресурсов и повышения эффективности. В настоящее время Kanban использует методы виртуальной визуализации с помощью систем управления и других инструментов управления проектами.

ВИЗУАЛЬНЫЕ СИГНАЛЫ

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

1. Доска Kanban. Доска (цифровая или физическая) отображает этапы разработки или управления.
2. Карты. Карты Kanban выдаются для каждого задания или предмета. Они могут отслеживать прогресс и сотрудничество, и предоставляя данные (управление крайними сроками, статус и т. д.).
3. Дорожки. Представляют собой особую форму отслеживания и классификации задач. Обычно они имеют горизонтальную планировку и потоки.

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

СИЛЬНЫЕ И СЛАБЫЕ СТОРОНЫ

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

ПРИМЕНЕНИЕ МЕТОДОЛОГИИ

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

PRINCE2

Методология управления проектами PRINCE2 часто ошибочно принимается за структуру PMBOK PMI (Project Management Body of Knowledge), которая дает рекомендации по традиционной методологии водопадной модели. В то время как PMBOK не является официальной методологией, PRINCE2 – это отдельный метод. Фактически он был создан как стандарт для управления проектами в области информационных систем правительства Великобритании. Это полноценная, определяемая процессом методология, основанная на водопадной модели. PRINCE2 делит проект на отдельные фазы, но входы и выходы для каждой из них тщательно определены. Каждый этап имеет свой детальный план, а методология стремится устранить любую неопределенность. Этот подход подробно описывает поставки, обязанности и роли.

ПРОЦЕССЫ

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

СИЛЬНЫЕ И СЛАБЫЕ СТОРОНЫ

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

ИСПОЛЬЗОВАНИЕ МЕТОДОЛОГИИ

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

Six Sigma

Последняя методология управления, которую мы рассмотрим, появилась в результате усилий Motorola по сокращению дефектов продукции в середине 1980-х годов и она также, изначально, предназначена для управления бизнес-процессами. Основная идея, лежащая в его основе, заключалась в повышении качества с последовательным уменьшением ошибок. Первоначально компания хотела, чтобы ее услуги и продукты отражали ее основные технические характеристики для всего процесса проектирования и производства. Этот метод ближе к контролю качества, чем полноценная методология управления проектами. Тем не менее многие из его стратегий могут быть интегрированы в управление проектами. Методология «Six Sigma» в целом основана на данных. Этот метод требует эмпирического анализа, статистики и инженерного опыта.

КЛЮЧЕВЫЕ КОМПОНЕНТЫ

«Six Sigma» базируется на трех основных составляющих:

• DMAIC – определение (Definition), измерение (Measurement), анализ (Analysis), улучшение (Improvement) и контроль (Control).
• DMADV — определение (Definition), измерение (Measurement), анализ (Analysis), проектирование (Design) и верификация (Verification).
• DFFSS – это дизайн для Six Sigma и представляет собой комбинацию двух предыдущих компонентов. Он также может включать в себя такие дополнения, как IDOV, то есть идентификацию (Identification), проектирование (Design), оптимизацию (Optimization) и верификацию (Verification).

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

СИЛЬНЫЕ И СЛАБЫЕ СТОРОНЫ

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

ИСПОЛЬЗОВАНИЕ МЕТОДОЛОГИИ

Методология Six Sigma оптимальна для проектов корпоративного уровня и крупных организаций. Ведущие компании, такие как Boeing, Toshiba и General Electric, являются примерами использования этой методологии. С помощью этого подхода, ориентированного на данные, крупные компании могут повысить качество и эффективность проектов. К сожалению, более мелкие предприятия могут оказаться не в состоянии извлечь из этого выгоду. Небольшие проекты, требующие креативности и скорости, могут пострадать от метода, основанного на данных.

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

Список методологий, проанализированных в данной статье, является довольно исчерпывающим. Другие важные методологии, которые следует принять к сведению, включают Adaptive Framework, PRiSM, Critical Path Method, Critical Chain Project Management, Crystal, PERT, Rational Unified Process, Extreme Programming, Rapid Applications Development, Outcome Mapping и многое другое. Как уже упоминалось, многие методологии основаны на гибких или бережливых структурах, в то время как некоторые проекты склонны отдавать предпочтение гибридным подходам. Некоторые из них могут содержать свои собственные стратегии, компоненты и ценности, которые не связаны с другими методологиями.

Выбор методологии

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

СОСРЕДОТОЧЕННОСТЬ НА РЕЗУЛЬТАТЕ

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

ОЦЕНИТЕ ВАШУ КОМАНДУ

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

РАССМОТРИТЕ ВЕСЬ ПРОЕКТ

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

Заключительные мысли

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

Опыт менеджеров Redmadrobot.

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

Ситуации, при которых появляется необходимость взять на себя обязанности PM (project manager), бывают разные: в маркетинге — при создании сайта, в HR — при организации мероприятий. Мы вспомнили десятки подобных случаев и подготовили список ошибок, которые допускают новоиспеченные руководители проектов.

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

На самом старте

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

Ошибка № 1: отсутствие фиксации договорённостей со стейкхолдерами

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

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

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

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

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

Вариант посложнее: железная команда аналитиков и дизайнеров Redmadrobot на этапе старта проекта всегда собирает паспорт продукта — документ с описанием характеристик и основных целей.

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

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

Ошибка № 2: бездумное формулирование целей и задач в команде

Одна из причин, почему идеи не выдерживают проверку временем — отсутствие «моста реализуемости». Менеджер может понимать цели стейкхолдеров и то, как их достичь, но не представлять вижн результата. Или, всё же видеть желаемый результат, но не учитывать всех трудностей, которые, вероятно, возникнут в будущем.

На выходе мы имеем старое доброе «ничего», а прикрываемся «внешними факторами», «незапланированными активностями» и «кто-то виноват, а мы не подозревали».

Простое решение: вариант для самостоятельного использования — воспользуйтесь одной из проверенных временем методологий постановки задач, например, SMART. Мы часто используем в работе подходы DoD и DoR .

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

Вариант посложнее: изучите вместе с коллегами одну из методологий постановки задач и грамотно её внедрите. Для этого разделите планирование результатов на несколько итераций, после чего сделайте deep dive (погружение в проект) всей команды по методологии постановки задач.

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

Ошибка № 3: перекладывание ответственности

Здесь всё просто: ответственность и распределение ролей в команде должны быть понятны всем участникам. В какой-то момент (а он точно может наступить, поверьте) придётся разбираться, почему что-то пошло не так и кто-то не выполнил важную задачу.

А в том случае, если в проекте что-то пойдёт не по плану, менеджер должен чётко понимать, в какой его части произошёл сбой. Иначе PM рискует поставить под угрозу результаты работы и деморализовать всю команду.

Одно из лучших решений для создания «прозрачности» — использовать матрицу ответственности. Её можно выбрать исходя из сложности проекта, размера команды и предпочтений.

Простое решение, если не хотите заморачиваться и у вас небольшой проект:

Главное — договоритесь о том, как планируете взаимодействовать в команде и зафиксируйте это любым удобным способом: текстом, в Miro или, например, набросайте mind map — как вам удобно.

Вариант посложнее: для крупных проектов можно сделать ролевую модель проекта в виде карты и добавить описание функций каждой роли (это можно сделать, например, в Miro).

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

По ходу реализации: про реализацию

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

Ошибка № 4: отсутствие инструментов для командной работы

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

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

Простое решение: не гонитесь за модой — используйте доступные и универсальные инструменты, такие как Trello или Google-таблицы.

Благодаря своей системе карточек, Trello отлично подойдёт для распределения задач. В них вы можете фиксировать важные части проекта: процесс выполнения работ, ведение сделок и заявок, организацию документооборота и другие вещи. Ну а Google-таблицы хороши своей многозадачностью. В Redmadrobot команды часто используют их в самых разных делах:

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

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

Ошибка № 5: отсутствие чётких приоритетов

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

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

Простое решение: если у вас небольшой проект, то используйте методологию MоSCоW — она хорошо подходит для определения приоритезации. Также обратите внимание на методологии RICE и ICE.

Вариант посложнее: в крупном проекте поможет формирование собственной системы приоритезации входящих задач. Её можно построить на базе Google-таблиц или Trello.

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

Ошибка № 6: отсутствие контрольных точек и оценки результата

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

Решение:

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

По ходу реализации: про взаимодействие

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

Ошибка № 7: неинформирование команды

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

Решение:

Ошибка № 8: отсутствие реакции на изменения или критичные ситуации

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

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

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

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

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

И в конце

Проект всегда имеет конечные точки и финал. Соберитесь силами и не допустите в них последних двух ошибок.

Ошибки № 9 и № 10: отсутствие рефлексии и подведения итогов

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

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

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

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

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

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

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

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

Урок 4. Методы управления проектами

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

Ниже мы расскажем о следующих методах:

• Agile
• Scrum
• Lean
• Kanban
• Six Sigma
• PRINCE2

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

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

Agile

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

Упрощенная схема работы по Agile выглядит так:

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

Преимущества Agile:

• Адаптивность и гибкость (его можно подстраивать под разные процессы и условия)
• Быстрое и относительно безболезненное реагирование на изменения
• Прекрасно подходит для разработки инновационных продуктов с высоким уровнем неопределенности и низкой информативности

Недостатки Agıle:

• Не является методом
• Необходимость каждый раз составлять новую систему управления на основе принципов подхода Agıle
• Применение подхода сопряжено с изменениями процедур реализации проекта и базовых ценностей
• Требует знаний, упорства, больших затрат и административных ресурсов (для облегчения применения подхода принято использовать методы Scrum, Kanban и другие)

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

Scrum

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

Наиболее важные части первыми отбираются для выполнения в спринте (спринты в Scrum – это итерации продолжительностью от 2 до 4 недель). По итогам спринта заказчик получает рабочий инкремент продукта, т.е. готовые к использованию части. Как только один спринт закончен, проектная команда начинает следующий спринт. Продолжительность спринтов всегда одинакова, но команда всегда сама устанавливает ее, оценивая свою производительность и особенности проекта.

Упрощенная схема работы по Scrum такова:

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

Вся процессуальная структура метода вращается вокруг пяти основных встреч:

• Упорядочивание беклога. Встреча напоминает планирование, рассмотренное нами в первом уроке. Проводить ее нужно в первый день нового спринта. На встрече обсуждается то, что уже удалось сделать по проекту и что еще нужно сделать, и определяются дальнейшие шаги. Инициатор ставит задачи, соответствующие новому этапу. Упорядочивание беклога определяет результативность нового спринта.
• Планирование спринта. После расстановки приоритетов и определения задач инициатором команда принимает решение о своих действиях на протяжении наступающей итерации и ищет способы достижения поставленной цели. Для этого могут использоваться самые разные инструменты планирования и оценки (важно, чтобы они соответствовали принципам метода). Планировать спринт нужно в самом начале итерации, но по окончании встречи по упорядочиванию беклога.
• Летучки.
• Подведение итогов спринта. На этом этапе исследуется и адаптируется созданный продукт. Члены команды делятся своими результатами со всеми заинтересованными лицами. Главной задачей здесь является удостовериться в том, что продукт спринта соответствует целям проекта и ожиданиям участников проекта.
• Ретроспектива спринта. Этап, проводящийся сразу же после предыдущего, но до того как начнет планироваться новый спринт. Команда определяет степень четкости и слаженности пройденного этапа, исследует появившиеся проблемы в методологии, работе и взаимодействии. Благодаря ретроспективе команда может сделать выводы и повысить эффективность следующего спринта.

Преимущества Scrum:

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

Недостатки Scrum:

• Высокая требовательность к проектной команде (нужно, чтобы в команде было от 5 до 9 человек, и все члены команды должны обладать сразу несколькими компетенциями, необходимыми для реализации проекта, благодаря чему сотрудники могут дополнять и заменять друг друга, а работа никогда не будет стоять на месте)
• Все сотрудники должны уметь и хотеть работать в команде, быть способны к самоорганизации и активно брать на себя ответственность
• Подходит не для всех организаций и команд, т.к. схема работы по методу подходит для разработки далеко не каждого продукта (например, построить здание или создать промышленный станок по методу Scrum будет невозможно)

Многие считают, что метод «Скрам» сложен для внедрения, указывая на необходимость в делегировании полномочий, необычную организационную структуру и т.п., однако при умелом использовании и благодаря своей гибкости метод не позволит работе пойти в неверном направлении. Это существенно отличает Scrum от общих принципов Agile.

Lean

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

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

Ниже представлена упрощенная схема работы по Lean:

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

Преимущества Lean:

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

Недостатки Lean:

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

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

Kanban

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

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

Упрощенная схема работы по Kanban выглядит так:

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

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

Созданная индивидуально система Kanban может обладать такой гибкостью, какая вам нужна. Но есть все же несколько основ, на которых зиждется вся эта система:

• Карточки. Должны создаваться для всех задач отдельно. В карточках фиксируется вся нужная информация о текущей задаче. Это очень удобно, т.к. к карточке можно обратиться в любое время.
• Ограниченное количество задач на одном этапе. Количество карточек для одного этапа всегда регламентировано. Это позволяет отслеживать возникновение «заторов» в потоке операций и сразу же его устранять.
• Постоянный поток. Задачи беклога поступают в поток, исходя из их приоритетности. Это и создает непрерывный рабочий процесс.
• Непрерывное улучшение. Здесь основой служит японская концепция постоянного улучшения «Кайдзен», суть которой состоит в перманентном анализе рабочего процесса и поиске путей повышения его эффективности.

Преимущества Kanban:

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

Недостатки Kanban:

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

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

Six Sigma

Метод Six Sigma или, проще говоря, «6 сигм» представляет собой более структурированную версию Lean, причем даже более структурированную, чем Kanban. Она отличается еще большим планированием, что позволяет экономить ресурсы, повышать качество продукта и минимизировать объем потерь и брака.

Так можно изобразить упрощенную схему работы по Six Sigma:

Цель любого проекта заключается в удовлетворении заказчика качественным продуктом. Качества можно добиться благодаря непрерывному процессу улучшения всех составляющих проекта, основанному на доскональном анализе его показателей. «6 сигм» в самой подробной форме разбирает методы устранения сопутствующих проекту проблем. Основной этого подхода служит алгоритм DMEDI, состоящий из 5 шагов:

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

Преимущества Six Sigma:

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

Недостатки Six Sigma:

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

Метод «6 сигм» напоминает «Канбан», но устанавливает конкретные этапы реализации задач – планирование, постановку целей и тестирование качества. Также Six Sigma требует более частых встреч команды, но сам процесс осуществления проекта будет более понятен, а команда всегда сможет придерживаться намеченного плана.

PRINCE2

От прочих методов проектного управления PRINCE2 (от англ. PRojects IN Controlled Environments version 2) отличатся отсутствием итеративного подхода. По сути, это гибрид классического проектного управления с концентрацией на качестве, как это делается в Six Sigma.

Схематично процессы работы по PRINCE2 выглядят так:

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

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

• Бизнес-аспект: выгоден ли проект?
• Потребительский аспект: какой нужно создать продукт?
• Ресурсный аспект: есть ли возможности и ресурсы для достижения цели?

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

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

Сами же процессы можно охарактеризовать так:

• Старт проекта. В ходе первого процесса назначается руководитель, и устанавливаются общие требования к характеристикам конечного результата. Проект-менеджер должен уделять особое внимание деталям и давать отчет Управляющему комитету проекта, отвечающему за общее руководство проектом и успех его реализации.
• Инициация проекта. В ходе второго процесса руководителем составляется «Документация по инициации проекта», содержащая в себе разбитый на стадии план проекта. Стадии всегда следуют одна за другой, но по продолжительности вполне могут различаться.
• Руководство проектом. Третий процесс основан на том, что дает Управляющему комитету возможность нести общую ответственность за успех реализации задумки без погружения в детали, находящиеся в области полномочий проект-менеджера.
• Контроль стадии. Даже если проект осуществляется в идеальных условиях, в него будут вноситься какие-то поправки. Четвертый процесс необходим для реализации одного из принципов PRINCE2 – принципа управления по исключениям. Руководитель проекта должен выявлять отклонения от заданных параметров проекта (сроки, качество, бюджет и т.д.) в ходе выполнения стадии. В случае, когда отклонения превышают полномочия (допуски) руководителя, он должен поставить об этом в известность Управляющий комитет и предложить варианты решения возникших проблем.
• Управление созданием продукта. Пятый процесс – это взаимодействие руководителя и его команды, направленное на создание одного из проектных продуктов. К числу обязанностей руководителя добавляется делегирование соответствующих полномочий менеджеру команды и приемка готового продукта.
• Управление границами стадии. В ходе шестого процесса руководитель снабжает Управляющий комитет всей информацией, позволяющей оценить результаты завершенной стадии и принять решение о переходе к следующей стадии.
• Завершение проекта. Процесс завершения проекта является частью финальной стадии создания продукта. Его цель состоит в подтверждении или факта принятия продукта, или факта того, что проект не принесет больше ничего стоящего.

Преимущества PRINCE2:

• Легко адаптируется к особенностям организации
• Имеет четкое описание ролей и распределения ответственности
• Концентрируется на продукте проекта и экономической целесообразности
• Имеет конкретные уровни управления
• Позволяет последовательно выстроить проектную работу
• Фиксирует опыт и позволяет постоянно совершенствоваться

Недостатки PRINCE2:

• Отсутствуют отраслевые практики
• Отсутствуют конкретные инструменты для проектной работы

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

Управление проектами – это, пусть и не совсем точная, но серьезная наука. Конечно, в ней вряд ли удастся отыскать универсальные решения и основы, однако если вы сможете найти такой метод проектного управления, который подойдет вашему проекту по большинству параметров, вы можете быть уверены, что достичь успеха – в ваших силах. Главное – это применять метод, в котором есть хоть какая-то структура, а также использовать в своей проектной деятельности вспомогательные инструменты, такие как системы управления проектами, например, MS Project, Asana, Wrike, Basecamp и другие. И о самых популярных системах вы узнаете из заключительного урока, после чего в вашем распоряжении будет вся основная информация по управлению проектами.

Проверьте свои знания

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

← 3 Управление рисками5 Системы управления →