Читать книгу Проектное управление. Как правильно делать правильные вещи (Павел А. Алферов) онлайн бесплатно на Bookz (2-ая страница книги)
bannerbanner
Проектное управление. Как правильно делать правильные вещи
Проектное управление. Как правильно делать правильные вещи
Оценить:
Проектное управление. Как правильно делать правильные вещи

5

Полная версия:

Проектное управление. Как правильно делать правильные вещи

Модель, или, как еще иногда говорят, фреймворк, «Киневин» определяет тактики поведения в различных условиях и контекстах. Она выделяет четыре (а на самом деле пять) доменов. И все они разные. Каждый домен отражает один из видов систем, в самом широком смысле – элементов и связей между ними. С такой точки зрения эта книга – система; проект, который вы реализуете, – система, как и ваша компания. И в модели «Киневин» дана одна из типологий систем и сказано, что делать с ними (рис. 2.2).


Рис. 2.2. Домены модели «Киневин»


Пройдемся по доменам модели.

Первый вид систем – простые (simple). Далее, для краткости, будем их называть простыми. В них связи между причинами и следствиями ясны, неизменны и поддаются предсказанию. Их еще называют obvious – очевидные.

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

В запутанных (complex), или, как их иногда еще называют, комплексных, системах связи между причинами и следствиями неясны. И полностью ясны не будут, разве что в ретроспективе. Приходится с этим жить.

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

Любая управленческая теория или модель полезна настолько, насколько она позволяет помочь в работе, в принятии решений. Дейв Сноуден не только предложил разделение систем на домены, но и сразу сформулировал, как действовать в каждом из них. Давайте рассмотрим на примерах (рис. 2.3).


Рис. 2.3. Примеры и порядок действий для разных доменов «Киневин»


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

1. Восприятие – изучить систему.

2. Категоризация – отнести ее к известному классу.

3. Реакция по правилам – делать то, что положено делать с такой системой согласно лучшим практикам.

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

Возьмем теперь более сложную систему. В ней нужно анализировать, привлекать экспертов. Больше нет однозначно лучших практик. Есть ХОРОШИЕ. Это означает, что разные эксперты могут предложить по-разному работать с системой. И это не означает, что кто-то из них неправ. Прав. Просто по-своему.

Алгоритм действий, по Сноудену:

1) восприятие,

2) анализ и экспертиза,

3) реакция на основе результатов экспертизы.

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

Пойдем дальше. Запутанные системы. Здесь нет ни лучших, ни хороших практик. Здесь имеются паттерны – понятные «кусочки», части системы, которые похожи на что-то нам известное. Но существенная их часть непонятна и ни на что не похожа.

Алгоритм действий, по Сноудену:

1) исследование,

2) восприятие и понимание,

3) реакция.

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

А вот хаотической системе не нужно думать и анализировать. Здесь все новое, все непонятное. Надо действовать!

Алгоритм действий, по Сноудену:

1) действие;

2) восприятие – смотрим, что получилось в результате нашего действия;

3) реакция.

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

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

Наконец, есть еще пятый домен – о нем мы пока не говорили. Это центральная часть «Киневин». Середина между всеми моделями. Это беспорядок (Disorder) – когда непонятно, в каком домене мы находимся, с какой системой имеем дело.

Сноуден утверждает, что в большинстве случаев мы именно в этом домене: мы просто не задумываемся, в какой ситуации пребываем, и действуем вслепую. И чтобы справиться с беспорядком, первым делом надо разобраться (здесь важен, критически важен контекст), кто и как думает о системе, какие факторы учитывает.

На наш «Киневин» (среду обитания), систему, которую мы рассматриваем, влияют множество факторов, включая наши прошлое / ценности / предубеждения. Выбор домена ВСЕГДА весьма субъективен, определяется контекстом и тем, как мы его понимаем (рис. 2.4).


Рис. 2.4. Домены «Киневин»


Часто домены «Киневин» специально рисуют в виде столбиков. Их высота отражает степень НАШЕГО понимания и контроля ситуации. Самый высокий (самые большие понимание и контроль) – в простом домене. Самый низкий, соответственно, в хаотическом. При этом, как я уже раньше говорил, изначально мы, скорее всего, находимся в зоне «беспорядка», поскольку определяем контекст инерционно. Или вообще не определяем.

Контексты постоянно перетекают друг в друга. Смена переходит по часовой стрелке. Самая опасная зона находится между простым и хаотичным контекстом. Когда вы уверены, что все просто и понятно, вдруг наступает потеря контроля – «обрыв самоуверенности». Часто это происходит мгновенно (ситуация знакома многим водителям: все тебе было просто, понятно и под контролем, но вдруг что-то пошло не так).

Давайте рассмотрим практический пример (рис. 2.5).


Рис. 2.5. Сложный проект-схема


