Комунікації не буває багато, або Як побудувати спілкування з клієнтами правильно

Привіт, мене звати Богдана. Я розвиваю напрям бізнес-аналізу в компанії TechMagic. У цій статті поділюся порадами щодо комунікації із замовниками, які ґрунтуються на власному досвіді та перевірені протягом майже 7 років роботи в ІТ :) Читати варто всім, хто спілкується з клієнтами: бізнес-аналітикам, проєктним менеджерам, тестувальникам, розробникам. Можливо, хтось почерпне щось нове, хтось нагадає собі те, що призабув, а дехто подивиться на ту чи іншу ситуацію під іншим кутом.

Інструменти комунікації

Communication Plan

Мудрі книжки пишуть, що комунікаційний план — це мистецтво, імпровізація, індивідуальний підхід. То як тут застосувати такий прагматичний інструмент, як планування? Десь так я думала, поки не потрапила на проєкт, де працювало близько 50 людей, не враховуючи багатьох зацікавлених осіб з боку замовника. Кожен з них відігравав, без сумніву, важливу роль, однак на те, щоб з’ясувати, у чому ж вона полягала, доводилось витрачати немало зусиль. А тим часом ключових стейкхолдерів не поінформували про важливі речі, бо ніхто не знав, кому і що повідомляти, а той, хто таки знав, перебував у відпустці (про що теж мало хто був у курсі). І щоб знайти якусь інформацію чи того, хто цією інформацією володіє, треба було кілька днів займатись «соцопитуванням» різних членів команди, щоб зрештою потрапити в замкнене коло, де вас відсилають туди, звідки прийшли. Стало зрозуміло, що далі так тривати не може і потрібен план, щоб навести лад у цьому комунікаційному хаосі. Ось етапи його формування:

1. Список стейкхолдерів (як з вашого боку, так і з боку замовника).
2. Ролі та обов’язки (наприклад, Олег — техлід, відповідає за архітектурні рішення, надає права доступу в GitHub; Мішель — проєктна координаторка від замовника, відповідає за дедлайни, надає права доступу в Jira та Confluence тощо).
3. Про що інформувати стейкхолдерів та з чим до них можна звертатись (наприклад, повідомлення про реліз, зміщення графіка, уточнення вимог, зміни в складі команди, державні вихідні та відпустки).
4. Як часто інформувати (раз на тиждень, щодня, щоразу після змін у певному компоненті тощо).
5. План (на малюнку внизу).
6. План стейкхолдерам (якщо про цей план будете знати лише ви, він навряд чи сильно вплине на якість комунікації на проєкті).

Emails

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

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

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

Тема листа — «RE:RE:FW: Discussion on some important points» не можна вважати зразком чіткої теми :) А от, наприклад, «Follow up on discussing migration to new server» звучить вже значно краще.

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

Перевірка. Перечитайте те, що написали: чи все зрозуміло, чи нічого не забули. Можна дати ще комусь почитати, якщо йдеться про складну чи важливу проблему. Недарма ж у кожного письменника є редактор :)

Meetings

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

1. Готуватися до зустрічі. План, учасники: хто має бути обов’язково присутній, а кому це опціонально. (Може, люди зможуть зробити щось корисніше, ніж гортати стрічку соцмереж, слухаючи ваші обговорення у фоновому режимі :) Розішліть матеріали, які будете обговорювати. Це значно зменшить кількість питань типу «А що, там десь таке писало? А де це таке не дизайні?»
2. Дотримуватись плану зустрічі.
3. Контролювати мову тіла. На одній зустрічі, де обговорювали новий проєкт, який ми хотіли виграти, замовник захоплено розповідав про свій геніальний задум, а скептичний вираз обличчя та закрита поза техліда давали зрозуміти, що ця ідея не гідна навіть того, щоб бути висловленою. Думаю, не важко здогадатись, що проєкт ми так і не здобули ;)
4. Вести нотатки. Ви структуруєте, чого досягли під час зустрічі, які наступні кроки і хто за що відповідальний (і завжди можете послатись на нотатки, якщо люди не дотримуються зобов’язань

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

Замовники із різних країн

Ситуація

Я працювала із замовниками зі США, Німеччини, Данії, Бельгії, Швеції, Великобританії і зрозуміла, що єдиного підходу до бізнесу не існує :) Клієнт із США міг працювати до пізнього вечора й очікував від нас такої ж самовіддачі. А данці — написати о 15:00, що більше сьогодні не вийдуть на зв’язок, бо з’явилося сонце після похмурого дня і вони хочуть ним насолодитись. Презентація у форматі «проблема — кроки її вирішення — результат» завжди проходила успішно для американських клієнтів, а от німці засипали питаннями: «А як ви дізнались, що саме в цьому проблема? А чому думаєте, що варто ці кроки зробити? А як ми виміряємо результат?».

Що зробила я

