How to Give Technical Feedback Diplomatically

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

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

---

Основний принцип: відокремити роботу від людини

У англійській мові існує ключова відмінність між цими двома твердженнями:

• “Ти зробив поганий вибір дизайну.” - нападає на людину
• “Ця конструкція має деякі компроміси, які ми повинні обговорити.” — адреса роботи

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

---

Позитивна реакція на перший огляд

Перед тим, як висловлювати свою занепокоєність, визнай, що працює. Це не ласкаво — це професійне контекстне налаштування:

• “В цілому це добре структурована пропозиція. У мене є кілька запитань щодо шару даних, які я б хотів обговорити з вами».*

• “Це підхід є суцільним для звичайного випадку. Мені цікаво, як він обробляє крайні випадки навколо одночасних запитів — чи можемо ми про це поговорити?»*

• “Це значно поліпшує порівняно з попередньою реалізацією. Одна річ, яку я б хотів дослідити, це чи можемо ми зменшити з’єднання між цими двома модулями.”*

---

Фрази для підняття занепокоєння

Задаю вопрос о предположении:

“Я хочу переконатися, що розумію аргументацію тут — що очікується від пропускної здатності при піковій навантаженні?”

“Чи ми розглянули, що станеться, якщо сторонній API буде недоступним? Я не бачу обробки помилок для цього шляху.”

Пропоную альтернативу:

• “Одним з варіантів, який варто розглянути, є використання черги подій замість прямих викликів — це від’ єднає служби і спростить керування повторними спробами.” *

• “Я бачив подібну проблему, вирішену за допомогою стратегічного шаблону. Це може дати нам більше гнучкості, коли змінюються вимоги. «Що робити?» (фр

Позначити ризик:

• “Я хочу попередити про потенційний ризик: ця зміна стосується потоку платежу, який має велике значення. Я б відчував себе більш впевнено, якби ми мали інтеграційні тести, перш ніж це піде в виробництво.”*

• “Розробка тут виглядає добре для поточного навантаження, але якщо ми збільшимо кількість користувачів до 10x, цей цикл O( n²) може стати в’ язкою. Чи слід нам розглянути це зараз або створити квиток на пізніше?»*

---

Мова, що говорить, говорить ясно

“М’якше” не означає слабше. Ці фрази зменшують тертя без втрати ясності:

Direct (potentially abrasive)	Softened (still clear)
“This is wrong."	"I think there might be an issue here."
"You should have done it this way."	"One approach that tends to work well is…"
"This doesn’t scale."	"I have some concerns about how this will perform at scale."
"Nobody does it like this."	"The more common pattern for this is X — is there a specific reason for this approach?"
"That’s a bad idea."	"I see some challenges with this. Can I share my thinking?”

---

Записується в ефір на СТБ. В лицо

** Підписання ** (Slack, електронна пошта, PR коментарі):

• Будь більш чітким — тон важко прочитати у тексті
• Додати «Я» твердження: * «Я не впевнений, що я слідую цій частині» *, а не * «Це неясно» *
• Використовуйте мовлення: * “Я можу щось пропустити, але…” *
• Закінчуйте запитанням, коли це можливо: “Що ви думаєте?”

Лично або по телефону:

• Використовуйте теплий тон, але будьте прямолінійними
• Затримайтесь і запитайте: “Чи має це сенс?” або “Що ви думаєте?”
• Обережно ставтеся до невербальних сигналів - якщо людина виглядає оборонливо, сповільніть

---

Зміна імені на старше

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

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

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

• “Я подумав про цей дизайн — чи варто було б дослідити, чи можна уникнути спільного стану бази даних? Щасливий бути неправильним, якщо є на це причина.»*

Ці фрази не нечесні — вони професійні. Вони показують смирення, але все ще виявляють занепокоєння.

---

Після цього слідує відновлення

“Я хотів продовжити коментар, який я дав минулого тижня — чи ви мали можливість його переглянути?”

• “Я буду рад поговорить с вами об этом, если это поможет обсудить варианты.” *

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

---

Дипломатическая техническая обратная связь - это умение, которому можно научиться. Інженери, які це роблять найкраще, достатньо прямі, щоб бути корисними, і достатньо ввічливі, щоб їм можна було довіряти. Ці дві якості разом роблять відгук радісним, а не страшним.

Назва походить від мови індіанців — неандертальців

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

Однією з найчастіших пасток для носіїв мови, яка не є рідною, є використання надто прямої мови. Замість того, щоб сказати «Цей код неправильний», що може здатися жорстким, спробуйте обрамити його м’якшою фразою. Наприклад, ви можете сказати: « Я помітив потенційну проблему у цьому розділі, пов’ язану з обробкою помилок. Можливо, ми могли б дослідити додавання блоку try...catch, щоб граціозно управляти несподіваними відповідями і запобігти аварії програми.” Додаток “можливо, ми могли б” негайно пом’якшує критику і запрошує до співпраці. Аналогічно, замість того, щоб сказати « Ця змінна не використовується », ви можете запропонувати: « Мені цікаво, чи ця змінна зараз потрібна в цій функції. Чи можемо ми обговорити його мету або чи може він бути зайвим?» Ця фраза відкриває розмову, а не видає негайну оцінку.

Іншою областю, що потребує ретельної уваги, є використання умовної мови, пов’язаної з технічними термінами. Багато розробників використовують специфічний жаргон, який може не перекладатися ідеально на іншу мову. Під час опису проблем з швидкодією, не описуйте їх просто словами « Цей код повільний ». Замість цього ви можете сказати: « Я спостерігав певну затримку у цьому розділі коду під час пікового використання. Можливо, буде корисно дослідити потенційні оптимізації, пов’ язані з запитами бази даних або стратегіями кешування.” Надання контексту - * коли * з’ являється проблема - додає значної ясності і демонструє більш докладне розуміння. Крім того, такі фрази, як «було б добре» або «ми повинні розглянути» є кращими, ніж вимоги.

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