×

Вникайте в процессы, или Что не так с sales в IT

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

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

Я сталкивалась с sales, как работая с ними по одну сторону баррикад, в одной компании, так и по другую — как представитель заказчика. В основном работала с самыми популярными регионами: Восточной Европой, Индией и чуть-чуть Юго-Восточной Азией (Филиппины).

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

Специфика общения слишком отечественного бизнеса

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

  • Добрый день! Давайте пройдемся с вами по требованиям, чтобы понять, какие есть вопросы и услышать вашу оценку.
  • Добрый день! Да, конечно. Я тут пацанам дал посмотреть — вы ж понимаете, хоть в заявке было написано, что я один работаю, у меня тут команда — так вот они посмотрели и сказали, что смогут сделать.
  • Ооок, в документе мы просили объяснить, какой способ имплементации вы выберете и почему.
  • Ой, вы знаете, я вам не отвечу, давайте программиста подключу. (Вызванивает программиста в бэкграунде. Программист раскрывает свою точку зрения).
  • Спасибо, понятно. У нас в очереди еще два кандидата, мы планируем определиться до конца недели.
  • Шо, серьезно? Ааа, ну хорошо. Ну ваще программист у меня хороший, он точно сможет сделать. У меня еще один есть, если нужно. А мы как с вами работать будем: официально или неофициально?

В таких диалогах мне начинает казаться, что я покупаю партию ворованных с завода подшипников.

Совет: начать с чтения книг по деловому общению. Предложения обычно такие ребята делают как раз нормальные и знают, какими сильными сторонами заинтересовать. Но из-за того, что продукт завернут в такую ужасную оболочку, клиент пугается.

Ctrl+C, Ctrl+V

Некоторые ребята имеют в арсенале только копипасту. В ход идут pdf с презентациями, портфолио, описание компании и её достижений. На звонке об обсуждении конкретно поставленной задачи озвучивается та же generic информация: «Большое спасибо, ваша задача так хорошо описана, мы являемся certified partner XYZ, все наши разработчики имеют уровень Золотого Специалиста, и мы больше десяти лет на рынке». Сейлзам обычно «всё понятно, вопросов нет».

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

Пример: заказчик хочет e-commerce сайт. Вы рассказываете, что поняли, что нужен веб-магазин с возможностью добавлять товары из админки, с трехуровневым каталогом товаров и регистрацией пользователей. Вы предлагаете сделать это на WP, используя искоробочный плагин и готовую тему. Preview или похожую работу можно посмотреть во-о-от тут.

Хроническое «да»

  • Вы сможете сделать систему из пяти модулей с интеграциями двух API?
  • Да. У нас есть опыт работы со всеми технологиями, что вам нужны.
  • За три месяца?
  • Я думаю, что да. У нас очень хорошая команда.
  • Вам точно понятна задача?
  • Да, ваша задача очень хорошо описана.

Нужно ли говорить, что когда дело доходит до общения с техническим персоналом, ответ на все три вопроса становится «нет».

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

Беспомощность

Иногда кажется, что представитель sales ничего не может сделать самостоятельно. Для любого ответа клиенту нужен кто-то из технической команды, для ответа технической команде нужно что-то от клиента. Sales выступает исключительно в роли протокола передачи данных и сам боится что-то добавить. Клиент что-то спросил — вопрос пересылается команде. Команда ответила — ответ (часто с сохранением стиля и орфографии) отправляется клиенту. Sales находится в китайской комнате. Проблема в том, что лишний раз дергается команда, клиент дольше ждет ответа, ответ получается в неожиданном формате и по нему понятно, что писал кто-то технический. При возникновении дополнительных вопросов цикл повторяется, иногда срабатывает испорченный телефон, когда недокопировали абзац переписки или, наоборот, скопировали что-то лишнее.

