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

Product University

Подробное руководство по управлению проектами

Части 1, 2

Всё, что нужно знать об управлении проектами

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

Возможно. Но для начала вам нужен план.

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

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

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

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

Кому пригодится это руководство?

Проекты бывают самые разные. Собираетесь изобрести что-то новое со своей командой? Это проект. Ремонтируете кухню? Тоже.

Эта книга начинается с самых основ управления проектами, она познакомит вас с такими терминами, как Lean, график Ганта, Scrum и другими. Она придётся очень кстати начинающим менеджерам проектов или тем, кому трудно справиться со всеми навалившимися проектами.

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

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

Введение в управление проектами

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

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

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

Видите ли, проект — это всего лишь «предложенное или спланированное дело». А значит, система управления проектами — это способ спланировать такое дело. Начинать всё делать сразу или разделить на задачи поменьше? Что нужно сделать, прежде чем приступать к выполнению новой задачи? На эти и другие подобные вопросы отвечает ваша система управления проектами.

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

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

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

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

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

Приложения для управления проектами

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

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

Дополнительные материалы, чтобы справиться со всем остальным

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

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

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

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

Настало время запустить ракету, о которой вы мечтали. Приступим.

Основы управления проектами: Подробное руководство по Agile, Kanban, Scrum и многому другому

«Пожалуй, главной сложностью в миссии НАСА по отправке человека на Луну в рамках программы «Аполлон» было управление проектом.»

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

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

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

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

РАСПРОСТРАНЁННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ ПРОЕКТАМИ

• Традиционное управление проектами
• Agile
• Scrum
• Lean
• Kanban
• Six Sigma
• PRINCE2

Зачем нужно управление проектами?

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

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

Согласно книге НАСА «Управление программой полёта на Луну», главным вопросом было не «Что делать?», а «Как успеть столько всего сделать за такой короткий срок?». «Мы знали, что нужно было делать,» — вспоминает доктор Макс Фаже, руководитель инженерного отдела Космического центра имени Линдона Джонсона. «Но до объявления президента нам не приходилось задумываться о том, как всё это сделать за десять лет. Тем не менее, для начала мы просто поделили программу на несколько этапов.»

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

Эта система c пятью блоками, названная «Блоками GEM» по инициалам Мюллера в его честь, была создана, чтобы сразу же сосредоточиться на необходимости тестирования и создании таких объектов, которые можно протестировать. В блоке программного управления содержалось описание всего необходимого, распределялся бюджет, обозначались требования и то, как все элементы системы должны работать вместе. Системная инженерия отвечала за разработку новых объектов, тестирование позволяло убедиться, что они работают должным образом, область надёжности и качества проверяла эти объекты на соответствие стандартам, а управление полётами исследовало их работу в условиях полёта.

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

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

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

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

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

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

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

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

Диаграмма Ганта, изобретённая в начале 20 века одновременно Каролём Адамецким и Генри Гантом, представляет собой график проекта, изображающий даты его начала и конца. Нужно записать, сколько времени уйдёт на каждую задачу и отметить, если некоторые задачи необходимо выполнить раньше других — например, нельзя подать блюда на стол, не приготовив их заранее. Затем можно определить «критический путь» действий, которые нужно завершить к определённому времени, и рассчитать, сколько всего времени уйдёт на проект.

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

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

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

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

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

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

Ключевые термины проектного управления

