Management&Business

Viktoriia Kopeykina, HR Manager/Recruiter/Таргетолог в Design and Test Lab

Всім привіт! Мене звати Вікторія Копейкіна, я HR менеджер у Design and Test Lab з 2019 року. Моя робота — це наймати та будувати ефективні команди, підтримувати мотивацію, допомагати співробітникам розкривати свій потенціал і створювати атмосферу довіри. За ці роки я побачила, що навіть найталановитіші спеціалісти можуть стикатися з проблемами через непорозуміння у спілкуванні.

Саме тому ми з директором компанії Design and Test Lab Володимиром Обрізаном вирішили розібратися з технікою надання конструктивного фідбеку та впровадили цю культуру в компанію. У цій статті я поділюся моделлю та практичними прикладами надання конструктивного фідбеку, які ми вже успішно застосовуємо в IT-командах.

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

Коли ми відчуваємо, що щось у відносинах на роботі йде не так, то ми часто:

мовчимо, бо боїмось образити;
висловлюємось занадто емоційно, коли накипіло;
кидаємо пасивно-агресивні репліки на дейлі-мітингу — замість того, щоб звернутись напряму;
конфлікт вже є, а ми робимо вигляд, що все нормально.

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

У Design and Test Lab ми вирішили розвинути одне одного та провели два тренінги з конструктивного фідбеку, розібрали десятки реальних кейсів, попрактикувались у парах, обговорили барʼєри, страхи, зворотний зв’язок.

І я хочу поділитись у статті з вами найціннішим:

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

Давайте розбиратись разом, як побудувати лояльну та ефективну команду і як її зміцнювати для досягнення цілей організації.

Що таке конструктивний фідбек і чому це важливо — простою мовою

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

Чотири ознаки конструктивного фідбеку:

Конкретність: фокус на діях, а не на особистості.
Опис ситуації, а не оцінка.
Я-висловлювання замість ти-звинувачень.
Пошук та пропозиція рішень, а не «випуск пари».

Порівняємо «випуск пари» та конструктивний опис ситуації:

❌ «Ти знову запізнився — це безвідповідально!»
✅ «Коли ти запізнюєшся, мені складно планувати зустрічі. Мені важливо, щоб ми починали вчасно».

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

📚 Я багато читала на цю тему. І от що мені запам’яталось:

У двохфакторній теорії Герцберга фідбек належить до мотиваційних факторів. Це не бонус «якщо пощастить». Визнання досягнень, підтримка, розвиток — те, що тримає людину у включеному стані. Фідбек підкреслює людині, що її робота прийнята, сприймається позитивно, що вона досягла успіху та взагалі має сенс.
У теорії цілей (SMART) фідбек — обов’язковий супутник досягнення мети. Ціль без фідбеку — це просто план. А з фідбеком — це постійний розвиток і удосконалення.

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

💬 Колись я прочитала фразу: «Фідбек — це складна річ, треба навчитись його сприймати». І я згодна. Але хочу додати своє: Фідбек треба навчитись давати. Бо тільки тоді ми будуємо команду, яка не здогадується, що не так, а розуміє, покращує і працює разом.

Давайте вчитись разом!

Етапи надання конструктивного фідбеку

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

Давайте розглянемо чотири етапи надання конструктивного фідбеку по моделі PINE. А далі у статті ми покажемо, як вирішити різні ситуації, зокрема під час код-рев’ю, за допомогою цієї моделі.

PINE — модель надання конструктивного фідбеку:

Preparation — Підготовка
Initiation — Ініціація
Negotiation — Переговори
Evaluation — Оцінка / наступні дії

В моделі PINE ці етапи надання конструктивного фідбеку даються послідовно:

Підготовка

Потрібно усвідомити досягнення або проблему, сформувати мету — чого я очікую після надання фідбеку. Обираю час та місце та техніку, за допомогою якої й буду надавати фідбек.

1️⃣ Визначити проблему. Запитай себе

