Categories:

7 лучших методов для управления - Часть 1

За всю историю существования человечества, начиная с древних времен, накопился список воплощенных в жизнь достаточно тяжелых проектов, начиная со строительства египетских Пирамид и заканчивая полетом на Луну. Самые отважные достижения – результат слаженной работы огромного количества людей. За всем этим стоит сложная система управления.
Немногим из читателей придется поучаствовать в заданиях и проектах такого масштаба, но большинство будет являться участниками проектного управления. Приняв во внимание прогноз PMI, к 2020 году откроются 15 млн. новых позиций проектных специалистов. Все остальные профи руководят мини-проектами на личном уровне.
Доступным языком, управление проектами – это руководство и концентрация всего необходимого для получения результата в срок и в установленных объемах денежных средств. Независимо от того, какая задача поставлена перед руководителем проекта, начиная от разработки нового ПО и заканчивая полетом на Марс, – проектное управление даст возможность получить желаемый результат.
Одинаковых проектов не существует, также, как и единой системы управления, которая бы подходила для всех без исключения. Зная, что нет идеальной системы, стоит акцентировать свое внимание на существующих эффективных подходах, методиках и стандартах. В этой статье уделю внимание самым известным.
Имеющиеся подходы очень разнятся между собой, в зависимости от сферы использования, детализированности, значительности и формализации.
Стандарты, концепции, методы, фреймворки, применяющиеся в управлении проектами, для доступности, в названии статьи объединены в «методы».
Предоставляем более глубокий обзор подходов, используемых в управлении проектами.
Предлагаю к рассмотрению:

  1. Классический проектный менеджмент,
  2. Agile,
  3. Scrum,
  4. Lean,
  5. Kanban,
  6. Six Sigma,
  7. PRINCE2.

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

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

Нил Армстронг и БаззОлдрин оставят свой след в истории, как люди, высадившие человека на Луну. Этого могло бы и не произойти, если бы не слаженная работа 400 000 сотрудников НАСА и 20 000 организаций и университетов, которые внесли свою лепту в миссию «Аполлон».
Джон Кеннеди в 1961 году отдал приказ сделать высадку человека на Луну и вернуть его обратно. В то время НАСА имели опыт по отправке человека в космос всего на 15 минут. Для выполнения столь «заносчивого» приказа необходимо было задействовать множество средств, слияний, новшеств и планирования.
Книга НАСА «ManagingtheMoonProgram» повествует о том, что проблемой было выполнение столь громадного объема работы за минимальный срок. Макс Фагет, глава инжиниринга в Космическом центре имени Линдона Джонсона, утверждал, что в НАСА не могли понять, как выполнить все необходимое за 10 лет. Именно поэтому первым делом «разбили проект на отдельные управляемые этапы». Важно было следить, чтобы компании и команды, выполняющие отдельные этапы, вкладываются в установленные сроки и эффективно взаимодействуют между собой. Контролировал всю ситуацию Джордж Мюллер, отвечавший за реализацию проекта «Аполлон» по всей цепочке его выполнения. Чтобы облегчить контроль, Мюллер выделил 5 составляющих проекта:

  1. «Контроль Программы»;
  2. «Системная Инженерия»;
  3. «Тестирование»;
  4. «Надёжность и Качество»;
  5. «Лётная эксплуатация».

Данная система состоит из 5 частей, которые названы по инициалам Мюллера – «Этапы GEM» (Доктор говорит, что она создана «ради фокусировки на тестировании продукта, и на его разработке с учётом того, что его будут тестировать»):

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

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

Возникновение проектного управления

Замечу, что изобретателями проектного управления были не НАСА и не Джордж Мюллер, а люди, жившие задолго до них. Первые продукты проектного управления, а именно Пирамиды в Гизе и Китайская стена, появились в древнейшие времена (хотя, думаю, были и до них крупные проекты, но мы о них не знаем). По истечению стольких лет никаких документальных подтверждений того, как это происходило не осталось, а современное управление никак не связано с первым опытом.
Наиболее реальный способ осуществить проект – поделить его на составляющие или различные задачи. Примерно, как готовка, сначала приобретаете продукты, миксуете их, далее идет приготовление и подача. Для достижения нужного результата, создается гайд с пошаговыми действиями, именно он облегчит работу (да, я говорю про кулинарную книгу). Беспроигрышный вариант. Если вы главный повар и под руководством находится сразу несколько блюд (и групп, которые их готовят), приготовление которых состоит не из одного ингредиента, тогда, нужно то, что поможет наблюдать за временными затратами на каждый этап и временем готовки в целом. Спасителем в данной ситуации является современный инструмент проектного управления – Диаграмма Гантта.
Ее создали KorolAdamecki и Genry L. Gantt в 20 веке. В диаграмму вносятся задачи, их продолжительность и связь между ними, после чего высчитывается самая длинная цепочка взаимосвязанных задач, которая определяет протяженность проекта. Проще говоря, она отображает расписание проекта с учетом дат окончания задач. Связь между началом и окончанием различных заданий важна, потому что нельзя вынести блюдо, не приготовив его, верно?
Стандартный проект напоминает процесс готовки и подачи блюда, только состоит из большего количества целей, заданий, связей друг с другом, дедлайнов и других средств. Проекты, в которых четко установлены крайние сроки, диаграмма подсказывает, когда нужно начать выполнение тех или иных заданий для уменьшения затрат времени осуществления. Для проектов с небольшим запасом средств диаграмма дает возможность создать алгоритм в виде четкой последовательности процессов для планирования средств.
Каждому проекту необходим свой уровень контроля. Для публикации группы статей в блоге установление крайних сроков не играет большой роли. Тут важен конкретный процесс, который поможет:

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