• Agile — гибкая итеративная методология управления проектами, в рамках которой задачи выполняются согласно определённым этапам
• Критический путь — список критически важных задач, которые необходимо выполнить, чтобы завершить проект; совокупность таких задач позволяет определить, сколько времени уйдёт на проект
• Диаграмма цепочки событий — диаграмма событий проекта и их порядка, основанного на доступности ресурсов
• Запас времени (float) — срок, на который можно откладывать выполнение задачи, не вызывая при этом промедления в ходе выполнении других задач или всего проекта
• Диаграмма Ганта — диаграмма-календарь, которая демонстрирует время выполнения каждой задачи в проекте; подвид диаграммы цепочки событий с упором на время
• Веха (milestone, контрольная точка) — время выполнения важной задачи в проекте
• Менеджер проекта — участник команды, основная задача которого заключается в планировании, реализации и завершении проекта
• Ресурсы — важные составляющие проекта, такие как время, оборудование, материально-технические средства, участники команды и другие
• Содержание проекта (scope) — объём работ проекта; если он растёт, когда проект уже в работе, происходит «расползание границ проекта»
• Спринт — также иногда называется итерацией; срок, за который выполняется некая часть проекта и демонстрируется результат работы
• Традиционное управление проектами — базовая система управления проектом, в рамках которой задачи выполняются последовательно одна за другой

Итак, вооружившись этими знаниями, можно отправляться на поиски системы управления проектами, которая подойдёт вашей команде. Для начала мы рассмотрим традиционное управление проектами и Agile — две основные концепции, на которых основано большинство остальных систем, после чего углубимся в Scrum, Kanban, Six Sigma и другие.

Традиционное управление проектами

Традиционное управление проектами представляет собой, пожалуй, самый очевидный способ организации рабочего процесса и зачастую называется «каскадом», поскольку подразумевает последовательное выполнение задач по одной за раз. Эту систему можно представить в виде всеми любимой игры «Candy Crush»: на новый уровень не перейти, пока не будет пройдён текущий (и, надеемся, вашим проектом так же весело заниматься, но он не вызывает нездорового пристрастия).

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

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

• Этап запуска: Менеджер проекта и команда определяются с требованиями продукта. Также этот этап называют «этапом установления требований», но, по сути, это просто мозговой штурм, при котором составляется список всего необходимого для завершения цели проекта.

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

• Этап реализации и тестирования: Именно на этом этапе начинается непосредственная разработка и интеграция продукта. Команда создаёт продукт, руководствуясь детальным планом, и оценивает процесс разработки согласно метрикам, заданным на предыдущих этапах. Каждая стадия реализации состоит из подэтапов, а после наступает время тестирования. Тестирование так же важно, как и этап проектирования, поскольку оно позволяет обнаружить и исправить неполадки, будь то ошибки кода при разработке ПО или неправильно размещённая электропроводка в строительном проекте. После тестирования всё, что требует доработки, возвращается на этап реализации, и этот цикл повторяется, пока проект не будет завершён.

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

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

Поскольку при традиционном управлении проектами делается упор на время, в рамках этой системы удобно пользоваться большинством популярных инструментов планирования. Можно составить список этапов в приложении для списков дел или разметить сроки работы в календаре. Тем не менее, лучшим инструментом традиционного планирования остаётся старая-добрая диаграмма Ганта, которая позволяет наглядно представить каждый этап проекта и время его выполнения. Её можно составить в таблице вроде Smartsheet или в традиционном инструменте планирования, например, Microsoft Project.

ПРЕИМУЩЕСТВА ТРАДИЦИОННОГО УПРАВЛЕНИЯ ПРОЕКТАМИ

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

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

НЕДОСТАТКИ ТРАДИЦИОННОГО УПРАВЛЕНИЯ ПРОЕКТАМИ

Основным недостатком традиционного управления проектами является недостаток гибкости. Оно словно старое высохшее дерево, которое нельзя толком изменить. Даже компанию Toyota, на заводах которой впервые стали применять такие системы управления проектами, как Lean и Kanban, критикуют за использование традиционной системы управления проектами для разработки ПО, поскольку её сложно адаптировать к изменениям.

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

Agile

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

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

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

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

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

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

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

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

Scrum

Пожалуй, Scrum — это самый структурированный фреймворк, основанный на принципах Agile. Он появился в 1986 году как способ «наладить взаимодействие нескольких команд, работающих ради единой цели», согласно его изобретателям Икуджиро Нонаке и Такеучи Хиротаке. Scrum сочетает в себе идеи традиционного проектного управления и Agile, являясь одновременно структурированным и гибким способом управления проектами.

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