Що саме мене турбує?
Чому я хочу це обговорити?
Як ця ситуація виглядає з мого боку?
Як її може бачити інша людина?

2️⃣ Сформулювати мету 🎯 Чого я очікую після фідбеку?

Покращити співпрацю?
Уникнути помилок у майбутньому?
Домовитись про нові правила гри?

3️⃣ Оцінити доцільність

Чи впливає проблема на якість роботи, строки, командну атмосферу?
Наскільки це важливо для мене у виконанні моєї роботи?
Чи бачу я картину загалом і чи ця людина дійсно повинна отримати фідбек?

4️⃣ Обрати час і місце 🕒 Коли і де говорити?

Розмова = 50% вчасність.
Особисто — завжди краще, ніж у чаті.
Приватна атмосфера = більше шансів бути почутим.

5️⃣ Визначити підхід

💬 Використай «Я-висловлювання»:

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

Ініціація

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

✅ КРОК 1. Зробіть перший крок

Очний фідбек: у приватному, безпечному просторі.
Письмовий: з повагою до контексту (не в загальний чат, а особисто, у оцінці 360 градусів).

💬 Почніть м’яко:
«Маю важливу річ, яку хотів би обговорити з тобою. Це впливає на нашу роботу.»

✅ КРОК 2. Сформулюйте проблему через «Я-висловлювання»

🧩 Структура: Коли... (опис ситуації), Я відчуваю... (емоція), Тому що... (наслідок/вплив)

✅ КРОК 3. Уважно слухайте

👂 Активне слухання = довіра

Не перебивайте
Задавайте уточнюючі запитання
Дивіться не лише на слова, а й на емоції за ними

💬 Запитайте: «Як ти бачиш цю ситуацію? Що з твого боку могло її спричинити?»

Для цього вам допоможуть відкриті питання.

✅ КРОК 4. Узагальніть спільну позицію

📣 Підсумуйте, щоб переконатися, що ви розумієте одне одного.

📌 Фрази-помічники:

«Я правильно зрозумів, що...»
«То виходить, для нас обох важливо...»

Переговори у пошуках win-win рішення

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

1️⃣ Створіть спільне бачення проблеми

Переконайтесь, що ви однаково розумієте суть проблеми. Сформулюйте її нейтрально: «Мені здається, що в нас є різне бачення процесу рев’ю. Я бачу, що це створює напругу, а ти?»

2️⃣ Озвучте фідбек з опорою на факти

Техніка «Я»-висловлювання (Коли... я відчуваю... тому що...)

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

3️⃣ Запропонуйте варіант вирішення та послухайте іншу сторону

Покажіть, що ви не нав’язуєте рішення, а готові разом шукати вихід.

4️⃣ Слухайте активно і уважно

Зосередьтесь на розумінні аргументів та почуттів іншої сторони, навіть якщо вони відрізняються від ваших.

📌 «Я чую, що ти хвилюєшся через нестачу часу. Це справді важливо врахувати».

5️⃣ Узагальніть позиції та визначте зони згоди/розбіжностей

Сформулюйте прогрес у спільному розумінні:

🟢 «Ми згодні, що дедлайни важливі. Ми не згодні щодо обсягу задач. Давай сфокусуємось на розрахунку навантаження».

6️⃣ Знайдіть win-win рішення

Разом оберіть варіант, який:

Реалістичний для обох сторін та компанії.
Вирішує суть проблеми.
Має чіткі кроки й відповідальність.

Оцінка і подальші дії

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

1️⃣ Визначте чіткі критерії прогресу після фідбеку

Зафіксуйте, що саме має змінитись у поведінці або роботі. Домовтесь, як і коли ви оцінюватимете прогрес. Визначте конкретні індикатори: дедлайни, якість, поведінка, дії.

📌 Наприклад: «Ми домовились, що ти щоп’ятниці о 12:00 оновлюєш статус задач у Jira».

2️⃣ Налаштуйте систему зворотного зв’язку

