Onboarding Vocabulary for Developers: Bus Factor, Runbooks, and Knowledge Transfer Language (англійською)
Розробники англійської лексики повинні орієнтуватися в процесі навчання як новий співробітник або наставник — плани 30-60-90, підручники, фактор шини, племінні знання і мова ефективної передачі знань.
Почати працювати в новій компанії розробником - це приголомшливо для будь- якої мови. Одночасно ви вивчаєте нову базу коду, нову командну культуру, новий набір інструментів і — якщо англійська не є вашою першою мовою — навігацію професійним спілкуванням другою мовою. У цій статті наведено певний словниковий запас, з яким ви зіткнетеся під час впровадження, незалежно від того, чи ви новий користувач, досвідчений інженер, який навчає інших, чи менеджер, який наглядає за цим процесом.
План на 30-60-90 днів
**30-60-90 день план ** це структурований підхід до перших трьох місяців на новій роботі. Він ділить період впровадження на три фази з різними цілями і різними мовами, щоб відповідати.
** Дні 1-30: Спостерігайте і вбирайте. ** Очікування на цій фазі полягає в тому, що ви навчаєтеся, але ще не виконуєте. Словник відображає скромність і цікавість:
- ** « Вступ » **: ознайомлення з базою коду, процесами і динамікою команди
- “Рампинг ап”: поступове зростання продуктивності та вкладу
- ** « Вивчення бази коду » **: читання існуючого коду, локальне запуск програми, розуміння архітектури
«Я все ще підвищую темп, але ось моє початкове читання про архітектуру системи» «Я швидко вдосконалююсь з потоком розгортання — чи є книга, з якої я повинен почати?»
** Дні 31- 60: Внесок. ** Ви повинні почати працювати, зазвичай над добре розробленими завданнями.
- “Одержання моєї першої ролі”: взяти на себе відповідальність за невелику роботу
- ** « Вплинути » **: створити щось вимірне — об’ єднану PR, виправлення вади, покращення
“Я б хотів мати свою першу роль в цьому спринті. Чи можемо ми знайти щось, що добре обмежено і не блокує нікого?»
Дні 61-90: Лідер. Ви починаєте діяти як повноцінний член команди, керуючи своєю роботою і роблячи внесок в роботу інших.
- ** « Діяльність з ініціативи » **: прийняття на себе відповідальності за мету або проект, а не лише за завдання
- ** « Поділитися тим, що я вивчив » **: активний внесок знань — написання документації, запуск демонстраційних сеансів, наставництво наступного нового учасника
Фрази для 30-60-90 заїздів:
«Я б хотів взяти на себе більше відповідальності в найближчі 30 днів — на чому б я хотів зосередитися?» «Я все ще будую контекст, але ось моє початкове читання про ситуацію з технічним боргом» «Я відчуваю, що я вдарив по моєму кроку — я б хотів, щоб мене розглядали для наступної можливості головної ролі»
Система Buddy і ролі на борту
Багато інженерних команд призначають ** друга ** для нових членів — колегу, який надає щоденні практичні рекомендації протягом перших тижнів. Друг відрізняється від менеджера нового учасника: друг не має оцінюючих повноважень і пропонує психологічно безпечний простір для запитів.
** Роль друга в простих словах: **
- Відповідай на питання «де я знайду X?» без суджень
- Будь готовий до неформальних зустрічей
- Допоможи розшифрувати командну культуру і неписані норми
Фрази для прохання про допомогу, не відчуваючи себе вразливим:
Чи можу я перевірити своє розуміння потоку автентифікації з вами?» «Перед тим, як я спустився в кроличу нору — чи це правильний підхід, чи я пропускаю щось очевидне?» «Я не хочу турбувати всю команду з цим — можу я задати вам швидке питання?»
Фраза **“зайти в кроличу нору” ** - що означає витратити непропорційну кількість часу на бічне дослідження - надзвичайно поширена в інженерних командах. Вчися рано.
** “Не існує дурних питань” культура: ** Багато високоефективних команд явно вербалізують цю норму. Як новий столяр, прийми це за те, що воно є. Задавати питання, яке виводить на поверхню прогалини в документації, є цінним. Не запитувати і витрачати три години на вирішення проблеми - це не так.
Передача знань і документації
Коли хтось залишає команду, або коли власник системи змінює руки, команди виконують ** передачу знань ** - структурований процес перенесення інституційних знань від однієї особи або групи до іншої.
Мозговая перегрузка против структурированной передачи:
** Brain dump ** це неформальний, неструктурований вилив усього, що хтось знає — корисний як початкова точка, але не використовується як документація. ** Структурована передача ** вимагає організації: які системи беруть участь, які типові режими невдач, хто є зацікавленими сторонами, які рішення були прийняті і чому?
** Типи документації ядра: **
- ** Runbook **: покрокова інструкція щодо роботи з певним процесом або системою. Подумайте про це як про документ “як підтримувати роботу”. Приклад: «Це є runbook для процедури відключення конвеєра платежу»
- ** Playbook **: підручник вищого рівня, який охоплює ширший сценарій, часто включає дерева рішень. Там, де Runbook каже «зроби ці кроки в порядку», Playbook каже «в ситуації X, розглянь варіанти A, B або C».
- ** ADR (Architecture Decision Record) **: документ, який записує важливе архітектурне рішення — що було вирішено, чому, які альтернативи було розглянуто і які були наслідки. Приклад: «ADR в репо пояснює логіку, яка стоїть за нашим рішенням використовувати пошук подій для обслуговування замовлень»
«Я напишу книгу для процесу анульування кешу, перш ніж я передам це» «Є ADR з 2024 року, який пояснює, чому ми обрали цього брокера повідомлень — прочитайте це, перш ніж запропонувати нам перейти»
Ця різниця має значення: Runbook вказує вам, що робити; ADR вказує вам, чому щось було побудовано так, як було.
Автобусний фактор і трибальні знання
** Фактор автобуса ** є мірою ризику: скільки людей повинно бути несподівано вилучено з проекту — чи то через відхід, хворобу, чи потрапляння в автобус — перш ніж проект зазнає невдачі? Фактор шини один означає, що одна людина має критичні, недокументовані знання. Це серйозний організаційний ризик.
“Наш автобусный фактор в системе оплаты один. Прія єдина людина, яка знає, як працює сценарій примирення»
Плем’ яні знання (також називаються неявні знання) є накопиченим розумінням, яке існує в головах людей, але ніколи не записується. Це включає: чому існує певне обмеження, які є краєві випадки застарілих систем, який зацікавлений учасник повинен викликати, коли процес схвалення заблокований. Проблема з племінними знаннями не в тому, що вони існують - це в тому, що вони передаються тільки через близькість і час.
Стратегії зменшення та їх лексика:
- ** Ротація пар **: навмисне створення пар різних членів команди на різних системах для розподілу знань
- ** Спринти документації **: запланований, зосереджений час для команди, щоб записати те, що вони знають
- ** Сеанси обміну знаннями **: неформальні презентації або огляди, під час яких одна людина навчає решту команди тому, що вона добре знає
- ** Одна точка відмови **: у контексті людей, член команди, відсутність якого може призвести до переривання критичного процесу — людський еквівалент невідновлюваної системи
«Ми повинні запустити спринт документації до заморозки випуску Q4 — на новому трубопровіді є занадто багато знань племен» “Она - один пункт неудачи на стороні інфраструктури. Нам потрібно, щоб хоча б ще одна людина піднялася на швидкість»
Технічні та техніко-економічні аспекти
Найнадійніший спосіб підтвердити, що ви щось зрозуміли, це ** відповісти на це ** своїми словами, а не кинути головою і сподіватися. Це особливо важливо при вивченні складної системи, де одне нерозуміння складається з десяти.
** Фрази-відповідь: **
«Тоді, якщо я правильно розумію, поток: API отримує запит, перевіряє токен, потім публікує подію в чергу — і працівник підбирає її асинхронно. Чи це так?» «Дозвольте мені просто підтвердити: коли ви кажете «стара система», ви маєте на увазі моноліт, а не новий мікросервіс?»
Техника навчання:
** Вчити назад ** йде далі: після того, як ви щось вивчили, ви пояснюєте це людині, яка вас навчила. Это поверхностные пробелы, которые твой собственный мозг загладил.
«Дай мені пояснити це вам, щоб перевірити моє розуміння — скажи мені, де я помиляюся» “Я б хотів дати короткий огляд того, що я дізнався про процес розгортання. Це допоможе мені зміцнити його, і ви можете виправити все, що я зробив неправильно»
** Документування під час навчання: **
«Я додам записку до вікі, як тільки я це зрозумію — таким чином наступній людині не доведеться проходити через те ж саме відкриття» «Я збираюся написати те, що я дізнався про налаштування середовища стажування, поки воно свіже»
Професійна оцінка непевності:
«Я на 80% впевнений в цьому — дозвольте мені перевірити крайовий випадок, перш ніж ми продовжимо» “Я думаю, що це правильно, але я не бачив цей шлях коду в виробництві. Чи може хтось, хто має, подивитися?»
Вміння розрізняти те, що ви знаєте, те, що ви думаєте, що знаєте, і те, що вам потрібно перевірити, є одним з найцінніших професійних навичок спілкування в інженерії - і це вміння, яке вимагає певної мови, щоб добре виразити.
Продовжувати будувати ваш словник
Вправляйтеся у розумінні цих концепцій за допомогою вправ, розроблених для реальних ситуацій на робочому місці розробника:
- [Вправи зі словниковим запасом] (/exercises/)
- Розробник комунікаційного фразника
Незалежно від того, чи ви переживаєте перший тиждень роботи у новій компанії або допомагаєте колегі ефективно вступити на роботу, правильна мова робить цей процес швидшим, зрозумілішим і менш стресовим для всіх, хто бере участь у цьому процесі.