Розробник може читати документацію без перекладача, дивитися технічні доповіді й роками працювати з англомовними інтерфейсами. Потім на дзвінку його просять пояснити, чому завданьа займе не два дні, а п’ять, і звична впевненість кудись зникає.
Термін dependency він знає. Слово estimate теж. Складність не в перекладі окремих понять, а в тому, щоб швидко побудувати аргумент, перевірити реакцію співрозмовника й не погодитися з нереалістичним строком надто різко.
Саме тому сильне читання технічної англійської не завжди переходить у сильну робочу комунікацію. Це пов’язані, але не однакові навички.
IT уже давно не складається лише з коду
Навіть фахівець без менеджерської посади постійно пояснює рішення іншим людям. Він пише опис завдання, уточнює вимоги, коментує pull request, повідомляє про ризик, бере участь у плануванні й відповідає на питання під час демо.
Чим старша роль, тим більша частина роботи відбувається через мову. Senior інженер не просто виконує складніші завдання. Від нього очікують, що він допоможе команді зрозуміти компроміс, попередить проблему та пояснить технічне рішення людям із різним рівнем підготовки.
Тимлід або архітектор може витрачати на комунікацію більше часу, ніж на написання коду. Перехід до такої ролі іноді впирається не у знання технології, а в здатність зробити власне мислення зрозумілим для інших.
Стендап перевіряє не словник, а стислість
На щоденному стендапі потрібно коротко відповісти на кілька передбачуваних питань: що зроблено, що буде далі, чи є блокери.
Здається, це найпростіший формат. Проте саме тут людина може загубитися в деталях, почати переказувати весь процес або, навпаки, сказати так мало, що команда не зрозуміє ризик.
Слабкий звіт:
Yesterday I worked on the payment task. There were some problems, and I tried several things. Today I will continue.
Тут є слова, але немає корисної інформації.
Точніше:
Yesterday I completed the payment API integration. The remaining blocker is an authentication error in the sandbox. I’m checking it with the provider today, so the task may move to Thursday.
Різниця не в складнішій граматиці. Другий варіант називає результат, проблему, дію та можливий вплив на строк.
Таку структуру можна відпрацювати до автоматизму. Після цього стендап забирає менше мовного ресурсу, а увага залишається на змісті.
Code review вимагає точного тону
Письмовий коментар до коду легко зробити надто прямим:
This is wrong. Change it.
Автор може мати на увазі лише технічну помилку. Колега читає оцінку своєї роботи й, можливо, власної компетентності.
Надмірна м’якість теж не допомагає:
Maybe it might perhaps be better to consider another option.
Незрозуміло, це обов’язкова зміна чи необов’язкова думка.
Корисно розділяти тип коментаря. Десь є помилка, яку потрібно виправити. Десь питання. Десь пропозиція, від якої можна відмовитися.
Наприклад:
This can return null when the user has no active subscription. Could we handle that case here?
Suggestion: extracting this logic into a separate function would make it easier to test.
Blocking issue: this query exposes data from other accounts.
Такий коментар пояснює причину й силу вимоги. Команда витрачає менше часу на здогадки про те, що мав на увазі автор.
Уточнення вимог є мовною, а не лише аналітичною навичкою
Багато проблем починаються не в розробці, а в момент, коли команда вирішила, що вже зрозуміла завданьу.
Фраза клієнта The page should load quickly не містить критерію. Наскільки швидко? Для яких користувачів? На якому пристрої? За якої кількості даних?
Інженерові потрібно перетворити загальне бажання на перевірювану умову:
What response time would be acceptable for the first release?
Should we optimise for mobile connections as well?
How many concurrent users do you expect at peak time?
Знати термінологію тут недостатньо. Потрібно не боятися ставити питання, які можуть показати, що вимога ще не готова до оцінювання.
Іноді слабша англійська підштовхує людину погодитися раніше, ніж вона все зрозуміла. Кивнути на дзвінку простіше, ніж зупинити розмову й уточнити незручну деталь. Через кілька днів ця ввічливість повертається у вигляді переробки.
Пояснити строк важче, ніж назвати число
Клієнт питає, чи можна завершити завданьу до п’ятниці. Відповідь No, it’s impossible звучить жорстко й не дає альтернативи. We’ll try може створити очікування, якого команда не здатна виконати.
Професійна відповідь пояснює обмеження й вибір:
Friday is not realistic because the change affects the billing flow and requires regression testing. We can deliver the core functionality by Friday and complete the full release on Tuesday.
Тут англійська працює як інструмент переговорів. Інженер не просто відмовляє. Він показує причину, ризик і можливий компроміс.
Такі ситуації важливіші для кар’єри, ніж знання ще двадцяти назв елементів інтерфейсу. Технічні терміни часто підказує сама робота. Аргументувати строк вона автоматично не навчить.
Документація та жива розмова розвиваються нерівномірно
Читання є відносно комфортною навичкою. Людина сама визначає темп, повертається до попереднього абзацу, бачить код і контекст. Через кілька років роботи її пасивний словник може бути дуже широким.
Говоріння потребує іншого типу доступу до мови. Слова мають з’являтися швидко, а речення формуються ще до того, як думка повністю завершена.
Тому фахівець може розуміти складну архітектурну статтю й водночас користуватися дуже простими фразами на зустрічі. Це не дивна суперечність і не доказ, що попереднє навчання було марним. Просто одна навичка отримувала щоденну практику, а інша майже ні.
Виправляється цей розрив не повторним читанням документації, а регулярним говорінням у знайомих професійних ситуаціях.
Які сценарії дають найбільше користі
Програма для IT фахівця має враховувати загальний рівень, але практика може будуватися навколо реальної роботи:
- короткий статус на стендапі;
- опис блокера;
- уточнення вимог;
- оцінка строку;
- code review;
- пояснення технічного рішення нетехнічній людині;
- демонстрація функції;
- повідомлення про помилку або затримку;
- незгода з колегою;
- співбесіда й обговорення досвіду.
Саме так працює прицільна англійська для айтівців: загальна мовна база розвивається через ситуації, у яких фахівець уже працює або планує працювати.
Це не означає, що кожному розробникові потрібен окремий вузький курс із першого дня. Початківцеві спершу може бракувати загальної граматики й базового словника. Але після появи основи універсальні побутові теми дають дедалі менше віддачі, якщо головні труднощі виникають на робочих зустрічах.
Різниця між інженером, який розуміє англійську, та інженером, якому довіряють комунікацію, з’являється в маленьких діях. Він вчасно уточнює, не ховає ризик за словом maybe, пояснює компроміс і завершує розмову зрозумілим наступним кроком.
Саме ці дії й потрібно тренувати. Код, на відміну від людей, рідко ображається на невдалий тон і майже ніколи не просить пояснити дедлайн ще раз.