Короткі регулярні 1:1, рев’ю, стендапи або оновлення в чаті. Частота: щотижня, раз на 2 тижні — залежно від теми фідбеку.

Питання для перевірки:

Що змінилося у поведінці/в роботі?
Що працює добре?
Що ще викликає труднощі?

3️⃣ Надавайте підкріплюючий фідбек (позитивне підсилення)

Підкреслюйте навіть невеликий прогрес:

🗣 «Я дуже ціную, що цього тижня ти вчасно оновив усі задачі — це значно полегшило мені планування спринту».

🗣 «Помітила, що ти був уважніший до тону в коментарях — це дуже позитивно вплинуло на атмосферу в рев’ю».

Це мотивує людину підтримувати зміни. ⚠️

4️⃣ Розробіть план дій на випадок відхилення від домовленостей

Визначте, що може піти не так (ризики, слабкі місця).

Складіть «план Б»: що ви робите, якщо результату немає.

📌 Наприклад: «Якщо наступного тижня знову виникне затримка — ми разом подивимось, як можна перерозподілити завдання або уточнити пріоритети».

5️⃣Уникайте псевдокомпромісів

Будьте чесними з собою: де рішення лише виглядає як компроміс, але по факту дозволяє проблемі зберігатися.

Наприклад: «Ну, добре, я ще трохи потерплю, може, все само минеться» — ❌ не спрацює.

⚡ Модель PINE допомагає пройти шлях від проблеми до рішення конструктивно.

Формула, яка працює: техніка «я-висловлювання»

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

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

Воно складається з трьох частин:

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

Кілька прикладів, які команда опрацьовувала на тренінгу:

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

Коли ми говоримо від себе, ми відкриваємо можливість бути почутими. А це вже половина успіху в будь-якому фідбеку.

Кейси з життя команди

Ми провели два тренінги з конструктивного фідбеку — і я хочу поділитися реальними ситуаціями, які розбирали разом, і як ми навчились надавати конструктивний фідбек за моделлю PINE.

Почнемо з ситуації, яку ми описали раніше у прикладі про код-ревʼю як неправильний та неконструктивний фідбек, і перетворимо його за допомогою моделі PINE на конструктивний.

Ситуація перша

Ліза часто залишає коментарі в pull request’ах з емоційною лексикою або сарказмом, використовує фрази на кшталт «це лайнокод», «так ніхто не пише», «ти взагалі програмування вчив?». Олександр, який отримує ці коментарі, починає сумніватися в собі та уникає публічного обговорення своїх рішень. Але наважився надати коментар Лізі.

Неконструктивний фідбек

Олександр:

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

Ліза:

— Ой, вибач, що не гладжу тебе по голові. Це — робота, а не гурток підтримки. Якщо не вмієш сприймати критику — не пиши код, який треба виправляти. Я не твоя мама.

Фідбек за чотирма етапами надання конструктивного фідбеку

1. Підготовка

Визначити проблему:

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

Сформулювати мету:

Мета фідбеку: покращити комунікацію в код-рев’ю, знизити напругу, домовитись про поважний тон.
Що я очікую? — Більше нейтральних і конструктивних формулювань у коментарях.
Чому я хочу це обговорити? — Щоб я міг без страху і стресу брати участь у відкритому рев’ю.

Оцінити доцільність:

Так, це критично важливо: впливає на командну динаміку, мій вклад у проєкт і мій професійний розвиток.

Обрати час і місце: формат: Особиста зустріч 1:1 (не в чаті, не на рев’ю).

Визначити підхід: використовую «Я-висловлювання».

2. Ініціація

Зробити перший крок:

— Привіт, Ліза. Є тема, яку хотів би обговорити з тобою. Це впливає на мою залученість у рев’ю, і я вважаю, що ми можемо разом знайти рішення.

Сформулювати проблему через «я-висловлювання»:

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

Уважно слухати іншу сторону: Ліза має право пояснити свою точку зору: наприклад, вона поспішає, і тому не фільтрує тон.

Узагальнити спільну позицію:

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

