"Когда в товарищах согласья нет, на лад их дело не пойдет…" И.А. Крылов
В компании нет второстепенных ролей. Без разработчиков нечего будет продавать, без маркетинга и отдела продаж – некому.
Успешная команда должна эффективно взаимодействовать как с внешними партнерами, так и внутри себя. Сегодня мы поговорим про коммуникацию между отделом продаж и разработчиками. Поделимся и своими неудачами – случаями, когда из-за плохой коммуникации на заре становления компании мы теряли клиентов.
Информация пригодится прежде всего коллегам, которые только начинают выстраивать связи в компании.
В разных компаниях у продажников разные задачи. У нас сейлзы – это те, кто первые заговаривают с лидами, ”отсеивают” неформатные проекты, вникают в потребности заказчика. Еще в их команде есть аккаунт менеджер. Он принимает эстафету от сейлз специалиста на стадии разработки проекта.
У эффективного сейлз менеджера не просто хорошо подвешен язык. Он знает все текущие проекты и их бюджеты, может сориентировать клиента по компетенциям и технологиям, умеет работать в команде.
Техническую команду представляет менеджер проекта (ПМ) или техлид. Именно к ним обращаются сейлзы по различным вопросам.
Плохая коммуникация входит в топ 5 причин провальных проектов. То есть страдает не просто атмосфера в компании, а эффективность бизнеса. Часто проект можно спасти, приложив усилия, но, если клиент недоволен, все будет напрасно.
Лет 6-7 назад мы проходили этап выстраивания коммуникаций между командами. Были промахи, о которых расскажем далее. Мы проделали большую работу, чтобы такие моменты не повторялись.
Кейс №1. Заказчик выдал новые требования к проекту. Сейлз передал их софтверной и хардварной командам, но по разным каналам: софтверной – в привычном общем чате, а хардварной – в личных сообщениях менеджеру проекта.
Личное сообщение затерялось, хардварная команда не внесла изменения в спецификацию. Сейлз пропустил этот момент, в результате клиенту ушла неправильная оценка. Ошибка была существенной, вскрылась поздно, в итоге клиент отказался от дальнейшего сотрудничества.
Вывод: Используйте во время проекта привычные всем каналы связи, не меняйте правила игры.
Кейс №2. Клиент описал свои требования устно во время созвона. Специалист отдела продаж не зафиксировал их в документе и при передачи информации техкоманде напутал в деталях. Получился глухой телефон. Разработчики использовали неверные вводные, поэтому анализ проекта был некорректный. Заказчика не устроил такой подход, проект не стартанул.
Вывод: Подходите к переговорам ответственно. Не полагайтесь на память, фиксируйте все, что говорит заказчик.
Кейс №3. Клиент хотел закончить проект за 3-6 месяцев. Менеджер указал в требованиях только максимальный срок. Проанализировав проект, разработчики увеличили срок разработки на 1 месяц, что обычно совсем не критично. Но в этом случае заказчику было важно сделать все не более чем за 6 месяцев, и такой расклад его не устроил.
Вывод: Требования должны передаваться техкоманде в той форме, в которой их озвучил заказчик. Для понимания проекта важны любые мелочи. Точность передачи информации поможет сэкономить время, потому что проекты с нереальными сроками сразу отсекаются.
Кейс №4. ПМ не учел загрузку команды, сроки анализа проекта постоянно переносились и вместо недели заняли месяц. У менеджера по продажам не была выстроена коммуникация с ПМ, поэтому он не смог объяснить заказчику причину отсрочки. Клиент отказался от проекта.
Вывод: Техкоманде стоит сообщать сейлз отделу о любом цейтноте, чтобы те могли вовремя проинформировать заказчика об изменениях.
Кейс №5. Во время работы над проектом ПМ мало общался с клиентом. Коммуникация шла через сейлз менеджера. Клиенту передали обновленную версию разрабатываемой программы, но он не смог войти в аккаунт – хотя раньше таких проблем не было. Техкоманда не знала о проблеме, поэтому клиент не получил поддержку вовремя.
Вывод: ПМ держит связь с заказчиком на протяжении всего процесса разработки, чтобы оперативно обсуждать ход проекта, сложности, требования. Сейлзы – не технические специалисты и не могут помочь в решении всех вопросов.
Кейс №6. Написание ТЗ пришлось на лето. То один специалист, то другой уходили в отпуск. На то чтобы передать дела оставшимся коллегам, уходило много времени. В результате работа над ТЗ растянулась на 3 месяца, и клиент не получил объяснений, почему даты так сдвинулись.
Хорошо, что у заказчика не горели сроки, поэтому обошлось без серьезных проблем.
Вывод: Ни праздники, ни сезон отпусков, ни грипп, ни увольнение отдельного сотрудника не должны задерживать разработку. На уровне команд нужно проработать быструю взаимозаменяемость специалистов.
Как построить эффективное общение между сейлзами и разработчиками?
Какие приемы, инструменты лучше использовать? Ловите ценные идеи на этот счет.
Выстраивайте межличностные отношения. Эффективная коммуникация между подразделениями складывается из дружеских отношений между сотрудниками. Прислушивайтесь к коллегам, учитывайте их мнение, находите подход к каждому.
Советуйтесь с техкомандой. Эффективная коммуникация между подразделениями складывается из дружеских отношений между сотрудниками. Прислушивайтесь к коллегам, учитывайте их мнение, находите подход к каждому.
Обсуждайте с ПМ сроки и бюджеты проекта, прежде чем озвучить их заказчику.
Имея дело с типовым проектом, сейлз менеджер может сам дать первичную оценку стоимости и сроков разработки. Но стоит оговориться, что окончательную оценку дают только разработчики.
Например, клиент заказывает разработку Windows-драйвера и на первом созвоне хочет услышать приблизительную стоимость. Это типовой проект, который стоит $15 000- $30 000. Специалист отдела продаж может назвать заказчику эти цифры, но уточнить, что окончательную стоимость дадут после анализа проекта.
Иногда это и проверка на бюджет. Если клиент считал, что работа стоит $5 000, и не готов платить больше, то мы сэкономим и свое, и его время.
Если же клиент согласен с оценкой, то работа идет дальше, и к анализу проекта подключаются разработчики.
Важное дополнение: Сейлз менеджеру лучше всегда уточнять у ПМ, как подсчитаны часы для финальной оценки – учитывалась только разработка, или брали в расчет часы менеджмента, тестирование, коммуникацию с клиентом, оформление документации. Все это может добавить до 30% времени.
Аккаунт менеджер – важное звено. Он ведет проект на стадии разработки, выставляет счета, контролирует исполнение договора, получает фидбек от клиентов. Аккаунт менеджер также запрашивает обратную связь от ПМ о том, как идет проект, есть ли проблемы и как их решают.
Вот пример. Первоначально технические специалисты оценили фичу в 30 часов, но во время работы поняли, что времени нужно в 1,5 раза больше: недооценили сложность, переоценили свои силы, или возникли непредвиденные обстоятельства.
Если в договоре подобные риски не отражены, с клиентом связывается менеджер проекта и ищет пути решения проблемы. Если заказчик не удовлетворен коммуникацией с ПМ, к переговорам подключается аккаунт менеджер.
Аккаунт специалист сглаживает острые углы, которые могут возникать между разработчиками и заказчиком, находит компромисс.
Равная ответственность за сроки. Нужно назначать сроки, тщательно анализируя нагрузку команды.
Сейлз специалист всегда уточняет возможности разработчиков, прежде чем называть клиенту сроки оценки или анализа проекта.
Важное дополнение: Лучше озвучивать клиенту реальные цифры – 2 дня, 7 дней и т.д., а не писать расплывчато “в течение нескольких дней”.
Поддерживайте друг друга. Бывают случаи, когда сроки горят из-за непредвиденных обстоятельств. Например, техкоманда вынуждена поставить на паузу изучение нового проекта и переключиться на срочную задачу по текущему проекту, так как текущие клиенты всегда в приоритете.
В этом случае сейлз менеджер старается уладить все вопросы с новым заказчиком так, чтобы не подорвать его доверие, не уронить реноме компании и не выставить никого виноватым.
Входите в положение коллег. ПМ всегда очень загружен – он руководит своей командой, общается с клиентами, другими отделами, руководством, отвечает за документацию. Поэтому сейлзу следует не давить и не требовать, а постараться найти приемлемое для всех решение по срокам исполнения таска. Задача ПМ – не затягивать сроки, не отмахиваться от сейлзов и грамотно планировать занятость.
Работа или встречи офлайн. Все вопросы решаются быстрее, когда коллеги находятся в одном офисе. В онлайн режиме решать задачи сложнее. Загруженный работой специалист не всегда сразу отвечает на сообщения, соответственно, обсуждение затягивается.
Если сотрудники работают удаленно, необходимо проводить регулярные онлайн и офлайн встречи, планерки, предусмотреть каналы экстренной связи.
А теперь про инструменты, которые помогают эффективно общаться. У каждой компании они свои, расскажем о тех, которые нашли применение у нас.
- Jira. ПО для управления проектами, основной канал связи сейлз отдела и разработчиков. Сейлзы ставят сроки, задачи, дают квалификацию заказчика, пишут оценку проекта в часах, указывают, что необходимо сделать на данном этапе. Например, нужно проанализировать требования и составить уточняющие вопросы. В Jira можно также кратко описать проект и задать вопросы техкоманде.
- Google Документы. Очень полезен файл загрузки команды, куда ПМ вносят данные по текущим задачам и нагрузке каждого специалиста. Здесь же указываются сроки, когда освободится тот или иной разработчик. Сейлз может использовать документ самостоятельно или связаться с ПМ, который подскажет, кто и когда сможет заняться новой задачей.
- Skype. Старый добрый Скайп, где ведутся чаты компании, отдельных служб, проектов и личные переписки. Канал общения не без недостатков, но достоинств пока больше.
Компания похожа на сложный механизм. Взаимодействие всех элементов нужно отрегулировать, чтобы все работало идеально.
Дружба и понимание между сейлзами и разработчиками – одна из составляющих успешного бизнеса. А строится коммуникация прежде всего на хороших личных отношениях.
Так что находите подход друг к другу, работайте в команде, и тогда общая работа будет приносить отличный результат!