Для підвищення ефективності будь-якого бізнесу достатньо…
Майже в кожній компанії, де я працював або яку консультував, була одна й та сама проблема з комунікаціями. Вона збільшує витрати на комунікації, призводить до помилок у рішеннях і, чесно кажучи, дратує співробітників через втрату часу.
Основна проблема
Проблема в тому, що в початкових повідомленнях немає повної інформації, поданої в зрозумілому вигляді. Майже будь-яке листування починається з постановки задач або повідомлень про проблеми. І або переходить у дзвінок, або триває, доки всі вхідні дані не будуть з’ясовані, одна за одною. А в чатах ситуація тільки погіршується — вони ж неформальні й швидкі. То навіщо напружуватися?
Чому це відбувається?
- Ми завжди робимо, як простіше. Це не добре і не погано, просто так ми економимо енергію, яку витрачає мозок.
- Ми вважаємо, що те, що знаємо ми, знають і всі навколо. Ну звісно ж, окрім наших геніальних ідей та унікального досвіду.
Приклади некоректних комунікацій
Вічна класика: “Привіт” ▸ Що має бути: Щось осмислене, а не те, що змушує просто сидіти й чекати наступного повідомлення.
Запит без деталей: “Ми хочемо зробити новий сервіс Foo для проєкту Bar. На чому порадиш робити його базу?”
▸ Що має бути: Опис проєкту, досвід команди або просто посилання на зустріч у календарі, якщо це запрошення на мітинг.Повідомлення про інцидент без подробиць: “У нас проблеми із сайтом baz.com!”
▸ Що має бути: Як проявляється проблема? Скільки користувачів зачеплено? Коли з’явилися перші повідомлення? URL сторінки з помилками? Чи відкрито інцидент?Задача без контексту: “Я зайнятий тікетом JOB-1234. Потрібна твоя допомога.”
▸ Що має бути: Посилання на тікет із заголовком, який автоматично підтягне опис і назву. І опис проблеми або того, що від мене очікується.Неповний опис задачі: “Перевір, будь ласка, звіт із продажів.”
▸ Що має бути: Які конкретно моменти у звіті потребують уваги? Які часові періоди або дані треба врахувати?Рішення без причин: “Нам потрібно зробити апгрейд kubernetes.”
▸ Що має бути: Навіщо?Неконкретна проблема: “У нас є затримка з проєктом Z.”
▸ Що має бути: І які дії очікуються від мене? Співчуття?
Розв’язання проблеми
Чим менше читачеві потрібно виконувати дій і задіювати мозок, тим більша ймовірність, що він відповість. Тому, якщо ви хочете, щоб хтось щось зробив, надайте йому всі необхідні дані та інструменти.
Зазвичай я вирішую це проведенням тренінгів із прикладами та впровадженням фреймворку на кшталт SCR (Situation-Complication-Resolution) для задач, фреймворку для повідомлень про помилки (що завгодно: 5W1H, REACT, щось своє). Зрештою, тому, хто пише повідомлення, теж вигідно, щоб задача вирішилася якомога швидше. І це важлива навичка, яка гарантовано стане у пригоді й у звичайному житті.
SCR задає рамки, у які потрібно вписувати постановку задачі, і підштовхує “автора” хоча б замислитися про необхідні деталі з самого початку, що економить час і покращує розуміння.
Він ділить опис задачі на три частини:
Situation (Ситуація): Опишіть поточну ситуацію або контекст проєкту. Це допомагає зрозуміти, де ми зараз і які умови потрібно враховувати.
Приклад: “Наш поточний проєкт із розробки сервісу для управління задачами перебуває на стадії бета-тестування. Ми отримали зворотний зв’язок від першої групи користувачів.”
Complication (Складність): Визначте проблему або виклик, з якими зіткнулися. Це допомагає зрозуміти, які саме проблеми потрібно вирішити.
Приклад: “Зворотний зв’язок показав, що система часто зависає під час додавання нових задач. Це вже викликало невдоволення у 30% тестувальників і сповільнило процес тестування.”