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

Условием успеха делового или социального проекта являются системный подход со стороны исполнителя и наличие у него профильных навыков. Если нет ни того, ни другого, проект почти наверняка застопорится, выйдет за границы бюджета или просто потерпит фиаско. Найти толкового менеджера проекта «по заказу» непросто. Руководителю приходится использовать готовые решения в сфере управления, обросшие солидной теорией и обкатанные на практике. Такие шаблоны не являются панацеей, но существенно снижают риск прогореть. С ними рабочий процесс переходит из области хаоса в сферу логики.

Оговоримся: все нуждающиеся в профессиональном управлении проекты делятся по масштабу. Существуют глобальные проекты, такие как PMBOK и основанная на нем система стандартизации ISO. Рангом ниже идут проекты национальные: DIN 69901 в Германии, AFITER во Франции, P2M в Стране восходящего солнца. В основании пирамиды лежат локальные и специализированные проекты.

Глобальные и национальные проекты предполагают управление мощными структурированными командами с сотнями и тысячами участников. Нас больше интересуют локальные проекты для средних и малых предприятий.

В этой сфере выделяются два ключевых направления:

• классика менеджмента, основанная на знаниях, которые дают в университетах;
• гибкие дискуссионные методики управления проектами, которые пока проходят обкатку в реальной жизни.

Исторически повелось, что в России теория и практика управления проектами в негосударственном секторе экономики в основном привязана к различным направлениям IT-отрасли. Это объяснимо: у айтишников всегда под рукой программно-аппаратные средства, без которых невозможна полноценная реализация проектов.

Наиболее эффективными методиками проектного менеджмента считаются:

• Agile-методики, в основе которых гибкость и адаптивность, умение управлять, уступая.
• Scrum-методики (от английского «хватка»). Имеют много общего с предыдущей категорией, но предполагают более жесткое взаимодействие участников процесса.
• «Канбан» — система, в которой проектные задачи получают динамическую визуализацию.
• Водопад (англ. waterfall), или каскадная модель.
• Итеративная (линейная пошаговая) модель.
• Инкрементная модель, в которой проект разбивается на взаимозависимые модули и менеджер проекта отслеживает реализацию отдельных модулей и задачи целиком.

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

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

Agile («Эджайл») — это даже не столько методика, сколько базовая система ценностей, которые важны для реализации проекта. Опор успеха четыре:

• приоритет — люди и их взаимоотношения;
• цель — функционирующий продукт, а не его описание;
• живая коммуникация с клиентом важнее формальных договоренностей;
• неожиданные повороты в реализации проекта — норма, а не стихийное бедствие.

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

Методика Scrum («Скрам») наиболее эффективна при работе команд с ограниченным числом участников.

По сравнению с «Эджайл» это более конкретная и формализованная методика. Команда подчиняется итеративному (пошаговому) алгоритму реализации проекта, где каждая стадия рассматривается как короткий спринтерский забег.

Накануне каждого старта формулируется список задач. В этом процессе каждый раз участвуют представители клиента.

Все задачи размещаются на интерактивной (или даже реальной) скрам-доске. По сравнению с канбан-досками (см. следующий раздел) таблички на scrum-доске более информативны. Расписываются роли участников, сроки исполнения и т. д.

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

Методику «Канбан» (точнее «камбан», но прижилась первая транслитерация) придумали в компании Toyota в середине прошлого века как способ внедрения «бережливого производства». В подразделениях устанавливали большую доску, на которой работники вывешивали таблички со своими целями и показателями. По мере реализации проекта табличка перемещалась слева направо. Все участники проекта знакомились с достижениями коллег-конкурентов и корректировали при необходимости собственную работу. Во главу угла ставилось снижение затрат и повышение производительности труда.

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

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

Количество статусов канбан-табличек неограниченно. Методика отчасти напоминает воронки продаж в CRM, однако там в начале «действа» в потоке оказываются все контакты с клиентами, но «катарсиса» (конечной сделки) достигают не все. На канбан-доске все таблички движутся не в конусе сверху вниз, а параллельно по горизонтали, но не все достигают конечного столбца.

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

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

Если рассматривать проект как динамично развивающуюся систему, то нужно выделить следующие базовые компоненты:

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

Документальное оформление (формализация) проекта предусматривает выполнение следующих правил:

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

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

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

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

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

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

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

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

Оптимальным решением для небольшой команды исполнителей является облачный сервис с «подушевой» подпиской сотрудников. Пример такой системы — программа для управления проектами PROJECTO. Она легко адаптируется под любые цели и под любую методику, включая Agile, Scrum и Kanban.

#методики #методология #методологияуправления #agile #scram #kanban #управлениепроектами #управлениебизнесом

Истосник: официальный канал Projecto на Дзен