Управление программами: «Почему бюрократия помогает?»

Докладчик: Аксель Ферст

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

Если у вас не создана оптимальная техническая инфраструктура, быстро возникают проблемы: она нужна для работы команд, должны быть карты доступа, ноутбуки, все остальное. Это задача, кстати, для ОУП — все организовать, и чем крупнее компания, тем более забюрократизирован такой процесс, на это требуется достаточно много времени. В проекте по переводу SAP ERP на HANA мы привлекали около 60 дополнительных сотрудников, которым нужно было организоваьт доступ, выделить ноутбуки, помещение предоставить — на это все требуется время, и это тоже нужно учитывать, что не сразу этот вопрос решается.

Также важно понимать, откуда будут браться исходные данные — из PowerPoint, Excel или других систем? Этот вопрос должен быть решен специалистами по управлению программами и проектами, и созданная структура должна получить одобрение руководства на самом начальном этапе проекта. В SAP мы планируем работу на первые полгода и потом смотрим, что необходимо будет в проекте дорабатывать в последние два квартала. В таком режиме мы решаем сначала самые важные, высокоприоритетные задачи. Это гибкий подход, который используется при работе над стандартными проектами. Нужно осуществлять мониторинг таких вещей более регулярно.

Проектный план подразумевает ответственность проект-менеджера, но ее рамки достаточно стандартны: делать все по расписанию, по графику, определять ключевые вехи проекта. То есть нужно обеспечить надежное планирование реализации проекта. Например, 8 релизов в год — с точным обозначением времени их выхода. В определенных проектах и программах у нас 12 вариантов реализации планируется на следующий год, на них нужно сконцентрироваться и собрать эти проекты воедино. И чем больше неопределенностей, тем хуже — нужно всегда скоординировать план А и план Б, это задача проектного менеджера.

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

Как я уже сказал, риск-менеджмент, управление рисками — очень важная вещь. В прошлом году мы проводили обучение, и бывший CEO компании «Альянс» говорил о том, как у них это реализуется. И он сказал: «Мне не требуются инструменты, я общаюсь со своими ребятами постоянно, я знаю все о рисках, меня эта ситуация устраивает, все нормально». Но этот человек ожидает результата, и вы должны дать этот результат. То есть нельзя просто сказать, что все нормально. Вы должны сделать так, что все работает, и работает, как надо. Так что мы должны принять во внимание как можно больше информации. Управление рисками и управление сложными ситуация — это ключевые инструменты, которые здесь нужно использовать.

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

Мы для этого разработали целый инструмент, который позволяет очень быстро, меньше чем за две минуты оценить риск, его возможное влияние на систему и сроки наступления этого влияния, кто «владелец» этого риска. Часто программный менеджер говорит: «Чтобы внести дополнительный риск и его описать, требуется слишком много времени!». А с другой стороны, говоришь: «Если риск есть, нужно его оценить, если этого не сделать, это слишком опасно».

Вот что всегда нужно бизнесу говорить: «Если я об этом риске не знаю, и если он возникнет, независимо от его масштаба — наше отрудничество будет под угрозой». Если это высокоопасный риск, то его статус нужно проверять, по крайней мере, раз в неделю и смотреть, какова его вероятность, какова динамика. И этим должен заниматься ОУП, используя определенные метрики. Если шкала до 12 доходит — можем риск не рассматривать; все, что выше 12 — рассматриваем; все, что выше 16 — направляем все внимание, регулярно к нему возвращаемся, еженедельно беседуем с людьми, ответственными за эту зону риска. Это должен взять на себя ОУП. Если риск, например, есть, но пока еще не наступил, я об этом проинформирую комитет только в том случае, если у него вероятность очень высокая, и он может появиться в определенных обстоятельствах. И тогда нужно принимать меры по его предотвращению и передавать информацию об этом риске руководящим сотрудникам компании, руководству компании и информировать о том, какие меры были приняты. Я не хочу обсуждать риски на управляющем комитете, потому что это всегда создает плохой имидж. Поэтому лучше проактивно должны эти риски рассмотреть и предотвратить.

Есть очень хороший инструмент, который позволяет вам не только IT-риски покрыть, но и бизнес-риски и определить, кто отвечает за проблемную область. Например, если не работает regression-тест, IT не занимаются тестированием, это риск. А кто ответственный? Business Program Manager. И ему можно задать вопрос — почему тестирование не проводится. Этот инструмент помогает вообще всем, а не только айтишникам.

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