Мова прийняття платформи: англійська для внутрішніх команд платформи
Англійський словник і фрази для внутрішніх команд платформи: впровадження інженерів, повідомлення золотого шляху, dogfooding, запуск опитувань DX і підтримка міграції платформи.
Внутрішні команди платформи стикаються з комунікаційними викликами, які зовнішні команди продуктів рідко зустрічають: їхніми клієнтами є інші інженери, які часто скептично ставляться, мають власні думки і здатні будувати власні рішення, якщо платформа не відповідає їхнім потребам. Для того, щоб інженери прийняли платформу, потрібно більше, ніж хороша технологія - це вимагає переконливого спілкування, чіткої документації і мови, яка поважає автономію розробника, демонструючи цінність захисних рейок платформи і типових параметрів. Цей посібник містить ключові слова і фрази для спілкування щодо прийняття платформи.
Ключовий словник
Золотий шлях Рекомендований, добре підтримуваний спосіб виконання звичайного завдання на платформі — шлях, який передбачає найбільше інструментів, документації і підтримки команди.
“Золотий шлях для розгортання нової служби - це використання шаблону служби платформи - він включає CI/CD, спостережність і управління секретами безпосередньо з коробки.”
- Собачої їжі Практика команди платформи, яка використовує власну платформу для власних послуг - перевірка досвіду розробників з перших рук і демонстрація впевненості в тому, що вони просять інших прийняти.
- “Ми розробляємо платформу для розгортання всіх наших власних служб. Якщо це боляче для нас, ми виправляємо це перед тим, як розгорнути його для інших команд»
** Досвід розробника (DX) ** Загальна якість досвіду розробника під час використання інструменту, платформи або API — включаючи якість документації, повідомлення про помилки, час налаштування і когнітивне навантаження.
- “Наше дослідження Q1 DX показало, що найбільшою проблемою був час до першого успішного розгортання для нових інженерів - золотий шлях скоротив це з трьох днів до чотирьох годин.” *
Чемпіон платформ Розробник в команді продукту, який прийняв платформу і закликає до неї внутрішньо - міст між командою платформи і іншими інженерами.
- “Ми визначили чемпіонів платформи в шести продуктових командах. Вони отримують ранній доступ до нових функцій і пряму лінію до команди платформи для ескалації. ”*
Вступ на борт Процес отримання нової команди або інженера і роботи на платформі - включає документацію, кероване налаштування і підтримку першого використання.
“Ми переробили процес впровадження, щоб нова команда могла розгорнути свою першу службу протягом двох годин після прочитання посібника по запуску.”
** Підтримка міграції ** Допомога, надана командам, які переходять від старішого або ad-hoc рішення до платформи - включаючи інструменти міграції, документацію, робочі години і парні сеанси.
“Ми пропонуємо підтримку міграції на наступний квартал — будь-яка команда, що мігрує зі старої системи розгортання, може замовити парний сеанс з командою платформи.”
Блокова дорога Метафора, схожа на золоту дорогу — маршрути через платформу, які добре підтримуються і мають розумні типові значення, в протилежність «позашляховому» використанню, яке технічно можливе, але не підтримується.
- “Брусова дорога обробляє 95% наших випадків використання. Команди, які йдуть по бездоріжжю, можуть — але вони самі є власниками підтримки цього шляху.»*
Корисні фрази
** Введення можливостей платформи: **
“Ми розгортаємо нову систему управління секретами у всіх службах цього кварталу. Золотий шлях вже задокументований — більшість команд можуть мігрувати менш ніж за день. Я проведу вас через ключові кроки і те, що відрізняється від поточної установки»
Передача цінності:
«Причина, чому ми тиснемо команди до спільного стека спостережливості, не в тому, щоб додати бюрократію - це так, що коли у вас є інцидент, ви дивитеся на ті ж панелі, що і інженер на гарячому, SRE і менеджер продукту. Спільний контекст робить інциденти коротшими»
** Запит на відгук через DX- опитування: **
“Ми проводимо наш квартальний дослідження досвід розробників цього тижня. Це займає близько п’яти хвилин і безпосередньо формує дорожню карту платформи. Опитування останнього кварталу є причиною, чому ми спростили налаштування місцевого розвитку — ми хочемо почути, що все ще боляче»
Честно признавая ограничения:
“Поточна система планування завдань ще не підтримує розподілене відстеження. Это в нашей программе на третий квартал. Якщо це вас блокує, у нас є обхідне рішення, задокументоване на платформі wiki, і я радий пройти через це з вами»
** Підтримка міграції: **
«Ми знаємо, що міграція конвеєра розгортання не є нульовою вартістю інженерної роботи, і ми хочемо зробити це якомога простіше. Ми створили скрипт миграции, который обрабатывает 80% случаев автоматически. Для решти 20%, ми пропонуємо парні сеанси кожного вівторка — забронюйте слот і ми будемо працювати через це разом»
Поширені помилки
Наказувати замість демонструвати Команди платформи, які кажуть * “всі команди повинні мігрувати до нової системи до Q3” * без демонстрації цінності часто стикаються з опором і обхідними шляхами. Англійська має більш ефективний реєстр для прийняття платформи: * “Ми бачили, що команди, які мігрували, витрачають на 40% менше часу на інциденти, пов’язані з розгортанням. Ми б хотіли допомогти вам досягти цього також.” * Переконання через продемонстровану цінність є більш тривалим, ніж мандати.
** Використання « просто » для мінімізації зусиль з міграції **
- « Вам просто потрібно оновити налаштування розгортання, і все буде працювати » * недооцінює зусилля і створює розчарування для інженера, який виконує цю роботу. Замініть * « просто » * на більш чесне визначення: * « Міграція включає три кроки. Для більшості сервісів це займає близько півдня — ось як виглядає процес».*
** Не вдалося закрити петлю зворотнього зв’ язку ** Коли команди платформи проводять DX-опитування і ніколи публічно не визнають, що вони чули або що вони змінили в результаті, інженери перестають відповідати. Закриття петлі створює довіру: “Засноване на вашому відгуку минулого кварталу, ми перебудували повідомлення про помилки CLI — вони тепер включають конкретний виправлення, а не загальний код помилки. Дякую всім, хто позначив це.»
Найуспішніші внутрішні платформи приймаються, тому що вони роблять життя інженерів кращим - і комунікація цієї цінності чітко і чесно є такою ж частиною інженерії платформи, як і сама технологія.
Введення в лексику: лексика для немовлят
Мета цього блогу – «Мова прийняття платформи: англійська для внутрішніх команд платформи» – забезпечити вашу команду комунікаційними навичками, необхідними для ефективного залучення інженерів, сформулювати «золотий шлях», закликати до dogfooding і проводити опитування цифрового досвіду (DX). Однак, ми визнаємо, що не всі, хто приєднується до команди платформи, походять з виключно англомовного середовища. Розвиток вільної мови не тільки про розуміння окремих слів; це про розуміння нюансів фразування і розпізнавання того, як стилі спілкування відрізняються в різних культурах. Цей новий розділ зосереджено на наданні лексики і практичних прикладів для підтримки носіїв мови, для яких мова не є рідною, у вирішенні унікальних завдань сучасної внутрішньої команди платформи. Це про надання їм можливості робити свій внесок впевнено і безшумно, а не просто перекладати безпосередньо.
Однією з ключових областей є розуміння * технічного жаргону * - часто завантажений неявними припущеннями, які можуть бути заплутаними для тих, хто новий для конкретного технологічного стека або процесу розробки. Наприклад, коментар перегляду коду, на кшталт «Ця гілка потребує більш детального оброблення помилок» може здатися простим, але фраза «детальний обробник помилок» сама по собі несе очікування розбиття помилок на дуже детальні рівні. Розробник, який не знайомий з цією концепцією, може інтерпретувати її як потребу в більшому веденні журналу, що є зовсім іншим підходом. Замість простого зауваження «Попрацювати над помилками», більш доступна фраза — щось на зразок «Давайте переконаємося, що ми захоплюємо всі потенційні точки невдачі на найнижчому можливому рівні, щоб полегшити зневадження» — прояснює бажаний результат без покладання на потенційно неоднозначні технічні терміни. Аналогічно, при описі Запиту на завантаження, уникайте надто коротких фраз, наприклад, « Виправити ваду # 123 ». Замість цього спробуйте « Цей PR стосується вади # 123, зосереджений на [особливій області змін] і включає [відповідні тести] »
Крім того, розгляньте мову, яку використовують у каналах Slack, присвячених міграції платформ. Фрази на зразок « Давайте синхронізуємо стратегію розгортання » можуть викликати плутанину, якщо команда не знайома з поняттям « синхронізація ». Яскравішою альтернативою може бути « Чи можемо ми запланувати коротку зустріч, щоб обговорити кроки, пов’ язані з розгортанням цієї зміни? » Цей перехід до більш чіткої мови зменшує неоднозначність і сприяє кращій співпраці. Не вагайтеся попросити про пояснення - активне пошуки демонструє бажання вчитися і будувати розуміння, яке завжди цінується. Пам’ятайте, *просити про «розпакування» * - прохання когось пояснити щось більш докладно - цілком прийнятно і заохочується.
Нарешті, при обговоренні концепцій, таких як «dogfooding» (використання власного продукту як користувача), сам термін може відчуватися абстрактним. Хорошим поясненням може бути: «Ми повинні особисто перевірити цю функцію, щоб зрозуміти, як вона працює з точки зору кінцевого користувача. Це допомагає нам визначити потенційні проблеми, перш ніж вони вплинуть на наших клієнтів, і забезпечує, що ми створюємо те, що * їм * насправді потрібно. “Надання контексту разом з термінологією є ключовим для забезпечення розуміння і керування прийняттям цих важливих практик. Заохочуйте членів команди ділитися своїми спостереженнями — навіть дрібні деталі можуть дати цінний взірець.