Программная инженерия. Управление рисками

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

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

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

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

Другой вопрос в том, что практика планирования в управлении проектами подразумевает наличие единственного верного пути, приводящего нас к цели. Я ни разу не видел диаграмму Ганта, имеющую ветвления, условные переходы, альтернативные последовательности работ. Не знаю, почему так сложилось, но в проектном плане, в отличии, например, от модели бизнес-процесса, принято рисовать только один вариант действий. Это вам не use cases в стиле Алистера Коберна, описывающий основной сценарий, исключения и последовательности действий для обработки исключений. Ничего подобного в проектном менеджменте нет. Отчасти из-за этого и возникает необходимость в формулировании рисков (исключений, говоря языком use case-ов) и планировании последовательности действий, реализуемой при их возникновении.

Программная инженерия. Управление рисками: 13 комментариев

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

    1. “Управление исключениями” – название очень меткое 🙂 спасибо. Подозреваю, что если участникам бизнес-процессов, в случаях, когда они не знают что дальше делать, предоставить возможность заводить инциденты на процессного архитектора, то очень востребованная услуга получится

  2. “…главное в управлении рисками – это качество планирования” – well said. Considering that this is about internal project concerns, good EA should help with the risk management about external (relative to the project) concerns.

    “…практика планирования в управлении проектами подразумевает наличие единственного верного пути, приводящего нас к цели” – not at all. A project at initial phases may consider several “proposed solutions” to be evaluated, POCed, etc.

    Thanks,
    AS

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

  3. “Проектные риски появляются в ходе планирования и целеполагания.” – я бы расширил до: … в ходе фиксации ожидаемого результата.

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

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

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

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

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

  4. “Я ни разу не видел диаграмму Ганта, имеющую ветвления, условные переходы, альтернативные последовательности работ.”

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

    Как я понял из открытых источников (часть американских field manuals свободно лежит в открытом доступе), план операции как раз включает в себя альтернативные ветви, приоритеты по целям и exception handling.

    1. Как я помню из курса тактики, полученного мной на военной кафедре, всегда планируется лсновная позиция, запасная позиция, позиция для отхода, ну и навернео много ещё чего я не помню.
      Но дело в том, что в современном ИТ, а соответственно и в управлении ИТ-проектами (за другие не скажу не участвовал) доминирует некое упрощенчество. Как говорил один мой заказчик: “Хватит уже проектировать, давайте макет делать”.
      Может дело в разной мере ответственности? На войне следствием неудачного плана может стать трибунал, снижение в звании, а то и пуля офицерской чести… А в проектах: “Неудочные проекты, являются даже лучшим опытом, чем удачные…” 🙂

      1. Конечно. Если я правильно помню уставы, то командир, принимая решение об организации боя, начинает с определения первоочередных мероприятий. С чего начинает IT project manager, представить себе нетрудно 🙂

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

  5. Если в контексте рисков сравнивать проекты с процессами, получается, что процессные исключения – это и есть контроль рисков в процессах, но как и всё остальное в процессах, исключения должны быть на 100% известны заранее, то есть в момент создания или доработки исполняемой модели процесса, которая потом многократно воспроизводится во множестве его экземпляров.

    > “риски возникают в ходе планирования из-за нашей принципиальной неспособности создать абсолютно точный план”

    Можно сказать, что предсказуемость, а значит и точность планирования, в значительной степени зависит от повторяемости: в процессах при 100%-ной повторяемости экземпляров нужна детерминированная обработка исключений, а в уникальных проектах – вероятностное управление рисками.

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

    А теперь можно добавить, что в типовых кейсах повторяются еще и риски!

    1. Попробовал систематизировать сказанное выше.

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

      Процессы:
      Для Процесса всё известно заранее, и в каждом экземпляре повторяется на 100%: и цели и ход работ.
      Всё делается по детерминированному алгоритму;
      Контроль отклонений – через заранее предусмотренные исключения.

      Кейсы (в своем большинстве похожи на типовые проекты):
      Повторяются: цель, структура документов, роли участников, состав этапов/стадий, события, контрольные точки;
      Ход работ в деталях – не повторяется и непредсказуем;
      Контроль отклонений – через управление рисками, но более эффективно, поскольку повторяемо на многих экземплярах.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *