☔️ Как управлять рисками в проектах. Часть 1.

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

Итак, что такое риск в управлении проектами? Риск – это негативное событие, которое может произойти и повлиять на проект.

Давайте разберем это определение. Во-первых, риск – это негативное событие. Предположим, вы выходите на улицу, и у вас в кармане лежит сто рублей. И при этом карман дырявый, вам все некогда его зашить. Можно ли при таком раскладе потерять этот стольник? Да, конечно. Значит, есть возможность негативного события – потери денег. Это и будет риск.
Но при этом вполне возможно, что вы сами найдете оброненные кем-то сто рублей. Редко, но бывает же! Найти деньги – это для вас уже явно позитивное событие. Позитивные события обычно называются не рисками, а потенциальными возможностями, управление ими ничем не отличается от управления рисками. С точки зрения технологий менеджмента, события нейтральны, а эмоциональную окраску им придают люди. Но вот что интересно, даже в компаниях, в которых внедрена система управления рисками, никто не управляет потенциальными возможностями, по крайней мере, с помощью риск-инструментов. Ни в проектах, ни в операционной деятельности. То ли из-за того, что возможностями и рисками управляют разные люди (и разные подразделения компании), то ли из-за того, что никто не верит в хорошее и потому даже не пытается этим хорошим управлять.

Во-вторых, риск – это событие, которое может произойти. Нас не интересуют события, которые абсолютно точно произойдут. Если мы ожидаем такое событие, и оно на нас повлияет, то нет смысла управлять им как риском. Это событие для нас – просто очередная задача, которую нужно запланировать и выполнить. Нас не волнуют и события, которые абсолютно точно произойти не могут. Нет события – нет проблемы, нечем управлять. Вообразим, что мы отправляемся на машине из Москвы в Красноярск. Какие неприятности могут поджидать нас по дороге? Ну, например, мы можем проколоть шину. Это событие может произойти, а может и не произойти. Значит, это риск, которым мы должны управлять. Какие еще? Мы можем устать и захотеть спать. Нужно ли управлять этим событием как риском? Нет, не нужно – расстояние 4000 км преодолеть за рулем без отдыха невозможно, поэтому мы не должны относиться к этому событию как к имеющему вероятностную природу. Оно гарантированно произойдет, мы гарантированно устанем! Значит, нужно просто запланировать, в каких точках маршрута мы будем отдыхать, и сколько времени мы будем это делать. Нужно ли нам бояться, что по дороге мы встретим агрессивно настроенного тиранозавра? Нет, не нужно, мы его точно не встретим (они вымерли, если кто не в курсе), поэтому для нас такого риска нет, управлять им не надо.

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

Итак, еще раз: риск – это негативное событие, которое может произойти и повлиять на проект.

Очевидно, что влиять на сами события мы не можем – ни акуле, ни шине, ни желанию спать, ни потере ста рублей не прикажешь не случаться. Чем же мы тогда управляем, если не можем влиять на события? Мы управляем их влиянием на нас.
Управлять рисками нужно для того, чтобы избежать действия негативных событий или ослабить его.

​​А если, несмотря на все наши ухищрения, негативное событие произошло? Тогда это уже не риск, а материализовавшийся риск, иными словами – проблема.

Момент, когда риск материлиализуется и превращается в проблему, называют событием риска. Как же узнать, в какой момент риск стал проблемой? Вот смотрите, еще секунду назад мы ехали с ветерком по прекрасной федеральной трассе. И вдруг – пшшшш... Шина-то проколота. Конечно, из кабины машины не видно, как огромный ржавый гвоздь входит в правое переднее колесо. Событие риска произошло, но мы его не видим. Зато машина вильнула в сторону, она уже едет как-то не так, и мы слышали странный хлопок. Т.е. мы узнали о том, что событие риска произошло, по некоторым признакам, симптомам, которые называются индикаторами риска. Именно отслеживание этих индикаторов – одна из основных задач при управлении рисками.

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

