Что значит связи по руководителям

Техники обратной связи для тимлида: разбор с примерами

Кажется, что сложного — прийти к сотруднику и дать ему обратную связь. Мы же десятки раз преодолевали то, на чем стопорятся они. Можем увидеть, что человек движется не в ту сторону или закопался в задаче. Направить в нужное русло. Подкинуть вариантов, как еще расти в компании. Повысить мотивацию, наконец.

Но на практике, мы не всегда умеем. Боимся испортить отношения с теми, кто круто перформит, но не очень софтскилловый. Возможно, как-то выдали критику и она сработала не в ту сторону. Я изучил порядка 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 — делаем выводы из успехов

Здесь мы не обсуждаем негатив и не носим «черное пальто». Фокусируемся на двух успешных кейсах за проект, одном извлеченном уроке и одном изменении, которое стоит применить в следующий раз.

Порядок важен и тут. Есть контекст: автоматизировали сборку окружения для тестирования на одном из проектов. Вспоминаем, как это помогло. Делаем вывод, что в целом это выгодная практика для длительных проектов.

Опять же используется в командах. И по идее каждый следующий проект, по этой технике разобранный, должен вести к успеху еще большему, чем есть. Т.е. вы каждый раз берете самое лучшее и применяете к следующему проекту.

Ошибки, которые мы часто совершаем при использовании этих (и любых других) техник

Оцениваем человека, а не его действия

Переход на личности, эмоции, особенно мат, — этого лучше не делать. Это показывает вашу слабость, неумение общаться. Смотрите именно на ситуацию, на поведение и его причины — обычно это не человек плохой, это система мешает ему двигаться, вот он и изворачивается.

Сравниваем людей

Никто не любит, когда его сравнивают — сотрудник скорее воспримет это как негатив, демотивируется. Тем более, люди обычно не видят всей работы другого человека и готовы возразить: «А я делаю больше». Я всегда стараюсь проговаривать, что это твоя личная история, мы развиваем тебя, но ты можешь взять опыт кого-то из коллег.

Не даем конкретику

Если мы говорим человеку, что «что-то плохо», «не очень круто» и так далее, то должны подтверждать это собранными фактами. Факты также важны, когда к вам, например, приходят и говорят про ваших сотрудников. Разберитесь сами — может быть, люди просто не разобрались. Не надо сразу бежать к сотруднику и говорить: «Смотри, мне на тебя пожаловались».

Включаем догадки

Пытаясь анализировать мотивы человека на уровне «он сделал это, потому что не любит нашу компанию», вы, как правило, не попадете в точку. Проще прийти и спросить: «А почему ты так сделал?» Человек выдаст свою версию.

Не умеем слушать

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

Несвоевременно даем обратную связь

Не ждите, когда попросят. Иногда надо приходить первому, ставить эти встречи. Если вы долго не общались с сотрудником, это ваша проблема, это вы недорабатываете. Делая что-то нерегулярно, мы теряем прогресс, которого добились ранее — настраивайте регулярные временные промежутки для обратной связи.

Послесловие

Моделей много, но у них есть одна и та же суть. Всегда есть ситуация (проблема), есть последствия, которые мы получаем, и то, как можно из нее выйти.

Дальше нужно выбирать по ситуации, а то и по интуиции: вот здесь, кажется, подходит такая-то модель, ее и попробуем применять. Обратная связь — это инструмент. И его можно научиться использовать.

Источник

Почему обратная связь так важна и как правильно ее использовать в scrum-командах, чтобы получить максимум эффекта

Всем привет! Меня зовут Мария Фомина, я являюсь scrum-мастером в компании «Ренессанс страхование». Моя статья включает в себя две части: первая посвящена определению обратной связи, ее основным видам и критериям, моделям использования и распространённым ошибкам при применении техник, а также советам, как можно принимать обратную связь.

Во второй части вы узнаете секреты создания и проведения эффективного тренинга в scrum-командах по обратной связи.

Что такое обратная связь (далее по тексту обратная связь – ОС)? Под обратной связью понимается информация о том, как объект обратной связи проявляется и как это влияет на других людей, команду, разрабатываемый продукт, организацию. Не стоит путать это с неконструктивной и субъективной критикой, разного рода манипуляциями, выраженными в том числе в словесной форме, а также оценочным суждением, приказами и побуждениями к действию.

Какие виды обратной связи нам известны? Вы скорее всего встречали обширное количество видов, но я бы предложила опираться на нижеизложенные вариации:

поддерживающая обратная связь – позволяет человеку осознать действия, которые приводят его к успеху, более эффективным результатам и т.д.;

корректирующая – помогает человеку осознать, какие его действия приводят к нежелательным для него или команды результатам, и как эти действия можно скорректировать;

развивающая – помогает человеку осознать его сильные стороны, развить их и использовать более эффективно.

А вы когда-нибудь задавали себе вопрос, как понять, насколько сессия обратной связи прошла успешно? Если вы будете придерживаться нескольких несложных правил и критериев, то ваша обратная связь и вашей команды обречена на успех:

ОС должны быть своевременной;

описывает факты, а не гипотезы или предположения;

не содержит оценок (за исключением моментов, где критерии оценки однозначны и объективны);

сфокусированная (обсуждаем один аспект поведения за один раз);

не затрагивает личность объекта обратной связи (обсуждаем действия и поведение, не личность);

однозначно описывает результат действий объекта обратной связи и их последствия;

однозначно описывает желаемые изменения и причины, по которым изменения необходимы (за исключением объективных и очевидных причин);

сохраняет позитивный баланс между похвалой и критикой;

подразумевает диалог, а не только монолог.

Зачем в целом собирать обратную связь в scrum-командах и какая от этого польза? Я в свою очередь выделяю три наиболее весомых аргумента в пользу сбора ОС, это помогает:

определить текущее состояние команды в плане зрелости существующих процессов и взаимодействий;

определить вектор дальнейшего развития;

выработать ряд решений для непрерывного улучшения процессов и взаимодействий с последующей адаптацией.

Теперь предлагаю разобрать несколько моделей обратной связи и примеров их применения.

Модель бутерброда

Это одна из самых распространенных моделей, которая есть у многих на слуху. Заключается метод в несложном алгоритме: похвалить – поругать – похвалить. В своих продуктовых командах я использую модель бутерброда достаточно часто, как в сессиях one-to-one, так и в групповых сессиях сбора обратной связи. Важно подчеркнуть, что метод нацелен на корректировку результатов, взаимодействий или поведения.

Модель SLC

Модель SLC расшифровывается как S — Successes (Успехи), L — Learn (Уроки), C — Change (Изменения). Давайте теперь поподробнее. Например, во время ретроспективы или другой активности каждый член scrum-команды вначале говорит о двух ключевых личных достижениях за время итерации или определенного промежутка времени. После чего команда озвучивает важные уроки, которые каждый из участников вывел для себя во время последнего спринта. И завершается сессия обратной связи одним важным изменением, которое команда внесет в работу в будущем спринте, основываясь на озвученных ранее успехах и уроках.

Достаточно просто, не правда ли? Полезно отметить, что данную модель можно использовать в следующих случаях работы scrum-команды:

после завершения спринта или закрытии одной из вех проекта;

для организации прозрачной работы, когда всем членам команды необходимо быть в курсе происходящего;

в кейсах, когда важно формировать стандарты и быстрые рабочие алгоритмы: выявлять узкие места процесса и типичные ошибки, чтобы корректировать процессы и методы работы сразу у всех.

Модель BOFF

Из аббревиатуры модели B — Behaviors (Действия), Outcome (Результат / Эффект от этих действий), Feelings (Чувства), Future (Будущее) можно догадаться, каким образом и в какой последовательности участники команды делятся своей обратной связью с коллегами.

Вначале член команды выделяет один факт, событие или поведение, которое, по его мнению, следует подсветить. После озвучиваются естественные последствия, которые произошли или возможно произойдут в результате отмеченного факта, либо поведения, сопровождающиеся чувствами и эмоциями члена команды. Следующий шаг – договориться с командой, что произойдет в случае, если действие повторится и как избежать этого в будущем. Важно, чтобы команда или сотрудник самостоятельно предложили варианты разрешения проблемы в будущем.

Приведу пример из своего опыта, который произошел при внедрении процесса поддержки в продуктовых командах. На первых порах работы по новому процессу участники проходят стадию шторминга, где отшлифовываются острые углы и налаживаются взаимоотношения в командах. Поэтому став свидетелем неверной маршрутизации запроса от поддержки в адрес своей команды, я решила использовать модель BOFF и помочь коллегам договориться. Сотрудника поддержки зовут Иван, название моей команды – Звездные войны:

