Все руководители проектов слышали словосочетание «управление рисками». Если спросить на собеседовании, что такое риски и как ими управлять, видно, что РП усердно вспоминают определение риска, вспоминают слово «митигация», но вот ответить на вопрос о том, как с этим работать, не может почти никто. В тоже время есть много книг, посвященных управлению рисками в проектах, на Хабре есть несколько интересных статей (я гуглил, пока готовился).
Почему так получается? Что, на ИТ проектах вообще нет рисков, только одни проблемы? Или работать с рисками надо начиная с определенного уровня проекта?
Давайте разберемся с рисками.
Эта статья – часть цикла статей о том, чего обычно не рассказывают на курсах РП и до чего я дошел сам, наступая на многочисленные грабли за все 25 лет опыта в ИТ. Если вам такой опыт интересен, читайте другие мои статьи здесь на Хабре и заходите в мой ТГ канал «Морковка спереди, морковка сзади».
Часть 1. Типовые риски
Что такое «сбывшиеся риски» я увидел на одном из моих самых первых проектов. Я был зеленым балбесом-аналитиком и учился рисовать в UML, когда Руководитель проекта собрал нас в конце года и сказал: «ребят, я недооценил риски проекта, это какой-то треш, я слишком стар для этого, я устал, я ухожу», после чего уволился, а наш Лид аналитики со словами (в шутку, конечно 😊): «этот проект протух, надо искать новый на фазе анализа» ушел на другой проект. А потом всю нашу проектную команду ждали 9 месяцев лютого треша по выходу в прод с работой по ночам и выходным. Вот тогда я понял, что такое «риск недооценки объемов работ из-за слабой экспертизы», который состоялся.
Давайте сразу: на любом проекте есть риски и проблемы. В начале проекта проблем обычно нет и может возникнуть иллюзия, что все очень хорошо и тихо. Но хорошо вам от того, что вы просто не видите волну в виде рисков, которая к вам приближается. В этом отличие опытного РП от новичка. Новичок радостно проводит статусные встречи, а тертый внимательно изучает контракт. Новичок тратит свое время на встречах по аналитике, а тертый смотрит, че там по интеграциям, надо ли перетаскивать данные, что там по описанию данных в источниках, какие требования по отчетности, что там по NFR, встречается с техлидами и так далее. Почему так? Потому что во всем вышеперечисленном сидят риски.
Месяцевчерез 3–6 это обычно выглядит так, что при одной и той же сложности проектов новичок зашивается, бегает как бешеный, ничего не успевает и просит помочь, а тертый делает проект левой пяткой и надо бы ему еще 1–2 таких проектов отдать. Это и есть то самое отличие Джуна от Синьора, о котором я писал вот тут, и за которое людям деньги платят.
Не видите рисков – у вас будут проблемы.
Если у вас на проекте часто и внезапно случаются проблемы, которые вы решаете в пожарном порядке — вы не умеете прогнозировать, и вы не умеете видеть риски. Не делаете вы этого или потому что у вас нет опыта, или потому что на самом деле, вам так нравится. Есть даже особый психологический тип менеджеров, которые обожают работать в режиме пожаротушения и непрерывного треша, а когда все прогнозируемо и спокойно, им становится скучно, они чувствуют себя ненужными.
Проблема в том, что такой подход приносит ущерб компании. Рост хаоса в проекте приводит к смещению сроков. Смещение сроков = потерянная прибыль.
РП обязательно должен заглядывать дальше своего носа и видеть проблемы заранее. РП и только РП должен быть самой главной истеричкой в начале проекта, это нужно как раз для того, чтобы истеричками к концу проекта не стала вся остальная проектная команда. Нормальный РП всегда должен уметь запустить у себя в голове заряд паранои в виде Законов Мерфи:
Конечно, невозможно предвидеть все, и нельзя в теории научить всему. Часто ИТ проект — это создание нового уникального продукта, а значит и риски могут быть настолько специфические для проекта, что предвидеть их невозможно.
Но давайте начистоту: большинство ИТ проектов, это типовые Enterprise внедрения. Это оцифровка процессов, перенос данных с устаревших платформ на новые и непрерывное улучшение и поддержка существующих ИТ систем. И вот на этих проектах предсказывать проблемы вполне возможно. Больше того, через 5 лет таких внедрений вы и сами научитесь их отлично видеть.
Типовые риски ИТ проекта или что может пойти не так?
Начну с ответа на вопрос в начале статьи: почему РП как правило знают, что такое риски, но с трудом могут рассказать, как они с рисками работают? По моей практике, ответ в том, что РП работают с рисками, но неосознанно. Как правило, РП выделяет типовые проблемы проекта, с которыми он уже сталкивался и готовится к ним, приоритизируя список рисков внутри своей головы. Просто он нигде его не ведет, не знает, что у риска есть «вес» и прочую теорию.
Почему это работает для небольших проектов? Потому что риски типового ИТ проекта тоже типовые. Ниже я подготовил список рисков проекта, которые считаю типовыми и которые рекомендую начинающим менеджерам использовать прямо в качестве чек листа:
Функции системы. Чем сложнее и неопределеннее процессы, которые вам надо оцифровать, чем сложнее функции системы или GUI системы, тем больше объема работы там может сидеть. И если простые функции дописать можно быстро, вносить изменения в процесс может быть очень неприятно на поздней стадии проекта. Такие требования заказчика могут ставить под угрозу сроки сдачи.
Митигация: изучение ТЗ совместно с лидом аналитики, выделение «слабых точек»: недоописанные схемы процессов, нечеткие требования к функциям. Это надо или прояснить сразу, или не забыть на фазе уточнения требований. Плюс, заложить запас в деньгах и сроках на потенциальные проблемы.
Интеграции (и миграции). Если у вас серьезная банковская или телеком система, есть немаленькая вероятность того, что она должна будет интегрирована с несколькими другими ИТ системами для обмена большими объемами данных. Интеграции могут быть очень «тяжелыми». Недооценка интеграций в начале проекта = проблемы ближе к концу, которые быстро вы победить не сможете, если не подумаете заранее.
Митигация: смотрим, сколько интеграций надо сделать, какие потоки данных и сложность логики обмена. Условно, передавать 2 параметра в соседнюю систему — ерунда, ежедневно обновлять сведения о миллионе объектов с логами истории и подобъектами — геморрой, надо много времени отдельную архитектуру и команду.
Отчетность. Потенциальная бомба любого проекта оцифровки бизнес‑процессов. Заказчик почти никогда не понимает, что ему будет нужно по отчетности вначале, а когда понимает на приемке, выясняется, что нужные точки процессов не оцифровали и данных в системе нет. Это может сильно огорчить заказчика и помешать вам сдать проект.
Митигация: заранее проговаривайте, какую отчетность хочет заказчик. Возможно надо будет внести изменения в требования, но лучше так, чем страдать на сдаче‑приемке. Ну и фиксация всех этих обсуждений, чтобы потом вам не сказали, что вы не предупреждали.
Нефункциональные требования. Часто могут скрывать показатели вида «доступность 99.7%» или «максимальное время отклика системы 0.1с» и тп. Выглядит невинно, но за собой тянет требования к резервированию:
доступность 99.7% — может привести вас к понятию «катастрофоустойчивость», что потребует одинакового оборудования для основного и резервного хостов, расположение в разных ЦОД и правила репликации. Если этого нет в оценке работ — у вас большие проблемы;
максимальное время отклика — могут проверять без нагрузки и под нагрузкой (в этот момент у вас могут начаться проблемы).
Митигация: если подобные системы для этого же заказчика делались, поглядеть, как там детализировались аналогичные требования и как выглядела приемка. Если не делалось — закладывать доп. время и деньги.
Это что касается рисков по самой системе. Еще надо посмотреть на административные риски. Рассмотрим основные:
Риск сложной политической конфигурации. Бывает во внутренних подразделениях, когда РП от ИТ, а заказчики — внутренние департаменты. Когда таких департаментов больше 10, спонсоры — VP компании, а РП новичок, это грозит большими проблемами. Очень много сторон, очень много желаний, которые могут пересекаться и противоречить между собой.
Митигация: внезапно Устав проекта с зафиксированными целями по Департаментам, с сотрудниками, выделяемыми в проектную команду. Много коммуникации с департаментами, выделение проблемных департаментов для интенсивной работы. Фиксация всех договоренностей в отдельной папке на случай разборов «кто виноват?».
У РП много ответственности, а власти нет. Часто Руководитель проектов во внутреннем ИТ крупной организации — это «делатель без рук». Он отвечает за сроки перед заказчиками и своим бизнесом, он отвечает за предоставление данных перед своим подрядчиком, но у него нет никаких своих ресурсов, чтобы повлиять на ситуацию (аналитика, девопсы, тестирование), а на подрядчика он влиять не может (так, увы бывает, что подрядчик предопределен на пару уровней выше уровня РП). В итоге очень легко можно стать крайним и во всем виноватым между бизнесом (который всегда прав) и подрядчиком (который тут сто лет и отлично ориентируется).
Митигация: максимально хорошо изучить вводные от бизнеса, максимально изучить постановку подрядчику (контракт) и далее выравнивать ожидания бизнеса от работы исполнителя (как правило, они завышены). Ну и аналитика себе в штат запросить все‑таки нужно.
Риск большого объема разработки. Если у вас проект, на котором больше 10 разработчиков, есть риск хаоса разработки и деливери, если вы правильно не выстроите процесс разработки и поставки кода. Аналитики будут ставить постановки «кто как», разработчики будут тормозить и задавать вопросы, у вас не будет методики объединения фич в релизы, правил сборки кода и так далее, что приведет к срывам сроков поставок кода.
Митигация: выстроить процесс деливери в проекте. Оформление требований, правила разработки, правила тестирования, правила сборки, правила выкатки заказчику (написать и реализовать в своем трекере, разумеется).
Заключение Части 1
Я бы рекомендовал любому РП смотреть, для начала именно на вышеперечисленные риски. Разумеется, это неполный список. Чем больше ваш проект, тем больше рисков. Не будет поставлено оборудование в срок, сезон отпусков, вендор сам не знает систему, которую продает для внедрения и так далее — тут все очень индивидуально. Но то, что написано выше, играет почти всегда. Зная про эти подводные камни, вы уже процентов на 30% лучше готовы. Ну а остальные 70% все равно придется получать, наступая на грабли, куда же в нашей работе без граблей? 😊
Работа с рисками – это, пожалуй, основной инструмент проактивного менеджмента. Вы смотрите вперед, вы знаете, что вас ждет и готовитесь.
Если вы видите риски и решаете их, проблемы или не наступают или они наступают предсказуемо.
Часть 2. Реестр рисков и проблем
В Части 1 выше я рассмотрел типовые риски любого проекта: то, на что я бы рекомендовал смотреть Руководителю проектов в первую очередь. Однако, что делать, если кроме этих рисков вы видите и другие? Если их много и надо систематизировать эту работу? Здесь на помощь придет «Реестр рисков и проблем».
Как‑то очень давно, когда мне, зеленому РП достался большой проект. Меня моментально завалило кучей срочных дел: команде аналитики нужно помогать проблемы с бизнесом, команда разработки требует окружений разработки и тестирования, команда интеграции не может интегрировать без примеров данных, а их надо запрашивать, надо выстраивать процесс разработки и запускать его с нуля, а команда уже тогда была распределенной на 5 городов в разных странах с разницей в таймзонах 8 часов.
Короче, я не мог уснуть. Я психовал и чувствовал, что я не справляюсь: новые задачи поступали быстрее, чем я успевал обработать старые, я чувствовал, что еще немного, и я продолбаю что‑то настолько критичное, что исправить не выйдет. Здравствуй, невроз.
Как‑то ночью, когда я не мог уснуть, я просто взял и выписал все, что может случиться страшного (но еще не случилось) на проекте. И уснул.
А на завтра я вспомнил, что видел у заказчика шаблон матрицы рисков и проблем и — бинго! Я понял, что ночью я выписал риски своего проекта, и мне осталось только заполнить остальной шаблон.
Реестр понадобится вам, как Руководителю проектов, чтобы у вас был органайзер, куда вы сможете поглядывать, не упускаете ли вы что‑то критичное. Заодно вы научитесь использовать классическую формулу Risk priority = probability * impact в реальной жизни (и убедитесь, что это та самая приоритизация по признаку "кто умрет" о которой я упоминал в статье вот тут).
Реестр рисков
Ниже пример реестра рисков, как его использовал я. Все поля опциональны и вы можете менять их так, как вам нравится, лишь бы этот инструмент приносил пользу вам.
Для чего нужны поля.
Краткое описание: название.
Когда обнаружен: может понадобится при общении с руководством. Да и риск, который обнаружен давно и важен, а работы по нему нет, так проще найти.
Важность (0..1). Отвечаем на вопрос «Если это произойдет, кто умрет и что будет?» Если умрут все и будет срыв сроков и ужас‑ужас — это 1. Если никто особо и не заметит, то 0.01.
Вероятность (0..1). Вероятность наступления события на лично ваш взгляд. 0 — не наступит никогда, 1 — наступит 100%.
Вес — это самая важная метрика риска, по которой риски сортируются.
Описание — тут для непосвященного должно быть ясно, в чем риск.
План устранения (лог): история событий по риску. Требуется для восстановления последовательности шагов, если надо будет потом разбираться.
Как с ним работать: заполните все риски, которые есть у вас в голове и беспокоят вас. Даже если их будет 50 (особенно, если их 50!). Далее отсортируйте по полю «Вес» по убыванию и далее работайте только с 10 рисками сверху. Все.
Реестр можно обновлять каждый раз, когда произошли изменения по отслеживаемым рискам. К примеру, вы предприняли шаги по митигации риска «не поставят оборудование в ЦОД», подписали контракт с проверенным поставщиком, тот гарантировал сроки, риск снижен, реестр обновили, пересортировали и следим только за актуальными с максимальным весом.
Что вам дает реестр:
Он бережет вас от паранойи и ночных кошмаров вида «я что‑то позабыл». Все что вы знаете, уже есть в реестре и отсортировано, можно спать спокойно.
Он бережет вас на случай, когда риск сбывается и становится проблемой. Обычно, в этом месте начинаются разборки «кто виноват?» и «что делать?». В этом месте лог по риску отлично вам поможет ответить на вопросы без судорожных поисков истории вопроса в почте, трекерах и мессенджерах.
Реестр проблем
Проблема — это сбывшийся риск. Если у вас возникла критичная проблема, а риска такого в реестре не было — стоит задуматься, как так случилось, что вы проморгали риск. Реестр проблем строится аналогично реестру рисков, за исключением того, что поле «вероятность» и «важность» не нужны, можно сразу заполнять «вес».
Логика работы таже самая: сортируем по убыванию и работаем по верхним 10, каждый день пересматривая его (можно и реже, тут на ваше усмотрение и скорость принятия решений).
Заключение Части 2
Как видите, реестры рисков и проблем нужны как инструмент структуризации информации при ее действительно большом потоке. Использовать реестры на небольших проектах смысла нет. Однако, понятия «большой» и «маленький» — понятие растяжимое и зависят, в том числе, от опыта Руководителя проектов. Поэтому я бы рекомендовал попробовать РП, который этого не делал, поделать работу с реестром на своем самом сложном текущем проекте. Если довести эту работу до автоматизма, далее, даже на очень сложных проектах, вам не понадобится заполнять эксель, у вас вся эта таблица и логика будет уже в голове.
