Эффективно работаем и быстрее решаем задачи
Управление проектами — процесс, который помогает согласовать действия команды для решения какой-то задачи.
Например, компании нужно создать сайт. Сначала она планирует будущий ресурс и думает, как он поможет клиентам. Потом нанимает разработчиков, дизайнеров, копирайтеров и ставит им задачи. Когда сайт создан, его передают на следующий этап — продвижение, а затем — на оценку эффективности для бизнеса.
По сути это и есть управление проектами: перед бизнесом стоит задача → он решает её с помощью планирования и постановки заданий → оценивает готовый продукт.
А когда разберетесь с методами и этапами и будете выбирать надежную и удобную систему управления проектами, обратите внимание на Projecto. Здесь есть всё что нужно для ведения личных и рабочих задач: календарь, канбан-доски и диаграммы Ганта, наглядное делегирование и распределение ролей, удобные отчеты и уведомления. Платить сразу необязательно, демо-версия предоставляется на 30 дней.
Есть несколько методов управления проектами: Waterfall, Agile (Scrum и Kanban), Lean, Six Sigma, CPM. Выделяют и другие, но мы остановимся на часто используемых в бизнесе.
Такую классификацию мы составили благодаря статье на сайте Asana — компании, которая помогает управлять бизнес-процессами. Но классификация Asana — не единственная. Некоторые проджект-менеджеры распределяют методы по-своему.
На самом деле, существует всего два метода управления проектами: Waterfall — классический метод управления проектами, и Agile — гибкое управление проектами.
Есть ещё такое понятие как методики — это готовый алгоритм применения метода. К методикам относятся Scrum, Kanban, Lean, Six Sigma и пр.
Каскадный метод, его ещё называют классическим, — это линейный подход к процессу, в котором работа разбивается на несколько этапов. Команда завершает один этап — и начинает следующий.
Работает метод так: менеджер проекта собирает требования и пожелания от заказчика → создаёт проект → внедряет его → тестирует → дорабатывает недостатки → снова внедряет в бизнес.
Метод Waterfall применяют для больших и длительных проектов, которые не получится выполнить одним этапом.
Например, нельзя запустить email-рассылку, пока у компании нет готовой базы, созданного контента и продукта, который она будет продвигать через письма. Другой пример — строительство дома. Оно всегда разбивается на этапы, потому что нельзя поставить крышу, пока не залит фундамент.
Плюсы метода. Легко делить работу на этапы и соблюдать очерёдность.
Минусы метода. Нельзя корректировать процесс работы. Не подходит для задач, где есть много подпроектов. Например, разработка программного обеспечения в IT-сфере.
Современным компаниям я рекомендую присмотреться к классическому методу управления и адаптировать под потребности своего проекта.
В этом случае ТЗ станут более чёткими и понятными для исполнителя и, как результат, будет меньше доработок и разногласий.
Конечно, не всегда можно использовать классический метод, но использовать частично и миксовать с гибким методом — вполне реально. Вот небольшой чек-лист от меня, который поможет определить, подходит вам каскадный метод управления:
- ваш проект — со строгим бюджетом и сроками, например, строительная и инженерная сферы;
- проект с неизменным содержанием, т.е. такой, в котором нельзя вводить изменения по ходу выполнения.
Этот метод делится на Scrum и Kanban.
Scrum. Делит всю работу на несколько коротких промежутков времени — спринтов. Команды собираются на короткие совещания, на которых планируют будущую работу на 15 или 30 дней. Потом собираются вновь и «планируются» на следующие 15 или 30 дней. И так далее. Благодаря Scrum-методу команды не перегружаются и всегда могут перераспределить приоритеты в проектах.
Сам процесс начинается с бэклога — списка работы, которую нужно выполнить. В Scrum есть два бэклога:
Затем команда проводит спринт — работает 2 или 4 недели и каждый день собирает небольшие совещания или созвоны. Это помогает проверить, на какой стадии спринта находится компания. После очередного спринта компания выпускает на рынок готовый продукт либо оценивает спринт и формирует задачи на следующий.
Scrum подходит для стартапов, малого, среднего и крупного бизнесов. Например, по такой методологии работают Amazon, Apple и Microsoft.
Kanban. Если Scrum фокусируется на спринтах, то Kanban — на задачах. В его основе лежат интерактивные доски для управления проектами, в которых рабочий процесс и прогресс видны всем участникам.
Такая методика подходит для любых бизнес-процессов. Обычно её используют в виде карточек, которые перемещают слева направо по интерактивной доске. А саму доску делят на несколько колонок. Например:
Плюсы обоих методов. Гибкая структура, поэтому можно менять план в процессе работы.
Минусы обоих методов. Нет чёткого плана, поэтому реализация проекта может затянуться. Конечный проект может долго создаваться и постоянно масштабироваться, потому что конечной даты сдачи никто не устанавливает. Регламентируются только промежуточные спринты.
Применять метод Agile можно в нескольких случаях:
- Если постоянно меняется содержание проекта, например, разработка и обновление приложений.
- Если нет понимания конечного результата, а есть только общие представления, каким должен получиться проект в итоге.
- Если нужно очень быстро вносить изменения в проект. Например, чтобы успевать за нововведениями конкурентов.
Метод называют также скоростной разработкой. Суть: компания даёт пользователям пока ещё не готовый продукт, чтобы получить отзывы и исправить замечания.
Такое управление помогает создать продукт, который будет максимально отвечать потребностям аудитории. Кроме того, это помогает сэкономить время и деньги на постоянные обновления и тестирование новых версий разработки.
Метод подходит для любых бизнесов, в которых можно создать MVP — минимально жизнеспособный продукт. Например, сервис по заказу такси может сделать программу в конструкторе приложений, собрать обратную связь и выпустить другое приложение с собранными пожеланиями от клиентов.
Плюсы метода. Помогает контролировать, нравится клиентам продукт или нет.
Минусы метода. Долгий процесс от создания плана до выпуска конечного продукта.
Six Sigma работает так: компания заранее определяет, что должно быть в будущем проекте. А потом в процессе разработки ищет все ошибки в проекте, исправляет их и улучшает продукт. Часто метод шести сигм используют для контроля качества разработки, а не для управления проектом.
Теория шести сигм опирается на шесть пунктов:
Motorola предложила разделять шесть сигм на 5 технологических этапов:
Определить потребности клиентов (Define). Менеджеры составляют портрет клиента и решают, как их обслуживать. Это помогает определить масштаб и цель проекта.
Измерить производительность процесса (Measure). Когда проект выпущен, менеджеры оценивают, насколько хорошо он решает проблемы пользователей.
Проанализировать недостатки (Analyze). Менеджеры выделяют все проблемы проекта и думают, почему какая-то часть проекта не работает или не справляется с задачами.
Совершенствовать систему (Improve). Если менеджеры нашли проблемы — изменяют и улучшают бизнес-процессы.
Проверить изменения (Control). После того, как исправили проблемы, менеджеры проверяют, стал ли продукт работать лучше.
Метод шести сигм подходит бизнесу из сферы услуг, потому что он контролирует повторяющиеся операции. И чем лучше он их будет контролировать, тем больше будет зарабатывать.
Такой метод управления используют в Starbucks, Coca-Cola, Walmart.
Плюсы метода. Помогает создать наиболее качественный продукт.
Минусы метода. Долгий срок создания плана.
В этом случае менеджеры прописывают все нужные действия, которые помогут создать проект. После этого они определяют длительность всех задач и прописывают последовательность действий.
По сути, метод определяет самую длинную последовательность задач, которые нужно закрыть для завершения проекта. Кроме того, это помогает понять, какие задачи можно выполнять одновременно, а какие — в строгой последовательности.
Подходит для любого бизнеса, где планируют проект на длительный срок.
Плюсы метода. Помогает подробно спланировать проект и расставить приоритеты.
Минусы метода. Сложно распланировать задачи и сроки выполнения.
Когда будете выбирать систему проджект-менеджмента, имейте в виду, что Projecto точно не поставит вас и вашу команду в рамки жёсткой методологии — предложит удобные инструменты управления событиями, проектами и документами, которые можно использовать так, как хочется вам.
Основные этапы проджект-менеджмента описаны в книге «Руководство к своду знаний по управлению проектами». Её составил Институт проджект-менеджмента (США) в 1996 году. В издании выделяют пять этапов:
Поговорим о каждом.
На этом этапе проект ещё не подтвержден и не запланирован. Цель этапа — понять, зачем этот проект, какие задачи он решает и стоит ли его разрабатывать. Для этого нужно пройтись по нескольким пунктам:
Бизнес-сценарий проекта. Например, компания по продаже садового оборудования теряет деньги, потому что у неё нет интернет-магазина, а клиенты не хотят идти в офлайн-точку.
Выгода от разработки. Интернет-магазин привлечёт новых покупателей, улучшит клиентский опыт и поможет прорекламировать товары бизнеса.
Показатели успеха. Например, интернет-магазин повысит продажи в два раза, потому что теперь клиентам будет проще оформить заказ.
Если на этой стадии команда понимает, что разработка интернет-магазина выгодна — проект переходит на следующий этап.
Следующий этап — запланировать, что именно бизнес хочет получить от нового продукта и сколько времени придётся потратить на разработку. Но перед этим нужно ответить на вопросы:
Вернёмся к примеру с магазином и спланируем, что мы хотим получить от разработки.
Цель — разработать интернет-магазин по продаже садовой техники, который повысит продажи в два раза.
Срок разработки — до 31 декабря 2025 года.
Бюджет — 300 000 ₽.
Риски — сайт не будет приводить клиентов из поиска и не увеличит продажи.
Чтобы сделать проект, понадобятся: HR, веб-разработчики, графический дизайнер и команда по контенту.
Готовый план можно сделать в виде дорожной карты и рассылать сотрудникам.
После инициации и планирования менеджеры создают проект. На этом этапе перед сотрудниками появляются новые задачи:
Следить за выполнением проекта. Это мониторинг и отчётность по проекту — чтобы убедиться, что задача выполняется своевременно.
Управлять расходами. Менеджеры контролируют, сколько денег уходит на зарплаты, оплату подписок и т.д. Нужно для того, чтобы не выйти из запланированного бюджета.
Управлять закупками. Сюда входит покупка подписок, аренда помещений или контракты с внешними специалистами.
Следить за качеством. Если стадии по проекту закрывают в срок и расходы не превышают бюджета — это не гарантия успешного проекта. Поэтому менеджеры следят, чтобы проект на всех стадиях соответствовал ожиданиям, и согласуют его с руководителем.
Обычно этот этап идёт одновременно с предыдущим. На нём менеджеры проверяют, на какой стадии находится проект, и предоставляют отчётность руководителю.
На этом этапе права на проект передают заказчику, подписываются необходимые документы. Дальше заказчик запускает проект и анализирует, работает он или нет.
Задали ещё несколько вопросов нашим экспертам, чтобы лучше разобраться в теме.
В современном IT-мире нечасто можно встретить чистый Scrum, Waterfall и так далее. Обычно руководители и команды подстраивают фреймворки и методологии под свою ситуацию. Поэтому на выходе получается так называемый «гибридный» подход — по сути, комбинация гибких и каскадных методик. Зачастую это является оптимальным решением проблемы.
В книге Тома ДеМарко и Тимоти Листера «Вальсируя с медведями» наглядно показано, как часто сложные проекты, реализуемые по каскадной методологии, не вписываются в сроки и бюджеты.
К сожалению, мы не в состоянии точно, а иногда даже примерно оценить проекты с большим количеством неизвестных. В этом случае на помощь приходят гибкие методологии, которые позволяют адаптироваться на ходу и получить быструю обратную связь. Это в конечном итоге даёт большую ценность для бизнеса.
Но за гибкость и возможность быстрых изменений приходится платить невозможностью долгосрочного планирования, что не всегда вписывается в корпоративные стандарты.
Я как проджект-менеджер вижу много плюсов в использовании методов управления проектами. Дело в том, что даже самые разнообразные инструменты управления задачами не работают, если не объединить их в систему. Под инструментами управления я имею ввиду планировщики задач, трекеры, календари и пр.
В онлайн-проектах вот ещё пару лет назад не пытались как-то управлять проектом и выстраивать в нём систему. Но по мере роста команды и оборота всё равно стали к этому приходить. Я оказывалась в проектах, в которых царил хаос и деньги терялись буквально на каждом шагу, а после внедрения планирования, распределения задач по команде, грамотного управления рисками и т.д. мне удавалось увеличивать оборот компании минимум в 2 раза за месяц без дополнительных вложений.
Один из случаев — с 1 млн ₽ оборот проекта вырос до 2,7 млн ₽ за 3 недели. Название компании, к сожалению, сказать не могу.
Поэтому вот несколько моментов, которые я бы выделила для методов управления проектами:
- разбивайте объёмную задачу на конкретные шаги;
- определяйте исполнителя по каждой задаче;
- определяйте дедлайны для каждой задачи или подпроектов;
- управляйте бюджетом проекта;
- создавайте план, который понимает вся команда;
- внедряйте и/или оптимизируйте корпоративную коммуникацию в проекте.
А из минусов я бы выделила один — сроки внедрения методов управления в проект. Сейчас я не могу сказать однозначно, сколько времени уйдёт на внедрение управления, потому что на это влияет несколько факторов: размеры проекта, количество сотрудников в компании, её обороты и т.д.
Я предпочитаю использовать одновременно классический и гибкий методы управления.
Я работаю с онлайн-проектами уже более 5 лет и для себя определила, что для них метод Waterfall плюс гибкое управление подходит идеально.
Waterfall позволяет избежать большого уровня стресса, потому что на все этапы по решению задач отводится достаточно времени. А у руководителя проекта появляется время на решение возможных проблем.
А гибкое управление позволяет вносить изменения в содержание проекта по ходу.
Выбор методики управления определяется несколькими факторами:
- количеством неизвестных на старте;
- необходимостью внесения изменений в процессе;
- корпоративными и индустриальными стандартами;
- форматом заключённого договора и др.
Если не вдаваться в детали, можно сказать, что понятные и хорошо прогнозируемые проекты имеет смысл реализовывать по каскадной методологии, а проекты с большим количеством неизвестных и требующих гибкости — явный кандидат на Agile.
Для примера возьмём два проекта, которые отличаются по своей сути: первый — разработка нового ПО, второй — замена физических серверов в дата-центре. В первом случае я буду применять Agile-методики, потому что нельзя заранее запланировать на 100% то, как будет выглядеть конечное ПО.
А во втором случае подойдёт чистый Waterfall, потому что возможные проблемы, сроки и результаты по смене серверов можно просчитать заранее. Поэтому я считаю, что нет единственного и универсального метода управления проектами. Выбор всегда зависит от ситуации с большим количеством переменных.
Главное — не бойтесь менять процессы в идущем проекте и постоянно думать, что ещё и как можно улучшить. Пробуйте и экспериментируйте вместе с командой.
14-15 октября на бесплатном вебинаре эксперты Roistat и Unisender расскажут, как найти точки роста и получать больше от уже имеющихся данных, процессов, каналов — без механического увеличения рекламного бюджета.
Искренние письма о работе и жизни, эксклюзивные кейсы и интервью с экспертами диджитала.