Если же вывести этот процесс на сознательный уровень и формализовать, то получится, что управление рисками состоит из нескольких универсальных этапов:

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

2. Оценить степень воздействия риска. Как известно, в бизнесе существует только то, что можно измерить количественно. Поэтому для каждого найденного риска необходимо ответить на два вопроса:
2.a «Насколько возможно возникновение этого риска?» и
2.b «Насколько сильно будет его влияние?».
Как правильно ответить на эти вопросы, что значит «насколько возможно» и «насколько сильно»? Об этом мы еще поговорим. )  

3. Придумать, какие действия нужно совершить, чтобы риск не наступил. Можем ли мы сделать так, чтобы негативное событие не произошло или произошло, но не повлияло на нас? Или повлияло, но незначительно?

4. Придумать, какие действия нужно совершить, если риск материализуется и станет проблемой. Что мы будем делать, если негативное событие произошло? Кому звонить, куда бежать?

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

5. Регулярно следить, не появились ли новые риски, и так же регулярно просматривать список старых рисков, не изменились ли их параметры?

(продолжение следует)

🌪 Как управлять рисками в проектах. Часть 2.

Почему вообще менеджеры проектов занимаются управлением рисками? К этому очень располагает сама природа проекта. Напомню, что проект – это совместная работа группы людей для получения уникального результата за ограниченное время и деньги. Группа людей (проектная команда) тоже временная. Там, где есть люди, ограничения денег и времени, стремление получить ранее не существовавший результат и т.д., возникает огромное число неопределенностей. И на пути к результату проекта этих неопределенностей еще больше. А вдруг мы не успеем сделать эту задачу к 16 декабря? А вдруг Вася, наш самый опытный сотрудник, внезапно уволится? А вдруг большие боссы нам не дадут денег на последний этап проекта? В общем, проект – отличная среда для управления рисками. 

Вернемся теперь к нашему алгоритму управления рисками и рассмотрим этапы детально. На первом этапе мы должны выявить риски. Но откуда их взять? Если речь идет о несложных, «бытовых» задачах, скажем, подготовке к автомобильному путешествию в Красноярск, то тут все более-менее понятно, для выявления рисков нужен водительский опыт и здравый смысл. Хорошо также, если мы управляем проектом в знакомой нам сфере – там тоже ясно с какими проблемами мы можем столкнуться. А что делать, если нам поручили рулить проектом в совершенно незнакомой области? К счастью, у этой задачи есть решение – поиск следует начинать с анализа возможных источников рисков.

Оказывается, если выписать риски проекта (просто написать все, что придет в голову), то все они группируются по следующим категориям:

Люди (болезни, увольнения, саботаж и прочие проявления человеческого фактора).

Технологии (риски, связанные с ИТ-системами, оборудованием, технологическими подходами).

Бизнес-процессы (все организационные и процессные риски).

Организации (риски, которые порождают компании-клиенты и конкуренты, поставщики, подрядчики).

Государство и законодательство (регуляторы, проверки, изменения законов).

Природные явления (природные катастрофы, особенно те, у которых красивые женские имена).

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

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

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

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

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

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

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

Обратите внимание – мы пока до самих рисков даже не добрались, мы получили только их источники.

​​Вспомним теперь, что мы рассматриваем только проектные риски. На каких столпах стоит все управление проектами, чем рулит менеджер? Качеством проекта, его содержанием, сроками и стоимостью. Поэтому все риски стоит рассматривать именно как угрозу этим параметрам. 

Как это выглядит на практике? Берем источник риска, например, «Люди». Для каждого человека определяем, как он может негативно повлиять на проект, какое его действие (бездействие) снизит качество, задержит сроки сдачи, увеличит стоимость. Тут главное не переборщить – не надо совсем уж в детали погружаться, лучше начать с самого очевидного.

Повторяем это упражнение для всех источников. В этот момент вы поймете, достаточно ли подробно вы проработали их карту.

