Випилюємо 360: як ми перестали «оцінювати людей» і почали керувати роботою

Випилюємо 360: як ми перестали «оцінювати людей» і почали керувати роботою

Привіт ком’юніті! 👋

Мене звати Віталіна, я акаунт-менеджер в SToFU Systems.

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

На папері 360 виглядає як щось справедливе й доросле. Багато джерел. Менше упередженості.
«Обʼєктивність». М-м-м!

У реальності все цікавіше. 360 для нас виявився не інструментом посилення команди, а інструментом її розшарування. Працював добре формально, але проти нас по суті.
Тож ми його випиляли. Але про все по черзі.

Що таке 360?

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

Ми теж так робили. Розсилали анкету, збирали відповіді, агрегували, формували рекомендації.
З формального погляду — порядок. Є дані. Є висновки. Є «план розвитку».

Щоб було зрозуміло, про яку саме «анкету» йдеться, наведу дуже спрощений приклад того, що зазвичай питають у 360.
Наприклад: «Що людині варто продовжувати робити?».
Потім: «Що людині варто почати робити?».
Потім: «Що людині варто припинити робити?».
І ще одне питання, яке завжди виглядає невинним: «Опиши ситуацію, коли взаємодія була складною, і чому».

А підсумок часто виглядає як маленький звіт від колективного всевидячого ока. Приблизно так:

Сильні сторони: швидко підхоплює задачі, допомагає іншим, не зникає з радарів.
Ризики: «готово» інколи означає «майже готово», обговорення на мітингах може бути різким, у чаті відповідає уривками.
Що робити далі: домовитись про Definition of Done, синхронізувати очікування, узгодити формат ескалації.

На папері все ок. Красиво!
Але є одна деталь. Це пишеться людьми, які працюють разом кожен день. І як тільки ви додаєте туди анонімність або відкладений фідбек «на потім», воно перестає бути інструментом розвитку і починає жити своїм життям.

Чому 360 у нас працював як інструмент роз’єднання?

1. Пункт перший. Похвала — один рядок, критика — роман на три томи

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

Навіть якщо ви подаєте це максимально лагідно, мозок людини читає так: «Ми всі тут зібралися і написали, що з тобою не так». І все. Далі будь-яка спроба «конструктиву» сприймається як судове засідання. Ви хотіли інструмент розвитку — а отримали колективний трибунал.

Ми чесно спитали себе: ми справді хочемо робити це регулярною практикою? Бо воно дисциплінує форму — але руйнує довіру.

З життя це виглядає так. Людині приходить звіт, де три фрази «все ок», і два полотна «ось чому не ок». І мозок, звісно, запам’ятовує не три «ок», а два «не ок». Тому що так влаштована увага: болить — значить важливо!
І далі людина йде не в розвиток, а в самозахист. Вона починає доводити, що «це неправда», або що «це контекст», або що «ви теж не святі». І в цей момент 360 перетворюється на ритуал, де всі ніби хотіли добра, але вийшло як завжди.

2. Пункт другий. Анонімність у маленькій команді — це самообман

Є така менеджерська казка: «Анонімний фідбек знімає страх».
Анонімність? Ріллі? У маленьких проектних командах?
У дійсності це майже завжди означає «я зараз буду вгадувати, хто це написав!».

Людина отримує кілька неприємних зауважень — і наступного дня приходить на мітинг у свій проєкт, де сидить 3–5 людей. Вона не думає про «організаційний розвиток». Вона думає: «Хто з вас?». І це запускає дуже токсичний процес: ви всі ніби чемні, але всередині з’являється прихований шар недовіри.

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

3. Пункт третій. Як тільки 360 впливає на підвищення — починаються ігри

Ось тут було найцікавіше. І найсумніше.

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

Уявіть ситуацію. Ви кажете команді: «Оцінки 360 враховуються при промо». І в ту ж секунду ви перетворюєте частину людей на гравців, а не на колег. Бо якщо в системі з’являється кнопка «вплинути», нею хтось натисне. Не завжди зі зла. Іноді просто з відчуття несправедливості («а чого його підвищують, він же...»). Іноді з конкуренції. Іноді тому що «так працює світ». І в цей момент ви отримуєте те, що хотіли уникнути: політику, гру, оцінки «на всяк випадок нижче».

Це, до речі, одна з причин, чому багато дослідників і практиків радять розділяти фідбек для розвитку і адміністративні рішення (гроші, грейди, промо). У CIPD це сформульовано доволі прямо: розмови про оцінювання/адміністративні рішення краще відділяти від розмов, де фідбек дається з метою розвитку.
Ось PDF з їхнього evidence review (practice summary).

4. Пункт четвертий (наш болючий інсайт). 360 часто підміняє роботу менеджера

Після кількох циклів ми сформулювали фразу, яка спочатку звучала як образа, а потім як правда.

Якщо менеджеру потрібен 360, щоб зрозуміти, хто як працює і де проблеми, — значить менеджер не має системи спостережуваних сигналів. Немає метрик. Немає регулярних розмов. Немає ритму. Або все це є, але «десь там» і не використовується.