В этом случае вы руководите процессом, а не временем и средствами.
Тут подойдут более гибкие методы, например, Agile, Lean, Kanban. Существуют методы для управления рабочими потоками, временем и средствами – Six Sigma и Scrum.

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

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

  1. Agile – итеративно-инкрементальный подход к управлению, который обладает гибкостью. С его помощью можно управлять проектами и продуктами, ориентированными на быстрое формирование требований и обеспечение их создания, учитывая беспрестанное взаимодействие среди самоорганизующихся рабочих групп, момятощих из разнопрофильных мастеров. Данный подход является базой для методов Scrum и Kanban.
  2. Критический путь – безостановочная расстановка работ и событий с самого начала и до конца, выполнение которых требует колоссальных временных затрат, без возможности изменения сроков.
  3. Событийная цепочка процессов (EPC-диаграмма) – диаграмма, где представлены осуществление работ проектов, опираясь на доступность и загруженность ресурсов.
  4. Резерв времени – промежуток времени, позволяющий отложить начало работы, не повлияв при этом на продолжительность проекта в целом. Запас у работ на критическом пути равен 0.
  5. Контрольная точка (веха, milestone) – событие, которое обозначает конец определенного этапа. На диаграмме Гантта – задача, имеющая нулевую длительность.
  6. PM (project manager/руководитель проекта) – менеджер, который руководит командой, выполняющей проект. Ответственное лицо за планирование, осуществление и закрытие проекта.
  7. Ресурсы – то, без чего невозможна реализация проекта, а именно:
    • время;
    • оборудование;
    • материалы;
    • работники.
  8. Содержание проекта (Scope) – растолкование работ, обязательных для выполнения, без которых получение продукта – невозможно.
  9. Спринт (Sprint) – рабочий цикл в методе Scrum, продолжительность его от недели до месяца (обычно выбирают двух недельные спринты). В течение этого времени производится рабочая версия продукта или элементов, которые важны для заказчика.
  10. «Классическое» или «традиционное» проектное управление – самый известный метод управления проектами, базирующийся на каскадном цикле (Waterfall). Задачи в нем передаются последовательно по этапам и напоминают поток, от этого и пошло его название.

Теперь разберемся с подходами! Начинаем с Традиционного и идем дальше.

Традиционное (классическое) проектное управление

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

  1. Инициация. Первым делом PM и его команда устанавливают требования к будущему проекту. Для этого проводятся собрания и мозговые штурмы, все предлагают свои идеи и решают, как должен выглядеть продукт проекта.
  2. Планирование. Команда вырабатывает алгоритм действий, который поможет достичь главной цели. Анализируется задача, результат проекта, действия по нему. Данная информация служит базой для формирования календарного плана, бюджета, оценки рисков. На этом же этапе находятся заинтересованные стороны.
  3. Разработка. Такой этап существует исключительно для технических проектов. На нем определяется форма будущего проекта/продукта, способы достижения (в IT-проектах во время разработки выбирается язык программирования).
  4. Реализация и тестирование. Самый важный этап, ведь на нем проводится вся главная работа. Например, пишут код или строят здание. Основываясь на существующем плане, реализуется содержание проекта, которое определено заранее, происходит контроль по отобранным метрикам. Во время тестирования продукт проверяется на соответствие требований заказчика. Найденные недостатки исправляются на этом же этапе.
  5. Мониторинг и завершение проекта. На данном этапе существует два способа решения: передача заказчику или же общение с клиентами для улучшения и сохранения результатов. Второе решение используется для проектов в сфере клиентского сервиса и программного обеспечения.

