Як давати зворотній зв'язок, який відкидає дизайн-документ англійською мовою

Відхилення документації з проектування є справді незручним елементом зворотнього зв’ язку, оскільки нечітка несхвалення (« Я маю певні сумніви ») залишає автора нездатним діяти, в той час як чітка несхвалення може бути прочитана як відкидання справжніх зусиль. Словниковий запас тут має бути конкретним і прямим, залишаючи автору чіткий, шанобливий шлях уперед.

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

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

• “У мене є одна проблема: у проекті передбачено доступ до цієї таблиці з одним записом, але у нас вже є дві служби, які одночасно записують до неї. Все інше в документі читається добре, але це потрібно вирішити, перш ніж ми продовжимо.»*

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

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

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

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

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

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

Звичайні фрази

• «У мене є блокуюча проблема, відокремлена від пропозицій нижче, яку, на мою думку, потрібно вирішити, перш ніж це рухається вперед»
• «Є неадресований режим невдачі, який я хочу позначити: що станеться, якщо [спеціальний сценарій]?»
• «Я не бачу альтернативи, розглянутої для [спеціфічного підходу] — чи було це оцінено?»
• «Щоб ясно розуміти шлях вперед: [конкретний, обмежений наступний крок]»
• «Це в цілому сильна робота, і занепокоєння є конкретним і адресованим, а не відкиданням основного підходу»

Приклади висловлювань

Відкриття відмови без зниження мотивації:

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

Назва конкретного прогалини, а не нечіткий заперечення:

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

Закінчення з обмеженим, дійсним шляхом вперед:

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

Професійні поради

• Відокремте справжню ** проблему блокування ** від необов’ язкових пропозицій, ідеально, у власному розділі з відповідною міткою — захоронення справжнього блокування серед десятка незначних коментарів означає, що автор може не усвідомити, який зворотній зв’ язок дійсно потрібний, перш ніж продовжити роботу.
• Назвіть будь- який незареєстрований режим невдачі як конкретний сценарій, а не загальний коментар «а що щодо краєвих випадків» — конкретний сценарій дає автору щось, що дійсно досліджувати і відповідати, де нечітке запитання просто виробляє тривогу.
• Запитайте про альтернативу, яку не розглядають як справжнє питання, а не як неявну критику — автор, можливо, вже виключив це питання з добрих причин, які просто не потрапили до документації, і формулювання цього питання запрошує до цього контексту, а не ставить їх у оборону.
• Завжди закривати з явним ** шляхом вперед ** — відхилення без наступного кроку читається як безвихідна ситуація, тоді як обсяг, конкретний шлях вперед переформулює те ж саме зворотне зв’ язок як вирішувану проблему, а не відступ.
• Визнайте справжні сильні сторони в документації конкретно, а не як загальний пом’якшувач - конкретна похвала (“аналіз режиму невдачі в розділі 3 є ретельним”) є більш правдоподібним і більш корисним, ніж загальна “хороша робота” перед тим, як доставити зауваження.

Практичні вправи

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

Національні мови: мова рідних, мова нерідних

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

Однією з ключових областей є використання точної мови при описі того, що не працює. Замість того, щоб сказати « Це не добре », що звучить неоднозначно, спробуйте такі фрази, як « Поточна архітектура має деякі проблеми з масштабованістю » або « З точки зору підтримки, складність може викликати ризики ». Зауважте додавання технічних термінів — « масштабованість », « підтримка », « складність » — ці терміни часто використовуються у дискусіях щодо проектування і демонструють, що ви глибоко розглянули проблему. Іншою корисною тактикою є створення вашого зворотного зв’ язку навколо * потенційних * проблем, а не заява про них як про абсолютну правду. « Можливо, що цей підхід може призвести до … » надає дизайнеру простір для розгляду альтернативних рішень. Аналогічно, уникайте висловлювання, яке може призвести до суджень, на зразок « Це погана ідея ». Замість цього ви можете сказати: « Я хвилююся щодо потенційного впливу на швидкість роботи цієї конкретної реалізації; можливо, ми могли б розглянути [альтернативну пропозицію] »

Крім того, важливо визнати будь-які позитивні аспекти дизайну, перш ніж піднімати занепокоєння. Початок з « Я ціную зусилля, вкладені у створення цієї системи » або « Початкова діаграма чітко ілюструє основні компоненти » демонструє повагу і встановлює тон співпраці. Це зменшує удар і показує, що ви будуєте на їхній роботі, а не просто розбираєте її. Пам’ ятайте, що у розмовах Slack важлива короткість, але також і точність. Довга, нерозбірлива критика може бути приголомшливою. Створення коротких повідомлень з ретельно обраними словами значно поліпшить розуміння.

І нарешті, завжди пропонуйте чітку пропозицію щодо подальшого розвитку. Не просто вказуйте на проблеми; пропонуйте рішення. « Чи можемо ми дослідити використання [технології/ шаблону], щоб вирішити це?» або « Можливо, ми можемо перебудувати цей модуль на менші, більш керовані одиниці? » надає практичні рекомендації. Завершення відкритим питанням — «Які у вас думки щодо…» — заохочує діалог і співпрацю, а не остаточне відхилення. Пам’ ятайте, мета не просто відкинути; це допомогти вдосконалити дизайн до кращого результату.