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

Проект, продукт, процесс — эти три “П” являются краеугольным камнем в вопросах управления целенаправленной деятельности людей. Недавно меня попросили прочитать вступительную лекцию к курсу по управлению проектами и … я согласился. Согласился потому, что у меня есть релевантный опыт работы над улучшением бизнес-процессов, работы над проектами, а теперь и над продуктами, которые и формируют вид экосистемы Tinkoff для конечных пользователей. Эта статья является расшифровкой данного выступления.

Краткое содержание

  • Обсудим что является проектом, а что нет
  • Рассмотрим разные подходы к управлению проектам (PMI, IMPA, …)
  • Посмотрим на стандартный проект
  • Сравним проекты, программы и портфели проектов
  • Обсудим что делать будучи в проекте/продукте, чтобы достичь поставленных целей
  • В конце будут ссылки на дополнительные ресурсы

Начнем с основ, а именно

Что является проектом, а что нет

Project is a temporary endeavor undertaken to create a unique product, service or result.

Из этого определения сразу видны ключевые характеристики проекта, а именно:

  • Уникальность продукта или сервиса (функциональность)
  • Ограничение по времени (сроки)
  • Ограничение по ресурсам, которые так или иначе конвертируются в деньги (стоимость)

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

Рис.1 “Проектный треугольник”

Эмпирическое правило при выборе в какие ограничения укладываться при выполнении проектов — выберите любые два из трех:) Из определения проекта видно, что его результатом может быть создание продукта и это правда, но если рассмотреть вопрос отдельно, то станут видны различия.

Product

A product is designed to continually create value for customers by solving their problems. Products have more permanence, are living entities which we deliver quickly, iterate constantly, and are not something that we just walk away from.

В итоге, ключевыми характеристиками продукта являются следующие

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

Продуктовое мышление применяет эти принципы широко и не ограничивается только продуктами, которые продаются конечным пользователям.

Сравнение проектов и продуктов приведено ниже

Рис.2 “Сравнение проектов и продуктов”

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

Рис.3 “Прямой и перевернутый треугольники ограничений проектов и продуктов”

Теперь перейдем к сравнению проектов с операционной деятельностью.

Operations

Operations are the ongoing execution of activities and they follow an organization’s procedures to produce the same result or a repetitive service. Operations are permanent in nature.

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

Рис.4 “Сравнение проектов и операционной деятельности”

Сравнение Product, Project, Operations

Рис.5 “Разные виды деятельности”

Чем-то эта модель напоминает классический Кеневин фреймворк (Cynefin framework), представленный ниже. Здесь тоже четыре основные области, которые имеют следующие соответствия

  • Obvious ~ операционная деятельности
  • Complicated ~проектная деятельность
  • Complex ~ продуктовая разработка
  • Chaotic ~ R&D деятельность (research and development)

Причем движение по этим доменам идет по часовой стрелке от Chaotic к Complex, потом Complicated и Obvious. И чем ближе мы к Obvious тем большее commodity наши подходы и результаты.

Рис.6 “Cynefin framework”

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

Разные подходы к управлению проектами

  • PMI (Project Management Institute)
    Институт управления проектами — всемирная некоммерческая профессиональная организация по управлению проектами, основанная в 1969 году. Выпускает монументальную книгу PMBoK (Project Management Body of Knowledge), которая пережила уже шесть изданий и используется для проведения сертификаций на позицию PMP (Project Management Professional).
  • IPMA (International Project Management Association)
    Международная Ассоциация Управления Проектами — некоммерческая профессиональная ассоциация, созданная в 1965 году в Цюрихе и призванная объединить специалистов в области управления проектами из разных частей мира. От России в эту ассоциацию входит Национальная Ассоциация Управления Проектами “Совнет”. Здесь базовой книгой для сертификации является “Основы профессиональных знаний и Национальные требования к компетентности (НТК) специалистов по управлению проектами. Версия 3.1
  • PRINCE2 (PRojects IN Controlled Environments)
    структурированный метод управления проектами, созданный в 1989 году, одобренный правительством Великобритании в качестве стандарта управления проектами в социальной сфере. Методология PRINCE2 включает в себя подходы к менеджменту, контролю и организации проектов.

