Как команда убивает продажи

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

Ниже опишу причины и сразу рецепты решения:

1. Отсутствие коммуникации. Больше проблема сейлзов. Не все они умеют общаться с продакшн командой. Далеко не все берут девелоперов или ПМов на технические пресейлы.

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

2. Неумение общаться. Это уже проблема технической команды. Часто они не сильно хорошие коммуникаторы.

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

3. Палки в колеса. Специально или нет, но технический отдел часто вставляет палки в колеса сейлзам. Или просто не хочет помогать. Особенно, когда новый потенциальный проект им не нравится. Девелоперы не думаю масштабами: "продажа = деньги для компании", они чаще думают: "интересный проект", "новые технологии", "крутая команда" и т.д.

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

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

Решение: разработать четкие правила оценки, рейтов и планируемой маржи проектов. Очень важно выделить на оценку достаточно времени. Оценка всегда делается от и до. Заложить в рейты или формулу риски, чтобы ни один член команды не мог своевольно накинуть сверху часы. Также использовать Planning Poker и перепроверку всех оценок силами тим лидов с одной стороны и опытным сейлзом с другой. Разработать отвечающую стандартам рынка формулу просчета (например, на QA 15-25% от часов девелопмента - это нормально на рынке). Дать право сейлзу требовать от технарей обосновать любую цифру из оценки. Все декомпозировать и анализировать или, если этого не было сделано, - сообщить сейлзу. Дать право девелоперу иметь возможность оценивать некоторые функции, как черный ящик, с очень примерной оценкой, которую компания не может гарантировать и которая будет дальше выполняться без привязки к оценке. Очень важную роль тут будут играть контролирующие люди и их экспертный уровень, даже с правилами в конечном итоге оценка будет зависеть от них.

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

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

6. Низкий экспертный уровень. Вспомните ваши последние 50 попыток продать кого-то на аутстаф. Сколько из них реально доходило хотя бы до собеседования? Обычно все останавливается на разговоре про рейты или отправленном в никуда резюме. И это нормально, с той огромной конкуренцией, что сейчас есть на рынке. Из 20-30 компаний, которые откликнутся, всегда найдется та, которая предложит сеньера, сидящего на бенче за еду. А если сейлз преодолевает первый этап, потом будет собеседование и его тоже нужно уметь пройти. С техническим пресейлом в атсорсе тоже не просто. Ваши девелоперы оказываются не совсем того уровня, который хотел клиент. А если делаем дизайн? Клиенту просто не понравилось портфолио, "таланта мало"... Этот список можно продолжать бесконечно. Топовые сотрудники всегда пристроены, проблема с продажей более слабых.

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

7. Английский. Думаю, продать дева или дизайнера без английского пробовали все :) Как я люблю эти истории: "У нас ПМ знает английский". Если продажа на аутстаф, без нормального разговорного английского продать практически невозможно. Если про аутсорс, когда вы отвечаете за результат, всунуть часть команды без английского еще получится, но сделать это тоже не просто. Команда, чаще всего, не понимает, в чем сложность продать их, когда всем все вокруг нужно. Сотрудники вообще часто думают, что проекты сами собой появляются.

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

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

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

9. Медленная реакция. Отправляешь оценку и ждешь... Долго. По статистике, каждый день ожидания предложения клиентом уменьшает шансы на продажу на 50%. Когда оценка приходит через неделю - она уже никому не нужна.

Решение: создать правила, которые ограничивают время на оценку. Можно также привязывать к размеру проекта.

10. Неизвестные технологии. Сейчас в мире целый зоопарк технологий и каждый год они меняются. Девелоперы не успевают учить их все, поэтому появляются узкоспециализированные девелоперы, которые знают что-то одного и прекрасно себя чувствуют. Вот только для сейлза это тоже сильно ограничивает возможности. Конечно, переучиться на новую технологию не проблема, но это время, желание девелопера и самое главное - желание клиента. Как правило, клиент не готов ждать, пока девелопер переучится, в 95% случаев и фраза сейлза "мы доучим" сразу убивает продажу.

Решение: учить девелоперов нескольким похожим технологиям, дизайнеров нескольким направлением дизайна и программам, маркетолога нескольким каналам маркетинга. То есть сделать взаимозаменяемых сотрудников. Это также очень хорошо для быстрого расширения команд, да и вообще для стабильности бизнеса. Обязательно объяснять, почему это важно, чтобы у сотрудников была мотивация учить это все. Развивать внутреннее обучение и обучение внутри отделов, чтобы каждый линейный сотрудник хотя бы обзорно знал несколько близких технологий. Если это не аутстаф, можно продавать сотрудников сходного профиля с последующим доучиванием, но при этом не делая акцент на эту проблему. В целом, чтобы хорошему девелоперу, например, пересесть на новый фреймворк, нужно в среднем 2-3 недели, а большинство дизайнеров вполне могут успешно работать в 2-3 дизайн специализациях. Хотя в этом пункте чаще все же ошибка самого сейлза и не совсем правильно поведение в такой ситуации.

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

Эту глобальную проблему не замечают, потому что она на стыке двух очень разных областей знаний: продажи и производство. Также не всегда понятно, кто должен отвечать за решение подобных вопросов. И она начинает теряться внутри компании и разрушать её изнутри.

• Ошибки
• Команда