Як робити ефективні записки на зустрічі англійською мовою

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

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

** Захоплення рішень, а не обговорення ** — записувати те, що було вирішено, а не намагатися переписати дебати, які призвели до цього, оскільки дебати рідко потрібні пізніше. “Я зосередився на прийнятті рішень, а не на обговоренні — я пропустив більшу частину п’ятнадцятихвилинних дебатів про кешування і просто написав ‘Рішення: використовувати Redis, а не Memcached.’”

** Призначення власника кожному елементу дії ** — зауважте, хто відповідає за виконання кожного наступного завдання, оскільки елемент дії без власника легко перетворити на завдання, яке буде виконано кимось іншим. *“Я переконався, що кожен елемент дії має власника: « Оновити документацію API — [назва], до п’ ятниці », а не просто « Оновити документацію API. » *”

** Використання послідовного скорочення ** — розробка невеликого, повторюваного набору скорочень (наприклад, « AI » для елемента дії, « TBD » для « має бути вирішено »), щоб ви могли швидко писати без втрати ясності пізніше. “Я використовував послідовні скорочення: AI = пункт дії, TBD = буде вирішено,? = відкрите питання — щоб я міг писати швидко і все ще читати його чітко.”

** Позначити те, що ви пропустили ** — позначте місце, де ви не змогли чітко зрозуміти щось, щоб ви могли продовжити, а не вгадати і написати щось неточне. “Я позначив те, що я пропустив, [??] поряд з ім’ям, яке я не вхопив — краще позначити прогалини, ніж записати припущення.”

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

• «Рішення: [що було вирішено].»
• « Елемент дії: [задача] — власник: [назва], термін виконання: [дата]. »
• «Відкрите питання: [що ще не вирішено]»
• «[??] — не впізнав цього, потрібно підтвердити.»
• «Парковка: [тема піднята, але не обговорюється зараз]»

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

Блок нотаток з послідовною структурою:

• “Рішення: рухатися вперед з поетапним розгортанням, а не повним переходом. AI: [ім’я] має розробити план до середи. AI: [назва] для повідомлення команди підтримки перед початком фази 1. Відкрите питання: чи нам потрібно вікно повернення між фазами? — TBD, перегляньте наступного тижня

Позначити те, що ви не впізнали повністю: ”[??] згадав вимогу згідно з законом — не зрозумів деталей, потрібно зв’ язатися з [ім’ я] після виклику.”

Використання парковки для нетематичних елементів: “Парковка: хтось підняв ідею зміни постачальників CI — не пов’язане з сьогоднішньою програмою, запрацює для окремої дискусії.”

Після цього надсилання чистого резюме з необроблених нотаток:

• “Поділився моїми нотатами з сьогоднішнього дзвінка — будь ласка, виправте, якщо я щось неправильно написав. Ключове рішення: [X]. Елементи дій: [список з власниками і датами]. Одне відкрите питання все ще потребує відповіді: [Y].”*

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

• Приоритетувати ** рішення і дії ** перед самою дискусією — ви майже завжди можете пропустити дебати і просто зафіксувати, де вони завершилися.
• Ніколи не залишайте елемент дії без ** власника ** — навіть « ТБД, потрібно призначити » є більш корисним, ніж завдання, яке плаває без назви.
• Зробіть власну послідовну абревіатуру (AI, TBD,??) і використовуйте її щоразу — послідовність має більше значення, ніж те, які конкретні абревіатури ви виберете.
• ** Позначте прогалини чесно **, а не вгадуйте — позначений прогалину, який ви перевірите пізніше, набагато краще, ніж впевнено неправильна нота.
• Незабаром після закінчення зустрічі поширюйте ваші нотатки і просіть про поправки — це допоможе вам виявити ваші власні помилки і збільшити довіру до ваших нотаток.

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

1. Вправи з написання рядків « Рішення » і « Дія » для гіпотетичного результату зустрічі.
2. Створіть власну клавішу скорочень з принаймні чотирма скороченнями, які ви будете використовувати.
3. Напишіть одне речення про те, що ви не зрозуміли на зустрічі.

Національна мова: мова, що не є рідною для населення

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

Однією з найчастіших перешкод є розуміння запитів на зворотний зв’язок. Замість простого запису « Переглянути код », більш корисною заміткою може бути « Перегляд запитів: PR # 1234 — Розв’ язання потенційних проблем з продуктивністю у модулі розпізнавання ». Ця фраза негайно надає контекст — це запит на звантаження, у ньому міститься певне число (посилання), і підсвічується причина перегляду. Аналогічно, коли хтось каже: «Ви можете подивитися на це?», Це часто маскує очікування детальної оцінки. Краще було б написати: « Очікуємо відгуку щодо PR # 5678 — Потрібно роз’ яснення щодо інтеграції з попередньою системою ». Зверніть увагу на такі дієслова, як « очікуємо » і « запитуємо » — вони демонструють більш формальний і свідомо обдуманий підхід, який є ключовим для професійного спілкування.

Інша область, де виникає плутанина, це навколо елементів дій. Рідні носії часто використовують такі фрази, як «Давайте зробимо це» або «Дійте відповідно до цього» без явного зазначення * хто * відповідальний або * коли *. Хорошою нотаткою буде: « Елемент дії: Сара має дослідити проблеми з швидкістю запиту бази даних, які було виявлено під час зустрічі. Термін виконання: кінець наступного тижня. ” Цей рівень деталізації — призначення власника і встановлення часових рамок — є критичним для підзвітності. Ви також можете спостерігати за тим, як носії рідної мови приймають рішення; замість того, щоб сказати « Ми вирішили рухатися вперед », вони можуть записати « Рішення: Продовжити реалізацію нової кінцевої точки API відповідно до технічних специфікацій, описаних у документі XYZ. » Завжди намагайтеся зафіксувати * результат * обговорення і зв’ язати його з відповідною документацією або попередніми розмовами.

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