По окончании каждого спринта в Scrum проводится повторная оценка и, при необходимости, вносятся изменения в проект. Это позволяет гарантировать, что проект придерживается курса и соответствует целям, которые могли измениться в процессе. Обязанности в Scrum разделены между тремя ролями: владелец продукта (Product Owner, PO), скрам-мастер и команда.

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

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

• Совещание по упорядочиванию бэклога (backlog refinement meeting, backlog grooming): Это совещание напоминает этап планирования в традиционном подходе к управлению проектами и проводится в первый день каждого спринта. Команда рассматривает, какие задачи проекта ещё не выполнены и что осталось сделать с предыдущего спринта, а также решает, чему уделить внимание. Владелец продукта определяет порядок выполнения задач, что напрямую обуславливает эффективность спринтов.

• Планирование спринта (sprint planning): Это совещание помогает команде понять, над чем ей предстоит работать и зачем, основываясь на решениях владельца продукта. Здесь можно использовать «пользовательские истории» с описанием характеристик продукта с точки зрения клиента или просто разделить задачи между командами, работающими над данным спринтом.

• Ежедневные скрам-совещания (daily scrum meetings, летучки): Это простые совещания, которые проводятся ежедневно и длятся около 15 минут. На них члены команды информируют друг друга о подвижках в работе. Такие совещание не подходят для обсуждения проблем, которые направляются скрам-мастеру в другое время, а просто нужны, чтобы обменяться информацией.

• Обзор итогов спринта (sprint review): В методологии Scrum особое внимание уделяется обзору результатов работы, поскольку они должны быть презентованы в том или ином виде по окончании каждого спринта. На таких совещаниях команда демонстрирует стейкхолдерам, что удалось сделать. Несмотря на то, что этот процесс способствует соблюдению подотчётности, его главная задача — убедиться, что результаты спринта соответствуют бизнес-целям и пользовательским требованиям.

• Ретроспективное совещание по спринту (sprint retrospective): Это совещание проводится сразу после обзора итогов спринта и предназначено для обмена обратной связью. Команда обсуждает успехи и неудачи спринта и решает, что работает (что стоит продолжать делать), а что — нет (что стоит перестать делать). Это позволяет понять, на чём сосредоточиться в рамках следующего спринта.

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

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

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

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

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

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

Lean

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

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

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

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

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

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

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

Kanban

Сам по себе Lean может звучать довольно абстрактно, но из него легко создать свою систему управления проектами при помощи Kanban. Этот подход был придуман инженером компании Toyota по имени Тайчи Оно и впервые применён в 1953 год. Kanban напоминает производственный цех, где кусок металла шаг за шагом превращается в готовую деталь. Итак, Kanban предполагает, что вы работаете над какой-то частью проекта, а затем отправляете её дальше по конвейеру на следующую станцию, где над ней продолжат работу.

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

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

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

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

• Карточки («Kanban» переводится как «наглядная карточка»): У каждой задачи есть своя карточка со всей важной информацией о ней, благодаря чему всегда понятно, что необходимо для реализации данной задачи.
• Ограничение по количеству задач в обработке: Ограничьте количество карточек, по которым работаете одновременно. Это позволит избежать чрезмерной нагрузки на команду.
• Беспрерывность рабочих процессов: Отсортируйте задачи по степени важности и работайте над ними в соответствующем порядке так, чтобы всегда над чем-то работать.
• Постоянное улучшение (также известно как технология кайдзен, «kaizen»): Анализируйте рабочий процесс с целью определить его эффективность и стремитесь постоянно её улучшать.

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

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

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

Six Sigma

Компания Motorola решила посоревноваться с автомобильной индустрией в разработке систем проектного управления, и в 1986 году, через несколько десятилетий после внедрения Kanban, инженер Motorola по имени Билл Смит изобрёл Six Sigma. Это версия системы Lean, которая более структурирована, чем Kanban. Six Sigma включает в себя конкретные этапы работы и методики планирования, призванные сэкономить ресурсы, добиваться качественных результатов и избавляться от ошибок и проблем по ходу работы.

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

