Риск - благородное дело!.. Часть вторая

Публикация № 1104612

Методология - Управление проектом

19
Продолжаем разговор про риски

Совет №2. Предсказывайте риски до того, как пациент умрет, а не после - Продолжение разговора... 

 

В комментариях к первой части статьи про риски меня попросили раскрыть "Совет №2" подробнее. Попробую это сделать здесь.
Почему я искренне люблю технику "PreMortem" и стараюсь ее применять в начале любого проекта или какой-либо другой инициативы?... Дело в том, что она помогает справляться с прекрасно известной многим менеджерам болезнью "Избирательная близорукость".
Вальсируя с медведямиКак рассказывают Том ДеМарко и Тимоти Листер в книге "Вальсируя с медведями” (кстати, активно рекомендую эту книгу всем, кто хочет проработать свои навыки управления рисками) в разделе с говорящим заголовком  "А, вы имеете в виду этот приближающийся поезд!": 

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

Очень часто "избирательная близорукость" проявляется и усиливается в ситуации, когда уровень взаимопонимания и доверия между руководителями и командой проекта недостаточен… Отсюда стратегии поведения, подобные описанным в той же книге действиям, предшествующим провалу:

Я сразу понял, что если у него нет плана предотвращения риска, он такой риск просто игнорирует. 


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


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

Развитием техники “PreMortem” можно считать “Стратегию творчества Уолта Диснея”, которая является, по сути, сочетанием техники PreMortem и мозгового штурма.

Стратегия творчества Уолта ДиснеяВ ходе этой техники участникам предлагается по-очереди примерить три разные “шляпы”:

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

Во время ролевой игры участники могут циклически изменять свои роли и продолжать обсуждение проблемы до тех пор, пока решение не будет найдено.
Рекомендуется, чтобы разные роли размещались на разных местах в пространстве - то есть команда физически перемещалась от “стола мечтателей” к “столу реалистов”, к “столу критиков” и обратно. Как нетрудно догадаться, основное место формирования “позитивного настроя” - это “стол мечтателей”. А основное место выявления рисков - это “стол критиков”, помогающий наиболее надежно спуститься “с небес на землю”.  

 

Совет №4. Управление рисками должно идти планомерно от начала и до конца проекта

 

А если быть точным, то начинаться еще ДО того, как мы приняли решение ввязываться в тот или иной проект. И заканчиваться ПОСЛЕ завершения проекта передачей информации.
На своих вебинарах и в статьях я неоднократно рассуждала о сочетании умений “быть” (то есть реально делать работу) и “казаться” (то есть пускать пыль в глаза и производить нужное впечатление). Так вот, также как и во многих других сферах, когда управлением рисками занимаются в первую очередь с целью “казаться”, толку с этого, как правило, нет практически никакого. Что я имею в виду?...
В первую очередь, ситуации, когда реестр рисков составляется “для галочки”. Честно скажу, в моей практике были ситуации, когда меня просили, например, “пришлите примеры рисков для подачи документов на 1С:Руководитель проектов”. В чем будет ценность этого списка рисков для руководства реальным проектом? Да ни в чем практически. Здесь единственная цель - произведение впечатления.  А на самом деле, все внедрения очень разные, и все риски индивидуальны, и в разных ситуациях они различаются в первую очередь степенью влияния и вероятностью.

Вот, в частности, примеры нескольких внедрений из моего опыта, когда ключевыми рисками были совсем разные:

  • Разгильдяйство ведущего руководителя
  • Некомпетентность компании внедренца
  • Недостаточная включенность и непонятный статус лица принимающего решения (по сути, было два владельца продукта: номинальный и фактический)
  • Недостаточно качественное проведение предварительного исследования
  • Неполное выявление требований
  • Досрочное прекращение финансирования в связи с утерей интереса к проекту
  • (Можете продолжить список по своему опыту и усмотрению)

 

Совет №5. Закладывайте резервы в бюджет и расписание


Типичный план проекта строится исходя из оптимального развития событий. А ведь на самом деле, давно известно, что ни один план сражения не выдерживает столкновения с противником (это утверждение приписывается фельдмаршалу Хельмуту фон Мольтке, одному из основателей Германской империи). И основной практический смысл управления рисками, по моему опыту, состоит как раз в том, что по итогам обсуждения рисков в «красивый» график добавляются временные, денежные и кадровые резервы на случай, что что-нибудь пойдет не так.
В бытность мою руководителем проектного офиса на НПК, мне приходилось корректировать производственные планы. Смотрю я на стройный план-график, и вижу, что согласно нему предполагается изготавливать каждый новый опытный образец за 4 месяца. Нет, действительно, если посмотреть на технологический процесс – то как раз работа должна занять ровно 4 месяца, если не меньше. Но, как вы уже, наверное, помните, проблемы прошлых проектов – это входные данные в процессы управления рисками проектов будущих. И суровая действительность показывает, что в экспериментальном производстве обязательно что-нибудь, да пойдет не так – либо с качеством оптики возникнут проблемы, либо с герметичностью, либо со стыковкой компонентов… Ну, в-общем, средний срок - около полугода, если все достаточно гладко пройдет. Интересуюсь у автора плана: "А были ли случаи в вашей практике, когда опытный образец действительно был готов за 4 месяца?" На что мне следует сакраментальный ответ "Пока нет. Но мы будем стараться!".

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

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