Совет: переспросить себя несколько раз: «Я точно не могу ответить?». Клиент хочет интегрировать какое-то конкретное API? Прочитать про него, просмотреть проекты компании на предмет похожих интеграций и составить письмо с примерами. Если нет уверенности, что информация готова к отправке клиенту — отдать черновик команде на вычитку. После пяти-десяти повторений этой практики на разных запросах команда будет возвращать не «всё переделать», а «вроде ок, отправляй».

Нежелание ознакомиться с задачей

Часто на этапе запроса нет сложных технических моментов. Достаточно вдумчиво прочитать запрос несколько раз (учитывая стиль написания некоторых заказчиков, можно, правда, и 10 раз). «Хочу добавить себе платные подписки в SaaS», «Хочу себе тулзу, которая, используя кастомный шаблон, будет рассылать письма по списку адресов», «Хочу дизайн для своего landing page» — это примеры запросов, с которыми вполне можно справиться без делегирования технической команде. На самом деле много людей в работе сталкиваются с чем-то сложным и непонятным, но обычно стоит себя пересилить и начать разбираться — сразу становится легче и интересней. В то время как отношение «я не знаю, разберитесь» не приносит никому пользы.

Если попадается непонятная аббревиатура или название — прогуглите их сразу. Сокращение может означать что-то знакомое, а новое название могла получить какая-то популярная технология.

Советы (на примерах, приведенных выше):

  • Подписки в SaaS: ознакомиться с приложением клиента, посмотреть, с какими платежными системами есть опыт у компании, предложить на выбор. Если непонятно, на каком стеке сделано клиентское приложение — спросить. Можно сделать себе чеклист минимально необходимой информации со стороны заказчика и сразу выяснить всё, чего не хватает.
  • Рассылка писем: с такими размытыми требованиями можно предложить MVP часов на 150.
  • Landing: тут можно с примерами, даже с чужими: такой-то сложности — столько часов, такой-то сложности — столько.

Форма хорошая, контент плохой

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

  • Нам нужна интеграция с Google Spreadsheets API.
  • (Рассказ на 5 минут, о том, что вся команда уверенно пользуется Spreadsheets и в портфолио есть проект с интеграцией Google Maps).
  • Позвольте, но это же совсем не то.
  • (Еще 5 минут про то, что это все то же самое и, конечно, Google Spreadsheets API сделают).

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

Однажды искали очень узкого специалиста, пусть для примера будет «дизайнер по отрисовке кнопочек». Требования к исполнителям оформили предельно конкретно, с условием показать примеры отрисованных кнопочек. Опуская тему того, что в IT узкоспециализированные кадры — это редкость, и понятно, что портфолио из одних кнопочек — днем с огнем, но практически никто не постарался сделать выжимку из скринов с кнопочками. Основной посыл: «Можем всё, вот портфолио на 30 работ». Заказчики к этому довольно просто относятся: «Кто-то рассказал про опыт работы с кнопочками? Нет? Ищем дальше». Поэтому если ищут Google Spreadsheets API опыт, ключевые слова Google и API отдельно друг от друга не сработают. Лучше расскажите про похожий опыт, если непосредственно запрашиваемого нет.

Не понимает, что продает

Часто при общении складывается ощущение «мопед не мой», т. е. сейлз знает только какой-то узкий кусочек информации (в худшем случае просто только английский и расценки), за пределами которого компетенция заканчивается.

Тут приведу диалог с человеком (Ч), который никогда в жизни услуги разработки софта не продавал, но имеет маркетинговый бэкграунд:

Я: Today’s one was a manager with zero understanding of what he’s selling.
Ч: Ah, sounds like the original team i hired.
Я: Did you eventually find the better ones?
Ч: Don’t really need a person for it.
Я: I’ve never seen good salespersons of software development besides the people who were developers themselves.
Ч: Yeah, you don’t want to talk to an inexperienced person who doesn’t know anything about what they’re selling.
Я: Yeah, no one wants to talk to them but there are so many for some reason.
Ч: I mean u can have a junior person but they should start the call off with
«just so you know, I’m not a software developer — I’m the sales person and it’s my job to learn about the project, tell you more about our company and gather more details so, if things look like they can be a fit, we can schedule our next call w the lead developers».
Я: 99% panic and switch to «I don’t know, I’m not a technical person, I’ll need developers/PM to help you».
Ч: Yeah and if the client is like
«why don’t your devs juts join the call now?»
«we’ve got a small team and we’re very focused on making our clients the very best software products we can. That’s why we like to let the dev’s focus on building, while we help out with gathering requirements for new opportunities, and making the next call with them as productive as possible».