І 360 стає милицею: «ми зараз зберемо анкету і нарешті дізнаємось правду». А потім ви отримуєте не «правду», а емоційний знімок, помножений на анонімність, здогадки і політичні ігри.

Щоб це не виглядало як «в нас так було, значить 360 — зло», я додам посилання.

Є дослідження багатоджерельного фідбеку (multisource feedback).
Воно каже «не чекайте магії». У метааналізі 24 лонгітюдних досліджень Смізер, Лондон і Райлі пишуть, що покращення після 360 в середньому невелике, і що великого «масового апгрейду» після однієї хвилі фідбеку чекати не варто.
А от шанс зростає, коли людина бачить реальну потребу змінюватись, нормально сприймає фідбек, вірить, що може змінитись, ставить конкретні цілі і реально щось робить, а не просто «прочитала PDF і пішла далі». Ось сам текст (PDF).

Окей, ми випиляли 360. А що замість?

Ми перестали міряти людей тікетами

В один тікет може вміститись тиждень ресерчу, складне рішення, десять дзвінків і лише 20 рядків коду. В інший — 50 функцій, які реально вийшли з одного прогону AI-агента за 20 хвилин.

Якщо ви міряєте лише тікети, ви насправді міряєте не роботу, а те, як ваш процес ріже роботу на шматки.

Тому ми змінили питання. Не «скільки задач закрив». А «що доставили, яку цінність це дало, яка була якість, чи могли ми це прогнозувати і чи статуси були чесні».

Як ми визначили «результат» без шаманства

Ми зійшлися на простій рамці.

Результат — це коли цінність доставлена, якість прийнятна, команда може прогнозувати, а прогрес прозорий.

Цінність — це не «код написаний». Це «користувачу/клієнту стало краще» або «команді стало простіше підтримувати».

Якість — це не «мені подобається твій код». Це наслідки: баги в проді, інциденти, переробки.

Прогнозованість — це не «ми завжди встигаємо». Це «ми чесно розуміємо, що встигаємо, а що ні, і не брешемо собі».

Прозорість — це коли «майже готово» не перетворюється на життєву філософію.

Метрики

Коли люди чують слово «метрики», у багатьох всередині з’являється маленький травмований працівник з минулого досвіду. Той, якого били цифрами по голові.

Метрики повинні бути не батогом. Вони повинні бути окулярами. Без них менеджер часто сліпий.
А коли менеджер сліпий — він починає шукати «об’єктивність» в анкетах. Ну ви зрозуміли.

Ми залишили метрики на рівні команди, бо більшість проблем — системні!
І якщо ми хочемо не шукати винних, а виправляти процес, то треба міряти процес!

Ми, чесно кажучи, не винаходили велосипед. Є доволі приземлений набір метрик доставки, який роками просуває DORA (DevOps Research and Assessment): як швидко ви доставляєте зміни і наскільки боляче вони падають. Ось їхній короткий гайд.

Там же є важлива ремарка, яку я б прибила на стіну кожному, хто колись хотів зробити з метрик KPI: «не ставте метрику ціллю»! Бо як тільки ви кажете «нам треба деплоїти N разів на день», частина команд починає деплоїти не цінність, а цифру. Це стара історія про те, що коли показник стає ціллю, він перестає бути показником. DORA прямо посилається на Goodhart’s law і розписує типові пастки. Ось сторінка про «чотири/п’ять ключів» простими словами.

І ще одна важлива річ, яку DORA нормально підкреслює: контекст важливий. Ці метрики краще дивитися «всередині» однієї команди/сервісу і в динаміці, а не порівнювати мобільний застосунок з мейнфреймом, а маленьку команду з платформою на 200 людей.

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

І тепер — дуже важливе «не робіть так». Не перетворюйте ці метрики на індивідуальні KPI! Бо тоді люди починають оптимізувати не продукт, а цифру. KPI «деплої» — і у вас з’являються деплої заради деплоїв. KPI «cycle time» — і задачі починають дробити до абсурду, щоб «швидко закривати», а складні частини тихо виносяться в тінь. KPI «інциденти» — і інциденти починають перейменовувати в «особливості» та «непередбачувані сценарії користувача».

Перше, що нам допомогло, — прогнозованість.
Просте питання: що ми пообіцяли в плануванні і що реально віддали. Не для сорому. Для розуміння. Бо якщо ви постійно обіцяєте 10 і робите 6, то проблема не в «ледачих людях». Проблема в оцінці, пріоритетах, WIP, блокерах, контекст-свічі. Тобто у менеджменті.

Друге — час доставки. Скільки часу задача проводить у дорозі від «взяли в роботу» до «реально доставили». Це дуже протвережує. Бо часто виявляється, що ми «пишемо код» швидко, а от «доставляємо» — повільно. І тоді видно, де вузьке місце: рев’ю, тестування, реліз, узгодження, залежності.

