Чи звертали увагу, як це буває? У команду приходить новачок джуніор. У нього багато вільного часу, він постійно пише код, завдання закриваються одна за одною, і прогрес зростає як на дріжджах. А потім дивишся на свого досвідченого сеньора або тимліда. Увесь день у нарадах, постійно відволікається на якісь питання, а в Jira на ньому висить лише пара завдань, які він робить уже кілька тижнів.
І закрадається думка: «А чи не даремно він отримує свою зарплату?».
Я, як project‑менеджер, сам так думав, поки не зрозумів, що роботу досвідченого фахівця треба оцінювати не за кількістю рядків коду, а за загальний результат. Сьогодні розберемо цей міф по поличках.
Два різних світи: як виглядає день джуна і сеньора
Уявімо собі типовий день, як у тій анекдоті. Це добре показує сутність проблеми.
День Junior Developer:
- 10:00 — П’ятихвилинка (15 хв.)
- 10:15 — Пише код
- 11:00 — Задав коротке питання колезі (15 хв.)
- 11:15 — Пише код
- 12:00 — Обід (30 хв.)
- 12:30 — Пише код
- 15:00 — Рев’ю коду (30 хв.)
- 15:30 — Перерва
- 16:00 — Пише код
- 18:00 — Кінець робочого дня
Підсумок: Приблизно 6.5 годин чистого кодування. Продуктивність очевидна, усе видно.
День Senior Developer / Tech Lead:
- 10:00 — П’ятихвилинка (15 хв.)
- 10:15 — Допоміг колезі вирішити проблему (15 хв.)
- 10:30 — Нарада з продакт‑менеджером (30 хв.)
- 11:00 — Відповів на термінове питання в чаті (15 хв.)
- 11:15 — Відповів начальству на питання (15 хв.)
- 11:30 — Рев’ю коду та навчання джунів (30 хв.)
- 12:00 — Обід (30 хв.)
- 12:30 — Допомога новачку / обговорення проекту (1 год)
- 13:30 — Виправив помилку на продакшні (15 хв.)
- 13:45 — Допоміг ще одному колезі (15 хв.)
- 14:00 — Обговорення стратегії з архітектором (30 хв.)
- 14:30 — Пише техзавдання на новий проект (1 год)
- 15:30 — Уточнює деталі з PM (15 хв.)
- 15:45 — Знову допомагає по задачі (15 хв.)
- 16:00 — Нарешті! Пишe свої задачі (1.5 години з переривами)
- 18:15 — Кінець робочого дня
Підсумок: Приблизно 1.5 годин кодування. Здається, що людина недоопрацьовує. Але давайте подивимось уважніше.
Як 20 хвилин роботи сеньора економлять 7 годин роботи команди
Головне для досвідченого фахівця — не його особиста продуктивність, а ефективність всієї команди. Він більше не просто виконавець, він допомагає іншим працювати.
Дивіться самі:
У Свети складний баг. Вона може копатись у ньому 3 години, а може спитати у сеньора і вирішити проблему за 5 хвилин.
Паша не розуміє, як працює якийсь модуль. Він може витратити цілий день, щоб розібратися, або отримати пояснення від тимліда за 10 хвилин.
Проста математика: 20 хвилин роботи сеньора економлять 7+ годин роботи всієї команди. Це вигідно для бізнесу.
Невидима робота — це:
Архітектура та планування: Самі ті техзавдання, які допомагають команді не витратити місяці на неправильно розробку.
Навчання та рев’ю коду: Розвиток джунів та мідлів, запобігання помилок.
Вирішення складних проблем: Без цього команда може битися над завданням цілими днями.
Спілкування: Переклад вимог бізнесу на технічну мову і навпаки.
Усунення проблем: Він швидко вирішує критичні проблеми, поки вони не стали катастрофою.
Що робити керівнику? Як оцінювати невидиву роботу?
Якщо ви керуєте командою, ваша задача — не примушувати сеньора більше кодити, а оцінювати його реальний внесок і створювати комфортні умови для роботи.
1. Дивіться не на кількість, а на результат.
Не потрібно оцінювати всіх за кількістю закритих задач. Замість цього запитайте:
Наскільки швидше стала працювати команда завдяки його допомозі?
Наскільки менше стало критичних помилок після його рев’ю коду?
Скільки проблем він допоміг розв’язати за минулий тиждень?
Як швидко нові співробітники вливаються в проект завдяки його навчанню?
2. Зберигайте його час.
Ваш сеньор — найцінніший ресурс. Ваша задача — його захищати.
Не залучайте його на всі наради підряд. Його час має використовуватися максимально ефективно.
Дайте йому спокійно працювати над проектом. Йому потрібно час подумати, не чекайте швидких відповідей у чаті.
3. Довірйте йому.
Він краще за вас знає, як розпорядитися своїм часом. Дайте йому свободу.
Що може зробити сам senior‑розробник?
Звісно, не можна просто відгородитися від команди. Але можна зробити процес зручнішим для всіх.
Виділяйте час на годину коду. Нехай всі знають, що в цей час вас краще не чіпати.
Збирайте наради у першій половині дня, щоб другу половину присвятити роботі.
Виділяйте час на відповіді в Slack/пошті. Наприклад, 15 хвилин кожну годину. Вимкніть сповіщення в остальній час. Люди звикнуть, що ви відповідаєте не одразу, але завжди відповідаєте.
Висновок для менеджера
Ваш досвідчений розробник або тимлід, який може здаватися ледарем, насправді — двигун вашої команди. Він пише не так багато коду, бо допомагає іншим писати цей код швидше, якісніше та з меншим числом помилок.
Не дивіться на його календар і кількість комітів. Оцінюйте його успіх за успіхом всієї команди. Ваше завдання — не контролювати кожну його хвилину, а створити умови, в яких він зможе максимально підтримувати інших.
А що ви думаєте? Зустрічалися з цим у практиці? Як оцінюєте роботу своїх досвідчених спеціалістів?
Коментарі