Не ценит время

Это когда ты списался с компанией, сделал запрос, тебя заинтересовал профиль компании и портфолио, и настало время звонка. И вместо того, чтобы отвечать на твои вопросы, тебе рассказывают о том, какая компания классная.

Совет: просто говорить, пусть даже и очень хорошо, не означает сделать свою работу. Если вы заранее знаете, что не сможете предоставить информацию на звонке — или не планируйте его, или подготовьтесь, или пригласите того, кто сможет. Например, запрос был: «Мы хотим тулзу, которая будет генерировать словосочетания. Нам интересно, как вы предложите её реализовать и почему. Какие технологии, на фронте или на беке?». И ты созваниваешься с представителем, который упорно уходит от ответов и рассказывает, что у компании много опыта и компания справится. Но даже своими словами не может пересказать, с чем справляться собрались.

С другой стороны, время тратится, когда сейлз-коллега спрашивает у команды информацию, которую сам может найти. Работаем мы с node.js? А что такое MEAN? А какие мы делали похожие проекты?

Совет: гуглить новые термины, знать портфолио и уметь находить в нем нужное.

Не привносит полезности

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

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

Не знает свои ресурсы

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

Совет: есть смысл в кооперации с HR/PM поддерживать актуальным список скиллов компании. И общаться с разработчиками побольше. Узнавать, чем кто интересуется, кто что хвалит, кто что ругает и почему. Читать потом про то, что упоминали коллеги.

Bonus: виноват клиент

Не то чтобы это паттерн, скорее кулстори, встречается редко. Компания работает по fixed quote (что само по себе довольно тяжелая модель из-за хронического back&forth что было включено, а что нет), сделала проект, клиент пошел принимать и отдал список багов на исправление. Подрядчик в ответ жалуется, что не ожидал QA от клиента, которое будет пытаться найти все баги. И вообще они столько всего уже сделали out of scope, что надо бы доплатить уже, а вы еще и багфикс хотите!

Не скажу, как тут правильно поступать. Выглядит со стороны подрядчика непрофессионально, но может сработать :)

Выводы

Ребята — интересуйтесь доменом. Вы не какая-то часть процесса «с краю», вы в него очень интегрированы. Вы очень важная часть, от вас многое зависит. Например, какую технологию придется в панике учить девелоперам и каких специалистов искать рекрутерам :) Конечно, eventually это готовый продукт, довольный клиент и команда.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



19 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

Статья интересная, но адресована junior sales manager. За годы работы в продажах и постоянному обновлению клиентов многие переучиваются очень быстро. Просто вы не попадали на ок сейлзов.

Автор, советую написать админам ДОУ с просьбой удалить статью, не позорьтесь.... тупо бред сумасшедшего, видимо у вас там в компании жесткие контры с отделом продаж но хотел бы выделить вашу фразу "

Непосредственно на этой должности я не работала, многих деталей не знаю и могу только предполагать

" эта фраза о многом говорит. Благодаря сейлзам вы сидите на попе ровно, в т.ч. и рекрутерам .

Стаття не про сейлз, а про емуляцію сейлз. Колгосп-едішин якийсь...

але якщо розглядати варіант, коли на даній посаді працюють не дуже компетентні сейлз, то стаття починає бути схожа на реальний стан речей

Я й казав про жахливий стан продажників в місцевих (і не тільки) компаніях. Такі персонажі, які описанні в статті, більше схожі на сімулякрів продажників, гомункулусів.

Колгосп-едішин якийсь...

Да бро, здесь не Рио-де-Жанейро.

