Cross-Functional Team English: IT Vocabulary for Product Engineers

Introduction

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

Функціонально-семантичний словник

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

“Я провів більшу частину понеділка, вирівнюючи команду мобільного програмування та команду API щодо нового контракту про автентифікацію — вони мали різні припущення щодо терміну дії токена.”

** Містові команди ** — Діяти як зв’ язок комунікації між двома групами, які не регулярно взаємодіють, перекладаючи вимоги, проблеми і контекст, щоб обидві сторони могли ефективно співпрацювати.

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

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

“Команда інтерфейсу чекала на нашу схему API, щоб завершити налаштування їхніх імітаційних даних — я опублікував чернетку специфікації OpenAPI у четвер, щоб розблокувати залежності і дозволити їм рухатися вперед.”

** Координація зусиль ** — для організації і синхронізації роботи декількох людей або команд, щоб паралельні потоки роботи не викликали конфліктів, не дублювали зусиль або не створювали несумісних результатів.

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

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

• “Після двох тижнів без рішення щодо політики зберігання даних, ми були змушені ескалації блокування до віце-президента з інженерії - юридичний перегляд був заблокований і це затримувало весь наш віковий рубіж відповідності.” *

** Сприяння прийняттю рішень ** — Створення умов для прийняття рішення групою, а не самостійне прийняття рішення. Це включає в себе підготовку правильної інформації, чітке формулювання варіантів і керування обговоренням без домінування в ньому.

“Моя робота на цій зустрічі не була вибрати підхід - це було полегшити рішення, представлення компромісів чітко і забезпечити, щоб усі зауваження були почути, перш ніж ми голосували.”

RACI — акронім від Responsible, Accountable, Consulted, and Informed. Матриця RACI є інструментом, який визначає, хто робить роботу, хто володіє результатом, з ким потрібно консультуватися і хто повинен бути інформований про будь-яке задане завдання або рішення.

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

** Карта зацікавлених сторін ** — документ або діаграма, яка визначає всіх людей і команди, які зацікавлені у проекті, їх рівень впливу і тип зв’ язку, який їм потрібен. Він використовується для планування, кого залучати і коли протягом проекту.

“Я склав карту зацікавлених сторін для функції платежів — виявилося, що команда з відповідності повинна була бути проконсультована набагато раніше, ніж ми планували, що зберегло нам значний цикл переробки.”

Для чого потрібна мова?

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

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

Практичні поради

Найефективніші крос-функціональні комунікатори поєднують ці інструменти навмисно. Перед початком нового проекту створіть карту зацікавлених сторін. Перед початком складного потоку роботи створіть RACI. Якщо дві команди не врівноважені, заплануйте фокусований сеанс, щоб вирівняти їх, а не сподівайтеся, що це вирішиться само собою. І коли залежність блокує прогрес більше, ніж на кілька днів, рано скасовуйте — чекання рідко робить все простіше.

Інвестування в цей словник і ці звички зробить вас більш ефективним інженером продукту і більш надійним співробітником у будь-якій організації.

Розвиток мовлення: розв’язання проблем та пошук шляхів їх вирішення

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

Поширений сценарій виникає під час перегляду коду. Припустимо, що рецензент залишає коментар до запиту на збирання: « Ця функція могла б бути більш зрозумілою ». Хоча це здається простим, що ж насправді означає « більш зрозумілою »? Чи потрібні кращі назви змінних? Ще комментарії, що пояснюють логіку? Зовсім інший алгоритм? Розробник, який отримує цей зворотній зв’ язок, повинен запитати про особливості. Замість того, щоб приймати нечіткий коментар за його цінність, продуктивною відповіддю буде: «Дякую за відгук! Чи можете ви розібратися, що саме робить цю функцію менш читабельною? Чи є певні рядки, які викликають плутанину, або, можливо, є пропозиції щодо поліпшення назв змінних?» Це показує бажання зрозуміти і ефективно вирішити проблему. Аналогічно, в каналах Slack, де обговорюється реалізація функцій, хтось може сказати: «Давайте інтегруємо це». Це може означати будь-що, від об’єднання PR до забезпечення його роботи з існуючими системами — що викликає наступне питання: «Гаразд, інтегрувати як? Чи потрібно нам запускати тести проти поточного виробничого середовища перед злиття?»

Іншою областю, де виникає неоднозначність, є описи запитів на завантаження. Розробник може написати: « Виправлення краю сторінки ». Це надзвичайно нечітке слово! Що таке «край»? Які наслідки від його виправлення? Краще описати це так: «Основний випадок, коли вхід користувача перевищує 255 символів, що призводить до переповнення буфера. Реалізація перевірки довжини і повернення повідомлення про помилку користувачеві. » Метою є не просто описати * що * було зроблено, але надати достатньо контексту для переглядачів — і майбутніх розробників — щоб зрозуміти * чому * це було необхідно і як з цим слід поводитися.

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

# Example: Using `git diff` to highlight changes in a PR description
git diff --color-words --stat  # Shows the words changed and a summary of modifications