How to Present Architecture Decisions in English
Фрази, структури і методи для представлення технічних архітектурних рішень впевнено англійською мовою - для колег, лідерів і нетехнічних зацікавлених сторін.
Представлення архітектурних рішень є високо-стабільним комунікаційним завданням. Вам слід чітко пояснити складний технічний вибір, обґрунтувати його доказами, визнати його обмеження і відповісти на запитання людей з дуже різними рівнями технічних знань.
Цей підручник надає вам мову, за допомогою якої ви зможете робити все це англійською — від вступного повідомлення до вирішення складних питань.
Сцена: Відкриття
Начните с ориентации аудитории. Розкажіть їм, що ви презентуєте і чому вони знаходяться у кімнаті:
*“Сегодня я хочу провести вас через архітектуру, яку ми пропонуємо для нової платіжної служби. Я розкажу про проблему, яку ми вирішуємо, про варіанти, які ми оцінювали, і про нашу рекомендацію — а потім я б хотів почути ваші відгуки, перш ніж ми рухаємося вперед»
- “Ця презентація стосується рішення, яке нам слід прийняти щодо шару даних. Я збережу технічні деталі відповідними для цієї аудиторії і позначаю, де компроміси мають бізнес-наслідки. ”*
Фраза « Я б хотів почути ваші відгуки перед тим, як ми рухаємося вперед » є важливою — вона сигналізує, що ви справді шукаєте вхід, а не просто оголошуєте зроблене рішення.
Спочатку описується проблема
Ніколи не скачай прямо до рішення. Спочатку визначте проблему, щоб аудиторія зрозуміла, чому потрібно прийняти рішення:
- “Поки що, кожна з наших трьох мікросервісів зберігає власну копію даних користувача. Це викликає проблеми з послідовністю — коли користувач оновлює свою адресу електронної пошти, ми мали випадки, коли вона поширювалася на дві служби, але не на третю.»*
- “Виклик, з яким ми стикаємося, полягає в тому, що наша поточна монолітна база даних стає вузьким місцем. По мірі того, як ми масштабуємо, запиту на читання конкурують із запитами на запис, і затримка зростає.”*
- “У нас є можливість: ми переписуємо службу сповіщень з нуля. Це правильний час для прийняття рішення про основний брокер повідомлень, тому що зміна його пізніше буде набагато дорожче.”*
Проходження через варіанти
Структуруйте ваші альтернативи чітко:
- “Ми оцінювали три варіанти. Я пройдусь по кожному з них коротко, перш ніж пояснити, чому ми рекомендуємо другий варіант. ”*
** Варіант А: **
- “Першим варіантом було продовжити з існуючим монолитом і оптимізувати запиту. Перевага - мінімальні перешкоди. Недолік у тому, що це короткострокове рішення — ми знову зіткнемось з тим же обмеженням через 12 місяців»
Вариант B:
- “Другий варіант — наша рекомендація — це видобути службу користувача як самостійну мікрослужбу з власною базою даних. Це вирішує проблему послідовності і дає нам незалежне масштабування. Компромісом є більші початкові інвестиції: приблизно 6 тижнів інженерного часу. ”*
** Варіант C: **
- “Третій варіант був архітектурою пошуку подій. Це найпотужніший з трьох, але також і найскладніший. Зважаючи на попередній досвід нашої команди з пошуком подій, ризик був би занадто високим на цьому етапі»
Вказівка на рекомендацію
Будь прямою:
- “Ми рекомендуємо варіант B — автономну службу користувача. Ось чому»
“Після оцінки всіх трьох варіантів, ми вважаємо, що підхід мікросервісів дає нам найкращий баланс ризику, вартості і довгострокової гнучкості.”
“Ми пропонуємо продовжити з варіантом 2, з урахуванням вашого відгуку і підпису сьогодні.”
Підтвердження компромісів
Ось де ви демонструєте технічну зрілість:
“Я хочу, щоб було прозоро щодо компромісів. Цей підхід збільшує складність операцій — нам потрібно буде управляти виявленням послуг і розподіленим відстеженням для нової служби. ”
- “Головним ризиком є період міграції: приблизно протягом двох тижнів ми будемо працювати з обома системами паралельно. Ми розробили план відновлення для цього вікна.”*
“Це рішення не вирішує проблему кешування — це окрема ініціатива, яку ми розглянемо в Q3.”
Запитання і відповіді
Запрошуємо до запитів:
“Я тут зупинюся на питаннях - особливо в розділі про компроміси.”
“Чи хтось хоче, щоб я поглибився в якійсь з цих можливостей, перш ніж я перейду далі?”
Відповідь на питання, на які не можна відповісти відразу:
“Це чудове питання. Я не маю цих даних в руках зараз — дозвольте мені продовжити з вами після цієї сесії. ”*
“Я хочу убедиться, что я дал тебе точную ответ на это. Чи можу я повернутися до вас з цифрами до кінця тижня?»
Відповідь на незгоду:
*“Я вас чую - це законне занепокоєння. Чи можете ви допомогти мені зрозуміти конкретний ризик, про який ви турбуєтеся, щоб ми могли звернутися до нього безпосередньо?» *
“Вы поднимаете важный вопрос об оперативном бремени. Чи можемо ми кількісно виміряти це разом і побачити, чи це змінює рекомендацію?»
Закриття презентації
“Подсумую: ми пропонуємо варіант B, автономну службу користувача, починаючи зі спринту 14. Ми хочемо підписати сьогодні, щоб ми могли почати план миграциї. Чи є якісь останні питання перед тим, як ми закінчимо?»
- “Наступним кроком є створення докладного документа з технічного проектування. Я розповсюджу це до кінця наступного тижня і запланую подальший огляд. ”*
Представлення архітектурних рішень є лідерськими навичками, а не тільки технічними. Чим яснішою буде ваша структура і чим чеснішим буде ваш аналіз компромісів, тим більш впевненою буде ваша аудиторія — у вашому рішенні і у вас.
Розрізняють плавальні та неплавальні
Один з найскладніших аспектів комунікації архітектурних рішень - це конструктивне поводження з розбіжностями. Легко впасти в обвинувачувальну мову або просто висловити свою позицію, не визнаючи альтернативні точки зору. Ключовим тут є не обов’язково перемога аргументу, а скоріше демонстрація того, що ви розглядали інші варіанти і можете сформулювати аргументи за вашим вибором. Фрази на кшталт «Хоча я ціную пропозицію…» або «Я розумію логіку…» негайно пом’якшують тон і демонструють повагу до різних думок. Уникайте фраз типу « Це неправильно » або « Ви не розумієте ». Замість цього, сформулюйте це так: « Давайте дослідимо, чому цей підхід може бути неоптимальним у цьому конкретному контексті. »
Розглянемо сценарій під час перегляду коду: ви запропонували використовувати архітектуру мікросервісів для нової можливості, а інший розробник, Марк, пропонує монолітний дизайн. Позначте типи: « Мікросервіси здаються надто складними — ми просто залишимося з монолитом ». Хороша відповідь не буде: « Ви повністю не розумієте переваги мікросервісів! » Замість цього спробуйте щось на зразок: « Марку, я ціную вашу турботу про складність. Хоча моноліт може спростити розробку спочатку, введення його зараз може створити значні проблеми під час масштабування і майбутніх додатків функцій. Давайте обговоримо, як ми можемо зменшити ці ризики - можливо, через ретельний дизайн API або поетапне розгортання. “Фраза зосереджена на * потенційних * проблемах, а не прямо критикує пропозицію Марка.
Іншим корисним методом є використання тесту «І що?» часто. Після того, як ви прийняли рішення, коротко поясніть, чому це важливо. Наприклад, «Ми вибираємо React для цього проекту, тому що він пропонує кращу продуктивність і досвід розробника, що в кінцевому підсумку призведе до швидших циклів розробки і зменшення витрат на обслуговування».
Нарешті, при документуванні архітектурного рішення в описі PR, будьте чіткими щодо компромісів. Не достатньо сказати «Використання GraphQL покращує продуктивність». Слово: «Ми обрали GraphQL над REST, тому що він зменшує перевантаження даних, що покращить початкові часи завантаження і зменшить споживання пропускної здатності — важливе обґрунтування, враховуючи очікуване зростання нашої бази користувачів»
Ось приклад використання curl для демонстраційних цілей, який показує, як ви можете описати рішення про використання шлюзів API у технічній дискусії:
curl -s https://api.example.com/users?page=2&limit=10Ця команда описує наш перехід до централізованого рішення з керування API — API Gateway — для ефективної обробки розпізнавання, обмеження швидкості і маршрутизації запитів до серверних служб. Це не був випадковий вибір; це безпосередньо стосується проблем з вразливістю безпеки і масштабованістю, визначених в нашій початковій оцінці ризиків.