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