Вышеперечисленные 5 фаз – основа, на которой базируются другие методы управления. Каждому проекту нужны свои этапы осуществления, иногда, хватает и 3-х, а бывает и намного больше.
В некоторых случаях можно использовать «итеративный водопад». В нем каждый этап – подпроект, в котором осуществляются различные задачи по закрепленным итерациям. Главное, что весь проект поделен на этапы, реализующиеся в четкой последовательности.
В традиционном менеджменте четко установлено время, указанное еще на втором этапе, для реализации заданий. Чтобы осуществить проект, используя этот подход, можно воспользоваться инструментами календарно-сетевого планирования, например, диаграммой Гантта. Для ее построения пользуются любительскими таблицами Excel и Smartsheet или же профессиональными MicrosoftProject и Primavera.

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

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

Недостатки

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

Agile

Невозможно осуществить все проекты, используя классический подход. При изготовлении одного блюда удобно использовать «водопадный» подход, а если нужно приготовить энное количество. Приступать к новому по завершению готовки предыдущего? Не подходит, ведь так можно остаться без клиентов, но существует выход – Agile.
Данный итеративно-инкрементальный метод достаточно гибкий к руководству проектами и продуктами. В этом подходе проект нужно делить не на последовательные задания, а на маленькие задачи, которые в финале объединятся в продукт.
Получается так: разработка, тестирование и другие этапы относятся к каждой мини-задаче. Инициация и верхнеуровневое планирование – к проекту в целом. Достижения отдельных задач называются инкременты, их можно передавать быстрее. Начав новую задачу (итарацию) допустимо вставить изменения, без воздействия на другие части.
Agile – новинка, которая базируется на давнейшей итеративной идее. Название было получено в 2001 году, основываясь на публикации AgileManifesto. Манифест указал преимущества и принципы гибкой разработки софта, а именно – командная работа, приспособление, толерантность к изменениям.
Что представляет собой Agile? Это совокупность идей и принципов, которые отвечают на вопрос, как осуществить проекты, но никак не метод управления. Базируясь на данных идеях, принципах и практиках созданы именно методы (фреймворки): Scrum, Kanban, Crystal и тд. Разные способы, основанные на одинаковых принципах – это о них.

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

Основные: гибкость и приспособление. Легко адаптироваться в разных условиях и процессах компании, именно это способствовало бурной популярности на сегодняшний день. Поэтому Agile – база для различных систем во многих сферах.
Главный принцип: «Реакция на изменения важнее следования плану». Молниеносная реакция, которая не влечет особых изменений – весомая причина для влиятельных компаний, чтобы усовершенствовать гибкость своих процессов. Для проектов с «открытым концом» (сервисы, блоги) Agile – отличный вариант.
При разработке инновационных продуктов очень большая часть неопределенности, а информация появляется при разработке проекта. Из-за недостатка материала на начальном этапе, осуществление проекта по «водопаду» нереально.

Недостатки

Как мы уже отметили, Agile – не метод, а совокупность принципов и идей, поэтому организации сами разрабатывают систему управления, отталкиваясь от данных ценностей. Это достаточно сложно, долго и не всем под силу.
Для разработки нужно приложить величайшие знания и упорство, а также попрощаться с ресурсами и средствами. Scrum, Kanban, Crystal, LeSS, SAFe, Nexus – существующие наборы, которые сделают проще изменение организации.

Scrum

