🥚 Что первее курица или яйцо…
#проектныйкейс на повестке - почти Философский 🤣

На сколько глубоко РП должен погружаться в предметную область проекта

Вот вам кейс - абсолютно классический

Есть проект, к примеру, по автоматизации учетных процессов. Вы - РП на стороне Заказчика (бизнеса). Есть эксперты-методологи от бизнеса. Есть роль бизнес-аналитика, в задачи которого входит подготовка функционально-тех требований, ТЗ, проведение тестирования.

И вот так получается, что бизнес прибегает к РП (уже не первый раз) с жалобами на бизнес-анаитика - то он методологию не понимает, то он требования какие-то не учел, то алгоритм расчета по факту тестирования оказались неверными… и что приходится делать РП??? Погружаться в каждый вопрос… или все-таки нет, и делать этого не нужно?

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

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

Часть 1. Курица
Инициация и планирование.
или все-таки яйцо?

ОПИСАНИЕ КЕЙСА

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

😄И вот мы начинаем проект и происходит первая страшная вещь. Паспорт проекта/ Устав / Бизнес-требования (или любой другой документ об инициации проекта)

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

✔️ЧТо делать: добиваться подключения РП на этапе подготовки паспорта/ Устава (хотя бы на будущих проектах)

😄Отсутствие матрицы ответственности и описания детализации артефактов. Вот тут как правило ошибка РП и неумение объяснить важность этих документов заказчику.

◦ кто готовит первичные требования (обычно: Заказчик) и кто от Заказчика их утверждает (обратите внимание на эту роль, она еще появится позже)!
◦ кто доводит до детализации, нужной для передачи разработчику (обычно: бизнес-аналитик)?
◦ Какая вообще должна быть детализация описания (требования от Заказчика и стейкхолдеров, от РП - влияние на сроки/ компетенции команды)
◦ какие последствия (процедура эскалации), если какое-то требование выставлено ошибочно или не выставлено вообще (вот тут появляется РП на белом коне, готовый разрулить все вопросы, а НЕ СОГЛАСОВЫВАЕТ ДОКУМЕНТ ЗА ЗАКАЗЧИКА)
◦ Какие последствия от того, что бизнес-аналитик уже 3-й раз не может отработать одно и то же замечание от Заказчика (вот тут белый конь бежит к руководителю БА для подключения дополнительной экспертизы в проекте, а НЕ ПЕРЕПИСЫВАЕТ ДОКУМЕНТ ЗА БА)
◦ А ресурса Заказчика вообще достаточно для полноценной работы в проекте или, как всегда, люди выделены на 0,01 желательно во вне рабочее время? (опять же белый конь бежит к владельцу ресурсов, а не делает работу за Заказчика)

⚠️Важно: все участники процесса должны понимать правила игры в самом начале, а не тогда, когда на этапе тестирования оказалось, что вместо американских горок у нас
москвич на 3-х колесах..

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

Продолжаем? 🔥

Эскалация
Продолжаем разбираться с нашим проектным кейсом про понимание предметной области РМом
Часть 1 была тут

Сейчас Часть 2. Эскалация.

Об этом хочу поговорить с вами отдельно. Давайте разберем, как обычно происходит эскалация.
К примеру, вы поймали за руку БА, который уже в 3-й раз якобы не может исправить замечание от заказчика.
Прежде, чем идти к Лиду БА, давайте сделаем следующее

😄Соберемся «на троих» и разберемся в причинах такой ситуации. Какие возможны варианты:
◦ БА исправил, но не там, - заказчик не увидел
◦ заказчик выставил комментарии, не входящие в скоуп работы, поэтому БА не очевидно их отклонил
◦ там реально сложный бизнес вопрос, который не решался на протяжении 3-х итерации
◦ заказчик криво выставил замечания. Криво - это не оценка, а скорее не в том виде, в котором ожидал БА
◦ БА - долбоящер и реально просто «пробаранил»

Чувствуете разницу?

Если ситуация произошла в первый раз, вам вообще никуда идти не надо.

😄Вам скорее всего нужно будет погрузиться в вопрос (вот где нам нужно будет знание предметной области), разобраться в причинах, внести корректировки в формат коммуникаций/ формат или детализацию документов (реестры замечаний, примеры заполнения, он-лайн обсуждение документа на звонке и т.д.)/ или даже эскалировать вопрос на сторону заказчика

😄Ну а если ситуация повторяется несколько раз, вот вам пара лайфхаков по взаимодействию с тим лидом
◦ Опишите повторяющуюся ошибку, попросите Лида предложить варианты решения
◦ Не торопитесь менять человека. Введите процедуру предварительного акцепта документа со стороны тим Лида
◦ Если ошибка повторится снова, тут уж простите дело не в БА….
◦ Если все-таки вам приходится менять человека, не забудьте проработать это события про процедуре упр изменениями и учесть это в оперативном графике работ - скорее всего будут задержки по срокам/ качеству/ недовольству со стороны Заказчика. И опять же первое время предусматриваем предварительный акцепт от тим Лида.
◦ Не забудьте занести ситуацию в листочек под названием lessons learned или типовые проектные риски, в след проекте скажете себе спасибо;)

Пока писала, поняла, как веселят меня вопросы: «что вообще делают проектники?» - да ничего такого, конечно 😂

To be continued… осталась 3 часть - 🔥 если ждете;)