Вы ведь чувствуете, что чего-то не хватает? ) Правильно чувствуете. Ведь если делать список рисков проекта только на основе источников, этот процесс никогда не закончится. Но тут нам на помощь придет самый главный проектный документ – план-график проекта.

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

Начинающие менеджеры рисуют красивый список рисков, продумывают, как ими управлять, а план у них живет параллельной жизнью. При этом часть рисков, полученных из иерархии источников, совпадает с рисками, генерируемыми планом, но этого никто не замечает. А ведь каждая (!) задача в плане – гарантированный риск с точки зрения сроков, стоимости,  качества, людей и ресурсов. Нет ли здесь противоречия с тем, что мы говорили в прошлый раз –запланированная задача не риск, она гарантированно случится? Противоречия нет, все в порядке. Сама по себе, конечно, задача случится, но ее сроки, стоимость и качество – большая неопределенность. Именно потому и важно использовать план – в нем перечислены события, которые гарантированно произойдут, и которых нет в иерархии источников рисков. 

Также надо заметить, что, помимо плана, в качестве источника риска нужно рассматривать любой проектный документ (вдруг вы забыли что-то перенести в план).

А что делать с рисками, о которых мы даже не догадались? Все проверили: и план, и источники, а  вдруг есть что-то, о чем мы совсем забыли? Об этом позже.)

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

Теперь понятно, где искать риски и что это за риски. А как их искать и в каком виде результат поиска должен быть представлен? И дальше-то что делать?

(продолжение следует)

​​🌪 Лирическое отступление

Стал писать про риски - стал получать кучу писем с вопросами.)

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

Я тоже так думал, пока в 2005 году наша команда, ключевые разработчики которой жили в Штатах, не столкнулась с последствиями урагана Катрина. Догадайтесь, в каком городе жили эти разработчики. Правильно, в Новом Орлеане. Поэтому в 2012 году наша (уже другая) команда последствий урагана Сэнди даже не заметила, не считая пары дней простоя.
Люди хорошо учатся на своих ошибках. Хотя лучше учиться на чужих.

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

Управление рисками - управление проектами по-взрослому. Берегите свои проекты и себя.

💡🔫 О лампах и пистолетах

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

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

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

По-моему, классная идея. Своим сотрудникам сделать, что ли? )

И да, к каждой лампе нужен пистолет. Можно начать с водяного.)

🌦 Как управлять рисками в проектах. Часть 3.

В управлении рисками важна регулярность. Надо не реже раза в неделю проводить:

Поиск рисков командой проекта.
Поиск новых рисков в плане проекта.
Поиск в реестре источников рисков.
Опрос экспертов.

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

«Насколько возможно возникновение риска?»
и
«Сильно ли риск повлияет на проект?»

Что значит «насколько возможно»? Внутренняя шкала для ранжирования вида неопределенности у каждого человека своя. Но зависит она, в основном, от его видения проекта. Предположим, мы планируем проект автопутешествия к морю и выявили два риска: «Автомобиль сломается в дороге» и «Нас оштрафуют за превышение скорости». Как рассматривал бы возможность материализации этих рисков молодой водитель на новом джипе? Про первый риск он сказал бы: «Вряд ли это произойдет! У меня новая отличная машина, я в ней уверен». Про второй он сказал бы: «Да, это очень возможно! Дорога незнакомая, я люблю быструю езду. Наверняка попадусь!» А как оценил бы эти риски человек пенсионного возраста на стареньком отечественном автомобиле? На первый вопрос он ответил бы: «Очень возможно, машина старая, бывает, подводит. А уж на таком расстоянии...» А про второй сказал бы: «Вряд ли, я езжу медленно, годы не те».

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

A. Незначительная возможность возникновения.
B. Низкая возможность возникновения.
C. Средняя возможность возникновения.
D. Высокая возможность возникновения.

Я специально избегаю терминов из теории вероятностей, ну ее, не в ней дело.

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

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

A. Незначительные последствия.
B. Средние последствия.
C. Значимые последствия.
D. Критические последствия.

