Алина Прасковина

Руководитель проектов в MONS, «КОРУС Консалтинг»

Поменять РП… А если без шуток, то у нас есть два стула, два пути:
1) Действительно поменять РП на проекте
2) Провести работу над ошибками и (или) ожиданиями.

Меня зовут Алина Прасковина, я руководитель проектов в MONS, «КОРУС Консалтинг». И за свою РП-шную карьеру я успела побывать в обоих сценариях. Давайте их рассмотрим чуть подробнее, и разберем, как выйти победителем в наступившем кризисе.

Вариант 1. Смена РП. Как входить в проект, где вашей ролью уже не довольны.

1. Проведите аудит проблемы и состояния проекта.

Важно не сразу подхватить проектные задачи и начать их решать «хорошо», как нам кажется, а понять, что же делали не так и в чем кроется недовольство Заказчика.

Шаг 1: Соберите всю информацию о проекте от старого РП, в т. ч. матрицу коммуникаций и RACI, если они есть или проведите встречу на эту тему. При передаче проекта намного важнее правильно верифицировать всех участников и заинтересованные стороны, чем задачи (о них вам и так расскажут/напомнят).

Шаг 2: Проведите 1 to 1 с каждым стейкхолдером проекта (в т.ч. и командой). Попросите рассказать о их функциях и задачах на проекте, о + и -, которые они видят на текущий проект, что бы им хотелось изменить.

Шаг 3: Создайте из собранной информации план. Презентуйте его Заказчику. Важно не только подсветить какие боли вы нашли, важно сразу показать, что мы готовы действовать, знаем как изменить текущую ситуацию.

2. 1 to 1 с Заказчиком, честный разговор чем он недоволен.

Вы пришли сразу в кризисную точку проекта. Не всегда Заказчик не доволен чем-то конкретно. Может быть так, что проект идет без ярких негативных эксцессов, но и пользу особую он не приносит. А точнее не удовлетворяет потребностям Заказчика. 

Необходимо выслушать что же именно не нравится ЛПР со стороны Заказчика.

«Мало коммуникации» – регулярные встречи.

«Мы постоянно забывали про задачи» — ведение протокола задач.

«Я не понимаю на какой мы стадии, процесс выполнения не прозрачен» — доп. информирование всех заинтересованных сторон.

И т.д.

Очень важно в этот момент услышать детали большой «боли», и начать конкретными шагами улучшать атмосферу на проекте.

P.S. И еще совет: первую встречу или даже несколько лучше провести лично, если есть такая возможность. С живым человеком работать всегда приятнее – чем с аватаркой из мессенджера или должностью из письма.

3. Постарайтесь изучить характер команды, язык их общения и их традиции. Особенно с командой Заказчика.

Команды, как и человек, всегда разные. Где-то принято на Вы, где-то на ты. Где-то принято ходить в бар раз в месяц, где-то заказывать пиццу по пятницам. Где-то важны строгие регламенты, соблюдение иерархии, а где-то любят вместе играть в сквош и делиться своими милыми домашними животными. Где-то желают «доброе утро» друг другу каждый день, и т.д.

Очень важно попасть в этот ритм. Вы должны как можно быстрее стать частью этого «организма», иначе будет очень сложно его понять и что-то изменить.

4. Вы наладили процессы, закрыли все критичные боли отлично, можно выдыхать?

Нет. Теперь все эти действия, связанные в процессы, необходимо делать регулярно.

Важно не упустить вновь из фокуса те пункты, отсутствие которых когда-то поставило существование проекта под угрозу.

Вариант 2. Заказчик недоволен Вами, что делать?

В этой ситуации может быть два варианта: он не доволен Вами объективно или субъективно. Давайте разбираться.

1. Если Заказчик не доволен Вами по объективным причинам, необходимо пойти на честный разговор, провести тот же 1 to 1 и выявить все боли. Потому что не всегда понятно, что действительно кроется за недовольством Заказчика.

Если это и правда простой ряд ошибок тех. команды – отлично! Это исправить намного проще) Главное не закрывайте на них глаза. Признайте перед Заказчиком что да, недочеты были, разработайте шаги их устранения и покажите результат. Но иногда, казалось бы, ошибки настолько мелкие, что большинство бы их не заметило, кто-то прощал Вам и намного большие провалы, а тут отчитывают за каждый чих. Почему так? Потому что в первом случае – вы с Заказчиком выстроили доверительные и приятные человеческие отношения. Во втором случае – где-то серьёзно в этом процессе промахнулись.

Часто причиной, почему мелкие «провалы» стали настолько остро восприниматься – личная неприязнь с ключевым членом команды. Высказался в общем чате как-то снисходительно разработчик в сторону Заказчика, поставил его авторитет или экспертизу под вопрос. И все – вы уже под чутким прицелом. Теперь ВАС будут подтягивать за каждый промах.

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

2. Если Заказчик недоволен по субъективным причинам – не расстраивайтесь, на самом деле это зона роста! Причем финансового.

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

Главная цель на проекте у Заказчика – чтобы данный проект приносил пользу его бизнесу. И если в процессе реализации окажется, что пользу принесут еще +10 доработок, еще более маленький SLA, или пару фитчей – то Заказчик будет на них настаивать. Тут важно вовремя верифицировать что это превышение условий проекта и пойти на разговор с Заказчиком.

Только пожалуйста, не начинайте его со слов: «Это не было заложено в проект, мы это реализовывать не будем. В ТЗ было указано не так, мы будем делать как в ТЗ. У нас другой SLA в контракте, на этом точка».

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

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

Вместо заключения

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