3. Переговори у пошуках win-win рішення

Спільне бачення проблеми:

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

Озвучити фідбек з опорою на факти:

— Я зібрав кілька прикладів, де коментарі були емоційно забарвлені. Наприклад, в останньому PR було «ну, це очевидна помилка» — мені складно з цим працювати, тому що я не розумію, у чому саме проблема.

Запропонувати варіант вирішення:

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

Слухати Лізу. Вона може сказати:

— Добре, я спробую переформулювати. Я вважала, що ти вже вивчив мій стиль кодування, та просто звикла до жорсткого стилю рев’ю — так робив мій тімлід, коли я була на стажуванні.

Узагальнити позиції:

— Тобі важлива швидкість, мені — безпечне середовище для зростання. Якщо ми обидва формулюємо зауваження конструктивно, то рев’ю буде швидшим і якіснішим у довгостроковій перспективі.

Пропонуємо win-win рішення:

— Домовимось: ти звертатимеш увагу на тон коментарів, а я зобов’язуюсь ознайомитись з твоїм стилем кодування та реагувати на фідбек оперативно та без образ. Якщо щось незрозуміло — уточнюю напряму в особистих.

4. Оцінка і подальші дії

Критерії прогресу виконання цього win-win рішення:

Коментарі у PR — без сарказму, чіткі, з фокусом на дію.
Активність Олександра у відкритих обговореннях — зростає.
Комунікація — спокійна, без пасивної агресії.

Зворотний зв’язок: регулярні короткі 1:1 (раз на 2 тижні) — перевірка атмосфери, уточнення, що працює або не працює.

Підкріплюючий фідбек:

— Я помітив, що останнім часом твої коментарі дуже чіткі й по суті — це реально спрощує мені рев’ю. Дякую тобі!

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

Уникнення псевдокомпромісів: Не ігнорувати нові прояви агресії / сарказму — діяти одразу, не «терпіти».

Результат: Комунікація очищена, рев’ю стало безпечнішим. Олександр активніший, Ліза — уважніша до формулювань. Команда працює ефективніше.

Ситуація друга

Ігор координує розробку вебпроєкту між двома командами: frontend та бекенд. Марина — front-end розробник. Минулого тижня Марина мала реалізувати редизайн сторінки оплати. Після релізу клієнт виявив, що не працює кнопка підтвердження — бо Марина прибрала стару логіку в JavaScript, не протестувавши всі сценарії. Після виявлення проблеми Марина сказала: «Це, напевно, бекенд не віддає статус. Я просто зробила те, що було у Figma». Але бекенд працював — це було підтверджено, та й змін за останні тижні там не було. Ігоря турбує, що помилку не визнали і не зробили висновки.

Неконструктивний фідбек

Ігор: «Марина, це вже не вперше! Через твою неуважність клієнт не приймає роботи та не сплачує інвойс. Як можна було відправити на прод без тестів? Це халатність!»

Що не так:

Відкрите публічне звинувачення.
Емоції замість фактів.
Немає спроби знайти причини.
Підриває довіру і викликає захисну реакцію.

Фідбек за чотирма етапами надання конструктивного фідбеку

1. Підготовка

Після релізу не працювала кнопка підтвердження. Виявилось, що Марина прибрала JS-логіку, не протестувавши повністю. Відповідальність не взяла, сказала: «Я просто зробила, як у Figma».

2. Ініціація

Ігор:

— Марина, хочу обговорити ту помилку з кнопкою — це важливо для нашої якості. Маєш 15 хвилин?

Я-висловлювання:

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

Слухання + уточнення:

— Як ти бачиш ситуацію? Що вплинуло на твоє рішення?

Узагальнення:

— Тобто ти спиралась лише на макет і не мала повної картини логіки?

3. Переговори у пошуку win-win рішення

Спільне бачення:

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

4. Оцінка і подальші дії

Прогрес:
— Самоперевірка після кожного редизайну.
— Маркер задач зі зміною логіки.

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