С этими параметрами поступаем так же, как с предыдущими: приписываем каждому риску одно из четырех значений.

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

Она помогает нам ранжировать риски в проекте: каждой возможности возникновения соответствует своя степень воздействия на проект. Например, пара «Незначительная возможность возникновения» – «Незначительные последствия». Нужно ли нам беспокоиться о риске с такими параметрами? Нет, пока не стоит. Это почти невозможное событие, да еще и на нас не влияющее. Назовем это «низким риском». А если риск описывается парой «Средняя возможность возникновения» – «Средние последствия»? Тут уже надо беспокоиться и думать, что делать с этим риском. Такие риски назовем «средними». Так же выделим «высокие риски» и «критические риски».

А можно ли было нарисовать ее иначе? Например, поставить ячейке «Средняя возможность возникновения» – «Средние последств

ия» значение "низкий риск"? Конечно. Все зависит от проекта, и только вы определяете, как ранжировать риски.

Интуитивно понятно, что в красную зону этой матрицы попали риски, с которыми надо что-то делать. А в зеленую – пока можно подождать.

Ну а теперь мы сможем определить для каждого ранга свою стратегию управления.

(продолжение следует)

​​☄ Как управлять рисками в проектах. Часть 4.

Существует четыре стратегии реагирования на риск:

Мы можем риск принять.
Мы можем от него уклониться.
Мы можем его передать другому.
Мы можем снизить его влияние.

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

Уклонение от риска предполагает, что мы перестроим работу так, чтобы исключить риск из нашего проекта. Как мы можем уклониться от риска «Дорожные условия в автомобильной поездке ухудшатся из-за дождя»? Да просто: мы никуда не поедем. Или поедем, но не в Красноярск, а в Ташкент, там осенью с погодой получше. Можно ли считать это уклонением? Нет, это жульничество! Ведь мы изменили цели проекта! Теперь у нас уже новый проект, с новыми целями и планом. Но если не менять цели, как уклоняться от риска? Один из способов – прояснить требования и, не затрагивая целей проекта, постараться сократить список задач, которые нужно сделать.
Что делать, если уклониться от риска нельзя? Можно попробовать передать его другому.

В отличие от принятия риска, когда мы можем резервировать собственные средства, при передаче риска мы используем заемные средства. С передачей риска знакомы все, кто оформлял страховку на автомобиль. Любой страховой продукт – передача риска.
В проектах риск передается, например, привлечением вендора по модели fixed price. Как только мы заключили с вендором контракт, все риски за проект должен нести он.)

Конечно, так не бывает. Вендором можно прикрыться, если дойдет до разборок на высшем уровне, но на нашем уровне вендор сам источник рисков.)
Передача риска отлично работает в финансовой сфере, но плохо – в управлении проектами.
А что делать, если ни одна из описанных стратегий не подошла? Остается последний вариант – снизить влияние риска.

Снижение влияния риска – это понижение его ранга. Посмотрите на матрицу рисков – ранг зависит от возможности возникновения и от последствий воздействия риска на проект. Уменьшая один из этих параметров, мы понижаем ранг риска.
Статистика показывает, что управленцы обычно работают с последствиями, начинают придумывать, как их уменьшить. Это понятно – последствия можно потрогать, выразить в деньгах, товарах, синяках. С возможностью возникновения хуже, потому что за пределами моего рассказа ее называют вероятностью, и обращаться с ней умеют только выпускники мехмата, и то не все.
Вернемся к проекту про автомобильную поездку и рассмотрим риск «Можно проколоть шину». Как нам снизить влияние риска? Можно уменьшить последствия – взять запасное колесо. Тогда на трассе мы его поменяем, и, хотя риск воздействует на проект (мы же потратили 15 минут и испачкали руки), влияние незначительно. А можно снизить возможность возникновения – выбрать дорогу с лучшим покрытием или колеса повышенной прочности.

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

(продолжение следует)

​​⛷ Как стратегия уклонения от риска работает в реальности

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

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

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

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

Так избавляются от лишнего и сосредотачиваются на главном, не меняя цели проекта.