1. На кожному проєкті одразу визначала, який час зручний для всіх стейкхолдерів. Підлаштовувалась під клієнта, проте намагалась не відписувати на некритичні питання у позаробочий час: люди дуже швидко до такого звикають.
2. У роботі з європейськими замовниками відкинула всі складні граматичні звороти та конструкції (що було важко, враховуючи, як складно ті знання здобувались), аби мінімізувати ризик непорозумінь.
3. Проштудіювала літературу щодо культурних відмінностей. Якою б «заїждженою» не здавалася ця тема, культурні відмінності справді існують, і не враховувати їх у комунікації просто нерозумно. Наприклад, у Данії заведено довго та бурхливо сперечатися перед тим, як ухвалити рішення, тому варто набратися терпіння під час перемовин.
4. Дублювала усі домовленості листом після нарад.
5. Навчилась підлаштовуватися під стиль спілкування клієнтів. Наприклад, вживати ідіоми (якщо клієнт сипить ними, як з рогу достатку) чи додавати жарти в розмову (якщо клієнт до них ставиться прихильно). Якщо ви не впевнені, що це схвалять, краще не ризикуйте :)

Висновки

1. Враховуйте різницю в часі.
2. Прочитайте книгу Cultural Map Ерін Меєр на тему культурних відмінностей.
3. Спростіть своє усне мовлення та письмо, якщо є ризик того, що вас можуть не зрозуміти.
4. Фіксуйте домовленості в письмовій формі.
5. Враховуйте стиль спілкування співрозмовника, а не просто копіюйте: якщо замовник використовує жаргонну лексику, це не означає, що вам пора вітатись у листах «hey, dude», варто перейти просто на менш формальне спілкування.

Велика кількість стейкхолдерів

Ситуація

На одному з проєктів, де я сьогодні працюю, кількість стейкхолдерів зростала з кожним днем: «У нас тут новий менеджер, покличмо його на зустрічі», «Емір цікавився, як у нас справи, напевно, його теж варто запросити», «Філіп боїться, що його ідеї не будуть враховані у ваших прототипах». У результаті наші наради перетворювались на хаос, у якому брала участь чимала кількість людей і кожен намагався донести свою думку (яка часто суперечила думці інших) та відчути себе важливим.

Що зробила я

1. Ідентифікувала людину, яка ухвалює рішення, і залучила її в усю подальшу комунікацію як проксі.
2. Створила дашборд, де зібрала всю інформацію щодо проєкту: над чим працюємо, дані аналізу та досліджень, мокапи ідей, презентацію з результатами роботи, і надала можливість коментувати (не редагувати!) усім стейкхолдерам.
3. Описала процес роботи над проєктом: що робимо, як часто переглядаємо результати, як тестуємо ідеї, які метрики використовуємо для перевірки ідей, і затвердила зі стейкхолдерами.
4. Зафіксувала всі ідеї в єдиному документі з пріоритетами та статусом, до якого всі мали доступ.

У результаті зустрічі та комунікація стали більш ефективними та сфокусованими, а стейкхолдери — задоволеними.

Висновки

1. Визначити, хто ухвалює рішення. Це буває складно: «Ми ухвалюємо рішення колегіально, у нас демократія». У такому разі запитайте, хто затверджує бюджет. 99% ймовірності, що ви відразу дізнаєтесь, хто вирішуватиме.
2. Документувати вимоги та зберігати всю інформацію в єдиному місці, доступному всім.
3. Проводити Impact analysis. На що вплине те чи інше побажання одного із замовників, як воно відіб’ється на системі, які є ризики.
4. Визначити плюси та мінуси кожного рішення. Якщо є кілька альтернативних варіантів, краще підготувати переваги та недоліки кожного й одразу підкреслити той, який ви та ваша команда вважаєте оптимальним.
5. Презентувати результати аналізу усім стейкхолдерам для визначення пріоритетів. Як показує практика, це дає змогу клієнтам зрозуміти, наскільки той чи інший запит важливий, скільки часу (та грошей) займе його реалізація.

Заперечення

Ситуація

«Це так працює вже давно», «Ми знаємо краще», «У нас на це немає часу»... Навряд чи вдасться порахувати, скільки разів мені доводилось чути схожі фрази. Особливо коли долучаєшся до проєкту, який давно триває. Наприклад, на одному з проєктів, над яким зараз працюю, клієнти звикли до того, що спершу вони малюють дизайни, а потім з них пишуть вимоги. На пропозицію розписати передусім вимоги, а відтак зробити дизайни, я почула у відповідь: «Ні-ні, у нас user-centered design, ми спершу враховуємо потреби користувача і малюємо дизайни». Усе б нічого, якби ці дизайни не змінювались щодня, не з’являлись нові поля та функції і водночас не губились сторінки та переходи...

Що зробила я

1. Проаналізувала, у чому причина. Виявилось, не було кому сидіти й описувати вимоги і клієнти ділились усно ідеями з дизайнером, який те все малював.
2. Візуалізувала недоліки підходу документування дизайнів. Схематично зобразила сценарії користувача за допомогою user flows, на яких чітко можна було помітити пропущені моменти в дизайні.
3. Показуючи візуалізацію, підкреслила, що, якщо просто описувати екрани, усі ці недопрацювання можна не помітити, тому краще документувати вимоги та зіставляти їх з дизайнами.
4. Була одним з ініціаторів дизайн-рев’ю сесій, під час яких разом з клієнтом та дизайнером обговорюємо різні сценарії використання.

