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

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

Если у вас есть опыт работы в растущем стартапе, легко подтвердить это изменение в том, как работают современные команды по продажам, маркетингу, поддержке или топ-менеджмент.

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

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

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

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

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

Вот несколько причин разногласий.

У продажи четкие часы работы, а у продукта — нет.

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

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

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

Команда продаж продает функции, которых нет в продукте, и это приводит к переработкам.

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

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

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

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

Они не понимают, насколько тяжела работа другой команды.

Эй, разраб! У тебя когда-нибудь было, чтобы бросали трубку посреди разговора или проклинали? Когда-нибудь у тебя было, чтобы явная возможность просто срывалась?

Эй, сейлз! Ты когда-нибудь проводил часы, разбирая логи, чтобы выяснить, что же вызывает ошибку в программе?

Обе стороны просто не понимают разочаровывающих моментов в работе друг друга.

Вот некоторые действенные шаги, которые я реализовал в прошлых и нынешней компаниях, с которыми я работал.

1. Попросите инженерную команду звонить + присутствовать на звонках, когда закрывается сделка.

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

2. Разрешите команде отправлять запросы функций продукта асинхронно.

Сколько раз вы видели, как продавец вошел в чат-комнату Product / Engineering в Slack и сказал: «Когда мы сможем получить X-feature»? Потом, как стая акул, инженеры так тщательно изучают эту идею, что продавец сожалеет о том, что затеял разговор.

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

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

Затем команда Product может выделить время для прохождения запросов и задать вопросы.

3. Помните о растущей напряженности между командами. Давайте ей выход.

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

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

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

5. Когда каждая команда предлагает что-то, попросите их ответить на один и тот же вопрос.

Любая активная команда по продажам и продуктам будет стараться вносить предложения и поправки. Для продаж это может быть предложение скидки через новую акцию. Для продукта это может быть трата времени на исправление некоторой базовой backend-инфраструктуры.

Вы должны задать им один и тот же вопрос: как это помогает нам достичь приоритета №1 на данный момент для нашей компании?

Следите за предупреждающими знаками

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

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

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

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

Всегда помните: помимо разрешения конфликта, вы также поддерживаете здоровые дебаты.

Комментарии