«Иван, вчера я обратила внимание, что на команду Звездных войн был назначен дефект по системе Х, однако поддержкой этого функционала команда не занимается. Это нарушает согласованный ранее регламент. Я расстроена, так как это отвлекает ценное время продуктовой команды. Давайте вместе подумаем, как мы можем решить эту проблему с багами в будущем?»

Модель SOR

Эту модель ОС здорово использовать, когда в команде/ компании есть стандарты или правила, но кто-то игнорирует их, из-за чего нарушается цепочка правильного выполнения рабочих задач. Честно признаюсь, редко прибегаю к данной модели, поскольку, по моему мнению, она имеет некий «директивный» оттенок и уж если решили ее использовать, то мой вам совет — лучше в форме индивидуальной обратной связи 🙂

Итак, опираясь на этот подход, следует упомянуть про те самые правила, которые есть в вашей scrum-команде (S – Standard). Расскажите о своих наблюдениях, например, если кто-то нарушил договоренности – здесь нужны факты (O – Observation). После чего поделитесь с членом команды, как его действия или бездействие влияют на личные результаты и результаты команды в целом (R — Result). Хорошо, если вы оперируете конкретными примерами и кейсами. В идеале как результат такой сессии обратной связи – член команды осознанно озвучил готовность придерживаться ground rules команды / рабочих стандартов компании / т.д. И вуаля!

Модель ненасильственного общения (ННО)

Метод берет свое начало от автора Маршалл Розенберг и его книги «Ненасильственное общение». К слову, полезная литература для фасилитаторов и scrum-мастеров! Среди остальных техник особо выделяю эту за то, что такой формат обратной связи позволяет предельно просто, честно и открыто высказать свои мысли и чувства, при этом стараясь помочь команде изменить ситуацию. Суть подхода заключается в следующем алгоритме транслирования ОС:

рассказываем , которые связаны с поведением;

, которые являются причиной возникновения чувств и эмоций;

об изменении поведения.

Примеров может быть масса, попробуйте постепенно практиковать эту технику и, если доверять Маршаллу Розенбергу, вы сможете разрешить любой конфликт!

А теперь поделюсь с вами примером использования этой техники в scrum-команде.

Scrum-мастер дает каждому карточки: две зеленые и одну красную и просит написать обратную связь коллегам, опираясь на примеры конкретного поведения. Зеленая карточка — поведение, поддерживающее ценности, красная — нарушающее их. Обратная связь дается в формате ненасильственной коммуникации. Она может быть адресована как всей команде, так и конкретному человеку.

Карточки зачитываются по очереди, а scrum-мастер фасилитирует открытый диалог, помогая команде высказываться без оценок, интерпретаций и обвинений.

Давайте теперь поговорим о том, а как грамотно можно принимать обратную связь?

Для этого существует небольшой алгоритм:

Поблагодарить за обратную связь! Любую, позитивную или негативную. Если человек нам что-то высказал, значит ему не все равно.

Фиксируем обратную связь и задаем уточняющие вопросы. Даже если переполняют эмоции или вы с чем-то сильно не согласны — фиксируем. На этом шаге важно собрать информацию от команды или отдельного его участника.

Анализ обратной связи. Желательно, через промежуток времени, может пройти день или два. Мы возвращаемся к зафиксированному и смотрим, что из обратной связи мы можем применить в нашей работе? Если эмоции не дают спокойно проанализировать, то откладываем и возвращаемся позже.

Применяем то, что мы вынесли из обратной связи!

В завершении первой части хочется обратить ваше внимание на распространенные ошибки, с которыми сталкиваются ребята в процессе освоения азов обратной связи. Старайтесь их избегать! Итак, к типовым ошибкам относятся:

отсутствие любой обратной связи

несвоевременная обратная связь

дисбаланс в сторону критики или похвалы

создание ситуации, когда объект обратной связи должен защищаться или оправдываться

поверхностная обратная связь (тот, кто дает обратную связь, до конца не разобрался в ситуации)

затрагивает и оценивает личность того, кому дают обратную связь

основана на предположениях, а не фактах

основана на субъективном восприятии ситуации, полученном от третьих лиц

необъективна, основана на оценочных суждениях

обратная связь дается по ситуации, когда ожидания от объекта обратной связи ничем не обоснованы

На этом первая часть статьи подходит к концу. Надеюсь, вы нашли для себя ответы на свои вопросы и подчерпнули полезные советы! Вторая часть будет опубликована отдельной главой, не пропустите!

Источник