Підкріплення: «Дякую, що цього разу перевірила всі сценарії — це суттєво покращило стабільність».

План Б: «Якщо ще виникне проблема — переглянемо пріоритети або процес рев’ю».

Ситуація третя

Оксана — досвідчена QA-інженерка, яка працює в компанії вже 5 років. Після релізу виявили критичний баг, який начебто мав бути помічений під час тестування. На загальному мітингу тимлід Артем одразу висловив претензії в бік Оксани, не з’ясувавши всіх обставин. Проте Оксана перед тим питала, що робити, якщо бекенд ще не готовий — Артем відповів: «немає часу вже чекати, тестуй поточну версію». Оксана протестувала те, що було доступно. Бекенд викотили наступного дня — вона не мала доступу до нього вчасно. Артем не з’ясував, хто був відповідальний у першу чергу.

Неконструктивний фідбек

Артем: «Оксано, я не розумію, як ти могла це пропустити. Я вислухав від клієнта 15 хвилин сумнівів у нашій компетенції! Це твоя зона відповідальності, і ти знову не впоралася. Команда вкладається в дедлайни, а через твою неуважність ми маємо факап. Якщо ти й далі так працюватимеш, нам доведеться переглянути твою роль у проєкті.»

Оксана: «Серйозно? Ти навіть не запитав, чому це сталося. Я працювала з нефінальною версією, бо бек не оновили вчасно, а ти сказав: „Тестуй!“. Але окей, звинувачувати — простіше. Якщо ти вважаєш, що вся вина на мені — супер. Можеш не чекати, що я далі вкладатимуся на повну.»

Конструктивний фідбек

1. Підготовка

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

2. Ініціація розмови

Артем:

— Оксано, я хотів би обговорити ситуацію з останнім релізом і нашим флоу тестування. Мені важливо зрозуміти, як ми можемо покращити процес, щоб уникнути подібних багів у майбутньому. Чи можеш виділити 15 хвилин на розмову?

3. Переговори (фідбек і діалог)

Артем (я-висловлювання): «Коли ми виявили критичний баг після релізу, я відчув розчарування і напругу, тому що це вплинуло на довіру з боку клієнта. Тоді я одразу сказав тестувати, не перевіривши, чи був вже доступний бек. І, чесно кажучи, не розібрався, хто мав відповідати на якому етапі. Я розумію, що це могло спричинити плутанину в твоїй роботі. Хотів би вибачитись, що дав тобі завдання без уточнення контексту.»

«Мені важливо зрозуміти, як це виглядало з твого боку — чи була в тебе змога ефективно протестувати, і що можна покращити в нашій комунікації?»

Оксана (можлива відповідь):

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

Артем:

— Я тебе чую. Це справді могло виглядати, ніби ти відповідальна за помилку, хоча бек з’явився пізніше. Дякую, що пояснила.

4. Оцінка і подальші дії

Артем:

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

— Мені важливо, щоб ти відчувала впевненість у своїй роботі, бо я ціную твій досвід і твою увагу до деталей.

Цей приклад показує конструктивний тон, відповідальність за власні дії з боку Артема, фокус на вирішення, а не звинувачення, і дії для покращення взаємодії в майбутньому.

Ситуація четверта

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

Неконструктивний фідбек

Тім-лід: «Аліна, ти молодець, що допомагаєш. Продовжуй у тому ж дусі!»

Аліні може бути незрозуміло, за що її похвалили, бо вона допомагає тімліду у багатьох питаннях. Це за адаптацію, чи за код-ревʼю, чи за діагностику помилок? Аліна відчуває напругу: «Якийсь шаблонний фідбек. 🤔 Чи дійсно тімлід так вважає, чи відповів мені формально?»

Конструктивний фідбек

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

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

Ситуація п’ята

Дарина — мідл-тестувальниця. Минулого місяця вона ініціювала внутрішню міні-лекцію для команди з API-тестування. Підготувала презентацію, відповіла на всі питання, зібрала фідбек. Команда вперше відчула, що може самостійно рухатись у складніші напрями. А особливо це було цінно для джуніора Олексія. Project Manager надає фідбек.