​​⚡️Как управлять рисками в проектах. Часть 5.

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

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

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

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

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

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

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

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

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

Мы можем снизить влияние риска. И это самый интересный вариант, ради него весь разговор и затевался. Как можно снизить влияние риска? Понизив ранг. Например, уменьшив возможность его возникновения. Для этого надо объяснить ребенку правила дорожного движения, научить его переходить дорогу только на зеленый сигнал светофора и только по «зебре», внимательно следя за окружающей обстановкой.
Но разве этого достаточно? Ведь речь идет о серьезной опасности, грозящей дорогому человеку! Что же еще можно сделать? Да многое!
Можно заказать частный вертолет, который перенесет его через опасную дорогу. Можно построить подземный переход или пешеходный мост, и поход за кефиром станет совершенно безопасным, машины туда не доберутся. Почему же никто так не делает? Потому что это очень дорого. Нам проще вообще отказаться от кефира, чем ради одной бутылки нести такие расходы на управление риском.

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

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

‼️ Технарям о текстах

Слушай сюда. Если ты менеджер проекта или продукта, владелец продукта, аналитик, тестировщик или аккаунт-менеджер, ты пишешь тексты. Ты их пишешь, даже если ты программист. И если ты не умеешь писать тексты, ты хреновый специалист.

Повторяю для тупых: не умеешь передать мысль в письме или техническом документе – не умеешь нормально работать.  

Дам несколько дельных советов. Годятся и для технических документов, и для писем клиентам или коллегам.

1. Не пиши текст с первого раздела. Начинай с самой важной мысли, с самой важной части. Даже если это последние пять строк документа. Введение напишешь потом, когда основная мысль будет отточена и завершена. Если начинать писать текст так, как его будут читать, то потратишь кучу времени на раздел «Общие положения» и ему подобные. А потом все равно придется переписывать.

2. Запомни – ты не стилист уровня Чехова или Довлатова. Ты не сможешь написать сразу так, чтобы читатель подпрыгивал от восхищения. Ни-ко-гда. Начни писать так, как ты думаешь: корявенько, не подбирая слов, путаясь в предложениях и мыслях. Если легче с матом – матерись. Вывали на бумагу всю страшненькую кучу своих мыслей. И только потом начинай искать верные формулировки и подходящие слова, разгребай ее, делай из кучи конфетку. Сразу написать хорошо не выйдет.

3. Запомни: чем короче, тем лучше. Для текста это точно справедливо. )) Не пиши длинных предложений. Если получилось длинное, разбей на несколько коротких.

4. Не пиши предложения в пассивном залоге. Для тех, кто не в курсе: это фразы типа «тестирование системы было проведено специалистами заказчика». Надо так: cпециалисты заказчика протестировали систему. Меньше пассивного залога – лучше текст.

5. Проверь документ перед отправкой. В нем не должно быть ошибок, опечаток, несогласованных частей предложения, лишних скобок и кавычек. Не уверен в своей грамотности – пользуйся автоматическими средствами проверки орфографии. Если в документе есть ошибки, то и к автору документа, и к его компании, и к его продукту отношение как к … гм… ну, ты понял. Я уж молчу про ошибки в интерфейсе продукта.

Третий раз, для самых тупых и упертых: тексты – это важно.

​​1⃣ 2⃣ 3⃣ Три дела в день

Все полезные идеи очень просты.

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

Так же просто устроено и планирование задач на день. Надо просто определить три свои главные задачи и сделать их. Три. Не одну, не две, не четыре. Три.

И каждое утро спрашивать себя: "Какие у меня три главные задачи сегодня?"
А каждый вечер проверять, что они сделаны.
Это реально работает.

​​🍭 О вреде бесцельного обучения

Одно из самых вредных дел в жизни – бесцельное обучение.

– Зачем ты этому учишься?
– Ну, чисто для себяяяяя... Типа по приколу мнеееее... Хочууууу...

