Представлення архітектурних пропозицій англійською мовою: мова для технічних оглядів рішень

Захоплюється вивченням мови архітектури

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

Відкриття пропозиції

Почніть з встановлення контексту, а потім чітко викладіть свою пропозицію. Не вступайте прямо у технічні подробиці — вашій аудиторії спочатку потрібна спільна система відліку.

** Корисні фрази: **

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

Пропозиції та рекомендації

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

• «Я ** пропоную ** мігрувати службу попереджень до архітектури, що керується подією. »
• «Моя рекомендація полягає в тому, щоб прийняти шаблон CQRS для модуля звітності з важким читанням»
• «Заснований на наших вимогах, я ** пропоную ** ми підемо з проксі-сервером, а не з лінією управління мережею послуг. »

Описання компромісів

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

• «Компроміс тут знаходиться між простотою операцій та масштабованістю.»
• «Варіант A дає нам швидший час до виходу на ринок, ** але за рахунок ** тіснішого з’єднання.»
• «Якщо ми підемо з управляною службою, ми отримаємо надійність ** але втратити ** дрібнозернистий контроль над конфігурацією.»
• «Існує **напруга між ** вартістю і продуктивністю в цьому підході.»

Відповідь на запитання

Ви зіткнетеся з відступом. Підготуйтеся до цього за допомогою таких шаблонів:

Відповідь на запитання:

• “Це дійсно важливо. Дозвольте мені звернутися до цього прямо»
• “Я розумію занепокоєння щодо складності операцій. Ось як ми зменшимо це…»

Защита твоей позиции

• «Дані з нашого піку вказують на те, що витрати на продуктивність знаходяться в прийнятних межах»
• «Ми порівняли цей підхід з альтернативою, і результати сприятливі для запропонованого рішення»

Грациозно закінчую:

• “Ти маєш рацію, що це вводить ще один режим невдачі. Ми повинні додати це до реєстру ризику»
• «Fair point — Я перегляну пропозицію, щоб включити план повернення»

Консенсус-будівельні фрази

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

Ключовий словник

** Комбінація ** — баланс між двома бажаними, але конкуруючими якостями, такими як послідовність і доступність.

** Доказ концепції (PoC) ** — невеликий експеримент для перевірки того, що запропонований підхід технічно можливий.

** Критерії прийняття ** — умови, які повинні бути виконані для того, щоб пропозиція або результат вважалися повними.

** Обмеження ** — обмеження, яке обмежує які рішення є реалізовуваними, наприклад, бюджет, командні навички або вимоги законодавства.

** Сполучення ** — ступінь взаємозалежності між компонентами; щільно сполучені компоненти важче змінювати незалежно.

П’ять прикладів висловлювань

1. «Я пропоную замінити синхронні виклики REST асинхронною чергою повідомлень, щоб відокремити службу замовлення від служби виконання»
2. «Компроміс між сильною послідовністю і низькою затримкою є центральною напругою в цьому архітектурному рішенні»
3. «Це законне занепокоєння — щоб зменшити ризик втрати даних, ми б реалізували запис-наперед журналювання перед міграцією»
4. «Я рекомендую нам затриматися з доказом концепції на два тижні і визначити чіткі показники успіху, перш ніж ми почнемо»
5. «Чи є якісь виняткові заперечення щодо запропонованої стратегії версії схеми, перш ніж ми завершимо дизайн?»

Відповідає на запитання

Перед переглядом записайте три найскладніші питання, які хтось може задати вам. Практикуюсь відповідати на них вголос. Поширені складні питання включають: «Що станеться, коли це не вдасться?», «Який шлях міграції з поточного стану?», І «Чи ви розглядали X альтернативу?». Наявність структурованих, спокійних відповідей демонструє інженерну зрілість в будь-якій мові.

Націоналізм — це не просто мова, це не просто мова, це не просто мова

Ефективне представлення архітектурних пропозицій не тільки про передачу ваших ідей; це про навігацію потенційних розбіжностей конструктивно. Для не-англомовних носіїв англійської мови це може відчуватися особливо пригнічуючим - нюанси фразування, виражаючи невизначеність і закликаючи до рішення, визнаючи альтернативні точки зору, можуть бути викликом. Важливо пам’ятати, що технічні дискусії * завжди * під впливом комунікації, незалежно від індивідуальної плавності. Сфокусування на ясності, шанобливій мові і демонстрації розуміння набагато важливіше, ніж ідеальна граматика. Давайте розберемося з деякими поширеними занепокоєннями:

По-перше, уникайте надто наголошених тверджень типу «Це єдиний спосіб». Замість цього, оформляйте свої пропозиції умовною мовою – «Може бути корисно дослідити…», «Ми могли б розглянути…» Це негайно пом’якшує пропозицію і запрошує до співпраці. По-друге, коли виникають проблеми, не відразу їх відкидайте. Активно слухайте і демонструйте розуміння, перефразувавши протилежну точку зору перед тим, як відповісти. Фрази на кшталт «Я розумію вашу занепокоєність щодо X» або «Дайте мені переконатися, що я ясно розумію, що ви пропонуєте…» показують повагу і будують відносини. Не бійтеся задати прояснюючі питання - справжній пошук розуміння є ознакою професіоналізму, а не слабкості. Нарешті, зосередьтеся на тому, чому стоїть за вашою пропозицією. Обґрунтування вашого архітектурного вибору на реальних перевагах — поліпшеній продуктивності, зменшеному ризику, спрощеному обслуговуванні — робить їх більш переконливими і менш схожі на особисті думки.

Давайте розглянемо приклад. Уявіть, що ви пропонуєте мігрувати монолітну програму до мікросервісів за допомогою Kubernetes. Один колега висловлює занепокоєння щодо операційних витрат на управління такою складною системою. Ви можете відповісти, сказавши: «Це вірно; я ціную те, що ви підкреслили збільшення складності операцій. Ми можемо зменшити це, впроваджуючи міцний моніторинг і автоматизацію, що в кінцевому підсумку спростить наш робочий процес і зменшить потенційний час простою. ”

# Example CLI command to deploy a simple Kubernetes pod (using kubectl)
kubectl run my-app --image=nginx:latest --dry-run=client -o yaml

У цьому прикладі показано основну команду для створення підрозділу. Важливо розуміти основну концепцію розгортання програми в контейнерному середовищі — щось, що легко пояснити з ясною, короткою мовою, навіть якщо ваша рідна англійська не є ідеальною. Пам’ятайте, технічні команди цінують експертизу і аргументовані аргументи більше, ніж поліровану прозу. Спробуйте пояснити, * чому * ваша архітектура підходить для вирішення проблеми, і будьте відкритими до обговорення і вдосконалення.