Якщо не вмієш сказати «Ні», то твоє «Так» нікого не цікавить

Вы сможете сделать систему из пяти модулей с интеграциями двух API?
Да. У нас есть опыт работы со всеми технологиями, что вам нужны.
За три месяца?
Я думаю, что да. У нас очень хорошая команда.
Вам точно понятна задача?
Да, ваша задача очень хорошо описана.

а далі буває так:
— Отлично, подписываем контракт.
...
Сейл директору по маркетингу:
— Босс, я подписал очередной контракт
— Молодец, возьми с полки пирожок премию
Сейлз з проектом в клюві технарям:
— Вот, пилите «систему из пяти модулей с интеграциями двух API»
— Ок.
— За три месяца.
— Бля-аа! Та вы ох..ли !!!
— Но вы же сказали, что раньше делали «интеграцию модулей с API» за три месяца ?!
— Так там же не такие модули и API !
— Нифига не знаю, контракт уже подписан.
... 3 months after...
— Шеф, эти козлы-разработчики опять провалили проект !

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

За 10 лет в ИТ наблюдаю такое регулярно. Вообще, если сейлз делает какое-то движение, не согласованное заранее с СТО/Тимлидом то он может подставить компанию на очень большие деньги. Которые его зарпалтой даже на десятую часть не покроются. Поэтому такая самодятельность обычно очень жестко наказывается.

какое-то движение, не согласованное заранее с СТО/Тимлидом

— тут заказчик хочет детальный эстимейт с архитектурой и вообще вот это всё.
— а ну ок но там у него специально нанятые эксперты они уже написали что будут делать это две недели а чего вы хотите от меня (сто тимлида)?
— эксперты сильно дорогие и вообще тянут одеяло на себя ты (сто тимлид) на выходных посидишь пиэм наотсыпет тебе (сто тимлиду) 500 (пятсот) баксов и всё будет чики-пики!
(к)

какое-то движение, не согласованное заранее с СТО/Тимлидом

— мы тут провели крутой переговоры с заказчиком и согласовали со сто тимлидом вот 3 квадрата надо сделать за 3 месяца.
— а что внутри квадратов?
— ты же ж программист вот и разберись! со сто тимлидом мы уже согласовали 3 квадрата за 3 месяца любой сделает.
(к)
... прошло 3 месяца были найдены +3 программиста на проект.

какое-то движение, не согласованное заранее с СТО/Тимлидом

— хэй бро тут проект чуваки хотят вот в общем идею запилить оцени сколько по деньгах ну так чтобы мы и себя не обидели вот тебе наши сто тимлид.
— здравствуйте ув. сто здравствуйте ув. тимлид скажите пожалуйста а кто будет делать архитектуру вот этого всего?
— ну кто будет делать всё тот будет и делать. Но нам нужны ежедневные совещания с возможностью внезапных вопросов!
— а по какому поводу? проект небольшой времени всего 3 месяца существенных риском «внезапности» не предвидится давайте наметим основные точки «потенциальной внезапности»...
— ну как это «наметим внезапности» она же ж внезапная чувак я сто я тимлид мы старой школы мы можем звонить чтобы Рождество Новый Год и Православная Пасха мы за общение и коммуникацию в команде вообще вот это всё!
— ок не вопрос (любой каприз за ваши деньги) общение будет стоить вам +ххх.
— (да ты ох.л бро мы за 50 баксов планировали всё сделать и пообщаться непрерывно) приятного вам дня!
(к)
... прошло 3 месяца молчания...
— там у вас проект должен был начаться но видимо не начался есть ли у вас план на этот счёт?
— проект не начнётся потому что мы не нашли нужного нам исполнителя.
— а ну ок весёлого Рождества!
(к)

Видимо какая-то альтернативная

ну как это «наметим внезапности» она же ж внезапная чувак я сто я тимлид мы старой школы мы можем звонить чтобы Рождество Новый Год и Православная Пасха мы за общение и коммуникацию в команде вообще вот это всё!

Оно :)

Підписатись на коментарі