Когда дать обратную связь?

Когда давать обратную связь: Профессиональный подход

Определение

Обратная связь (Feedback) — это информация о результатах или качестве выполняемой работы, которая помогает человеку улучшить свои навыки, поведение или результаты.

Когда давать обратную связь

1. Сразу после события (Best Practice)

Оптимально давать feedback в течение 24-48 часов после события:

// Пример: код review
// Понедельник, 10:00 — разработчик выложил PR
// Понедельник, 14:00 — лучшее время для feedback
// (память свежая, контекст в голове)

// ❌ Неправильно: feedback месяц спустя
// "Помнишь, месяц назад ты писал код в методе foo()?
// Там была проблема с..." — контекст потерян

// ✅ Правильно: feedback день спустя
// "Вчера ты выложил PR #123. Отличная работа, но я хотел
// бы обсудить один момент в методе foo()..."
// — контекст свежий, легче исправить

2. Когда ошибка может повториться

Дай feedback немедленно, чтобы человек не повторил ошибку:

// ❌ Неправильно: ждать планерки
Разработчик: "Я только что задеплоил изменения"
Твой друг (через час): "О нет, это сломало production!"
Ты (но заметил только в планерке): "Кстати, почему ты так сделал?"
// Слишком поздно, уже 10 пользователей потеряно

// ✅ Правильно: feedback немедленно
Ты видишь код → сразу говоришь:
"Стоп, этот код может привести к null pointer exception
 при параллельном доступе. Давай обсудим перед деплоем."
// Проблема предотвращена на этапе разработки

3. Когда работник готов к feedback

Дај feedback, когда человек психологически подготовлен (не в стрессе):

// ❌ Неправильно: во время срыва дедлайна
// Разработчик работает 12 часов, пытается встать в дедлайн
// Ты заходишь: "Кстати, твой код некачественный, давай переделаем"
// Ответ: "Не сейчас, я спешу!" → feedback неэффективен

// ✅ Правильно: после успешного деплоя
// Разработчик вздохнул с облегчением, дедлайн встан
// Ты: "Отлично, сделали в срок! Хотел бы обсудить несколько моментов
// в твоем коде, от которых бы выиграла система"
// Человек готов слушать и учиться

4. Когда есть конкретные примеры

Дај feedback с конкретными примерами, не абстрактно:

// ❌ Плохо: абстрактный feedback
"Твой код плохой. Нужна лучшая архитектура. 
Работай над качеством."
// Что делать? Непонятно. Демотивирует.

// ✅ Хорошо: конкретные примеры
"В методе UserService.updateUser() у тебя 50 строк кода,
который делает 5 разных вещей:
1. Валидацию
2. Логирование
3. Обновление БД
4. Отправку email
5. Синхронизацию с Redis

Предлагаю разбить на отдельные методы/классы:
- updateUserData()
- sendNotification()
- syncCache()

Это упростит тестирование и понимание кода."
// Четко видно что делать

5. Перед критическими решениями

Дај feedback ДО того как решение будет имплементировано:

// ❌ Неправильно: feedback после написания
Разработчик потратил 3 дня на имплементацию микросервиса
Ты: "Ммм, это не нужно было делать так. Лучше было..."
// 3 дня работы выброшены

// ✅ Правильно: feedback до начала
Разработчик: "Я хочу создать отдельный микросервис для уведомлений"
Ты: "Подожди, давай обсудим. По моему опыту:
- Сейчас уведомления не требуют отдельного сервиса
- Можно обойтись очередью в основном приложении
- Микросервис усложнит нашу инфраструктуру

Давай сначала реализуем в основном приложении, а потом,
еслиъ нужно масштабировать, отделим."
// Экономим 3 дня и избегаем усложнения

6. Публично или приватно?

Похвалу давай публично, критику — приватно:

// ❌ Неправильно: критика на планерке
// На планерке (20 человек):
"Иван, твой код качается. Ты не тестировал?
Так нельзя было делать. Вообще, у тебя проблемы с дизайном."
// Иван: красный, унижен, защищается, аудитория смешится
// Эффект: 0, конфликт +1

// ✅ Правильно: критика один-на-один
// Приватная встреча:
"Иван, хочу обсудить твой PR. В целом направление правильное,
есть несколько моментов, которыми я озадачен:
1. В методе foo() нет unit-тестов. Как ты планировал это тестировать?
2. Эта логика похожа на то, что уже есть в Bar.java. Может
объединить?
3. О-wait, а что если concurrency issue? Как обезопасил?

После обсуждения Иван понимает, учится, улучшает код.

// Публично хвали:
// На планерке или Slack:
"Отлично сработал Иван с PR #456! Очень чистый код,
отличное покрытие тестами. Отличный пример для команды."
// Иван: гордится, команда видит лучший пример, мотивация растёт

7. Регулярно, не только проблемы

Дај feedback не только когда проблемы, но и когда работник хорошо сделал:

// ❌ Неправильно: только критика
// Разработчик видит тебя только с плохими новостями
// Ассоциация: твоя фамилия = проблемы
// Эффект: страх, избегание, снижение мотивации

// ✅ Правильно: баланс
// 80% положительного feedback, 20% конструктивного
// "Отличная работа над API! Тесты хорошо написаны.
// Один мелкий момент: можно было использовать..."
// Эффект: мотивация, доверие, готовность слушать критику

8. Когда просят

Дај feedback всегда, когда человек просит:

// Разработчик: "Как по-твоему, мой подход верный?"
// ✅ Дай честный feedback
// "Подход в целом хороший, но я вижу три проблемы:
// 1. ...
// 2. ...
// 3. ...
// Вот мои предложения..."

