Всем привет! Я уже больше 15 лет в IT, в роли РП 7 лет, до этого  долго был в смежных ролях релиз-менеджера и сервисного-менеджера. Долго мне не давали переходить в РП, но я формировал теоретическую базу и ворвался потом сразу в большие проекты. Сейчас являюсь играющим тренером, люблю сложные проекты/фичи большого масштаба. По запросу занимаюсь менторством, радуюсь когда вижу развитие и рост коллег. Хочу поделиться на мой взгляд ключевыми проблемам которым мало уделяется внимание, сразу расскажу предложения по решению. Надеюсь кому-то будет полезно.

1. Плохая коммуникация с Заказчиком

Это самая большая причина на мой взгляд исходя из опыта и взгляда со стороны реализации проектов коллег. Часто приходится сталкиваться с системным сбоем в процессах обмена информацией между участниками проекта. И если не управлять заинтересованными сторонами (стейкхолдерами) проекта, это может привести к серьезным проблемам, которые способны поставить под угрозу его успех. Вот основные негативные последствия: конфликты, сопротивление и неучтённые интересы; возможны неожиданные требования, как следствие доработки, перепланирование; низкое качество результата; недостаток поддержки от руководства или инвесторов; репутационные риски и даже провал проекта.

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

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

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

2. Нечеткие или меняющиеся требования и как следствие недооценка сроков и бюджета.

Это самая распространенная связка проблем, когда от Заказчика нет четко сформулированных, детализированных и согласованных требований на этапе старта и, конечно мы ИТ даем оптимистичные оценки при кажущиеся на первый взгляд простой реализации. Это создает риски для всех участников: команда разработки не понимает, что именно нужно реализовать, а Заказчик в итоге получает не тот продукт, который ожидал. Получается разработчики и менеджеры часто оптимистично прогнозируют сроки, не учитывая скрытые работы (тестирование, доработки, интеграции). Непредвиденные сложности (например, проблемы с API сторонних сервисов). А так же новички (что довольно часто на новых проектах) склонны занижать реальные сроки из-за недостатка опыта. И конечно Заказчик настаивает на нереальных сроках — мы пытаемся подстроиться под ожидание что бы реализация не казалась «такой большой». Потом в процессе разработки появляются новые пожелания, что ведет к "расползанию функционала" (scope creep). Непонимание между бизнесом и разработчиками.

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

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

• Проекты с высокой степенью неопределенности и недостатком прогнозной информации

• Проекты с высокими рисками, высокой динамикой внешней и внутренней среды проекта

• Проекты исследований и разработок (R&D)

• Проекты уникальные, впервые выполняемые работ и т.п

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

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

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

3. Проблемы с управлением рисками

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

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

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

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

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

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

Удачи вам в этом нелегком поприще!