Англійська мова для інженерних комунікацій
Необхідні фрази для інженерних менеджерів і технічних лідерів: встановлення очікувань, каскадні рішення, власні результати, вирівнювання за пріоритетами і ескалація з впевненістю.
Коли ви переходите від окремого співробітника до технічного керівника або інженерного менеджера, мова, яка вам потрібна, значно змінюється. Ви більше не просто пояснюєте, що ви створили — ви встановлюєте очікування, вирівнюєте свою команду навколо рішень, даєте зворотній зв’ язок і ескалаціюєте блокування. В англомовному середовищі конкретні фрази, які ви використовуєте, мають справжній вагу. Неясна мова призводить до невідповідності; точна мова лідерства створює ясність і підзвітність. Ця стаття містить ключові фрази, які потрібні кожному інженерному лідеру.
Ключові фрази
Встановлення очікувань:
- Я хочу поставити чіткі очікування для цього спринту»
- «Що мені потрібно від вас, так це проектний документ до четвертого і робочий прототип до кінця місяця»
- Успіх тут виглядає так: функція знаходиться за функціональним прапором, повністю перевірена і готова до випуску канарій
- «Дозвольте мені пояснити, що означає «зроблено» для цього завдання»
** Каскадні рішення: **
- Я хочу, щоб це рішення було доведено до команди до кінця дня»
- “Лідерство вирішило призупинити міграцію. Я поясню контекст і те, що це означає для нашої дорожньої карти»
- «Я не приймаю рішення тут — я передаю це вам для реалізації. Ось контекст…»
Блокери зв’язку:
- «Я блокую випуск X, тому що перегляд безпеки не завершений»
- «Я хочу повідомити про блокування: ми не можемо продовжувати без підпису команди даних»
- “Це заблоковано на зовнішній залежності. Я ескалаціюю, щоб отримати його розблокований»
Власні результати:
- “Я хочу, щоб ти був власником цього результату. Це означає визначення критеріїв успіху, відстеження прогресу і підвищення блоків на ранньому етапі»
- «Ви маєте повну автономію на реалізацію — але результат залежить від вас, щоб доставити»
- “Я тримаю вас відповідальними за контракт API, а не за внутрішні деталі реалізації.”
** Вирівнювання за пріоритетами: **
- «Давайте вирівняємо пріоритети, перш ніж ми перейдемо до спринту»
- Яким чином ми можемо оцінити цей успіх і як він позначиться на наших поточних зобов’язаннях?»
- «Я хочу переконатися, що ми вирішуємо правильну проблему, перш ніж ми почнемо будувати»
Ескаляция:
- «Я ескалирую, если мы не примем решения до среды»
- «Це вище мого рівня для вирішення — я ескалаціюю до віце-президента з інженерії»
- Я піднімаю це як ризик на наступному синхроні лідерства
Як це використовувати на практиці
Однією з найважливіших навичок в інженерному лідерському спілкуванні є розрізнення між направленням і делегуванням. Коли ви надсилаєте вказівку, ви маєте бути конкретними: « Мені потрібен договір API, який буде завершено до п’ ятниці ». Коли ви делегуєте, ви передаєте право власності: « Мені потрібен результат, який ви визначите — знайдіть найкращий шлях і принесіть мені всі блоки »
** Встановлення очікувань ** є найпотужнішим, коли ви визначаєте, як виглядає “зроблено”. Замість « будь ласка, працюйте над службою автентифікації », скажіть: « До наступної середи я очікую інтеграцію OAuth2 з тестами модулів і документованим контрактом API. Позначте все, що б це завадило»
** Каскадні рішення ** вимагають від вас відокремлення рішення від контексту. Люди більш схильні підтримувати рішення, які вони розуміють. Скажи: “Лидерство решило отложить выпуск. Причина - X. Для нашей команды это означает Y. Ось як ми будемо коригувати нашу дорожню карту»
Коли ** ескалація **, будьте конкретні про те, що вам потрібно і коли: “Я ескалація це до інженерного директора, якщо ми не маємо рішення до четвертого дня. Ризик затримки відсутній на запуску Q3»
Приклад розмови
** Технічний керівник (Roman): ** “Я хочу чітко визначити очікування щодо цієї можливості. Марта, я хочу, чтобы ты взяла на себя ответственность за этот исход. Успіх виглядає як працююча інтеграція платежу, яка пройшла всі перевірки відповідності і знаходиться за прапорцем можливості. Як виглядає ваша часова лінія?»
** Марта: ** “Я можу зробити початкове впровадження до п’ятниці, але мене заблокували на реєстраційних даних Stripe sandbox.”
“Я понимаю. Я передаю это в DevOps сейчас - мне нужны эти реквизиты к среде или мы рискуем пятьдесят дней. Давайте вирівняємо пріоритети: чи є інтеграція платежу вашим єдиним фокусом цього тижня, чи є конкуруючі зобов’язання, про які я повинен знати?»
Марта: “Только дежурная ротация во вторник.”
“Зрозумів. Я буду каскадувати оновлену хронологію до команди, щоб кожен знав, де ми стоїмо»
Практичні поради
-
** Переписати нечіткі інструкції як чіткі очікування: ** Візьміть нечіткий опис завдання, наприклад, « Чи можете ви розглянути проблему з швидкодією?», і перепишіть його як чітке очікування за допомогою фраз з цього повідомлення. Включити визначення виконано, термін виконання і заяву про право власності.
-
** Вправлятися зі сценарієм ескалації: ** Напишіть повідомлення про ескалацію з двох речень для вигаданого блокувальника. У ній має бути вказано: що було заблоковано, що станеться, якщо не буде вирішено проблему, і коли вам слід буде прийняти рішення. Читайте вголос, поки не станете відчувати себе природно і впевнено, а не вибачаючись.
-
** Слухайте мову лідерства у подкастах: ** Подкасти з інженерного лідерства (наприклад, « Лідер інженерії », « Подкаст Ленні » або « Інструменти менеджера ») повні прикладів цих фраз у контексті, які використовують носії рідної мови. Слухайте конкретні слова, що використовуються навколо відповідальності, пріоритетів і ескалації - не тільки ідеї, але й точне формулювання.
Словник мови: для немовлят
Багато інженерів, які переходять на лідерські ролі - або просто прагнуть вдосконалити свої комунікаційні навички - знаходять себе в боротьбі не тільки з * що * сказати, але і * як * сказати це ефективно англійською мовою. Окрім розуміння основних концепцій чітких і коротких повідомлень, ключовим елементом є оволодіння специфічним словником, пов’ язаним з професійними настройками, особливо при роботі з технічними обговореннями і зворотнім зв’ язком. Це не просто переклад з вашої рідної мови; це прийняття нюансованої фрази, яка сигналізує про авторитет, співпрацю і прихильність до якості в інженерній команді. Поширена пастка для носіїв мови, яка не є рідною, це за замовчуванням надто буквальні переклади, які можуть звучати незграбно, неясно або навіть ненавмисно відкидаючими. Давайте розглянемо деякі ключові області, де цілевказаний словник робить значну різницю.
Однією з областей, які часто ігноруються, є точна мова, використана при наданні зворотнього зв’язку - особливо під час перегляду коду. Замість того, щоб сказати щось на зразок «Цей код потребує поліпшення», що відчувається дещо нечітким і потенційно критичним, розгляньте можливість формулювання його як «Я бачу можливість тут, щоб поліпшити продуктивність цієї функції. Чи можемо ми розглянути використання [спеціальної техніки], щоб розв’язати потенційне вузьке місце?” Зверніть увагу на зміну тону: він зосереджений на співпраці можливості, а не на прямій критиці. Аналогічно, коли ви описуєте зміни у запиті на звантаження, не вказуйте просто « Виправлено помилку ». Ефективнішим підходом буде « Цей запит на звантаження стосується проблеми # 1234, яка спричинила [короткий опис проблеми]. Виправлення використовує [спеціальний метод], щоб забезпечити функціональність залишається надійним і відповідає нашим стандартам кодування. ” Використання таких термінів, як « адреса », « надійний », і посилання на існуючі проблеми (наприклад, використовуючи номер квитка) демонструє знайомство з процесом розробки і створює впевненість.
Крім того, оволодіння фразами, пов’язаними з пріоритетом, є життєво важливим для інженерного лідера. Вираз « Ми повинні зробити це » не має жодного впливу; замість цього спробуйте « Давайте визначимо пріоритет цієї можливості на основі її відповідності нашій дорожній карті на 3 квартал і очікуваного впливу на користувачів ». Або, під час обговорення залежностей: « Зважаючи на поточні обмеження у часі, нам слід переконатися, що завершення роботи над цим компонентом не перешкоджає прогресу [залежного завдання]. » Ці фрази демонструють стратегічний підхід і розуміння більш широкого контексту проекту. Нарешті, пам’ ятайте, що активне слухання і пояснювальні запитання є безцінними — не вагайтеся ввічливо попросити про пояснення, якщо ви зустрінете незнайому термінологію або фразу. « Чи можете ви розібратися, що ви маєте на увазі під « технічним боргом » у цьому контексті? » є цілком прийнятним і показує справжнє залучення. Сфокусування на створенні словника навколо цих ключових областей значно поліпшить вашу здатність ефективно і впевнено робити внесок у роль інженерного лідерства.