Talking About Team Topologies in English

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

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

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

• Приклад: « Команда з оформлення покупок є командою з потоковим вирівнюванням — їм належить все, починаючи від інтерфейсу користувача до бази даних для потоку покупок. »*

Команда платформи Команда платформи створює і підтримує внутрішню інфраструктуру, інструменти і послуги, які споживають потокові команди. Метою є зменшення когнітивного навантаження на потокові команди, абстрагуючись від складності. Приклад: «Наша команда платформи управляє кластером Kubernetes і забезпечує самообслуговуючий конвеєр розгортання, який команди продуктів використовують без необхідності розуміти базову інфраструктуру.»

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

• Приклад: «Команда, що займається впровадженням, провела серію семінарів, щоб допомогти нашим командам продукту прийняти контрактне тестування. Як тільки практика була встановлена, вони перейшли до наступної області.”*

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

• Приклад: «Ми розділили домен платежів на дві команди, оскільки когнітивне навантаження стало нестійким — одна команда відповідала за занадто багато послуг.»*

** Режим взаємодії ** Фреймворк визначає три режими взаємодії між командами: співпраця (дві команди, що працюють разом), X-як-сервіс (одна команда надає послугу, яку споживає інша з мінімальною взаємодією) і сприяння (одна команда допомагає іншій поліпшити свої можливості).

• Приклад: « Зараз команда з платформи і команда з розробки розробки працюють у режимі співпраці, поки ми розробляємо новий API розгортання. Як тільки вона стабільна, ми перейдемо до моделі X-as-a-Service. “*

Поширені сценарії, де використовується ця мова

В дискуссии о реструктуризации: Лідери інженерних команд використовують цей словник, коли пропонують або пояснюють організаційні зміни. « Ми переходимо від командної структури, заснованої на компонентах — де у нас були окремі команди інтерфейсу і сервера — до потокових команд, які володіють повним стеком для кожної області продукту. »

В инженерном мире: Коли CTO або VP of Engineering представляє нову організаційну модель, вони будуть використовувати ці терміни. Для того, щоб слідкувати за презентацією і ставити відповідні питання, потрібно знати поняття.

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

Корисні фрази для обговорення топологій команд

• «Ми намагаємося зменшити когнітивне навантаження на команди продукту, пересуваючи більше власності на інфраструктуру до команди платформи»
• «Поточна структура створює занадто багато залежностей — команди постійно блокуються, чекаючи один на одного»
• «Ми використовуємо модель команди, що дозволяє практикувати безпеку, але мета полягає в тому, щоб передати знання, а потім розпустити команду»
• Ця команда є потоково-зв’язаною — вони володіють повною поверхнею продукту від кінця до кінця
• «Ми хочемо перейти до режиму взаємодії X-as-a-Service, щоб команди могли самообслуговуватися без підняття квитків»
• “Залежність між цими двома командами створює вузьке місце. Нам потрібно перепроектувати кордон»
• «Закон Конвея стверджує, що наша архітектура буде відображати нашу командну структуру, тому нам потрібно спочатку правильно отримати командну структуру»
• “Домен цієї команди занадто збільшився. Ми повинні розглянути можливість розділити її вздовж природних ліній розлому»
• «Мета команди платформи — зробити правильні речі простими для команд продукту.»
• “Ми все ще в режимі співпраці, поки ми розбираємося в API контракті. Як тільки це буде вирішено, ми зможемо зменшити взаємодію»

Розробка структури команд

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

Уникайте жаргону, який є специфічним для командних топологій, коли пишете для нетехнічної аудиторії. Переклад: «команда, що вирівнює потоки» може стати «командою, яка володіє повною функцією продукту від початку до кінця»

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

Практичні рекомендації

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

Навигація по території: практичний підхід до словника командних топологій

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

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

Іншою ключовою областю є розуміння нюансів термінології. «Синергічні команди» не обов’язково є універсально зрозумілим терміном. Замість цього, описуйте їх як «команди, які спільно вирішують складні проблеми в багатьох областях», підкреслюючи спільний аспект. При обговоренні архітектурних шаблонів зосередьтеся на описі * ефекту * - наприклад, “Ми приймаємо архітектуру мікросервісів, щоб збільшити стійкість і гнучкість.” Це має більший вплив, ніж просто заява “ми використовуємо мікросервіси”. Нарешті, активне слухання і пояснення припущень є ключовим. Не бійтеся ставити питання на кшталт: « Чи можете ви розібратися, що ви маєте на увазі під « зменшенням залежностей »? Які конкретні проблеми ми намагаємося вирішити?»

# Example CLI command for deploying a Microservice (using Docker Compose)
docker-compose up --build -d

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