Третє — WIP. Якщо у команди одночасно «в роботі» десять задач, то насправді ніхто нічого не робить. Точніше, всі роблять все одразу. А потім ми дивуємось, чому все повільно і нервово. Виявляється, коли мозок розмазаний тонким шаром по десяти задачах, він не стає продуктивнішим. Він стає втомленішим.

Ще одна штука, яка нам допомогла мислити тверезо: якщо хочете, щоб щось проходило систему швидше, часто треба не «тиснути на людей», а зменьшувати розмір пакетів зі змінами. Менші зміни легше рев’ювати, тестувати, релізити й відкатувати. У DORA це теж прямо проговорюється як практична наступна дія: зменшення batch size підтягує і швидкість, і стабільність. (Так, це звучить як банальність, поки не спробуєш жити з цим місяць.)

Якість: ми перестали сперечатись «мені здається» і почали дивитись на наслідки

Оцінювати «якість» анкетами — погана ідея. Бо «якість» у анкеті — це часто про симпатію, стиль і смак.

Ми перейшли на наслідки.

Скільки дефектів долетіло в прод. Якої тяжкості. Як змінюється динаміка.

Скільки інцидентів у нас було. Скільки часу ми відновлювались. Чи повторюються одні й ті самі причини.

Скільки переробок. Скільки задач «здавали», а потім повертали назад. Бо «готово» виявилось не готово.

Ви більше не сперечаєтесь «хто молодець». Ви дивитесь, що реально відбувається з продуктом.

Контрінтуїтивний висновок: «а навіщо взагалі оцінювати людину?»

Чим довше ми копали, тим частіше впирались у дивне питання.

Навіщо ми оцінюємо людину? Щоб відмовити в підвищенні? Щоб показати, хто «зірка»? Щоб порівняти людей?

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

Тобто про систему.

А якщо так — тоді перший об’єкт оцінювання це команда і процес. А не людина як мішень.

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

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

«Людина не перформить»: що ми перевіряємо першими

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

Чи ця проблема була завжди? Якщо так — це провтик у наймі або онбордингу. І тоді лікувати треба процес найму, а не людину анкетами.

Чи раніше було нормально, а потім стало погано? Тоді це може бути контекст: вигорання, зміна задач, конфлікт ролей, особисті обставини. Це зона нормальної менеджерської роботи: розібратись, що сталося, зменшити навантаження, допомогти повернути контроль, сформувати короткий план на 2–4 тижні.

Чи є у людини чітка домовленість, що саме означає успіх найближчим часом? Бо часто проблема не в тому, що людина «слабка». А в тому, що ми поставили їй туман і назвали це очікуваннями.

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

Висновки

Звісно, 360 може працювати. У великих компаніях, де анонімність реально можлива.

Коли в команді вже є культура прямого фідбеку, і 360 — це додатковий сигнал, а не головна «правда».

У нас цього не було. У нас були малі команди, швидкий темп і висока ціна недовіри.

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

Ми випиляли 360 і повернулися до базових речей: простих командних метрик, відвертих розмов і прозорих статусів.

Матеріали й посилання (якщо хочете копнути глибше)

DORA — DORA’s software delivery performance metrics. Дуже людське пояснення п’яти метрик і типових пасток.

DORA — DORA’s software delivery performance metrics. Коротка версія з історичним «чому чотири/п’ять» і попередженням про ігри з метриками.

DORA Research: 2024 — DORA Report. Повний звіт (можна скачати PDF різними мовами).

Smither, London (2005) — meta-analysis on multisource feedback. Чому не варто чекати магічного ефекту від однієї хвилі 360.

CIPD — Performance feedback: an evidence review (PDF). Про те, як фідбек працює/не працює, і чому змішування «оцінювання» з «розвитком» часто шкодить.

CCL — 360 Degree Assessment & Feedback: Best Practices Guidelines. Якщо ви все ж робите 360 — є про що подумати до старту, а не після пожежі.

CCL — SBI feedback model. Дуже проста структура для фідбеку «без ярликів».

Google SRE — Postmortem Culture: Learning from Failure. Про blameless postmortems і чому культура шеймінгу вбиває навчання.

Amy Edmondson (1999) — Psychological Safety (PDF). Першоджерело про психологічну безпеку в командах.

WEF — Feedforward technique. Про те, як зміщувати фідбек у бік «що робимо далі», а не «що було вчора».

Goodhart’s law. Одна з найкорисніших «анти-теорій» для всіх, хто хоче зробити з метрик KPI.

Killing-360-reviews. Стаття англійською на нашому сайті.

Питання до спільноти 😊

Які думки у спільноти про 360? Чи використовуєтсья у вас 360? Який у кого досвід з цим?

Як ви вирішуєте проблему «анонімності», коли команда маленька і всі все розуміють?

І які метрики доставки/якості реально допомагають вам керувати процесом, а не малювати красиві звіти?

Дякую за ваш час і увагу,

Усім добра!