Разбор ситуации(кейса) 6 для ПМа. Коммуникация на проекте.

Продолжая разбор кейсов для ПМа. Шестой кейс про то, как выстраивать коммуникацию на проекте, как внутри команды, так и с командой заказчика.

Ссылки на предыдущие разборы кейсов:

• Разбор кейса 1. Начало проекта.
• Разбор кейса 2. Риски.
• Разбор кейса 3. Оценка даты завершения и размера команды.
• Разбор кейса 4. Коммерческое предложение (Proposal)
• Разбор кейса 5. Коммуникация о проблемах на проекте

Условие кейса

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

Решение

Для начала, введем понятие ЛПР — Лицо Принимающее Решения.В зависимости от размера проекта и величины компании заказчика можно выделить такие основные варианты на стороне заказчика:

• Только один человек, с которым происходит коммуникация по абсолютно всем вопросам. Не самый частый вариант, в основном на мелких проектах и стартапах на стадии проверки гипотезы
• Один человек отвечает за все вопросы, касательно проекта и является ЛПР по всем его вопросам, кроме финансовых (бюджет и оплата счетов). Наиболее часто встречающийся вариант при работе со средними и компаниями, иногда даже с крупными.
• Разделение ответственности по проекту. Со стороны заказчика целая команда, каждый член которой имеет свою зону ответственности. Например: ответственный за архитектуру, за UI/UX дизайн, за обьем работ (беклог) проекта и за контроль промежуточных результатов. В этих случаях за бюджет и оплату счетов отвечает кто то из финансового отдела, часто CFO (фин директор) или кто-то другой большой менеджер этого направления бизнеса. Стоит сразу выделить, кто является ЛПР по каким вопросам и за кем будет последнее слово, если члены команды противоречат друг другу (такое случается часто).
• Если на стороне заказчика присутствует его внутренняя команда или другой подрядчик, тоже делающий часть этого проекта, то схема коммуникаций ещё более усложняется и создание матрицы коммуникации становится жизненно необходимым. Появляется менеджер/координатор проектов на стороне заказчика, тех лид и даже бизнес аналитик и тестировщик. Из моего опыта такое встречается при работе с большими корпорациями с сильным разделением ролей и ответственностью, хотя мне доводилось встречать такое разделение в стартапе с понятной моделью под управлением СТО (тех директора) с большим опытом быстрого запуска продуктов. Ещё один жизненный пример — инфраструктура, на которой работают многие веб сервисы клиента, администрируется и обслуживается сторонней компанией субподрядчиком, которая занимается исключительно такими вопросами и не имеет разработчиков.

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

Структура коммуникации на проекте

Пример общей структуры коммуникации на проекте между командой исполнителя и командой заказчика:

PMBOK® Guide говорит нам, что коммуникации на проекте состоят из следующих частей:

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

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

Матрица коммуникаций

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

• Получатель информации. Лицо или группа, которые будут получать информацию. Например, группа аналитики проекта, состоящие в определенной рассылке, будут получать информацию о входящих запросах на изменение
• Информация. Что за информация передается, на каком языке, в каком формате (например документ pdf, doc, excel и т.д) и с каким уровнем детализации.
• Канал передачи. Каким образом информация будет передаваться. Например, по почте, мессенджеру, видео звонку, устно.
• Когда и как часто. При каких условиях информация должна передаваться, с какой периодичностью.
• Отправитель. Кто должен инициировать передачу информации.
• Ограничения и допущения. Перечисляем ограничения на передачу информации, если такие есть. Например, если есть соглашение о неразглашении, где указано, кто может иметь доступ к этой информации, то указываем это здесь, чтобы предупредить о недопустимости нарушения. Так же здесь перечисляем допущения. Например, если информация о запросе на изменение может быть передана на оценку, только после того, как получено одобрение от лида аналитиков. Ещё пример — если мы хотим послать клиенту доп соглашение на расширение команды, нам надо получить утверждение от ресурсного менеджера, что у нас есть возможность иметь необходимые ресурсы, указанные в этом соглашении.
• В редких случаях можно добавить сюда глоссарий для описания сокращений, акронимов и специфических терминов.

Возвращаясь у нашему кейсу, как может выглядеть матрица коммуникаций на этом проекте.

Отправитель	Получатель	Информация	Канал	Время/Частота
BA	Product Owner	request for requirements review meeting	email, slack, zoom	as required
PM	Product Owner	status reports	email	every Friday
Tech Lead	Technical Architect	request for technical review meeting	email, slack, zoom	as required
Technical Architect	Tech Lead	technical decisions, changes in architecture, questions regarding implementation details	email, slack, zoom	as required
PM	CFO	invoice, worklogs report	email	bi-weekly
BA, PM	Design Lead	design review meeting request	email, slack, zoom	as required

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

Что же делать?

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

• У вас есть трекер задач и у каждой задачи есть описание и четкие критерии приемки. Например Jira, Trello, Asana и так далее.
• Вы обсуждаете с командой клиента план технической реализации новой функциональности в проекте.
• Все технические решения задокументированы в системе контроля знаний/wiki, например в Confluence.
• У вас есть утвержденный алгоритм коммита кода в репозиторий (git flow), при котором каждый коммит в основную ветку должен получить одобрение ведущего разработчика или даже 2х., прежде чем код будет добавлен в эту ветку. Можно предложить техническому специалисту на стороне клиента, если такой есть, быть одним из ревьюверов таких запросов, при условии, что это не будет тормозить разработку.
• У вас назначены регулярные звонки с тех командой клиента, на которой обсуждается список открытых вопросов и проблем, связанных с разработкой. По результатам обсуждения вы пишете follow-up письмо с протоколом обсуждения. Как опция, хорошо иметь какой то общий список таких вопросов, который поддерживается актуальным между такими созвонами.

То есть, в случае из кейса, первое, что вам надо сделать — назначить ежедневный звонок между техническим контактом со стороны заказчика и главным тех лидом со стороны вашей команды. На этих созвонах собирать четкий список проблем и вопросов, записывать что по каждому из них нужно сделать и кому или какое решение было принято. После звонка высылать этот список всем участникам + копию главному лицу на стороне клиента.Частота созвонов должна не оставлять возможности возникнуть существенных вопросов между созвонами. В случае, если технический контакт клиента будет пытаться связаться с командой вне этих созвонов, то по любым существенным вопросам, команда может отсылать его к списку или предлагать обсудить это на ближайшем созвоне. Наличие принятого процесса будет дисциплинировать всех участников и даст понятную и прозрачную для клиента схему работы между техническими контактами с обоих сторон. Позволит избежать «наговаривания», «перевода стрелок» и прочей политики со стороны технического контакта на стороне клиента своему начальству против вашей команды.

Как бывает

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

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

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

Некоторые переговорные техники используются здесь чтобы максимально продавить свой интерес. Одной из таких и является придумывание проблем, которые якобы создает исполнитель, и если не прорабатывать каждый такой случай, то это дает возможность заказчику потом предъявить его как доказательство некомпетентности исполнителя и отказаться оплачивать часть стоимости услуг. Заказчик будет манипулировать вашим чувством вины настолько, насколько вы ему позволите. Больше про это с примерами я уже описывал в посте про «Переговоры с клиентом, манипуляции и выбивание уступок»

Дополнительное чтение по теме

1. PMBOK® Guide – 6е издание, Глава 10 — Управление коммуникациями проекта
2. Эффективные Коммуникции в Команде Проекта
3. Как написать хороший план коммуникаций проекта
4. Коммуникация как ключевая компетенция менеджера проектов