Sorry I’m Latte! Або як східноєвропейцю опанувати ділову англійську.
Професійність
Можна досконало оволодіти правилами структурування, стилю та ввічливості, але раз за разом потрапляти в різноманітні халепи через недолік більш високого рівня – брак професійності.
Професійність тут стосується зовсім не нашої кваліфікації в предметній сфері – наскільки хорошим інженером, дизайнером чи копірайтером ми є – а того, як саме ми спаковуємо наші думки в наші листи. Подивимось на такі два речення:
Спробуйте, будь-ласка, запустити цю прогу на іншому компі – чи буде бага проявляти себе там?
Ваш користувач використовує дивну опен-сорсну поробку, і, нам шкода, але ми не можемо гарантувати роботу нашого продукту в цій ситуації.
Ці речення є бездоганними з точки зору граматики і ввічливості, але нікуди не годяться з точки зору професійності. «Прога», «комп» та «бага» є жаргонними словами, які, хоча і є прийнятними і навіть інколи корисними в робочому середовищі, не рекомендуються для використання в бізнес-спілкуванні. «Опен-сорсна поробка» є терміном, по-перше, суб’єктивним (ця програма цілком може вирішувати задачі, які на неї поклав користувач, за ціну, яку він готовий платити), а, по-друге, зневажливим по відношенню до великого класу програм (навіть якщо програма користувача об’єктивно є «поробкою», це не привід розповсюджувати цей епітет на весь клас опен-сорсних продуктів, серед яких є немало якісних).
Професійність є дуже різностороннім поняттям, що включає силу-силенну нюансів – від того, що, як і коли ми пишемо, до того, як це виглядає на екрані отримувача. Тут ми розглянемо лише декілька найважливіших її компонентів, порушувати які вважатиметься моветоном в більшості бізнес-культур.
Один з цікавих самокритеріїв полягає в тому, щоб намагатись складати листа так, щоб при його випадковому розголошенні (CC іншим людям – субпідряднику, користувачу чи розробнику «опен-сорсної поробки», його публікації в газеті чи використання як свідчення в суді) воно не висвітило вас і компанію в негативному світі чи, у гіршому випадку, не потягнуло за собою позов за наклеп чи ще щось цікаве.
Дипломатичність полягає в уникненні в тексті оціночних, зверхніх, чи зневажливих суджень про співрозмовника та третіх осіб. Світ IT схильний до класовості і диктатур ідеологій, аж до релігійних війн. Не всі технології, що використовують ваші клієнти, будуть милі вашому серцю. Деякі будуть неодмінно використовувати open source, інші співати дифірамби Apple’у, треті прославляти геній Джефа Безоса.
Як би гучно вони це не робили, опиратись їм не варто – навіть якщо ми точно знаємо, що якість значної частини GNU-софта невелика, або що саме в тому open-source продукті, що використовує користувач, немає куди ставити штампи про вразливості. Як і належить справжньому дипломату, стискаємо зуби і пишемо приблизно так:
I am sorry that you came across issues when making EZ Spend work with GCardProcessor. We had customers in the past reporting similar issues. Our research back then suggested that GCardProcessor did not follow the 3D Secure design handbook fully. hose customers managed to resolve the issues by contacting GCardProcessor maker and requesting a patch from them.
Така відповідь звучить нейтрально і по суті. Будь-які зауваження, що виходять за рамки контексту проблеми – що модель open-source нежиттєздатна генерувати якісні продукти, що GCardProcessor написана першокурсниками на колінці, що краще вже взяти готівкові гроші та GCashCalculator, – ніяк не вплинуть ні на вирішення проблеми, ні на індустрію open source, ні на якість GCardProcessor, а в співрозмовника створять неприємне враження, що тут працюють несерйозні, childish, і ідеологічно упереджені люди.
Не варто принижувати конкурентів. Якщо вже мова про них зайшла, то будь-які порівняння мають бути лише на об’єктивних підставах – охоплення продукту, вимірювана ефективність, час на ринку.
Уникайте прямої критики. Тикати співрозмовника носом в його нестачу знань, помилку чи інший професійний недолік є неетичним. Наступне речення може стати останнім в вашому спілкуванні з користувачем:
You have made a mistake in line 4.
В ході надання технічної підтримки хіба що не кожного дня виникає потреба повідомити користувачу про те, що продукт він використовує невірно (пише некоректний код, встановлює невірні налаштування, користується в умовах, непридатних для використання). В таких випадках варто проявляти такт і витримку. Двома корисними техніками повідомити користувачу про помилку є:
- Перетворити в очах користувача цю помилку на випадковість, і
- Дозволити користувачу помітити помилку самому.
Це можна робити приблизно так:
It seems there’s a typo in line 4, could you please check it?
Line 4 looks suspicious to me, is it how you intended it to be?
Висловом про typo – описку – ми перетворюємо помилку на випадковість. Не називаючи помилку напряму, ми даємо користувачу шанс побачити її самому.
Можна вказати на помилку і напряму, але в такому разі робити це треба обережно і використати напускну «невпевненість»:
I double checked Microsoft’s guidance on this method and realized they advised to always use NULL as the third parameter. I know their guidance is often wrong, but could it be the case here?
I ran your code on my system and it has thrown a NullReferenceException for me because Y was not initialized. Not sure if I did anything wrong?
До критики, хоча і завуальованої, можна віднести і «нетерплячі» звороти як “As I mentioned in my earlier email, please try running your code through a memory profiler”. Краще уникати таких формулювань. Користувач міг пропустити ваше попереднє прохання через надмірну зайнятість іншими проблемами. Він міг не знати, як працювати з профайлером, і виділити для цього час в інший день. Він міг навіть виконати ваше прохання, але забув повідомити вам у відповіді. В кожному з цих випадків акцентування уваги на повторності прохання буде сприйнято як надмірний тиск.
В сухому підсумку, не треба привертати зайву увагу до помилок, неуважності чи косолапості співрозмовника. Навіть якщо він кульгає в сфері, де ви професіонал, він цілком може бути генієм в своїй сфері – навіть більшим, ніж ви в своїй. Не треба забувати й те, що в багатьох людей є складності зі сприйняттям настанов, критики в свій бік чи інших натяків на власну неідеальність. Просто тримаймо це в голові і залишимо звіра спокійно дрімати.
Переходи на особистості – відсилка до індивідуальних рис, панібратство, мізогінія, расизм, дискримінація за професійною чи непрофесійною ознаками, іронія, чи, боронь бог, сарказм – в діловому листуванні неприйнятні. «Тут я серйозна і дуже порядна людина», сказав мені один приятель, якого я по молодості кликав на безкоштовне пиво на якійсь-там конференції, де йому довелось виступати. Листа пише не Кристина Яцеку, а в першу чергу представник компанії А представнику компанії Ф. Кристина і Яцек можуть налагодити неформальні зв’язки на додачу до цих міжкорпоративних відносин, але міжкорпоративні відносини завжди йдуть попереду.
Інколи, в дуже окремих діалогах, між особами, які вже трохи знають один іншого, легке особисте зближення чи обережні іронічні жарти можуть відчувати себе на своєму місці. Але це нечасте і доволі велике виключення, з яким краще не ризикувати.
Жаргон, як і розмовний стиль, вважаються поганим тоном в діловій переписці. Терміни «bugs», «admin», «hacker» краще залишити для службового користування.
Термін «bug» не варто використовувати, навіть по відношенню до чужих продуктів, ще й тому, що він нічого толком не описує, а лише неаргументовано виставляє продукт в негативному світі – тобто, по суті, є образливим. Альтернативи? Issue, problem, mistake, glitch, fault, error.
Ще приклади жаргону: «Cool», «gotcha», «stuff», «NRE», «MS», «y’all» та смайлики.
Також в ділових листах варто уникати розмовного стилю – зокрема скорочень I’ve, you’re, I’d – як і ТЕКСТУ КАПСОМ.
Охайність оформлення. Лист має використовувати охайні стилі шрифтів і кольорів. Складно знайти видовище сумніше, ніж коли в тілі листа кожен параграф виконаний своїм шрифтом і кольором, що недвозначно натякає, що текст було нашвидкуруч зліплено з окремих заготовлених наперед шматків-штампів.
Dear John,
Thank you for contacting us about EZ Spend.
My name is Sonia and I’m your customer service angel.
Please find the pricing information you requested below:
1 copy – $100
2 copies – $150
3 copies – $200Let me know if you need any help.
Kind regards,
Sonia Timpson
Ginger Cat Ltd
І взагалі, уникайте copy-paste. Користувач, скоріше за все, вже вивчив ваш сайт і всі матеріали, які на ньому розміщені. Ваша відповідь, що побудована на скопійованих з сайту же матеріалах, чи, ще гірше, скрин-шотах звідти, миттєво дає користувачу зрозуміти, за кого його тут тримають. Навіть якщо інформація на сайті – це все, що в вас є, обов’язково викладіть її в листі своїми словами.
Використовуйте міць CC і BCC. Зокрема, привчіть себе натискати Reply All при створенні листа у відповідь – це збереже в списку CC всіх адресатів, які на цей момент вже були включені в вашу переписку.
За необхідності, додавайте в CC колег та партнерів, якщо ви бачите, що переписка може торкатись їхніх інтересів. Хорошим тоном є повідомити іншу сторону про нових адресатів в CC, а також впевнитись, що попередня (відквочена) переписка не містить чутливих чи особистих даних, розголошувати які новим адресатам було б не варто:
Copying Andrii, who is our lead designer.
Olga, in CC, will be the best person to talk to about this issue.
Перевіряйте імена. Мало що дратує більше, ніж невірно написане у привітанні ім’я. Поширеним є плутання імені та прізвища. В окремих країнах – Угорщині, В’єтнамі, і багатьох інших – імена в полі From і підписах традиційно починають з прізвища. В інших (Турція, Індія) вони можуть складатись з трьох чи більшої кількості частин, з яких перша далеко не завжди відповідає імені. Навіть в країнах, де імена зазвичай пишуться перед прізвищем, бувають виключення (Австрія, Бельгія, Італія). При недостатній увазі прізвище може потрапити в привітання, створивши дискомфорт для отримувача:
Hi Csaba,
Dear Ivanov,
Hello Reddy,
Будьте уважні при написанні привітань і не покладайтесь на вашу поштову програму, якщо вона робить це автоматично. Якщо не впевнені, яка з частин є власним ім’ям (таке буває), загугліть це ім’я по картинках. Результати, що містять обличчя людей однієї статі, як правило, відповідатимуть власному імені, а обличчя людей різних статей – прізвищу.
Поширеною помилкою є ігнорування в іменах діакритиків (акутів, циркумфлексів та умляутів). Імʼя Жан-Франсуа (Jean-François) без ç стає Жан-Франкуа, так само як позбавлений š Miloš з Мілоша перетворюється на Мілоса. Як писав Дейл Карнегі, імʼя людини є для неї найприємнішим словом у світі – ви впевнені, що хочете ризикувати його повагою до себе на такій дрібниці, як ледь помітна риска над літерою?
Мультикультурність. Хоча правила листування – від визначеної структури до нейтральності – сьогодні є, в певному сенсі, універсальними, вони, все ж таки, випрацьовувались в першу чергу в англомовному світі. І в той час, як англійці, американці чи австралійці їх сприймають достатньо буквально, люди з інших країн чи культур можуть вносити до них власні корективи.
Для іспанців в переписці типово бути більш неформальними і дружніми. Для італійців – гучними і сумбурними. Французи, як хіба що не найбільші антагоністи англійців, можуть взагалі написати французькою і очікувати французьку у відповідь.
Східноєвропейці – чехи, поляки – більш прямолінійні і звертають меншу увагу на стиль і мову. Але навіть вони не порівняються з китайцями, які взагалі часто пишуть в листі лише бізнес-складову і уникають всього іншого.
Індійці використовують характерний «бізнес-діалект», чимось схожий на «псевдо-ділову» українську. Втім, правила листування вони зазвичай знають.
Звичайно, не можна не звертати увагу на країну походження і культуру людини, з якою ми спілкуємось. Але цікавим є те, що слідування правилам «трьох-плюс-одного слонів» дозволяє створювати універсальні листи, які буде легко зрозуміти носіям будь-яких культур, навіть якщо самі вони ніколи про них не чули:
- Стислі, прості речення легше перекладаються Google Translate, ніж складні і технічні.
- Не можна бути занадто ввічливим, але легко опинитись недостатньо ввічливим.
- Позитивний настрій легко завантажується як в суворого німця, так і в життєрадісного іспанця.
- Мову привітливості, емпатії та подяки розуміють носії всіх культур.
Остання подача за вами. Якщо ви знаходитесь на боці надавача (а не отримувача) послуги, хорошим тоном є закінчувати переписку вашим листом. В залежності від того, чим переписка закінчилась, цей лист може втілювати подяку, констатацію факту, підтвердження дії або вибачення.
Glad to know that this little trick worked for you! Thank you for confirming!
Awesome! Thank you for letting me know.
That’s great! Glad to know that the issue is solved.
I am sorry that we couldn’t make it work for you. I hope that wasn’t too hard of a hit.
Thank you for your help so far. I will get back in touch as soon as this feature is ready.
В кінці дописуємо одну обов’язкову фразу – про відкрити двері для наступних звернень:
Please let me know if I could be of any further help.
Please do not hesitate to get in touch again should you need any assistance.
Please feel free to contact us at this email address if you have any questions.
Ця дія ставить жирну крапку в розмові і дозволяє додатково перевірити, чи всі питання користувача закриті.
Увімкніть пруфрідер – це чудовий інструмент, що дозволяє не допустити тривіальні описки в текст листа.
Візьміть за правило перечитувати листа перед відправкою. Ви самі не повірите, як легко в листи пробираються помилки. Відсутність підкреслень пруфрідера ще не гарантує якість: не всі пруфрідери можуть виловити пропущене слово, слова, випадково написані не так (омоніми), або випадково пропущені речення.
Окрім того, читання дасть можливість перевірити, чи логічно складений текст, чи всі аспекти теми враховані, і чи немає неоднозначних зворотів у викладенні.