Из трех этих подходов я трогал только два:

  • PMBoK я основательно зубрил в рамках подготовки к успешной сертификации на позицию PMP — на самом деле полезнее была книга “PMP Exam Prep, Eighth Edition” от Rita Mulcahy
  • С подходом СОВНЕТ я знакомился 12 лет назад в рамках курса по управлению проектами в магистратуре МФТИ. Подход интересный, но является локальным изобретением в отличие от PMBoK

Можем попробовать их сравнить.

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

В обеих моделях применяется различная терминология для системного описания. В IPMA используется пара “процесс-функция”, в PMI — “процесс-область знаний”. Перечень функций управления внешне напоминает перечень областей знаний. Но не смотря на сходство названий, имеется существенное различие по
существу групп процессов:

  • в IPMA группы процессов эквиваленты календарным стадиям управления по всему проекту
  • в PMBOK группы процессов повторяются на каждой фазе жизненного цикла

Дальше поговорим про проекты, причем скорее с точки зрения PMI.

Проект и из чего он состоит

  • Определение проекта
  • Проектирование
  • Разработка
  • Развертывание
  • Завершение проекта

Внутри этих фаз работа идет в рамках процессов, поделенных на группы и области знаний. Среди групп выделяют:

  • Процессы инициации
  • Процессы планирования
  • Процессы выполнения
  • Процессы мониторинга и контроля
  • Процессы закрытия

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

Рис.7 "Проект и группы процессов”

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

Рис.8 “Фазы проекта и группы процессов”

Области знаний

- Integration
- Scope
- Cost
- Quality
- Resource
- Communications
- Risk
- Procurement
- Stakeholder

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

Рис.9 “Разбивка процессов про группам и областям знаний”

Теперь, когда мы кратко рассмотрели модель проекта в версии от PMI, давайте пойдем дальше и попробуем посмотреть на более крупные образования относительно проектов

Проекты, программы и портфели проектов

Рис.10 “Взаимоотношение между проектами, программами и портфолио”

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

  • анализ производительности операционной деятельности влияет на стратегию
  • оценка влияния проектов и программ на бизнес помогает проводить ревью и корректировки портфолио
Рис.11 “Циклы обратной связи между проектами, программами и портфелями”

Подводим итоги

- Есть ли временные рамки? Четкая дата старта и финиша?
- Как сформирована команда? На время или на постоянку?
- Как выглядит планирование? Итеративное или up-front?
- Поставка функционала единоразовая или инкрементальная?
- Источник требований зафиксирован или адаптируется по мере получения информации?
- Фокусируемся на поставке обещанных заранее результатов или повышении общей эффективности решения?

Если это проект, то важно понять

  • Как выглядит проектный треугольник (сроки, стоимость, функционал)
  • Кто спонсор и стейкхолдеры и их ожидания
  • Какова ваша роль и ожидания от нее
    - Если вы не project manager, то это можно обсудить с ним
    - Если вы project manager, то теория по project management вам в помощь

Если это продукт, то вам стоит изучить вопросы зрелости процессов, например, KMM (Kanban Maturity Model). Или любую другую, которая поможет вам увеличить уровень зрелости команд и повысить эффективность процессов разработки продукта.

Источники

  1. Книга “PMP Exam Prep, 8 Edition” by Rita Mulcahy
  2. Книга “PMBOK® Guide — Sixth Edition
  3. Рекомендованные PMI книги
  4. Рекомендованные Sovnet книги
  5. Книга ребят из ThoughtWorks “Digital Transformation Game Plan
  6. Статья “What’s the difference between a product and a project?
  7. Статья “What are Projects and Operations?
  8. Модель “Kanban Maturity Model
  9. Фреймворк Cynefin

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.