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

Прежде чем углубиться в эти методы, давайте ответим на довольно очевидный вопрос: «Зачем вообще нужная система управления проектами?», а также рассмотрим краткую историю управления проектами и дадим определение основным терминам в этой области.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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