Количество человек в команде, которым необходимо общаться с клиентом?

В моей команде это работает так:

Когда мы сталкиваемся с проблемой, случилось что-то плохое, проект горит — мы обычно контактируем с клиентом на уровне управления (либо PM, либо TeamLead). То же самое относится, когда клиент спрашивает, сколько времени потребуется для добавления функции X. В таких случаях разработчикам предлагается направить разговор на уровень управления . На стороне клиента также есть люди на уровне управления .

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

Мы пришли к этому подходу, попробовав более строгие:

• Единая точка контакта - у нас были проблемы с искажениями передаваемых сообщений: от клиента к SPoC-персоналу, затем к разработчикам, и обратно в том же направлении
• Все - у нас были проблемы с тем, что некоторые вещи обсуждались с разработчиками, за исключением уровня управления ; еще одна проблема заключалась в том, что заказчик прямо обвинял разработчиков в чем-то

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

Существует ряд факторов, которые следует учитывать при принятии решения о стратегии коммуникации:

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

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

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

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

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

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

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

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

Если этот клиент создает конфликт, обращаясь ко всем в вашей команде, я бы порекомендовал вам создать механизм единого контактного лица (SPOC).

Этот клиент должен будет пройти через это назначенное лицо или отдел, чтобы искать информацию. Если клиент продолжает звонить другим членам команды, вам нужно будет дать конкретные инструкции, чтобы они немедленно переадресовали звонок этому лицу или группе SPOC.

В agile-методах вы получаете роль владельца продукта или аналогичную, которая создает на вашей стороне одного человека, ответственного за работу над концепцией продукта. Однако я бы предложил следующее (при условии, что ваша команда <10 человек):

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

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

3. Чтобы клиент не потерял способность быть в курсе, время от времени можно устраивать более короткие встречи. Это будет использовать протокол ежедневного стендапа, но это не обязательно должно быть ежедневным. Смысл в том, чтобы позволить команде информировать всех остальных о том, что происходит. Оно должно быть коротким, и клиент должен слушать. Вы можете позволить ему прокомментировать в конце, но сама встреча не может быть использована для обсуждения. Их нужно принять позже, желательно лицом, назначенным в пункте 1.

Единственное, чего точно следует избегать, — это разрешать контакт с конкретным разработчиком ad-hoc. Это приведет к непониманию и потере информации.

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

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

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

Должна быть ОДНА точка истины.

В противном случае слишком много политики, неверного толкования и потраченного времени.

Я согласен с Марком Филлипсом по большей части. Сохранение единственной истины защищает вас от «Он сказал, Она сказала». Когда вы действительно думаете о вещах, последовательный обмен сообщениями имеет решающее значение, если вы хотите сохранить авторитет и доверие.

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

Глава PM, знающий клиентов/проекты и известный клиентам, облегчает все для всех сторон, особенно в случае «чрезвычайной ситуации».
Также руководитель, который информирует заказчика и представляет заказчику новый PM в случае смены/переноса PM на другой проект, предотвратит ослабление связи с заказчиком.

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

M0N4K0 очень хорошо объяснил SPOC.