Тактичное программное обеспечение, разработанное в 1986 году, является самым классифицированным из рода Agile. Scrum соединяет в себе части традиционного алгоритма и задумки тактичного доступа к руководству проектами. В результате получили рациональное соединение тактики и классифицирования.
Как и Agile, Scrum делит проект на составляющие, которые, в свою очередь, уже представляют заделы продуктов (product backlog) и задействованы в получении ценностей заказчиком. Чаще в специализированной литературе используется выражение «беклог», хотя «задел продуктов» является дословным переводом. Потом составляющие компонуются по важности владельцем продукта – представителем заказчика в команде.
Наиболее главные части выбираются в первую очередь, для выполнения в Спринте – это действие по слиянию нескольких частей в одно целое. Оно длится от 2 до 4 недель. После окончания слияния заказчик получает рабочий инкремент продукта, те самые главные части, которые уже можно задействовать. Это может быть один или несколько элементов программы или функционала, способные, пусть и к частичному, но функционированию.
Следующим этапом команды будет другой Спринт. Продолжительность определенная поэтому, учитывая собственные возможности, команда, перед началом проекта сама делает выбор.
Перед пуском каждого Спринта осуществляется пересмотр содержания, внесение изменений в еще не пущенный в работу проект. Эти действия необходимы для окончательного согласования и уверенности, что проект соответствует всем пожеланиям заказчика. На данном этапе задействованы все – команда проекта, Scrum Мастер (ScrumMaster, глава команды проекта) и непосредственно сам владелец продукта. Как следствие, обязательства за выполнение данного этапа, возложены на каждого.
Еще раз подчеркнем, владелец продукта – уполномоченный заказчика в проекте, представляет всех последующих потенциальных покупателей проектов, в случае отсутствия. Именно поэтому он просто обязан ориентироваться в продуктах, знать технический процесс создания, а также, в отсутствие заказчика, уметь уловить сущность и определить надобности клиентов. Для более углубленного осознания, одобрения достоинств, правил и регламентов деятельности Scrum и нужен Scrum Мастер.
Базовая составляющая действий Scrum находится в окружении 5 важнейших встреч: упорядочивания беклога, планирования Спринта, ежедневных летучек, подведения итогов Спринта и ретроспективы Спринта:

  1. Встреча по упорядочиванию беклога (Backlog Refinement Meeting, «Backlog Grooming»). По идентичности напоминает фазу планирования в классическом проектном управлении, запускается в первый день каждого Спринта. На данном этапе рассматривается процент выполнения проекта, какие еще действия необходимо сделать, а также определяется приоритетность последующих задач. Здесь оценивается продуктивность Спринта, ведь от него зависит результат, а именно ценность заказчика.
  2. Планирование Спринта. Преимущества определены, команда вместе обсуждает дальнейшие ходы предстоящего объединения и пути достижения намеченных целей на предыдущей встрече. На этом этапе есть возможность использовать всевозможные средства планирования и оценивания, лишь бы они не вызывали разногласий в положениях и логичности Scrum. Планирование Спринта начинается уже в момент организации многократной обработки данных, после Встречи по упорядочиванию продукта.
  3. Ежедневные летучки. Для того чтобы вся команда была в курсе процесса работы, проводятся каждодневные планерки, минут по 15, где с помощью вопросов и ответов можно определить состояние проекта и положение задач. Здесь не решают проблемы, и не обсуждают решения. Но, в случае возникновения конфликтных ситуаций или претензионных вопросов, Scrum Мастер и замешанные участники рассматривают их наедине. Планерка необходима всей команде только для обмена информацией, касающейся выполнению проекта.
  4. Подведение итогов Спринта. Конечный результат – всестороннее изучение и приспособление изготавливаемого продукта. Команда демонстрирует итог деятельности людям, которым это интересно. Главная задача – удостовериться, что полученный продукт на данном этапе отвечает предвкушениям участников и не противоречит задачам проекта.
  5. Ретроспектива Спринта. Осуществляется после предыдущей встречи. Здесь идет рассмотрение, как точно и гармонично реализовывалось прохождение этапа. Вопросы, возникшие в процессе работы, подвергаются исследованию, концепции и функционированию. Только на этом этапе проводится обследование для возможности проведения следующего Спринта более результативно.

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

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

Scrum, как будто, создан для проектов, которые рассчитаны на получение мгновенных результатов, в совокупности с терпимостью к правкам. Помимо этого фреймворк незаменима в ситуациях, когда не вся команда обладает необходимым опытом в области реализуемого проекта. Беспрерывное общение членов команды дает возможность пополнять недостающий опыт и профессионализм одних по средствам участия и наставления других.
Сеть телеканала Netflix лучший пример моментального получения показателей. Чат запасов пополняется новинками через 14 дней с помощью Scrum, он дает возможность трудиться на большой скорости и сосредотачивает абонентский опыт, что позволяет определить главное для клиентов. При каждом повторе разработчики дополняют оригинальными процессами сайт и очищают те, которые не востребованы клиентами.
Команда Netflix утверждает, лихие промашки - главная способность Scrum.
Обеспечение по Scrum небольшое по объемам, его просто контролировать и в случае погрешностей молниеносно подправить, что нельзя сказать о подготавливаемых глобальных релизах, которые занимают много времени и глобальных вложений.

Недостатки

Scrum безапелляционен к команде проекта. Количество задействованных 5-9 человек. Все члены кроссфункциональны, а значит, обладают достаточной осведомленностью, нужной для разработки проекта. Взять создателя ПО, который обязан владеть навыками в апробации и бизнес-аналитике. Как следствие – отсутствие «простоев» в работе, на разных этапах ее выполнения, возможность взаимозаменяемости и взаимопомощи коллег. Также всей команде необходимо стать одним целым, энергично возлагать на себя должностные обязанности и уметь самоорганизовываться. Собрать такую сочетаемую команду – задача не из простых!
Как не прискорбно говорить, но Scrum присущ не всем командам и организациям, представляемый процесс вряд ли будет уместен при разработке такого продукта как профессиональный станок или строительство небоскреба.

Error

Anonymous comments are disabled in this journal

default userpic