Риски в жизни руководителя проектов Часть 1
Все руководители проектов слышали словосочетание «управление рисками». Если спросить на собеседовании, что такое риски и как ими управлять, видно, что РП усердно вспоминают определение риска, вспоминают слово «митигация», но вот ответить на вопрос о том, как с этим работать, не может почти никто. В тоже время есть много книг, посвященных управлению рисками в проектах, на Хабре есть несколько интересных статей (я гуглил, пока готовился).
Почему так получается? Что, на ИТ проектах вообще нет рисков, только одни проблемы? Или работать с рисками надо начиная с определенного уровня проекта?
Давайте разберемся с рисками.
Эта статья – часть цикла статей о том, чего обычно не рассказывают на курсах РП и до чего я дошел сам, наступая на многочисленные грабли за все 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% все равно придется получать, наступая на грабли, куда же в нашей работе без граблей? 😊
Работа с рисками – это, пожалуй, основной инструмент проактивного менеджмента. Вы смотрите вперед, вы знаете, что вас ждет и готовитесь.
Если вы видите риски и решаете их, проблемы или не наступают или они наступают предсказуемо.
Соответственно, если вы их не видите, то у вас каждый день неприятные новости и, что самое противное, они возникают непредсказуемо, что никуда не годится.