Когда качественного кода - мало: почему важно говорить с клиентом

Успішність проєкту сьогодні залежить не лише від технічних умінь команди. Ефективність комунікації з користувачами платформи не менш важлива, ніж якість коду. Вдала продуктова розробка базується на довгострокових відносинах із клієнтами. Налаштування потрібної фічі, вчасна обробка фідбеку задля вирішення багу — чи не найвагоміша складова роботи над сервісом. 

Чим корисна розмова із кастомером 

Клієнтський фідбек важливий на всіх етапах розробки: від задуму — до продакшена. Безпосередній діалог із користувачами дозволяє інженеру: 

-   формувати воркфлоу для виконання поточних і майбутніх завдань. Отримані відгуки можуть стати основою для роботи над новими фічами, а також слугувати інструментом для вдосконалення функціоналу продукту;
-   проводити власні дослідження. Опитування певної вибірки юзерів дозволяє швидко та якісно перевірити будь-які гіпотези;
-   ефективно вирішувати труднощі клієнтів. Це можливо за умови своєчасної обробки програмістом отриманого запиту. Продуктова команда може витрачати десятки годин на тиждень, працюючи над проєктом, однак без аналізу потреб і відгуків аудиторії це буде робота наосліп;
-   навчитись покладатись на клієнта. Довіра до користувача має бути пріоритетною. Інколи інженеру може здатися, що співбесідник неправий. При цьому, нерозуміння аудиторії — одна з ключових проблем сучасних IT-фахівців. Щоб писати код, який задовольняє запити реальних людей, девелоперам варто знати уподобання користувачів. Регулярне спілкування — найефективніший спосіб для цього;
-   підвищувати експертність і заробіток. Розвинуті комунікативні навички допомагають розробнику монетизувати не лише продуктові, але й технологічні пропозиції. 

Як налаштувати комунікацію з користувачем 

Спілкування із клієнтом не завжди передбачає безпосередньо говоріння голосом. Це може бути листування за допомогою email або чату. Для багатьох людей телефонні дзвінки вже давно в минулому і здебільшого можуть розтягувати діалог на години — не факт, що людині зручно розмовляти саме зараз. При цьому повідомлення в Skype або інших мессенджерах не залишаться без уваги. Головне, щоб співрозмовник був онлайн.

Наприклад, основна комунікація інженерів із клієнтами Preply відбувається через чат Intercom. Кожен розробник має доступ до чату та може відповідати на звернення користувачів. Фіксованої кількості обов'язково розглянутих запитів немає. Однак, співробітнику на це щоквартально відводиться повний робочий день. Цього достатньо, щоб зрозуміти тенденцію багів і не відволікатися від поточних задач. Така практика допомагає краще орієнтуватися на потреби реальних людей. В інших випадках вони можуть залишати коментарі для співробітників Customer Support. У нас із користувачами спершу спілкується саме сапорт, а вже потім, якщо потрібно, інженер. 

Для клієнта розмова з інженером в деяких випадках може бути більш результативна, ніж із сапортом. Програміст якнайкраще пояснить налаштування функцій продукту або розбере суть проблеми і запропонує шляхи її вирішення. Саме під час прямого спілкування з кастомером він відчуває більшу відповідальність за роботу.

Особливої підготовки для такого не потрібно. Втім, може знадобитись переклад. Часто до нас звертаються не англомовні користувачі, адже ресурс дозволяє шукати репетиторів з різних мов.  

Однак, не слід поспішати направляти всі запити програмісту. Зазвичай, до інженера потрапляє неструктурована інформація, і йому власноруч доводиться її обробляти. Це може відволікати від роботи, додавати розфокусу. Залучення профільних фахівців має бути точковим, коли їхня допомога дійсно вирішальна. Незлагоджені процеси безпосередньо в сапорті теж не повинні заважати ефективній праці розробників. 

Ми постійно використовуємо Intercom для розсилки сповіщень про нові фічі (in-app та email). Також наша команда застосовує відеоколл за допомогою Zoom чи Skype. Найкращий варіант — коли вдалося розшарити екран, щоб користувач показав, що він робить із сервісом та як це впливає на його юзабіліті. Телефонні дзвінки ми вирішили не виключати з переліку доступних каналів комунікації. 

Дзвонити чи не дзвонити — ось, у чому питання 

Найбільший челендж для інженера — власне дзвінок клієнту. Відтягування цього моменту — один із проявів мовного бар'єру. Коли працюєш в інтернаціональній компанії, постійно доводиться спілкуватися з користувачами з різних країн. Ніколи немає гарантії, що людина добре володіє англійською. А якщо і в тебе розмовна англійська нижча рівня Intermediate, така комунікація може призвести до непорозуміння. 

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

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

Насправді, зовсім не обов'язково дзвонити клієнту, бо в більшості випадків можна продуктивно взаємодіяти з кастомерами в письмовій формі. Зокрема, це стосується довідкових питань з приводу тулзів на сайті. 

Зарелізили фічу — зібрали фідбек 

Необхідно сортувати запити з сапортів за темами, щоб потім зручно аналізувати отриману інформацію. Наприклад, протягом тижня зросла кількість скарг на таку-то фічу, але про іншу — пишуть набагато менше, ніж декілька днів тому. Наші менеджери відслідковують нові відгуки, щоб виявити можливості для покращення сервісу. У цьому незамінним став Userfeed. Він допоміг запровадити одну з наших стратегічних функцій — Preply Space — інструмент відеозв’язку для онлайн-уроків. Ми вчасно відреагували на потребу користувачів і внесли корективи в продукт. Оскільки Userfeed глибоко інтегрований з Intercom, клієнтам зручно підтримувати зворотній зв'язок із нами через цей додаток. 

У Preply розробка будь-якої фічі починається з customer research. Над ним працює окрема команда. Як це виглядає: ми вибираємо певну когорту користувачів і запрошуємо їх на інтерв'ю. На цій зустрічі ставимо питання щодо наявної архітектури продукту, майбутньої фічі, показуємо різні варіанти макетів, збираємо фідбек. За це даруємо респондентам корисні бонуси — безкоштовні уроки на платформі. 

Наступне завдання дослідницької групи — агрегувати фідбеки в зручні для розуміння репорти. Пізніше зібрані дані аналізуються продуктовими командами для прийняття остаточних рішень із розробки. Всі результати інтерв'ю фіксуються в корпоративній базі знань (для нас це Confluence), щоб у будь-який момент знайти архівні записи. 

Важливо, щоб збір відгуків після запуску фічі проводився по «гарячих слідах»: зарелізили фічу — зібрали фідбек. Він має базуватись виключно на поведінці користувачів: як вони працюють із продуктом, що їм не вдається зробити або що вони роблять не так, як більшість опитаних юзерів. 

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

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