Як скласти onboarding checklist для нового розробника

Коли новий розробник питає: «що робити далі?»

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

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

Перший день: усунути типові перші гальма

Мета першого дня — вивести новачка з режиму «мені не вистачає доступу» в режим «я можу виконати задачу і перевірити результат».

Практичний порядок:

• доступи:
  • репозиторій, таск-трекер, чат команди, CI/CD, менеджер секретів.
  • одразу перевірити рівні доступів, а не чекати, поки людина виявить проблему в середині роботи.
• локальне середовище:
  • клонувати репозиторій.
  • поставити залежності.
  • запустити базовий тестовий набір.
• комунікація:
  • один канал для питань першого тижня.
  • один ментор відповідає в першому вікні.

Перше правило онбордингу: на 1-й день новачок має успішно пройти перевірку у локальному середовищі і побачити, що CI/CD дає зрозумілий статус. Якщо цього немає, то кожна наступна задача буде затягнута.

Перший тиждень: перші маленькі перемоги через pull request

День 2-5 — це не про великий функціонал, а про ритм.

• Дайте завдання з чітким визначенням результату.
• Забезпечте, щоб воно проходило тестування локально і в CI/CD.
• Заздалегідь встановіть, що вважається достатнім code review: формат коментарів, кількість правок, критерій готовності.

Типова помилка тут — дати складну задачу без базового шаблону PR. Новачок починає «влучати» в загальне, але не розуміє, чому коментарі ростуть. Коли ментор дає структуровану форму PR-опису, тягучка зникає, а час виправлень скорочується.

Перша синхронізація: робимо чекліст живим

На 5-7 день проведіть короткий ритуал 25 хвилин:

• Перевіряємо послідовність: доступи -> локальне середовище -> pull request -> CI/CD.
• Виявляємо перші блокери і фіксуємо власника.
• Дивимось, чи виникали ризики з секретами.
• Уточнюємо, чи має команда єдиний ритм онбордингу для всіх.

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

Поширені помилки та коли вони критичні

• Немає явного маршруту для доступів. Критично, якщо людина не може виконати навіть локальні кроки або чекати відповіді більше доби.
• Не стандартизований формат pull request. Критично для перших тижнів будь-якої fast-moving команди: зростає кількість суперечливих коментарів.
• Немає правил роботи з секретами. Критично майже завжди, бо ризики з’являються тихо і пізно.
• Відсутність CI/CD вимог до задач першого тижня. Критично, коли новачок не бачить зворотного зв’язку і починає дублювати роботу.
• Змішування onboarding з великим процесним навчанням. Критично для junior ролей: людина втрачає фокус і confidence.

Що перевіряти щопонеділка перед новим розробником

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

Як адаптувати під свій стек

Можна міняти інструменти, але не змінювати принципи:

• у всіх випадках потрібне швидке підтвердження доступів;
• локальне середовище має бути відтворюваним;
• PR не проходить без критеріїв і зворотного сигналу від CI/CD;
• code review має зменшувати ризики, а не ставати перепоною.

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

Джерела

• https://git-scm.com/doc
• https://docs.github.com/en/get-started/using-git/about-git
• https://docs.github.com/en/issues
• https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions
• https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/securing-your-account-with-2fa