Что почитать на тему рисков не отходя далеко от Инфостарта?

 

  • Базовую книжку я уже рекомендовала: Тимоти Листер, Том ДеМарко. Вальсируя с медведями. Управление рисками в проектах по разработке программного обеспечения.

Теперь на Инфостарте.  


 

19

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. bolefirenko 90 07.08.19 12:58 Сейчас в теме
Вопрос грамотно выстроить взаимодействие Мечтатель - Реалист - Критик и правильная балансировка участия каждого.
Понятно, что если Мечтатель в одиночестве строит план, получается мега оптимизм, оторванный от реальности. Если добавить сильных Реалиста и Критика, план зачастую получается неподъемным для Заказчика, идеи душатся в зародыше.
acanta; MariaTemchina; +2 Ответить
3. MariaTemchina 827 07.08.19 16:37 Сейчас в теме
Считается, что опытные сотрудники отличаются от начинающих тем, что вторые предлагают идеи из позиции "Мечтателя", а первые - уже сразу спускаются с небес на землю, и еще до высказывания, проверяют предложения на реализуемость, и подают их из позиции "Реалиста"...
5. acanta 64 07.08.19 17:33 Сейчас в теме
(3) Позиция "Реалиста" от "Мечтателя" отличается только ожидаемым результатом. Действия и графики как правило одинаковые.
"Критик" учитывает саботаж. Т.е. что будет с планами "Мечтателя", если вообще ничего не предпринимать, если выполнить их на 5%, на 10% и т.д. И каков минимальный процент выполнения, чтобы "Реалист" счел планы осуществленными.
6. MariaTemchina 827 07.08.19 17:59 Сейчас в теме
(5)
Позиция "Реалиста" от "Мечтателя" отличается только ожидаемым результатом. Действия и графики как правило одинаковые.

А вот и нет! Позиция "Мечтателя" - это способ сбросить привычные шоры и посмотреть на ситуацию вне ограничений "как бы хотелось сделать, если бы мы не были стеснены бюджетом, сроками, менеджментом и т. п..."
7. acanta 64 07.08.19 18:57 Сейчас в теме
(6) Как бы вы отнеслись к мнению, что Евросоюз возник благодаря системе SAP/R3? А Brexit потому что у части пользователей есть Oracle IBM ?
Есть мечтатели, которые просто хотят путешествовать по выходным, в отпусках или на пенсии. Есть система, которая позволяет свободно учитывать данные в разных странах и ее создали реалисты. А критиков они перетянули на свою сторону за счет того, что за пару десятков лет пользователи разных уровней в разных странах поработали в такой системе и увидели что это не только интересно, но и выгодно.
Когда критик становится на сторону мечтателей, а реалисты давно уже все сделали - разве это не сказка?
9. MariaTemchina 827 07.08.19 23:30 Сейчас в теме
(7) Мой опыт показывает, что именно благодаря Мечтателям иногда удается найти новые решения, выйти за привычные границы. Потому что люди, как известно, консерваторы, и на вопросы "как это должно работать?" по умолчанию обычно просто описывают, как оно работает в привычном им приложении, и им и в голову не приходит, что можно ту же задачу решать как-нибудь по-другому...
10. acanta 64 08.08.19 10:54 Сейчас в теме
(9) Вы несколько преувеличиваете возможности Мечтатателей. Мечтатель тоже обычно просто описывает, как оно работает в привычном ему мире, но его мир это не компьютерное приложение, а к примеру кукольная чайная церемония в детсадике, фермерское или лесное хозяйство, большой адронный коллайдер или какой нибудь объект G11 в каком нибудь созвездии.
Если программисты готовы слышать не пользователей, а участников процесса - то 1с легко превращается в совсем другую систему, поскольку ее конкурентным преимуществом позиционировалась именно скорость разработки, а значит - с довольно высокой допустимой долей ошибок.

Хотя, если говорить о привычном мире (7.7+Ехсеl)- например я не понимаю, почему не сделать подключение объектов в настройках конфигуратора как плагинов в екселе, если нет в конфигурации регистров расчета или веб-сервисов - выключили соответствующие галочки в конфигураторе (это удобнее чем подключение внешней компоненты в коде).

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

Если мы говорим о том, что 1С как интерпретатор на самом деле в процессе работы никак не использует исходные тексты модулей и их можно свободно удалить из поставки конфигурации, но скорость работы от этого не повышается, зачем вообще тогда интерпретатор?
2. brr 176 07.08.19 14:34 Сейчас в теме
план зачастую получается неподъемным для Заказчика, идеи душатся в зародыше


может оно и к лучшему?
MariaTemchina; +1 Ответить
4. MariaTemchina 827 07.08.19 16:38 Сейчас в теме
(2)
может оно и к лучшему?

Плюс один!
Мне кажется, что если есть возможность "не ввязываться в блудняк" - то лучше ее использовать...
8. _MavR_ 07.08.19 23:18 Сейчас в теме
Плюс еще один!
Ибо любой вышеозначенный блудняк должен душиться в зародыше регламентом, т.е. "Шаг в лево/право - попытка к бегству, прыжок на месте - провокация", а виновник должен наказываться засовыванием своих идей в рамки регламента. В итоге как раз и родиться Проект. В этом случае морально пострадавшим за идею выступит Мечтатель, а его проект к состоянию ПРОЕКТ будет приводить Реалист под мудрым надзором Критика
Оставьте свое сообщение