Англійські фрази для інженерних підйомів
Освоєння англійських фраз для щоденних виступів: «Я зараз працюю над... », «Мій блокер —... », «Мені потрібна допомога з... », «Я підніму... » і багато іншого.
Щоденне стійке мовлення є ключовим елементом гнучких інженерних команд. Він короткий, фокусований і має передбачувану структуру, що робить його чудовою можливістю для створення навичок англійської комунікації. Але навіть у знайомому форматі, носії, які не є рідними носіїв, часто відчувають невпевненість у правильному фразуванні. Цей посібник дає вам природні, професійні англійські фрази для кожної частини стендап-комедії.
Три класичні питання
Більшість виступів організовані навколо трьох питань:
- Над чим ти працював вчора?
- Над чим ти працюєш сьогодні?
- У вас есть блокаторы?
Деякі команди додають четверте питання: « Що ви збираєтеся дізнатися далі? » Давайте розглянемо кожне з них докладніше.
Про вчорашнє слово
Використовуйте ** простий минулий час ** для опису завершеної роботи.
** Основні фрази: **
- “Вчора я працював над переробкою автентифікації.” *
- « Я завершив скрипт міграції бази даних. » *
- “Я переглянув три запити на завантаження і залишив коментарі.” * “Я провів більшу частину вчорашнього дня, розслідуючи витік пам’яті в службі працівників.”
Когда ты не закончил что-то:
“Я працював над реалізацією обмеження швидкості API — це триває довше, ніж очікувалося. Я продовжу сьогодні.»
- “Я пройшов через частину тестових поліпшень покриття. Все ще в процесі».*
** Коли ви брали участь у зустрічах або виконували роботу, що не стосується програмування: **
- “Вчора було переважно зустрічі — сесія планування спринту і два перегляди дизайну. Я буду кодувати сьогодні.»* “Я провів цілий день над документацією для нового потоку вступу.”
Програма дій на сьогодні
Використовуйте ** теперішній постійний ** або ** майбутній** час.
** Основні фрази: **
“Сегодня я работаю над интеграцией платежей.” “Я завершу тестування пристроїв для служби замовлень.”
- “Моя сьогоднішня увага зосереджена на проблемі швидкодії в кінцевій точці пошуку.” *
- « Я підбираю завдання для служби сповіщень — воно вже деякий час перебуває у списку очікування. » *
** Вказівка завдань: **
- “Сегодня я работаю над двумя вещами: обновлением схемы базы данных и пересмотром кода для PR Лоры.” * “Я буду работать с Маркусом над вопросом о распределении.”
** Коли ваш план непевний: **
“Це залежить від того, як швидко я зможу розв’ язати блокування, але в ідеалі я почну з інтеграції фронт-енду сьогодні післяобідню.”
Блокування повідомлень
** Блокер ** (або перешкода) це все, що перешкоджає вам досягти прогресу. Будь ласка, вкажіть, що таке блокування і, якщо це відомо, яка допомога вам потрібна.
** Звіт про блокування: **
- « У мене є блокувальник: я чекаю доступу до журналів виробництва, щоб розслідувати ваду. » * “Мій блокувальник залежить від API команди з платежу — він ще не готовий.” *“Я заблокирован в решении по дизайну. Мені потрібна п’ятнадцятихвилинна розмова з кимось, щоб розблокувати мене»
** Коли у вас немає блокера: **
“Без блокаторов на моей стороне.” “Ніщо мене сьогодні не блокує.” “Я разблокирован и делаю хороший прогресс.”
** Коли щось сповільнює вас, але не повністю блокує: **
“У мене немає жорсткого блоку, але я рухаюся повільно — застарілий код складніший, ніж очікувалося.”
- “Мені б знадобилася друга пара очей на дизайні схеми бази даних у якийсь момент сьогодні.” *
Прохання про допомогу
Вставай, это момент, когда ты сигнализируешь, что тебе нужна помощь. Будь прямим, але коротким — детальна дискусія відбувається після виступу або асинхронно.
- « Мені потрібна допомога з налаштуванням Terraform — чи не міг би хтось подивитися після виступу?» *
- “Чи хтось знайомий з логікою повторних спроб webhook? У мене є питання “Я буду признателен за быструю сеанс парирования сегодня, если кто-нибудь имеет возможность.”
Передача або прийняття роботи
- “Я підніму завдання для панелі звітування про помилки — його було знижено до нижчого пріоритету, але воно буде наступним у моїй черзі.” * “Я передаю документацію API Томові — він буде її брати звідси.” “Я буду забирати квиток на аудит доступності.”
Корисні перехідні та закінчувальні фрази
“Все от меня.” “Це все, що у мене є - ніяких блокаторів.” “Буду рад обсудить блокатор подробнее после выступления, если у кого-нибудь будет время.” “Я надішле оновлення в Slack, якщо щось зміниться.” “Вперед, Прія.” (при переході до наступної людини)
Необхідно уникати помилок
** Перебільшення: ** Стоячи-на-столі - це оновлення статусу, а не обговорення дизайну. Якщо ви помітите, що пояснюєте більше двох-трьох речень, зупиніться і запропонуйте продовжити після зустрічі.
“Я можу згадати більше деталей після шоу, якщо хтось зацікавлений.”
** Використання неправильного часу для завершеної роботи: **
Неправильно: “Сегодня я переглядаю вчорашні запити на завантаження.” Правильно: * “Вчора я переглянув запити на завантаження.” *
** Забув згадати про блокувальники: ** Якщо ви застрягли, скажіть. Встаньте, чтобы выявить блокировщиков на ранней стадии.
Повний приклад Stand-up Update
- “Вчора я працював над логікою оновлення токенів розпізнавання — я завершив реалізацію ядра і об’ єднав його. Сьогодні я пишу інтеграційні тести для нього, а потім беру задачу закінчення сеансу з запізнення. У мене є один блокуючий фактор: мені потрібен хтось з команди безпеки, щоб переглянути підхід до зберігання токенів. Чи є хтось, хто може допомогти з цим сьогодні або завтра?»*
Це охоплює всі три питання чітко, згадує, що має статися далі, і робить конкретний запит на допомогу - менше ніж за 60 секунд.
Стоячий виступ - це проста зустріч, але це зустріч, де чітка англійська говорить про справжню різницю. Послідовні, короткі оновлення будують довіру з вашою командою, рано виявляють блокувальники і демонструють професійні навички спілкування. Фрази з цього підручника допоможуть вам відчувати себе впевнено і підготовлено щоранку.
Наприклад, сліди слідів: пошук і пояснення
Для нерідних носіїв, тонке мистецтво роз’яснення неоднозначності в професійному спілкуванні може відчувати себе особливо викликом. Станд-апи не просто про звіти про прогрес; вони динамічне середовище, де припущення постійно робляться і, можливо, неправильно інтерпретуються. Набагато краще активно вирішувати потенційну плутанину, ніж мовчки боротися з неясним завданням або очікуванням. Поширена пастка полягає в тому, що припускаєш, що всі розуміють обсяг твоїх робіт - завжди, завжди підтверджуйте це розуміння.
Розглянемо сценарій під час перегляду коду. Сара надсилає запит на перетягування для перефакторизації складної функції обробки даних. Рецензент, Марк, залишає коментар: « Це виглядає добре, але ви впевнені, що це обробляє всі краї? » Проста відповідь: « Дякую за відгук, Марк! Я додав спеціальні тести, щоб покрити ці сценарії - див. тестовий набір regression_tests/edge_cases.js ” може бути достатньо, якщо Сара відчуває впевненість. Однак, більш нюансований підхід, особливо коли ви відчуваєте невпевненість, може бути: «Марку, дякую за те, що вказали на це. Для того, щоб упевнитися, що все ясно, чи можете ви розібратися, які конкретні випадки я повинен був розглянути? Я сконцентрировался на первичном потоке данных, но я хочу быть абсолютно тщательным. Можливо, ми могли б коротко проаналізувати їх разом?» Це демонструє активне слухання і бажання вчитися, зменшуючи шанси на переробку пізніше.
Інша поширена ситуація виникає в розмовах Slack при обговоренні завдань, які були призначені під час стоячих. Уявіть, що вам доручено «дослідити проблеми з продуктивністю» в певному модулі. Без подальшого контексту неможливо знати, які аспекти продуктивності потребують дослідження - чи це затримка? Використання пам’ яті? Завантаження процесора? Відповідь на кшталт: “Гаразд, я розслідую проблеми з продуктивністю в модулі X. Щоб допомогти мені зосередити свої зусилля, чи можете ви пояснити, які конкретні показники ви хотіли б, щоб я контролював (наприклад, час відповіді, виділення пам’ яті)? І чи є якісь відомі вузькі місця або області, які ми повинні приоритизувати?» показує ініціативу і бажання бути ефективним. Пам’ятайте, що запитання прояснюючих питань не є ознакою слабкості; це розумна стратегія для ефективного вирішення проблем.
Нарешті, під час написання описів PR уникайте нечітких вказівок на зразок « Виправлено вади ». Замість цього спробуйте написати щось на зразок: « Врегульовано виправлення проблем, пов’ язаних з неправильною перевіркою даних у модулі розпізнавання користувача (PR # 1234). » Зокрема, було вирішено ситуації, коли неправильні формати електронної пошти не були належним чином відкинуті, і було введено більш надійну перевірку формальних виразів. Ця зміна покращує безпеку, запобігаючи потенційним атакам за допомогою втручання. » Цей рівень деталізації надає цінний контекст для переглядачів і забезпечує, що всі користувачі будуть мати спільну думку щодо внесених змін. Сфокусуйтеся на * тому, що * було виправлено, * як * це було виправлено, і * чому * це важливо - демонструючи чітке розуміння проблеми і вашого рішення.