На фото – результат брейнсторминга сложного проекта (фактически программы проектов) в крупной нефтяной компании. Каждый стикер – отдельный блок работ. Как вы можете видеть, все стикеры распределились по доменам. Интересны их названия – коллеги несколько переиначили их для большей понятности: «Все знают», «Эксперт знает», «Никто не знает, но мы узнаем», «Никто не знает, и мы не узнаем». Интересные названия.

Вначале все стикеры были наклеены в центре листа, в домене «беспорядок», а потом в рамках брейнсторминга брали каждый и обсуждали: ясно ли, что с этим делать. Если всем ясно, то стикер шел в правый нижний угол. Если понятно, что без глубокого анализа, без экспертов не разобраться, – в правый верхний, и так далее.

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

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

Итак, чем же она может быть полезна в практической работе над проектом? Дело в том, что в разных доменах «Киневин» у управленца будут разные объекты внимания и, соответственно, разные управленческие рамки (рис. 2.6).


Рис. 2.6. Разные объекты внимания в разных доменах «Киневин»


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


Рис. 2.7. Применимость управленческих рамок в разных доменах «Киневин»


В качестве примера будем использовать реально существующую компанию, но название – вымышленное.

Компания «Кварк» более 30 лет занимается разработкой и производством сложной медицинской техники: флюорографов, цифровых рентгеновских аппаратов, телеуправляемых аппаратов, компьютерных томографов и так далее. Аппараты собираются под заказ, с учетом индивидуальных требований заказчиков. В штате несколько сотен сотрудников. Продажи и сервис присутствуют в 50 регионах РФ. Всего по стране установлено и обслуживается несколько тысяч аппаратов. Детально бизнес компании описан в приложении 1.

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

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

Пример для компании «Кварк» – разработка и постановка на производство нового аппарата, например для искусственной вентиляции легких (ИВЛ), – такие устройства стали очень востребованы в связи с распространением COVID-19. Этот проект очень хорошо и эффективно может быть реализован через классический проектный подход. Или другой пример, который мы рассмотрим дальше: открытие нового филиала.

Для запутанного домена очень хорошо подходят agile-практики – здесь есть большая неопределенность и необходима работа в итеративном ключе, проверка гипотез. Это область продуктового подхода.

Примером для компании «Кварк» будет выход на новый рынок. Например, рынок Индонезии. Но что вы знаете про Индонезию? Скорее всего, ничего… Да и вообще, в России мало кто о ней знает. А между тем это четвертая страна мира по населению. Так что будет сложно все детально спланировать и сразу открыть успешный бизнес в Индонезии. Поэтому имеет смысл сформировать постоянную кросс-функциональную команду, включающую технологов, маркетологов, логистов, которые вместе будут прорабатывать вопрос и через целый ряд экспериментов постепенно начнут развивать новый рынок. Альтернатива – оформление этой деятельности как программы отдельных классических проектов, открытие представительства, анализ рынка, разработка линейки аппаратов под его потребности.

Теперь вопрос: как вы думаете, как лучше делать проекты в хаотическом домене? Ответ: в хаотическом домене проекты лучше не делать. Он про быстрое принятие решений на основе базовых принципов, разруливание возникающих инцидентов, быстрое выполнение поручений. В общем, это антикризисное управление в реальном времени, штабная культура.

Проекты иногда попадают в этот режим, например при сваливании в кризис. Со многими это недавно случилось – при введении ковидных ограничений. В том же «Кварке», например. Но в целом этот домен не про проектное управление. Сначала нужно стабилизировать ситуацию, и только потом запускать проекты. Хотя есть отдельный вид проектов, специфический для России, – форсированные, или, как их еще называют, мобилизационные. Они запускаются в очень высокой степени неопределенности и под большим давлением внешних факторов. Я как раз исследую такие проекты и даже с коллегами в 2023 году выпустил доклад «Форсированные мегапроекты. Российский опыт двух столетий»[1]. Но о том, как управлять такими проектами, видимо, будет отдельная книжка…

Вернемся к примеру нефтяной компании, который мы рассматривали ранее. Помните стикеры, попавшие в разные домены? Эти проекты управлялись как раз по-разному.

• То, что попало в ПРОСТОЙ домен («Все знают»), делалось в рамках операционной деятельности, по инструкции, специально ничего особенного не изобретали. Собственно, это и не проекты были, а текущая операционная деятельность.

• То, что попало в СЛОЖНЫЙ домен («Эксперт знает»), запускалось как классические проекты.

• То, что попало в ЗАПУТАННЫЙ домен («Никто не знает, но мы узнаем»), запускалось как гибкие проекты.

А как вы думаете, что делали с проектами, которые попали в хаотический домен?

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

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

