Техники обратной связи для тимлида: разбор с примерами
Кажется, что сложного — прийти к сотруднику и дать ему обратную связь. Мы же десятки раз преодолевали то, на чем стопорятся они. Можем увидеть, что человек движется не в ту сторону или закопался в задаче. Направить в нужное русло. Подкинуть вариантов, как еще расти в компании. Повысить мотивацию, наконец.
Но на практике, мы не всегда умеем. Боимся испортить отношения с теми, кто круто перформит, но не очень софтскилловый. Возможно, как-то выдали критику и она сработала не в ту сторону. Я изучил порядка 30 моделей, выбрал самые, на мой взгляд, понятные — о них и пойдет речь.
Инструменты для встреч 1-на-1
Модель бутерброда (похвала-критика-похвала)
Посмотрим на структуру:
А теперь — еще пример. Есть QA-инженер, который в целом молодец, но не выполняет задачи из личного плана развития. Мы хотим улучшить его результаты, для этого надо как-то скорректировать его поведение. Что можно сделать?
Сказать:
«Слушай, ты классно выполняешь основные задачи, после тебя мало багов. Но есть проблема с планом твоего развития: прошло 4 месяца, а задачи из него сделаны на 20–30%. Давай выберем тему, сосредоточимся на ней и закроем на 100%. Например, у тебя хорошо получается в автоматизацию, — давай пойдем туда?»
Похвала в начале психологически раскрепощает человека — важно показать, что вы его цените. Тогда дальнейшую критику он воспримет более мягко.
В блоке критики важно подсветить, что это проблема — бывает, человек ее не видит.
Выходим на похвале, чтобы настроить сотрудника на позитивный лад: все не так плохо, ситуацию можно поменять. Желательно давать конкретные действия, потому что иногда человек сам не видит, как можно выбраться из этой ситуации.
Есть одна опасность — если вы раньше никогда не хвалили сотрудника и тут вдруг начинаете с похвалы, он может напрячься.
Сторителлинг (когда нужно, чтобы фидбек хорошо зашел в голову)
Есть QA-лид, который не выполнил цель на квартал, — потому что ему кажется, что у него недостаточно влияния. Если у вас есть история, которая касается его ситуации — в идеале, из личного опыта, — время поделиться ей.
Например:
«Знаешь, когда я пришел в компанию, не все задачи тестировались. Некоторые сразу отправлялись в бой, а особо умные разработчики сразу вносили правки на проде. Я просил так не делать, но кто я для них? В общем, поругался, потом устал и перестал. Но стал подсвечивать проблемы, которые случались из-за этого. Рассказывал, объяснял — и оказалось, что проблема волнует всех, просто не все понимали ее масштаб. Так ответственность стала постепенно общей, разработчикам добавили (а потом убрали) KPI, они стали добрее. А у меня появилось влияние».
Вы раскрываете конфликт интересов, показываете, как проявляли характер.
Цель рассказа — подвести человека к умозаключению. Он должен сделать вывод сам. Для этого история должна иметь завершение для героя, но не для слушателя — он должен иметь возможность додумать, что происходило дальше, как вы развивались.
Модель BOFF (поведение-результат-чувства-будущее)
Еще пример: есть тестировщик, который перестал писать тестовую документацию по задачкам. В один момент это было ок — запускали маркетинговую акцию, нужно было спешить. Но после того случая он перестал писать кейсы совсем. И в результате у нас пошло большое количество багов.
Когда человек расслабился, стал равнодушным и небрежно относится к работе, можно зайти через чувства:
«Я посмотрел последние 30 задачек, они все без кейсов. Это вылилось в проблемы с маркетингом. Я расстроен — мы снижали баги последние 3 года, но за один месяц ты сильно провалился. Давай больше так не делать. Начнем писать кейсы и посмотрим на результаты последующих 10 задач».
Приводим факты, желательно со статистикой, — что изменилось в поведении сотрудника. Лучше подготовиться и собрать данные заранее. Иногда, когда ситуация сложная, надо собрать факты, поговорить с кем-то, на подготовку может уйти 2–4 часа. Но если задача важная, оно того стоит.
Что получилось и к чему это привело: обсуждаем причины, объясняем последствия — например, мы теряем клиентов, выручка падает.
Чувства. Рассказать, что вы как руководитель расстраиваетесь, — обычно это помогает чуть ярче донести, в чем именно не прав человек.
А дальше заканчиваем на позитиве — говорим о будущем и что нужно сделать, чтобы ситуация не повторилась. Желательно давать больше конкретики — и обговорить сроки. Если вы скажете: «Больше так не делай», — и придете через полгода, есть вероятность что ничего не изменится.
Важно, чтобы сотрудник не только принял, что он будет изменяться. Но и понят, когда он будет эти изменения производить. Если нужно, назначьте дату для такой задачи, помогите декомпозировать ее на более простые кусочки — и пусть двигает по ним.
Модель SOR (стандарт-наблюдение-результат)
У вас в команде или компании есть правила, но кто-то их игнорирует, хотя в целом претензий к человеку нет. Например, сотрудник систематически не логирует время —, а вам нужно понимать, какой проект и сколько ресурсов занял. Фактически человек работает — и мы это знаем, но в итоге реально не понимаем, уложились в оценку или нет, и как планировать.
Но если вы просто придете и скажете: «Надо логировать 8 часов», — он подумает: «Ну, докопался». И не факт, что будет это делать.
«Я посмотрел твои отчеты за август, и было то 3 часа, то 5, то 8. Вот смотри, у остальных все хорошо, а именно у тебя почему-то не логируется».
Напоминаем о стандартах и почему их вводили, какова была цель.
Дальше рассказываем о наблюдениях — с цифрами, с фактами.
Объясняем, как действия влияют на работу компании — опять же, на конкретных примерах.
В идеале, в этот момент сотрудник должен озвучить готовность соблюдать эти стандарты.
Как давать обратную связь в команде
Не забывайте про daily meet для синхронизации — не обязательно ежедневные, но короткие встречи (все, что не можем быстро решить, выносите в отдельные встречи), которые дают контекст. Важно, чтобы соблюдалась регулярность и четкость состава: если мы говорим, встречаемся раз в неделю, значит, раз в неделю встречаемся —, а все люди, которые приглашаются на встречу, либо должны приходить, либо их не должно быть на этой встрече. Это обязательно.
Feed Forward — фокусируемся на том, что нужно сделать человеку, чтобы команде стало лучше. Мы не можем изменить прошлое. Но зато можем повлиять на будущее. Цель этой техники — сосредоточиться на изменениях, показать их позитивное влияние на будущее команды.
Скажем, есть в команде человек, который постоянно опаздывает на встречи — вся команда собирается вовремя, а он приходит через несколько минут. Меня, как лида, у которого десятки митингов, это сильно аффектит. Но я могу не концентрироваться на негативе, а предложить образ будущего, который решит проблему для всех.
«Предлагаю тебе заходить за 2 минуты до митинга, сидеть в онлайне и ждать всех остальных».
Что важно — мы не обсуждаем, что было сделано плохо. Это не ретро. Мы не оцениваем, а сразу предлагаем изменение и конкретные действия.
Ретроспективные техники
4 пальто — делаем выводы из ошибок (в большей степени)
Во многом это можно назвать классическим ретро. Мы закончили проект, а дальше каждый из членов команды высказывается, что в целом случилось, что было плохо, что было хорошо и что стоит с этим делать.
Порядок имеет значение. Мы начинаем с контекста, потом озвучиваем негатив, затем добавляем позитив — и строим план на будущее. Например, это может выглядеть так:
Факт: мы запустили новый функционал на сайте, но сделали это с опозданием.
Оценка задач была некорректная — это то, что было плохо.
Что было хорошо: в принципе, мы выкатили, конверсия у нас подросла, багов было не очень много.
И что делать дальше: доработать процесс планирования и оценки ресурсов.
В этой техники мы в основном берем в «что делать дальше» вещи из негативного блока: что было плохо и надо поменять, чтобы двигаться. При этом «черное пальто» сложнее всего носить — и важно, чтобы люди «надевали» его и на себя, а только потом на всех остальных. Иначе есть риск, что люди в команде начнут друг друга «убивать» и это подорвет доверие.
Модель SLC — делаем выводы из успехов, чтобы новые стандарты и алгоритмы
Здесь мы не обсуждаем негатив и не носим «черное пальто». Фокусируемся на двух успешных кейсах за проект, одном извлеченном уроке и одном изменении, которое стоит применить в следующий раз.
Порядок важен и тут. Есть контекст: автоматизировали сборку окружения для тестирования на одном из проектов. Вспоминаем, как это помогло. Делаем вывод, что в целом это выгодная практика для длительных проектов.
Опять же используется в командах. И по идее каждый следующий проект, по этой технике разобранный, должен вести к успеху еще большему, чем есть. Т.е. вы каждый раз берете самое лучшее и применяете к следующему проекту.
Ошибки, которые мы часто совершаем при использовании этих (и любых других) техник
Оцениваем человека, а не его действия
Переход на личности, эмоции, особенно мат, — этого лучше не делать. Это показывает вашу слабость, неумение общаться. Смотрите именно на ситуацию, на поведение и его причины — обычно это не человек простой, это система мешает ему двигаться, вот он и изворачивается.
Сравниваем людей
Никто не любит, когда его сравнивают — сотрудник скорее воспримет это как негатив, демотивируется. Тем более, люди обычно не видят всей работы другого человека и готовы возразить: «А я делаю больше». Я всегда стараюсь проговаривать, что это твоя личная история, мы развиваем тебя, но ты можешь взять опыт кого-то из коллег.
Не даем конкретику
Если мы говорим человеку, что «что-то плохо», «не очень круто» и так далее, то должны подтверждать это собранными фактами. Факты также важны, когда к вам, например, приходят и говорят про ваших сотрудников. Разберитесь сами — может быть, люди просто не разобрались. Не надо сразу бежать к сотруднику и говорить: «Смотри, мне на тебя пожаловались».
Включаем догадки
Пытаясь анализировать мотивы человека на уровне «он сделал это, потому что не любит нашу компанию», вы, как правило, не попадете в точку. Проще прийти и спросить: «А почему ты так сделал?» Человек выдаст свою версию.
Не умеем слушать
Любая техника по факту очень проста, а сложности возникают, когда вы где-то не состыковываетесь. Например, если включаем установку «я руководитель, я самый умный». Это одна из частых проблем — мы начинаем выдавать тонну фидбека, сотрудник пытается в ответ что-то выдать, но мы увлекаемся и можем не услышать его.
Несвоевременно даем обратную связь
Не ждите, когда попросят. Иногда надо приходить первому, ставить эти встречи. Если вы долго не общались с сотрудником, это ваша проблема, это вы недорабатываете. Делая что-то нерегулярно, мытеряем прогресс, которого добились ранее — настраивайте регулярные временные промежутки для обратной связи.
Послесловие
Моделей много, но у них есть одна и та же суть. Всегда есть ситуация (проблема), есть последствия, которые мы получаем, и то, как можно из нее выйти.
Дальше нужно выбирать по ситуации, а то и по интуиции: вот здесь, кажется, подходит такая-то модель, ее и попробуем применять. Обратная связь — это инструмент. И его можно научиться использовать.
