Як пояснити технічні поняття нетехнічним людям англійською мовою

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

Для чого потрібні аналогії?

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

** Ключовий принцип: ** Знайдіть основну функцію концепції, а потім знайдіть щось у повсякденному житті, що виконує ту ж саму функцію.

Стратегія спрощення

** 1. Виявляйте проблему, а не її рішення Замість: “Ми використовуємо Redis як розподілений кеш.” Спробуйте: « Наша програма отримувала ті самі дані з бази даних тисячі разів на секунду. Ми додали шар, який запам’ятовує останні результати, тому нам не потрібно запитувати базу даних щоразу — як тримаючи блокнот поряд з телефоном замість того, щоб шукати той же номер в телефонному каталозі кожен раз, коли ви дзвоните»

** 2. Використовуйте “так що” для поєднання технології з бізнес-цінністю **

• «Ми контейнеризуємо наші послуги, щоб ми могли розгортати оновлення без перезапуску всієї системи»
• «Ми додаємо автоматизовані тести, щоб ми могли випускати нові функції швидше, не порушуючи існуючі»

** 3. Не допускати заміни жаргону** Не замінюйте один технічний термін іншим технічним терміном. « Ми використовуємо оркестрацію для керування нашими мікросервісами » не простіше, ніж « ми використовуємо Kubernetes для керування нашими контейнерами » — жодна з цих фраз не має значення для нетехнічного слухача.

Як уникнути жаргонних фраз

Коли ви впізнаєте себе у використанні технічного терміну, запитайте: « Що це насправді робить для бізнесу? » Тоді замість цього скажіть саме це.

Корисні фрази для переходу:

• «В простих словах, це означає…»
• “Подумайте про це так…”
• «Аналіз, який я вважаю корисним, це…»
• Технічно це називається X, але те, що це робить, це..
• «Вам не потрібно знати деталі, але важливо те, що…»

Перевірка розуміння

Никогда не думай, что слушатель понимает. Вбудуй в них естественные проверки, не заставляя их чувствовать себя допрошенными.

** Фрази для перевірки розуміння: **

• Чи має це сенс?»
• «Я хочу переконатися, що я пояснив це чітко — чи допоможе це, якщо я нарисую швидку діаграму?»
• «Це той рівень деталей, який вам потрібен, чи ви хочете, щоб я пішов глибше?»
• «Я втрачаю тебе де-небудь?»

** Фрази для запрошення питань: **

• «Будь ласка, зупиніть мене, якщо я занадто швидко»
• Тут немає ніяких дурних питань — це справді складна річ»
• «Які питання у вас є на цей момент?»

П’ять технічних концепцій пояснені простою англійською

1. Європа CI/CD (Continuous Integration/Continuous Deployment) — безперервна інтеграція/безперервне розгортання

“Уявіть собі конвеєр заводу. Кожного разу, коли працівник закінчує свою секцію, інспектор якості негайно перевіряє цю частину перед тим, як вона рухається далі. CI/CD працює так само для програмного забезпечення: щоразу, як розробник закінчує частину коду, наша автоматизована система негайно перевіряє його і — якщо все виглядає добре — передає його до продукту. Результатом є те, що ми можемо випускати поліпшення кожен день, замість того, щоб чекати місяці на великий випуск»

Мікросервіси

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

3-е видання

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

Кубернет

«Якщо у вас багато незалежних мікросервісів, вам потрібно щось, щоб керувати ними всіма — щоб вирішити, на якому сервері вони працюють, перезапустити їх, якщо вони зламалися, і дати їм більше ресурсів, коли вони зайняті. Kubernetes робить цю роботу. Подумайте про це як про автоматизовану команду операцій, яка стежить за всіма вашими послугами 24 години на добу і підтримує все в порядку»

Машинне навчання

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

Приклади слів у контексті

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

2. «Чи має це сенс, чи допомогло б, якби я накреслив діаграму того, як ці служби спілкуються між собою?»

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

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

5. “Я тебе втрачаю? Я усвідомлюю, що я просто використав кілька слів — дозвольте мені перемотати і дати вам версію одного речення»

З часом розвивається здатність до самостійного життя

Найкращий спосіб поліпшити свої навички — це вправлятися у поясненні концепції, над якою ви зараз працюєте, другу, який не працює у цій галузі. Если они понимают, то твое объяснение работает. Якщо вони виглядають заплутаними, проблема майже завжди в тому, що ви почали з рішення, а не з проблеми. Почніть з “ось проблема, з якою ми стикалися”, і пояснення буде набагато більш природнім.

Наприклад, мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова мови: мова

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

Розглянемо такий сценарій: ви готуєте запит на звантаження для нового конвеєра CI/ CD. У вашому PR-описі, замість того, щоб сказати «Конвейєр використовує контейнери Docker, організовані Kubernetes і моніторяться за допомогою Prometheus», більш доступною фразою буде «Це оновлення спрощує наш процес розгортання. Ми створили автоматизовані тести, які запускаються при кожній зміні коду — уявіть це як автоматичну перевірку якості для кожної зміни. Він використовує контейнери (наприклад, коробки для доставки) для пакування коду і забезпечує, що все працює гладко перед випуском оновлень для користувачів. ” Це негайно формує концепцію в відносних термінах, підкреслюючи * переваги * – гладкіший, більш надійний процес – замість занурення в технічні особливості. Аналогічно, при обговоренні мікросервісів з менеджерами продуктів, зосередьтеся на тому, як вони розбивають складні завдання для ефективності: «Замість однієї великої системи, ми будуємо менші, незалежні сервіси, які працюють разом, як спеціалізовані команди в компанії»

Іншою частою перешкодою є пояснення API. Замість того, щоб описувати їх як « інтерфейси програмування додатків », ви можете сказати: « Подумайте про це як про замовлення їжі у ресторані — API — це меню і офіціант; це дозволяє різним програмним програмам запитувати інформацію або дії один від одного. » Це уникнення технічного жаргону, одночасно передаючи основну функцію. І коли ви обговорюєте Kubernetes – можливо, найстрашніший термін в цьому списку – не починайте з «платформи оркестрації контейнерів». Замість цього, «Kubernetes керує нашими програмами на декількох серверах, забезпечуючи їх завжди плавне функціонування і автоматичне масштабування вгору або вниз на основі попиту – ніби у вас є віртуальний помічник, який керує всіма вашими програмами»

Нарешті, пам’ятайте, що активне слухання так само важливо. Запитайте прояснюючі питання, щоб переконатися, що ви розумієте їхню точку зору, і відповідно підберіть ваше пояснення. Просте «Чи можете ви сказати мені, яку частину цього ви хочете, щоб я розробляв?» може відкрити двері до більш фокусованої і ефективної розмови. Сфокусуйтеся на результатах, а не на процесах - завжди починайте з питання “чому”, перш ніж занурюватися в “як”