Обучение с целью – это селекция (быстро и с управляемым ожидаемым результатом).
Обучение без цели – эволюция (непредсказуемо, долго и с неизбежными тупиковыми ветвями).

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

"Хочу научиться играть на гитаре" – обучение без цели.
"Хочу научиться играть на гитаре, чтобы на днюхе у Машки спеть "Ой-ё" – обучение с целью.

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

🖋 Вакансия технического писателя

Мне в команду нужен хороший технический писатель.

Что он будет делать:

Писать технические тексты для проектов: ТЗ, пользовательские инструкции, программы и методики испытаний, описание API и т.д.

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

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

Требования к кандидату:

Любит писать тексты.

Умеет писать технические тексты. 

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

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

Грамотный.

Заботится о качестве: не отправляет клиентам текст с ошибками и опечатками, тщательно проверяет форматирование, нумерацию, названия рисунков, обновляет содержание и следит за колонтитулами.

Не боится и не стесняется задавать вопросы.

Знает, что такое «канцелярит», и не использует его обороты в текстах.

Умеет просто и понятно писать о сложном. 

Умеет учиться. Читал «Пиши, сокращай», разделяет и использует идеи из этой книги.

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

Умеет разговаривать и договариваться с другими людьми.

Если интересно, пишите мне на psilonsk@gmail.com, в теме - ТП2020

​​👶🏼 🍼 Свежие плоды цифрового века

Мы начинаем пожинать плоды нашей цифровой эпохи.

Раньше было так. Хочет человек стать, скажем, менеджером проектов. А работает он аналитиком. Или инженером. Или программистом. И он начинает думать: а как же ему стать менеджером проектов? Что для этого нужно? Какие навыки могут пригодиться? Каких знаний не хватает и где их можно найти? Какие книжки почитать? Где потренироваться? Как получить первый рабочий проект? Как убедить руководство, что он справится с проектом? Человек думает, отвечает на вопросы, ищет путь. Он не ищет проводников на этом пути, он набивает шишки и учится решать задачи.  

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

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

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

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

​​🤸‍♀ Гибкие навыки

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

А вот с софт-скилами не так. Чтобы делать современные продукты, нужно объединять специалистов и команды из разных отраслей. Это объединение может происходить только на основе софт-скилов. Надо уметь видеть целое, а не разрозненные детали. Надо уметь выявлять закономерности в сложных сущностях. Нужно уметь общаться, договариваться. Если вы выучили язык программирования или освоили новый инструментарий, это процентов тридцать будущего успеха. Остальные семьдесят – ваше умение коммуницировать.

Когда упертые инженеры это поймут, мир станет  чуть-чуть лучше.

А музыканты и хирурги пусть идут своей дорогой. )  

​​🧩 Компания как продукт

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

Но самое крутое, когда все в компании понимают, что и сама компания -  тоже продукт. Удобно ли пользоваться процессами компании? Какие проблемы при этом возникают у пользователей - сотрудников? Можно ли двумя кликами оформить отпуск? Легко ли получить доступ к нужным сетевым ресурсам? Что нужно, чтобы оплатили такси, когда рабочий день превратился в рабочую ночь? Удобный ли у вас стул, клавиатура, мышка? Можно ли прилечь подремать в середине рабочего дня? Нужно ли идти за кофе за два квартала или вкусный кофе уже есть на кухне? А что с корпоративной культурой? А как создаются продукты (и это самое главное!), все ли подходы обоснованы? Какие метрики стоит отслеживать? И вообще, удобно ли пользоваться компанией как продуктом?    

Если к компании начинают относиться как к продукту, все встает на свои места. Ведь когда вы создаете продукт, вы действуете итерационно. Поменяли что-то - посмотрели на результат, улучшили и продукт, и процесс его создания. Нельзя делать новый продукт старыми методами. Так и с компанией - она должна все время меняться и улучшаться.     

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

​​🍔 Трагедия менеджеров среднего звена

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

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

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

Как масло в бутерброде - между хлебом и икрой. Во всех смыслах.