Неконструктивний фідбек

Project Manager: «Дарина, круто, що провела лекцію. Мені сподобалось. Молодець!»

Дарина відчуває напругу: «Хм, наче похвалили, але якесь таке відчуття дивне... Чи сподобалось, що я ініціатор? Чи те, що була взагалі хоч якась лекція? Чи те, що я поділилася своїм ефективний методом тестування?»

Конструктивний фідбек

Project Manager: «Коли ти ініціювала та провела лекцію з API-тестування, я відчув справжню гордість за команду, тому що ти не лише поділилася знаннями, а й запустила процес професійного росту зсередини. Це справді допомогло Олексію зробити перші кроки в складнішому напрямі. А я бачу в цьому не лише експертизу, а й лідерство, що дуже цінно для команди».

Поради: як застосовувати фідбек щодня

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

1. Дотримуйтесь принципу «малими дозами — часто». Не чекайте 1:1 або перформанс-рев’ю. Надавайте короткий фідбек одразу після ситуації — це підсилює зв’язок між дією та результатом.

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

🔴 Замість: «Ти молодець, активний на мітах» (без деталей через 3 тижні).

2. Говоріть про дію, а не про особистість. Фокусуйтесь на тому, що сталося, а не на рисах характеру. Це дозволяє людині не оборонятися, а чути.

📌 Формула: «Коли [подія], я відчув [вплив], тому що [наслідок для процесу/команди]».

3. Баланс позитивного й коригувального фідбеку. Якщо ви даєте лише негативний фідбек — це підриває мотивацію (людина не отримує позитивний фідбек та вважає, що взагалі нічого не може зробити добре та її робота не має сенс). Якщо тільки позитивний — не сприяє росту та не вирішує існуючі конфлікти. Дотримуйтесь балансу.

4. Фідбек — це діалог, а не монолог. Інша сторона має право на відповідь. Запитуйте: Що ти думаєш про це? Як бачиш ситуацію зі свого боку? Що могло б тобі допомогти?

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

6. Використовуйте канали розумно. Письмовий фідбек — для фактів. Усний — для емоційного контексту. У чаті — короткий, нейтральний. Складне — тільки особисто або віч-на-віч онлайн.

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

8. Не перетворюйте це на «мікроменеджмент». Фідбек — не про контроль, а про розвиток. Не варто коментувати кожен крок, особливо без запиту. Поважайте зону відповідальності.

Коротка інструкція «як застосовувати фідбек щодня»:

Дія	Приклад
Надаю одразу	«Класна структура презентації — було зрозуміло з перших слайдів».
Чітко про поведінку та робочий вплив	«Твій коментар в чаті допоміг заспокоїти команду, та я не витрачав багато часу на відповіді кожному особисто».
Запрошую до відповіді на відкрите запитання	«Чи ти бачиш це інакше?»
Фіксую прогрес	«Бачу, що вже другий тиждень немає помилок у тест-кейсах — дякую».
Уникаю узагальнень	«Ти завжди...» або «Ти просто такий.»

Джерела

Модель цього тренінгу поєднує підходи, описані в загальнодоступних методиках фідбеку (SBI, BOOST, IDEA, EEC, STAR) та стратегіях конструктивного вирішення конфліктів (collaborative conflict management), з корпоративними практиками, відомими в провідних технологічних компаніях. Одним із натхнень стала концепція constructive confrontation, яку застосовує компанія Intel — культура відкритого, але поважного обговорення робочих питань, де увага зосереджена на ідеях, а не на особистостях.

На основі цих джерел ми створили та адаптували модель надання конструктивного фідбеку для нашої компанії Design and Test Lab. Ми доповнили її реалістичними прикладами для команд розробки програмного забезпечення, включили кейси з позитивним фідбеком та пристосували її для щоденного використання в роботі.

https://tinyurl.com/2s4dxyhx