Це дало змогу дещо зменшити час, який уся команда витрачала на аналіз дизайнів і вишукування неточностей, та краще зрозуміти продукт.

Висновки

1. Визначити причини. Часто це може бути брак бюджету, страх втратити авторитет чи й просто нерозуміння важливості змін.
2. Пояснити, чому зміна важлива.
3. Візуалізувати свої аргументи.
4. Наголосити на вплив, який матимуть ті чи інші зміни.

Робота з негативом

Ситуація

«Це ви винні, що так сталось», «Ваші естімейти завжди завищені або ви ніколи не потрапляєте в них», «Чому в вас завжди так багато багів», «Я не збираюсь за це платити», «Ваша команда недостатньо компетентна», «Це не те, що я хотів, ви мене ніколи не розумієте», «Вам більше не можна довіряти». Доводилось чути щось схоже? На одному з проєктів клієнти кілька місяців казали, що задоволені результатами, а потім написали гнівного листа, основний лейтмотив якого: «Усе, що ви зробили, не так, як ми хотіли. У вас купа багів, що роблять ваші тестувальники?».

Що зробила я

1. Опанувала себе й замість емоційної реакції відписала клієнтам, що ми проаналізуємо ситуацію та проведемо зустріч, щоб усе обговорити.
2. Дослідила причини: зібрала всі баги, посортувала за пріоритетом, статусом, тим, чи знайдені вони замовником, чи нашою командою, вивела метрики.
3. Обговорила результати аналізу з клієнтом. Стало зрозуміло, що баги, про які писали клієнти, пов’язані з різним уявленням про те, як будуть поводитись користувачі.
4. Разом з тестувальниками переглянули тест-стратегію, скоригували сценарії та затвердили з клієнтами, щоб уникнути таких ситуацій надалі.

Що робити

1. Зберігати спокій і позитив.
2. Виграти час. Клієнт виявив критичний баг у продакшені й бурхливо вимагає негайного виправлення, але ви розумієте, що це неможливо зробити за 5 хвилин. Скажіть, що усвідомлюєте серйозність проблеми і зробите все можливе, щоб її ліквідувати, і в жодному разі не залишайте листи клієнта без відповіді довго.
3. Дослідити причину негативу з боку клієнта.
4. Скласти стратегію розв’язання проблеми.
5. Доповнити пояснення цифрами чи візуально. Якщо клієнт не розуміє, як працює якийсь функціонал і чому це не так, як він хотів, намалюйте діаграму, розпишіть сценарії, зробіть скріншоти. Маючи візуалізацію, значно легше обговорювати навіть дуже складні питання.
6. Ніколи не сперечатись з клієнтом до з’ясування всіх обставин.
7. Ніколи не звинувачувати нікого зі своєї команди в комунікації з клієнтом.
8. Бути готовим визнати свої помилки: усі ми помиляємось, головне робити висновки і не повторювати одні й ті самі помилки багато разів :)

Брак комунікації

Ситуація

Клієнт не відповідає на листи, не з’являється на мітинги, не ділиться бізнес-цілями та планом розвитку продукту — доволі поширена ситуація. В одному проєкті клієнт пішов з рюкзаком у гори на тиждень перед важливим релізом, а нам треба було, щоб він налаштував зміни у своєму AWS-профілі, без яких цей реліз не міг відбутися. І доступу до інтернету в горах в нього, звісно, не було.

Або клієнт на зв’язку, ви точно про це знаєте, але на листи з питаннями щодо вимог не реагує. А відповіді потрібні, інакше є ризик зробити не так, як замовник хоче.

Що зробила я

1. З’ясувала канал комунікації, найзручніший для клієнта, зокрема для термінових питань.
2. Склала план відпусток і вихідних і попросила клієнта повідомляти, коли він буде недоступний.
3. Почала додавати в тему листа помітку Blocker, якщо була потрібна швидка реакція.

Що робити

1. Визначити канали комунікації, зручні для клієнта. Можливо, він не любить користуватись електронною скринькою і віддає перевагу листуванню в чаті.
2. Наголосити на важливості та терміновості питання. Проте тема листа на зразок «Need clarification about some issue» аж ніяк не дає розуміння того, що без цього уточнення ваш реліз заблоковано, і не викликає бажання миттю кинутись відповідати на запитання. Краще написати «Release blocked due to lack of decision on ».
3. Якщо клієнт продовжує ігнорувати ваші послання, спробуйте порушити питання на вищому рівні (як з вашого боку, так і з боку клієнта, якщо це можливо). Наявність у СС менеджменту зазвичай підсилює важливість вашого звернення, але перед тим, як його туди вписувати, переконайтесь, що питання справді важливе і цього варте.

Підсумок

Комунікацію можна вважати мистецтвом чи наукою, але щоб зробити її ефективною, потрібно опанувати правильні інструменти та постійно відточувати свої навички на практиці. Бо, як сказав колись Бернард Шоу, найбільша проблема комунікації — це ілюзія її присутності.