Як написати Standup Async Update англійською мовою

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

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

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

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

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

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

** Позначка стану (на шляху / під загрозою / заблоковано) ** — явний, зрозумілий індикатор того, чи виконується завдання за планом, що надає змогу членам команди швидко переглянути багато оновлень без прочитання кожного рядка. “Статус: під загрозою. Задача складніша, ніж очікувалося — я маю чіткіший графік до завтра, але хотів позначити це раніше, ніж здивувати когось в кінцевий термін.»

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

• « Перенесення з вчорашнього дня: скрипт перенесення все ще виконується — недооцінено краї даних, зараз виконано близько 70% ». *

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

• “Вчора: [конкретна завершена робота]. Сьогодні: [конкретна запланована робота]. Блокери: [спеціальна перешкода або відсутня]»
• Статус: на шляху / під загрозою / заблокований — флагування рано, щоб не було сюрпризу пізніше
• Процитовано 2014-08-11.  «Carryover from yesterday’s update: still working on X, here’s the current state»
• «Заблоковано на [конкретній особі/команді] для [конкретної речі] — слідкуйте за [коли]»
• «Ніяких блокувань наразі, але флагування залежності на X приземлення, перш ніж я можу почати Y.»

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

Ясне, специфічне асинхронне оновлення:

• “Вчора: відправили середнє програмне забезпечення обмеження швидкості і отримали його після перегляду. Сьогодні: початок роботи з логікою повторних спроб для SDK клієнта. Блокери: ні. Статус: на шляху до четвертого демо. *

Позначити блокування з чітким запитом:

• “Блокер: мені потрібен оновлений контракт API від команди мобільних додатків, щоб завершити розробку схеми відповідей. Pinged them yesterday, no response yet — will escalate in standup channel if I don’t hear back to the end of the day. *

Звіт про перенесення:

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

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

• Зберігайте структуру yesterday/today/blockers у конкретному вигляді, а не у загальному — « працював над можливістю » не повідомляє віддаленому співробітнику нічого корисного; « завершив логіку перевірки, починаючи з обробки помилок » це робить.
• Назвіть блокувальника з вказівкою, хто або що має робити — нечітке « блокований » без вказання залежності залишає членів команди у невідомості щодо того, чи можуть вони допомогти.
• Використовуйте ** позначку стану **, якщо щось піддається ризику, замість того, щоб чекати до кінця терміну, щоб здивувати всіх — рано позначати завжди краще, ніж пізно.
• Підтверджуйте ** перенесення ** чесно, замість того, щоб тихо переписувати вчорашнє завдання, ніби воно було новим — це створює довіру до ваших оновлень і надає вашим колегам з команди точний огляд поточного стану справ.

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

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

Наприклад, англійська мова не є офіційною мовою, оскільки англійська мова не є офіційною мовою

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

Однією з найчастіших перешкод є вираз що вас блокує. Замість простого « заблоковано », яке може здатися пасивним і нецікавим, спробуйте такі фрази, як « Зараз розслідується проблема з інтеграцією API — очікується відповідь від команди сервера » або « Мене заблоковано, оскільки я очікую на роз’ яснення щодо схеми даних; я звернувся до Сари за допомогою ». Ключовим є те, щоб * показати *, що ви активно вирішуєте проблему блокування. Аналогічно, коли ви описуєте свій прогрес, не обмежуйтеся лише словами « завершено », а додайте детальну інформацію. Сказати «Успішно реалізовано поток автентифікації користувача згідно зі специфікаціями проекту» демонструє більш ретельне розуміння і зобов’язання, ніж просто «завершено автентифікацію»

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

Не бійтеся трохи більш формального виразування, коли це потрібно, особливо у перегляді коду. Замість « Це виглядає дивно », подумайте про « Я помітив невідповідність з логікою перевірки даних; чи могли б ви розібратися у запланованій поведінці? » Використання таких фраз, як « Щодо … » або « Щодо … » може додати шар професіоналізму і продемонструвати, що ви підходите до зворотного зв’ язку конструктивно. Пам’ ятайте, що чіткість є найважливішою — навіть якщо це означає невелику зміну вашої фрази, щоб забезпечити ефективне сприйняття вашого повідомлення вашою командою. Будівництво впевненості приходить з практикою; не вагайтеся запитати про пояснення, коли це потрібно - більшість команд цінують когось, хто активно шукає розуміння.