Это становится возможным благодаря пяти этапам работы в системе Six Sigma, которые называются «DMEDI»: Define, Measure, Explore, Develop и Control.

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

• Measure / Измерение: Поскольку Six Sigma делает большой упор на данные, на этапе измерения определяются показатели, по которым команда будет измерять успех работы. В основе этого подхода лежит идея о том, что степень успеха — то есть ценность продукта для клиента и для бизнеса — можно измерить.

• Explore / Исследование: На этапе исследования менеджер проекта решает, каким образом команда будет удовлетворять требованиям продукта. Это позволит работать в рамках бюджета и не срывать сроки. Менеджеру проекта важно уметь мыслить нестандартно, чтобы находить новые пути решения проблем.

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

• Control / Контроль: На последнем этапе делается упор на долгосрочное улучшение процесса работы, к которому всегда стремятся проекты на Six Sigma. Полученный опыт документируется в виде рекомендаций и применяется к работе всей компании и будущим проектам.

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

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

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

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

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

PRINCE2

НАСА было не единственной правительственной организацией, стремившейся усовершенствовать модель проектного управления. Правительство Великобритании много лет оттачивало методы управления проектами, и результатом этой работы стал подход PRINCE2, зародившийся в 1989 году. PRINCE2 — это акроним от «PRojects IN Controlled Environments version 2» или «Проекты в контролируемых средах, 2 версия». В рамках этой системы весь проект воспринимается как один большой спринт, а упор делается на качество финального продукта, что напоминает смесь традиционной модели управления проектами и Six Sigma. Этот фреймворк уделяет особое внимание конечному результату, а не процессу работы. Именно требования к конечному продукту определяют объём работ и подход к планированию.

В PRINCE2 учитываются три типа интересов: деловой интерес (принесёт ли это прибыль?), интересы пользователей (принесёт ли это ценность пользователям?) и интересы поставщика (есть ли у нас всё необходимое для реализации?).

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

• Начало: Первым делом руководство назначает менеджера проекта и чётко заявляет о своих ожиданиях от продукта. Главная задача менеджера проекта — уделять внимание деталям. Он отчитывается перед проектным комитетом, который задаёт направление работы. Проектный комитет следит за тем, чтобы проект придерживался курса, и отвечает за его успех. Их всех остальных сотрудников образуется команда проекта.

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

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

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

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

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

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

Такая организация процесса может оказаться слишком громоздкой для некоторых проектов, поэтому вы можете изменить этапы под себя, придерживаясь основной структуры, порядка планирования и подотчётности PRINCE2. Если Scrum — это более структурированная версия Agile, то PRINCE2 — более структурированная версия традиционной модели управления проектами, дополненная преимуществами подхода Lean.

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

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

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

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

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

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

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

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

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

Традиционная система + Agile

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

Именно так поступило агентство по разработке ПО Panoptic Development, изменив традиционную каскадную модель под свои нужды. Шэннон Льюис, отвечавшая за проект, хорошо знала каскадную модель и понимала её ограничения, из-за которых пришлось бы пожертвовать качеством, функциональностью или сроками.

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

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

Работа над многими проектами не заканчивается никогда, как, например, в отрасли переработки отходов штата Кентукки. Население США является крупнейшим потребителем алюминиевых банок в мире, поэтому Secat Inc, металлургическая исследовательская лаборатория, объединила силы с Университетом Кентукки и алюминиевой промышленностью, чтобы увеличить темпы и объёмы переработки алюминия.

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

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

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

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

Какая система управления проектами лучше всего подойдёт вам

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

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

18 марта в Product Univeristy стартует программа «Менеджер проектов». За 8 недель, онлайн, ты разберешься в методологиях управления проектами, изучишь необходимые процессы и инструменты, отточишь все на практике.

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

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

Полезные шаблоны
каждую среду

на ваш email