Когда НЕ давать обратную связь

1. Когда эмоции зашкаливают

// ❌ Неправильно: feedback в гневе
Твой код: 5 часов отвалился production
Ты (в ярости): "Кто ПИСАЛ этот говнокод?! Это просто ужасно!
 Я не могу поверить что ты это сделал!"
// Эффект: оборона, конфликт, никаких перемен

// ✅ Правильно: жди пока успокоишься (1-2 часа)
// После восстановления production:
Ты: "Хорошо, проблему решили. Теперь давай разберёмся,
что произошло и как избежать в будущем. Вот что я вижу..."  
// Эффект: спокойное обсуждение, конструктивные решения

2. Когда это не твоя область компетенции

// ❌ Неправильно: feedback без понимания
// Ты (frontend разработчик): видишь PR в backend коде
// "Не нравится тебе эта архитектура, слишком сложно"
// Backend разработчик: "Ты же frontend разработчик?
// Это обоснованная архитектура для наших требований"
// Конфликт, потеря времени

// ✅ Правильно: просишь объяснение
// "Я не специалист в backend, но могу ли я понять
// почему именно этот подход? Можешь объяснить?"
// Развивает Knowledge Sharing в команде

3. Когда информация неполная

// ❌ Неправильно: предполагаешь
// Видишь медленный query: "Почему ты не добавил индекс?"
// На самом деле разработчик уже добавил, но миграция
// ещё не накатилась на production

// ✅ Правильно: сначала уточниш
// "Я вижу, что query медленный. Это известная проблема?
// Есть план по её решению?"

4. Когда это личное мнение, не объективный факт

// ❌ Неправильно: личное мнение как критика
// "Мне не нравится твой стиль кодирования. Нужно переделать."
// Что означает "не нравится"? Субъективно

// ✅ Правильно: объективные критерии
// "По нашим code guidelines (ссылка):
// - Методы должны быть < 20 строк (у тебя 50)
// - Нужны unit-тесты для каждого публичного метода
// - Комментарии на English (у тебя Russian)
// Давай привести в соответствие с guidelines"

5. Когда человек в кризисе

// ❌ Неправильно: feedback когда стрессовано
// У разработчика:
// - Болеет сын
// - Только что потеря кого-то близкого
// - На грани срыва
// Ты: "Кстати, твой код плохой"

// ✅ Правильно: подожди лучших времён
// Скажи: "Я вижу что у тебя сейчас сложный период.
// Есть ли что я могу помочь? Код может подождать,
// главное что ты в порядке."

Как давать эффективный feedback

Структура (SBI Model)

// Situation: описание ситуации
// Behavior: что именно произошло
// Impact: какой был результат

"На планерке (Situation) ты занял микрофон и перебивал других
10 раз (Behavior). В результате мы не услышали мнение половины
команды и потеряли 20 минут (Impact)."

// ✅ Vs.
// ❌ "Ты очень поговорчив" (плохо)
// ❌ "Ты эгоист" (оскорбление)
// ✅ "На планерке ты перебивал других. Давайте в следующий раз
// слушать друг друга и давать слово каждому" (конструктивно)

Правило Sandwich (не переусложнять)

// Не делай "sandwich" из хлеба и начинки
// Это выглядит манипуляцией

// ❌ Манипуляция (sandwich):
// "Отличный код в целом. Но здесь и здесь ошибки.
Вообще ты молодец!"
// Человек понимает что это theatre

// ✅ Честно и прямо:
// "В этом PR 2 критических проблемы (ссылки).
По остальному — отличная работа. Давай это исправим."

GROW Model (для развития)

G - Goal: Что человек хочет достичь?
R - Reality: Где он сейчас?
O - Options: Какие есть варианты?
W - Will: Что он будет делать?

Ты: "Мне кажется, ты хочешь стать senior разработчиком?"
Он: "Да"
Ты: "Где ты сейчас — mid?"
Он: "Да"
Ты: "Вот что я вижу как пути развития:
1. Углубить знание в системном дизайне
2. Привести к лучшему пониманию бизнеса
3. Развить soft skills (коммуникация)

Что из этого тебе интересно?"
Он: "Системный дизайн!"
Ты: "Ok, давай построим план: читай систему design интервью книгу,
воплощай принципы в своих PR, раз в неделю обсуждаем.
 Когда ты готов начать?"
Он: "С понедельника"
Ты: "Отлично! Я буду помогать"

Timeline для feedback

Чек-лист перед тем как давать feedback

☐ Данные, которые я использую, проверены и верны?
☐ Я включаю своё эмоциональное состояние в оценку?
☐ Это конструктивная критика или я просто жалуюсь?
☐ Человек сейчас готов слушать?
☐ Я предложу решение, а не только проблему?
☐ Я помогу человеку улучшиться или просто скажу что плохо?
☐ Это публичное или приватное обсуждение?
☐ Есть ли у меня право давать этот feedback (компетенция)?
☐ Я буду благодарен за feedback в обратную сторону?

Вывод

Давай feedback: ✅ Сразу после события (1-2 дня)
✅ Когда человек психологически готов
✅ С конкретными примерами
✅ Приватно если критика, публично если похвала
✅ Когда просят
✅ Регулярно, не только проблемы
✅ Перед критическими решениями

Не давай feedback: ❌ Когда ты в гневе
❌ Без полной информации
❌ Если это не твоя компетенция
❌ Когда человек в кризисе
❌ На основе личного мнения, не фактов

Помни: хороший feedback меняет людей. Плохой feedback — ранит их.