How to Give Feedback on a Failed Deployment in English
Вивчіть англійські фрази для конструктивного обговорення невдалого розгортання, незалежно від того, надсилаєте ви або отримуєте зворотній зв’ язок.
Неуспішне розгортання є достатньо стресовим без зворотного зв’ язку, який відчувається як звинувачення, тому формулювання навколо нього має таке ж значення, як і технічні факти — мета полягає у розумінні того, що сталося і запобіганні повторення, а не в приписуванні вини людині.
Розв’язувати проблеми спокійно
Відкрийте розмову фактично, без тривоги або звинувачення.
- «Розгортання цього ранку спричинило проблему з оплатою — я хочу пройти через те, що сталося, не приписувати провину, але щоб ми могли зрозуміти це разом»
- “Я помітив, що щось пішло не так з останнім релізом. Чи є у вас кілька хвилин, щоб пройти через це разом?»
- «Це не про вказування пальцями — я просто хочу зрозуміти послідовність подій, щоб ми могли запобігти цьому наступного разу»
Запитання про послідовність подій
Перед тем, как делать выводы, отремонтируйте, что произошло.
- «Проведи мене через те, що сталося, крок за кроком, з твоїх позицій»
- Чи це було виявлено нашим власним моніторингом, чи клієнт повідомив про це першим?»
- «У який момент стало зрозуміло, що щось не так, і що ви зробили, коли це помітили?»
Відповідь без покарання
Сфокусуйтесь на системі і процесі, а не на компетентності людини.
- «Я не думаю, що це була помилка з вашої сторони, особливо — це виглядає як прогалина в нашому процесі перегляду, який дозволив це зробити»
- «Це саме те, що наші тести повинні були виявити — це прогалина в нашому тестовому покритті, а не відображення вашої роботи»
- «Я хочу бути ясним: мета тут не в тому, щоб когось виокремити, а в тому, щоб з’ясувати, які зміни б запобігли цьому»
Отримання зворотнього зв’язку про власне розгортання
Відповідай професійно, якщо ти той, чиє розгортання спричинило проблему.
- “Я вдячний, що ти принесла це мені прямо. Ось що, на мою думку, сталося, і ось що, на мою думку, ми повинні змінити»
- «Я беру на себе відповідальність за те, що я пропустив це — я б хотів запропонувати конкретну зміну процесу, щоб це не повторилося»
- “Дякую, що ви були прямими в цьому питанні. Я хочу переконатися, що ми звернемося до кореневої причини, а не тільки до цього одного випадку»
Прийняття рішень щодо заходів попередження
Закрий, погодившись на те, що зміниться в результаті.
- «Ідучи вперед, я думаю, що ми повинні додати вручну крок схвалення для змін до цієї конкретної служби»
- «Додамо конкретний тестовий випадок для цього сценарію, щоб він автоматично був виявлений перед наступним розгортанням»
- «Я задокументую це як вивчений урок і поділлюся ним з більшою командою, щоб інші могли уникнути тієї ж проблеми»
Словник-довідник
| Term | Meaning |
|---|---|
| Deployment | The process of releasing new code to a live environment |
| Root cause | The underlying factor that led to a problem, distinct from its symptoms |
| Take responsibility | To acknowledge one’s role in an outcome without excessive self-blame |
| Process gap | A missing safeguard or step in a workflow that allowed an issue through |
| Lesson learned | A documented insight from an incident intended to prevent recurrence |
Ключеві моменти
- Піднімайте питання про невдале розгортання спокійно і фактично, чітко визначаючи розмову як не-звинувачувальну.
- Відтворити послідовність подій перед тим, як робити висновки про те, що пішло не так.
- Рамки зворотного зв’язку навколо процесу або системних прогалин, а не компетентності особи.
- Якщо ви отримуєте відгук, підтверджуйте його прямо і пропонуйте конкретне рішення, а не захоплюйте оборонну позицію.
- Закрийте, погодившись на конкретні заходи по запобіганню, і поділіться вивченим уроком з більшою командою.
Національна мова: мова, що не є рідною для населення
Будьмо чесними - навіть досвідчені розробники іноді стикаються з розчаруванням ситуацій, таких як невдача розгортання. Ключ не просто в тому, щоб визначити, що не так, а в тому, щоб ефективно і конструктивно про це повідомити. Для тих, хто вивчає професійну англійську, тонкощі фразування можуть бути особливо викликом. Це не просто про те, щоб сформулювати проблему; це про те, щоб зробити це таким чином, що запрошує співпрацю і уникнути звинувачення. Поширеною пасткою є використання надто прямої мови, наприклад, «Ви зламали його!», Що негайно створює оборону. Замість цього, зосередження уваги на впливі проблеми і запропонування рішень є набагато продуктивнішим.
Однією з областей, де багато розробників борються, є обробка спостережень навколо технічних деталей. Замість того, щоб сказати « Спроба з’ єднання з базою даних зазнала невдачі », розгляньте можливість написання повідомлення у вигляді « Ми спостерігали періодичні проблеми з’ єднання з основним сервером бази даних під час вікна розгортання. Це призвело до [спеціфічного наслідку, наприклад, ‘15-хвилинний відключення для користувачів, що отримують доступ до панелі звітів’].” Зауважте, як ми змінили фокус від простого повідомлення про помилку до спостереження з контекстом і вимірюваним впливом. Аналогічно, при перегляді запитів на витягування, замість простого написання «Це не працює», спробуйте «Я помітив, що інтеграція з Сервісом X не працює так, як очікувалося. Чи можемо ми дослідити потенційний конфлікт між поточним реалізуванням і документацією API?» Останнє запрошує обговорення про основну причину, а не відразу вказувати пальцем на помилку.
Інша часто неправильно розуміна область - це виражати занепокоєння без звучання обвинувачуючої. Фрази на кшталт «Здається…» або «Я переживаю, що…» є неймовірно корисними. Вони пом’якшують доставку потенційно критичного зворотного зв’язку. Наприклад, повідомлення Slack після проблеми з розгортанням може звучати так: «Я хвилююся, що ми пережили несподівані перерви під час розгортання. Давайте переглянемо журнали, щоб зрозуміти, що спричинило це і запобігти тому, щоб це трапилося знову. “Це демонструє активне залучення, а не пасивну критику. Пам’ятайте, ваша мета - це спільне вирішення проблеми, а не перекласти провину.
І нарешті, завжди віддавайте перевагу ясній, короткій мові. Уникайте жаргону, який може бути незнайомим для інших членів команди. Якщо вам доведеться використовувати технічні терміни, коротко поясніть їх, наприклад, « Ми пережили тимчасовий перевищення часу очікування мережі, яке іноді може трапитися під час масштабування наших серверів ». Таким чином ви продемонструєте професіоналізм і переконаєтеся, що всі розуміють, що відбувається. Сфокусування на конкретних діях, таких як «Давайте розглянемо журнали помилок» або «Чи можемо ми запланувати коротку зустріч, щоб обговорити це?», Надає конкретні кроки вперед, а не нечітку критику.