Лучшие статьи по средам
Не отображается письмо? Читать в браузере.

Подписаться на рассылку Product University.
Подробное руководство по управлению проектами
Часть 1
Выпуск № 44. Перевод статьи Matthew Guay
Всё, что нужно знать об управлении проектами
Всё началось с идеи: ваша команда создаст нечто потрясающее. Может, вы разработаете новое феноменальное приложение, добавите функцию, которую пользователи давно ждали, или напишите книгу, о которой раздумываете годами. Может, вы запустите человека на Марс, посадите ракету на корабль или изобретёте новый вид автомобилей.

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

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

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

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

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

Эта книга начинается с самых основ управления проектами, она познакомит вас с такими терминами, как 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» по инициалам Мюллера в его честь, была создана, чтобы сразу же сосредоточиться на необходимости тестирования и создании таких объектов, которые можно протестировать. В блоке программного управления содержалось описание всего необходимого, распределялся бюджет, обозначались требования и то, как все элементы системы должны работать вместе. Системная инженерия отвечала за разработку новых объектов, тестирование позволяло убедиться, что они работают должным образом, область надёжности и качества проверяла эти объекты на соответствие стандартам, а управление полётами исследовало их работу в условиях полёта.

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

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

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

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

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

Тут в игру вступает один из первых современных инструментов управления проектами, диаграмма Ганта.
Список задач с календарём-диаграммой Ганта, созданный при помощи Smartsheet
Диаграмма Ганта, изобретённая в начале 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 бывает непросто сосредоточиться на работе и довести проект до конца. Всё меняется, и нет единого процесса, который гарантировал бы последовательное продвижение проекта к завершению, ввиду чего становится проще сбиться с курса.

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

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

Разрабатывая каждую новую итерацию сайта, команда тестирует новые функции, отсекает неподошедшие и придумывает новые. Основное преимущество Scrum, которое так приглянулось Netflix — это возможность совершать ошибки и быстро их корректировать. Вместо того, чтобы полностью переделывать сайт, разработчики дважды в месяц внедряют изменения, которые легко отследить, и если что-то идёт не так, выявить и быстро устранить причину не составляет труда.
НЕДОСТАТКИ SCRUM
У Scrum есть несколько минусов, и один из них — потенциально раздосадованные разработчики, которым грустно видеть, как их идеи проваливаются при тестировании. А раз тестирования проводятся очень быстро, может казаться, что новая идея сработала бы, если бы ей уделили больше времени. Также команде, привыкшей к длинному циклу разработки, может быть сложно перестроиться. Более того, может оказаться, что в вашей сфере необязательно так часто презентовать результаты работы.

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

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

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

МЕНЕДЖЕР ТЕХНОЛОГИЧНЫХ ПРОЕКТОВ

Научись получать результаты быстрее и дешевле

Бесплатная программа акселерации. Оплата только в случае трудоустройства. 8 недель в онлайне.
Смотреть программу курса
Понравился выпуск? Перешлите его друзьям, кому может быть интересна эта тема.
*|POLL:RATING:x|* Оцените эту рассылку по 10-бальной шкале. С какой вероятностью вы порекомендуете ее знакомым? *|END:POLL|*
© 2020 Product University
119311, Москва, Вернадского 9/10
a@productuniversity.ru
+7 499 938 66 46

отписаться от рассылок