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