Performance Review для DevOps. Ділюся тернистим шляхом створення системи та цікавими інсайтами

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Всім привіт! Мене звати Дар’я, я HR-менеджер в DevOps компанії під назвою Alpacked. Компанія була створена девопсами для девопсів. Ми допомагаємо бізнесу покращувати інфраструктуру, залучаючи кваліфікованих спеціалістів із використанням сучасного стеку технологій.

Чим же в компанії займаюсь я? В мою зону відповідальності входить підбір персоналу, створення та імплементація всіх внутрішніх процесів та практик, робота з колективними запитами та потребами.

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

Тому в мене виникла ідея написати про наш тернистий шлях створення системи Performance Review. Сподіваюсь, що моя щира розповідь надихне менеджерів з інших компаній не здаватись та створювати саме ті процеси, які будуть максимально корисними в межах їх компанії. Можливо, хтось захоче використати наш метод, але навіть якщо вам просто буде цікаво це прочитати — вже непогана таки похвала за мою працю, я вам скажу.

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

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

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

Деякі процеси у нас вже були імплементовані (такі як: онбординг, офбординг, retention/dismissal та інші), але ми розуміли, що найважливіший та найбажаніший процес — це зрозуміла для всіх система Performance Review. Це завдання було для мене із зірочкою, навіть не одною. Тож, тут і почалось...

З чого ми стартанули

З розуміння того, що ми не знаємо з чого почати:) В чому була основна складність? А точніше, їх було декілька.

По-перше, компанія уникає градації на Junior, Middle, Senior. А ви вже розумієте абсурдність процесу Performance Review без чітко розписаних рівнів. Справа тут у відмінності думок кофаундерів. СЕО був прихильником системи з чітко розписаними критеріями й технологіями, а СТО — навпаки, уникав можливості якихось обмежень.

За його словами, «Є цілковито нерелевантним використання Junior, Middle, і т.д. термінів як показників досвіду й технічних скілів. Особливо, коли мова заходить про internal performance review. Тому що ці лейбли або люди привласнюють собі самостійно, спираючись виключно на самовідчуття, або їх приписує людям компанія, спираючись на внутрішні екзамени. Перший варіант мені здається потенційно відірваним від реальності, а другий — бюрократичним пеклом, яке люди зазвичай проходять у великих компаніях.

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

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

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

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

Перші спроби

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

ALPACKED = A (Junior), L (Junior+), P (Middle) і так далі. За іронією долі, букв у назві якраз вистачало для всіх рівнів. Але, увага, спойлер: було важко одразу швидко визначити, який рівень знаходиться на букві К, наприклад.

Потім був варіант менш креативний, але поширеніший серед інших ІТ-компаній. Це позначення рівня комбінацією А+цифра певного рівня. Схематично так це виглядало: А1-Junior, A3-Middle, А5-Senior і т. д. Після того, як я намудрувала приклади градацій, я створила величезну Ексель-таблицю, де розписала приблизно необхідні хард та софт-скіли. Виглядало це так:

Тобто, сукупність хороших софт-скілів та збільшення функціональних обов’язків (читай — більше відповідальності) запускає процес Performance Review. Причому, дана градація була побудована на гіпотезі що, якщо компанія дає новий функціонал, то людина має хороші софт-скіли.

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

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

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

Дана схема дуже допомогла в обговореннях побудови нашого власного процесу

Що ж ми придумали

Ми виділили 5 (для Team Lead їх було 6) софт-скілів, які найбільше цінує компанія, і які нам всім необхідні для хорошої продуктивної роботи на проєктах. Це:

• ефективна комунікація,
• problem solving,
• надійність,
• мотивація,
• професіоналізм та
• менторство /участь в наймі.

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

Як це виглядає в процесі Performance Review

Все досить просто. Співробітник звертається до HR-менеджера з проханням запустити Performance Review. В HR-системі я створюю шаблон для оцінки софт та хард-скілів.

Хто бере участь в оцінці: технічний спеціаліст (СТO або Team Lead) та нетехнічний (СОО або HR).

Після опрацювання наданого зворотного зв’язку, HR створює загальний фідбек для співробітника у вигляді pdf-файлу з такими пунктами:

1. Самарі по кожному софт-скілу.
2. На що варто звернути увагу.
3. Що варто виправити.

При кожному наступному Performance Review буде звертатись увага на те, як співробітник впорався з моментами, які необхідно було відкоригувати.

Щобільше, ми не обмежуємо співробітників у часі, тобто кожен може податись тоді, коли він відчуває потребу в цьому.

Які плюси даного процесу для нас

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

Короткі підсумки

Застосування Performance Review — один із найбільш комплексних способів оцінки співробітника не тільки кількісно, але й ідейно. А ідея проста: допомогти зрозуміти, що оцінка потрібна заради розвитку професійних якостей учасників команди.

На жаль, важко передати в статті всі наші обговорення, варіанти та брейншторми, які ми проходили та відкривали для себе по ходу створення Performance Review.

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