Вникайте в процеси, або Що не так з 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 gather and 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 розробники 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 це готовий продукт, задоволений клієнт і команда.

У вас у всіх дуже хороші скіли спілкування — спілкуйтеся більше з технічною командою, розповідайте їм про свої проблеми з клієнтами — у багатьох розробників дуже туманне уявлення про замовників, інформація з реального життя їм допоможе. Наприклад, у чому полягає бізнес клієнта і як деякі клієнти вміють себе вести. Слідкуйте, як продукти розвиваються, заходьте на тестові сервера. Занурюйтеся в процес. І якщо вам вся ця кухня нецікава, то, може бути, це не ваша сфера. Але я вірю, що при належному бажанні ви зможете зацікавити будь-якого клієнта.

Опубліковано: 09/01/18 @ 11:15
Розділ Різне

SEO Блог