Кто говорит с клиентом об активном проекте?

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

Когда проект запущен, кто должен говорить с клиентом о специфике проекта? Если есть проблема с кодированием, то, очевидно, такие разговоры будут у разработчика.

Однако должен ли PM взять на себя все дальнейшие разговоры с клиентом или оставить это человеку, который договаривался об условиях работы? Мне кажется, что ПМ был бы лучшим выбором, чем переговорщик, когда проект уже запущен.

Ответы (6)

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

Обычно у клиента есть несколько человек, с которыми можно связаться. Здесь подходят ответы Марка. Я полагаю, что ваш вопрос о том, кто из ВАШЕЙ команды должен связываться с клиентом.

Обычно продавец (переговорщик) не принимает большого участия после подписания сделки. Тем не менее, этот продавец вполне может оставаться на связи только для проверки, и PM может попросить продавца принять участие в некоторых случаях (когда условия контракта неясны и т. д.). Однако да, обычно продавец должен сосредоточиться на продажах. PM должен сосредоточиться на проекте. Каждый должен сосредоточиться на своей работе, и если им нужно связаться с клиентом, они должны это сделать. ОДНАКО, PM должен убедиться, что контакт с клиентом происходит ТОЛЬКО организованно, иначе вы рискуете завалить клиента одними и теми же вопросами, что приведет к плохому имиджу вашей фирмы и испорченным отношениям с вашим клиентом.

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

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

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

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

  • Принятие пользователем и тестирование

  • Безопасность

  • Инфраструктура, поддержка и операции

  • . . . (что угодно).

Обновление: @Earthling правильно указывает, что я сделал это так, будто речь шла только о том, кто общается в клиенте; Это не было моим намерением. Смысл плана коммуникаций состоит в том, чтобы определить необходимые коммуникации и определить, кто несет ответственность за эти коммуникации. Я полагаю, что роли в вашей компании будут относительно постоянными от проекта к проекту и будут определены в шаблоне. Естественно, вы просмотрите эти роли до того, как поговорите с клиентом.

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

Как отметил Марк, это зависит от размера и сложности проекта. Тем не менее, вот несколько советов из моего опыта управления программными проектами.

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

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

Таким образом, PM должен быть единой точкой связи для следующего:

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

И PM должен прослушивать все другие сообщения с клиентом о проекте.

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

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

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