February 2012
M T W T F S S
« Jan    
 12345
6789101112
13141516171819
20212223242526
272829  

Identify It. Now!

20 дней назад моя команда стартовала разработку нового проекта. Проект небольшой, но заказчик – наш стратегический партнер. В рамках необходимой функциональности был заявлен веб-интерфейс для отчетов, а мои бойцы имеют мало опыта в веб-разработке. Я подумал о том, что вероятность не справиться с новой для нас технологией ASP.NET (ну бывает, отстали от жизни) весьма высока. Поэтому попросил команду развернуть стенд проекта заранее, на середине этапа разработки, а не за день до срока сдачи. Пусть вместо отчетов был бы просто “здравствуй мир”. И работа закипела….

Немного лирики

Риск – это игра, а когда выигрываешь – чувствуешь себя круче. Управление проектами не исключение.  И спасибо за этот неиссякаемый источник адреналина в крови менеджера проекта.  Когда менеджер собирает команду на митинг с призывом “Тигры- вперед!!!” – им движет риск сорвать сроки проекта. Когда пишет аккуратный и точный отчет заказчикам – им движет риск сорвать коммуникации. Опытный менеджер немного параноик, которого каждый день преследует вопрос “Что может помешать достижению цели и как это предотвратить?”. И этот вопрос делает интересной самую рутинную работу.  Риск – благородное дело и потому требует уважительного обращения.  В управлении уважение означает планирование.

О чем речь

Цель этой статьи – рассказать о том, что такое риск и как его правильно искать (Risk Identification).  Статья адресована в первую очередь менеджерам проектов. Я считаю тему этой статьи важной по трем причинам:

  1. Недооценивают у нас риски. Кажется, это наша национальная черта, взять хоть ту же футбольную сборную России.
  2. Идентификация рисков это отправной пункт в управлении рисками. Если вы не справились с идентификацией – дальнейшее  теряет всякий смысл и превращается в видимость работы.
  3. Risk Identification – it’s a magic, который приходит с опытом. Но кое что можно узнать заранее.

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

Для того чтобы что то искать, надо знать что ищешь. Мне нравятся такие простые определения риска из книги “Software Sizing, Estimating and Risk management” Daniel D. Galorath • Michael W. Evans, которые дополняют друг друга.

  1. “Factors that have the potential to impact a project”
  2. “Сritical events that would prevent the program from achieving its objectives.”

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

Комментарий 1

Риск – это не просто “случилось страшное”. “Ничего не работает”, “видимо что-то случилось”, “много ошибок” – это все не про риски, а про проблемы. Все уже случилось, пора каяться и исправлять. Риск – это угроза, factors, critical events. Вы рискуете сломать себе шею, гуляя по карнизу. Риск заключается в опасных прогулках, а не в переломе позвоночника, не гуляйте где попало!

Комментарий 2

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

Комментарий 3

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

В следующей части статьи вас ждет крутой, но скучный процесс идентификации рисков, Круто, но скучно – это в стиле PMBOK.

Risk Identification Plan

На входе

  • План управления проектом. Пришлите мне открытку на @vzzvzz те, у кого этот план есть. Такой план должен объяснять миссию проекта, содержание (scope), расписание, стоимость, структуру работ (Work Breakdown Structure), критерии качества, коммуникации и многое многое другое….
  • План управления рисками. Кто, что, когда, где и как будет делать с рисками в течении жизненного цикла проекта. Для идентификации рисков в этом плане важны следующие моменты
    • Роли и ответственности – определяем ответственного за управление рисками путем назначения ему соответствующих задач и полномочий;
    • Бюджет – сколько средств и на что мы готовы потратить в рамках управления рисками;
    • Расписание – какую деятельность и в каком порядке мы планируем вести в процессе управления рисками;
    • Категории рисков – какие виды рисков мы будем рассматривать для идентификации и приоритезации.
  • Содержание проекта (Project Scope Statement) - это цели проекта, содержание работ, основные результаты, границы и допущения. Для идентификации рисков нас тут будут интересовать последние два пункта. Выход за границы проекта и неоправданные допущения – это готовые риски в проекте. Пример такого риска – в одном проекте мне надо было организовать внедрение продукта на ста удаленных рабочих местах пользователей за два месяца. Исходя из опыта прежних проектов мы предположили, что справимся двумя бригадами внедренцев, если они будут обслуживать по 3 точки в день. Это предположение стало моей головной болью на все время проекта, так как приходилось постоянно отслеживать ситуацию. Плохая погода, плохие дороги, отсутствие пользователей на местах – все это угрожало сорвать план.
  • Активы организационного процесса (Organizational process assets) Это формальные и неформальные стратегии, планы, руководства и правила, короче все то, что обычно раздражает вас в вашей фирме. Они задают определенные правила действий, например для получения дополнительных ресурсов. Сколько дней юрист будет рассматривать договора с подрядчиками, связывается ли ваша фирма с фрилансерами, подумайте об этом заранее. Эти активы не столько создают риски, сколько ограничивают возможности по их предотвращению.
  • Факторы внешней среды предприятия (Enterprise Environmental Factors) Любой или все внешние факторы воздействия и внутренние организационные факторы, влияющие на успех проекта. Наличие ресурсов, условия рынка, плохие дороги или медлительный подрядчик и все в таком духе. Умение видеть эти факторы  – волшебство, которое приходит с опытом.  Самые коварные риски прячутся как раз здесь. Общее правило работы с внешними факторами – все будет не так хорошо как нам бы хотелось.

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

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

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

Мы успели. В гости к стратегическому партнеру не бывает опозданий. :-) Но мы приступили к  развертыванию стенда  в последний момент, когда уже “все было готово”. Ясное, дело – в пятницу вечером. И конечно, ничего не работало на сервере, а локально все было супер. И конечно, билеты на поезд уже были куплены. Хорошо, что  нашлось время все починить из дома. В управлении проектами героизм как правило следствие пренебрежения рисками.

  • is

    Дорогой Vzzvzz!

    Никогда не верьте разработчикам, что “все готово”. Пока это не стоит на сервере с которого показывают. И пока это не было протестировано. А то их “все” не включает очень много вещей…

  • is

    Дорогой Vzzvzz!

    Никогда не верьте разработчикам, что “все готово”. Пока это не стоит на сервере с которого показывают. И пока это не было протестировано. А то их “все” не включает очень много вещей…

  • Konstantin Bychenkov

    Уважаемый Is! :-)
    Насчет “все готово” у меня иллюзий не было ни секунды. Работы до сих пор продолжаются. Но я зря не дожал ситуацию и поддался на отговорки чтоб не делать стенд заранее. Я страраюсь лишний раз не дергать разработчиков, и не доказывать, что “я всегда прав”, но это был не тот случай.