У меня есть такая метафора: раньше в нашем условном корпоративном зоопарке было два основных «животных» (две управленческие рамки) – проекты и процессы. Но сейчас к ним прибавилось много других, и каждое «животное» требует своего ухода. Под каждый из них придуман свой набор подходов, методик и инструментов для планирования, организации и контроля работ. Многие инструменты полезны и используются в разных рамках, и часто возникает идея, что нет нужды делить «животных» в зоопарке и специально за ними ухаживать. Какая разница – проект, процесс, продукт, стартап?! Но это на самом деле важно. Если вы скажете: «Какая разница, что это за животное, – я со всеми буду обращаться одинаково. Все у меня будут собаки. Буду кормить, вычесывать и выгуливать два раза в день!» – ну, кошка, может, напряжется и привыкнет, а вот рыбкам станет от такого ухода плохо…

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

КРАТКОЕ РЕЗЮМЕ ДЛЯ СЛОНОВЩИКА

• Модель «Киневин» (CYNEFIN) – базовая для определения, требуется ли вам проектное управление.

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

Рис. 2.8. Модель «Киневин»


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

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

Глава 3. Характеристики проекта. Сложность, уникальность, ограничения

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

Сенека

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

• ПРОЕКТ – это временное предприятие, направленное на создание уникального продукта, услуги или результата. PMBOK-7.

• ПРОЕКТ – это уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания и предпринятый, чтобы достичь цели соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам. ISO/TR 10006:1997.

• ПРОЕКТ – это уникальная совокупность взаимосвязанных действий (работ) с определенными датами начала и окончания, предназначенных для успешного достижения общей цели. Australian National Standard for PM.

• ПРОЕКТ – это уникальная совокупность скоординированных действий (работ) с определенными точками начала и окончания, предпринятая индивидуумом или организацией для достижения определенных целей с установленными сроками, затратами и параметрами выполнения. BS 6079-1:2000.

И так далее и тому подобное. В общем, мы решили: раз уж у всех есть свое определение, почему бы нам не сформулировать свое? И вот определение из ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом».

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

И это определение, и вышеперечисленные выделяют три основные особенности любого проекта: сложность, уникальность и ограничения (рис. 3.1).


Рис. 3.1. Три основные характеристики проекта


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

И все три черты важны. Что будет, если одну из них убрать? Например, ограничения. Что мы увидим? Делаем что-то сложное, уникальное, но особых ограничений нет. На что это похоже? Например, на научную деятельность. Поиск каких-нибудь экзопланет в других звездных системах – это очень и очень сложно и очень-очень уникально. Но нет требования сделать это к какой-то дате. И здесь рамка проектного управления не нужна, избыточна. Уберем уникальность. Делаем что-то сложное в условиях ограничений – имеем процессную деятельность, работу по регламентам и опыту. Убираем сложность, необходимость совместной работы, – это задача экспертов, отдельное поручение. Не нужна проектная рамка.

Таким образом, нужны все три элемента.

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

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

Учитывая все эти особенности, в организациях обычно прописывают некоторую границу, выше которой необходимо применять проектный подход. Обычно это комбинация нескольких параметров: длительность, затраты, количество вовлеченных подразделений, рискованность и так далее. И если по этим параметрам деятельность оказывается достаточно масштабной, ее заворачивают в проектную рамку (табл. 3.1).


Таблица 3.1. Пример определения проекта для небольшой компании

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

** Возможно наличие затрат на единоразовые активности (закуп лицензий, оборудование и так далее).


Этот набор критериев может быть и совсем коротким (табл. 3.2).


Таблица 3.2. Пример критериев для регионального банка


Для выделения инициативы в проект необходимо соответствие всем четырем критериям.

Важно отметить, что проектный подход, кроме непосредственно проекта, предполагает и другие объекты управления – программу проектов и портфель проектов (табл. 3.3).


Таблица 3.3. Проект, портфель и программа


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

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

Продолжая слоновью метафору: проект – это отдельный слон, программа проектов – несколько слонов, которые вместе идут к одной цели (на водопой

), а портфель проектов – это целое стадо слонов, осваивающих определенную территорию.


Сравнение проектного, программного и портфельного подходов

Программное и портфельное виды управления нужны, когда проект становится настолько большим, что управлять им целиком уже очень сложно (рис. 3.2).


Рис. 3.2. Схема управления проектом


Важно понимать, что программный и портфельный виды управления – это высшая математика проектного подхода. На сотню организаций, внедривших проектный подход, приходится всего несколько, которые доходят выше. И это очень жаль, потому что, согласно исследованиям (PMI Pulse of Profession 2021[2]

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Сноски

1

URL: http://skolkovo.ru/researches/forsirovannye-megaproekty-rossijskij-opyt-dvuh-stoletij.

2

URL: http://pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pmi_pulse_2021.pdf.

Вы ознакомились с фрагментом книги.

Для бесплатного чтения открыта только часть текста.

Приобретайте полный текст книги у нашего партнера:


Полная версия книги
bannerbanner