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

Оригінал: How platform teams get stuff done
Автор: Pete Hodgson

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

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

Розглядаючи, як співпрацюють команди розробки, основним ресурсом є чудова книга Team Topologies. У розділі 7 автори визначають три режими командної взаємодії: співпраця, X-як-послуга і фасилітація.

Команди доставки платформи і команди доставки продуктів

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

Команда з доставки продуктів створює функції для клієнтів компанії – кінцеві користувачі продукту, який вони створюють, є клієнтами компанії. Я також бачив такі типи команд інженерів, які називаються «функціональні команди», «команди продукту» або «вертикальні команди». У цій статті я використовуватиму «команда продукту» як скорочення команди доставки продукту.

На відміну від цього, команда доставки платформи створює продукти для інших команд всередині компанії – кінцевими користувачами продукту команди платформи є інші команди всередині компанії. Я буду використовувати «команда платформи» як скорочення «команди доставки платформи».

Мовою командних топологій команду доставки продукту зазвичай можна охарактеризувати як команду потоку (Stream Aligned). Хоча автори Team Topologies спочатку визначили команду платформи як окрему топологію, згодом вони почали розглядати «платформу» як ширше поняття, а не окремий спосіб роботи – з чим я дуже згоден. З мого досвіду, коли йдеться про термінологію командних топологій, хороша платформа, як правило, функціонує або як команда потоку (їхня платформа є потоком цінностей), або як команда можливостей, допомагаючи іншим командам досягти успіху з їхньою платформою. Фактично, у багатьох моделях співпраці між командами, які ми розглянемо в цій статті, команда платформи діє як команда можливостей.

"Платформа" > Внутрішня платформа розробника

Навколо розробки платформ зараз багато шуму, головним чином зосередженого на Внутрішніх Платформах Розробників (Internal Developer Platforms - IDPs). Хочу пояснити, що розмова про «платформи» тут значно ширша; вона охоплює інші внутрішні продукти, такі як платформа даних, дизайн система для інтерфейсу або експериментальна платформа.

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

команди платформ створюють продукти, клієнтами яких є інші команди в їхній компанії

Етапи прийняття платформи

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

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

Міграція на платформу

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

Ми бачимо, що в таких ситуаціях саме команда платформи керує змінами, але право власності на кодову базу, яка потребує змін, належить іншій команді – команді продукту. Звідси виникає потреба у міжкомандній співпраці.

Приклади міграційної роботи

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

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

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

Останнім прикладом може бути зміна платформи на рівні інфраструктури — використання Docker контейнерів, що належить команді продукту, впровадження service mash, перехід баз даних з MySQL на Postgres тощо.

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

Шаблони взаємодії

Давайте розглянемо, які шаблони взаємодії між командами підійдуть для роботи при міграції на платформу.

Попросіть виконати роботу

Команда платформи може Подати Заявку в список задач команди продукту, попросивши їх самостійно внести необхідні зміни.

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

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

Команда платформи виконує роботу

Команда платформи може вирішити самостійно внести зміни в кодові бази команди продукту, використовуючи три схожі, але відмінні шаблони – «Відрядження», «Залучений Експерт» або «Внутрішній Відкритий Код».

У «Відрядженні» інженер із команди платформи «вбудовується» в команду продукту та виконує роботу звідти.

Завдяки Залучений Експерт та Внутрішній Відкритий Код команда продукту приймала б запити на підключення до своєї кодової бази від інженера з команди платформи.

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

Так само, як і у випадку з подачою заявки, робота команди платформи має певні плюси та мінуси.

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

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

Іншим мінусом є те, що ця стратегія «зроби сам» не масштабується. Інженерний потенціал команди платформи завжди буде меншим порівняно з командами доставки продукту, і якщо не делегувати інженерну роботу командам продукту, весь цей потенціал залишається на столі.

Справді, це трохи складніше

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

Використання платформи

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

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

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

З використанням платформи ви можете подумати, що цей сценарій використання платформи не потребує спільної співпраці між командами. Однак, як ми побачимо, команда продукту все ще може потребувати певної підтримки з боку команди платформи.

Шаблони взаємодії

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

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

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

Професійні послуги

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

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

Ця модель професійних послуг використовує комбінацію шаблонів взаємодії. По-перше, команда продукту зазвичай надсилає запит на послуги команди платформи. Це той самий шаблон, який ми розглядали раніше під час роботи з міграцією на платформу, але інвертований — у цій ситуації команда продукту подає заявку на команду платформи з проханням про допомогу. Потім команда платформи може фактично виконувати роботу, використовуючи шаблони «Залучений Експерт» або «Внутрішній Відкритий Код».

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

Введення в роботу в білих рукавичках

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

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

Спільнота практиків

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

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

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

Практичні заняття не масштабуються

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

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

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

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

Еволюція платформи

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

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

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

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

Подати заявку

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

Залучайте інженерів до роботи

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

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

Це рівняння фіксованих початкових витрат і поточних вигод означає, що перепризначення інженерів є варіантом, який найкраще зарезервувати для більших удосконалень платформи – переведення інженера в іншу команду на пару тижнів було б швидше руйнівним, ніж корисним.

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

Працюйте на платформі заздалегіть

Якщо команда платформи прийняла підхід внутрішнього відкритого вихідного коду, тоді команда продукту має можливість самостійно впроваджувати необхідні зміни платформи. Роль команди платформи буде здебільшого консультативною, надаючи рекомендації щодо дизайну та переглядаючи PR (pull requests) команди продукту. Після кількох PR інженер продукту може навіть завоювати достатню довіру команди платформи, щоб отримати довіру та стати Залученим Експертом.

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

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

Висновок

Розглянувши міграцію, використання та еволюцію платформи, стає зрозуміло, що існує велика різноманітність того, як команди взаємодіють навколо платформи.

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

Співпрацювати, але лише на деякий час

У Team Topologies зазначають, що найкращий спосіб розробити гарні кордони між двома командами — це спочатку працювати разом у цілеспрямованому, дуже спільному режимі — подумайте про такі шаблони, як «Залучений Експерт» і «Відрядження». Цей період можна використати, щоб дослідити, де найкраще створити межі та інтерфейси між системами та між командами (закон Конвея говорить нам, що ці два аспекти нерозривно переплетені). Однак автори Team Topologies також попереджають, що важливо не залишатися в цьому режимі співпраці надто довго. Команда платформи має наполегливо працювати над визначенням своїх інтерфейсів, намагаючись швидко перейти до режиму «як послуга», використовуючи такі шаблони, як «Подати Заявку» та «Внутрішній Відкритий Код». Як ми обговорювали в розділі «Використання платформи», моделі взаємодії, які дають змогу співпрацювати, просто не будуть масштабовані для команди платформи. Крім того, режими спільної роботи створюють набагато більше когнітивне навантаження на команди користувачів – перехід до стилів взаємодії, що дає більше рук, дозволяє командам доставки продуктів витрачати більше часу, зосереджених на власних результатах. Насправді Team Topologies вважають це зменшення когнітивного навантаження визначальною метою команди платформи.

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

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

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

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