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

В статье о том, как я впала в ступор, когда моя команда из 10+ человек начала активно сопротивляться новому инструменту с фидбеком, и как я внедряла культуру обратной связи. Попробую разобрать, что пошло не так, и какие уроки я из этого вынесла.
Привет. Меня зовут Карина, я PM сервиса «Майснаб». Мне всегда казалось, что корректно сформулированный фидбек о работе — то, чего хотят все. Он как навигатор в Google Maps: не просто говорит, что ты не там, а показывает, где свернуть, чтобы прийти куда нужно.
Предыстория
Я пришла в команду «Майснаба», когда MVP-продукта только вышел на рынок. У нас было двое клиентов, которые по сути купили идею продукта до его реализации. Команда разработки – на аутсорсе. Во внутренней команде всего четыре человека: продакт, аналитик, тестировщик и я — новый продакт (+проджект) менеджер.
Главная цель — достичь product/market fit. Мы пытались привлекать новых клиентов, быстро собирать фидбек, генерить гипотезы и дорабатывать продукт. Но ключевое слово тут — «пытались». С аутсорсом это получалось плохо: сроки релизов плавали, фичи откладывались, было сложно понять, насколько технические оценки реальны. Код — чёрный ящик, экспертиза — на стороне подрядчика, внутри — ни одного разработчика, который работал с новой для нас архитектурой. Мы не управляли скоростью и зависели от внешней команды.
Решили забирать разработку на свою сторону, пока логики в коде немного. Об этом коллеги расскажут в блоге чуть позже. Но если кратко, у нас появился план: собрать свою команду и выстроить процессы так, чтобы увеличить скорость разработки и выпускать релизы регулярно. Мы быстро выросли до 12 человек: часть — из других продуктов группы, часть — с рынка. Перед нами был амбициозный вызов: в короткий срок запустить стабильные спринты, нащупать рабочую скорость и начать выпускать релизы раз в две недели.
Для этого (в числе прочего) нужно научиться важному скиллу – эффективно общаться друг с другом. Команду собрали из сильных, заряженных специалистов, но проблемы всё же возникали:
-
Мы не обсуждали ошибки, а терпели их.
Пример – Разработчик стабильно не дочитывает ТЗ, его задачи чаще других возвращаются на доработку. Тестировщик это видит, но молчит: как обсудить ситуацию без конфликта – непонятно. В итоге на разработку и тестирование уходит больше времени. -
Не было места/времени, где можно высказаться.
Говорить «в лицо» без повода — неловко. Пример – на регулярных собраниях часто уходили в сторону: обсуждали детали задач вместо того, чтобы идти по плану. Время уходило, все раздражались, но никто не говорил напрямую. И главное — непонятно где и когда об этом сказать. -
Напряжение росло.
Начались мелкие конфликты: кто-то раздражался, кто-то избегал общения с человеком, с которым некомфортно. Недовольство копилось и иногда прорывалось на ровном месте — из-за мелочей, которые давно всех достали.
А ещё я видела, как команда глубже погружалась в синдром самозванца. Люди с крутыми(!) скиллами делали крутые(!!) штуки, но боялись принимать решения. Они не понимали, всё ли делают «нормально» — оценку своей работы можно было получить только от себя (а в плохие дни все мы умеем убедить себя в том, что ничего не умеем).
Первый цикл review
Я хотела дать людям безопасный способ говорить друг с другом — не «в лицо», а в формате. Поэтому выбрала Performance Review: 1to1 в спокойной обстановке с заранее собранной обратной связью от команды.
С помощью этого инструмента решала следующие задачи:
-
Узнать каждого и понять, что на самом деле волнует.
-
Ввести понятный и регулярный способ делиться фидбеком и получать его — не копить, а говорить и брать в работу.
-
Научиться обсуждать, если в процессе что-то идёт не так — чтобы править на месте, а не постфактум.
Раз в полгода — оптимально: не слишком часто, чтобы не достать всех, и достаточно регулярно, чтобы ничего не терялось.
На дейли рассказала, зачем это нужно и что даст. Команда встретила инициативу с сопротивлением. Возражения были разные, и чтобы сдвинуться с места, пришлось разложить их по полочкам. Вот что чаще всего слышала:
1. «А зачем это вообще нужно?»
Люди не видели пользы. Объясняла: фидбек — не просто форма ради формы. Это способ понять свои сильные стороны, найти точки роста и улучшить взаимодействие в команде. Не ждать, пока накопится и рванёт, а обсуждать по ходу дела. Инструмент, который помогает и людям, и продукту.
2. «Я не эксперт, как я могу давать фидбек?»
Самое частое возражение: «Я не разбираюсь в коде, как я скажу что-то разработчику?» Но суть фидбека — не в технологии, а в совместной работе. Даже без техэкспертизы ты можешь сказать: «Мне неудобно, когда ты перебиваешь на встречах». Это тоже важно.
3. «Я стараюсь, но не знаю, что писать»
Нормальный страх. Мы не учились давать фидбек. Кажется, что сказать нечего — пока не начнёшь. Мы не ждали идеально оформленных мыслей. Главное — попробовать. Навык приходит с практикой.
4. «А кто будет это читать?»
Страх, что слова пойдут сразу к адресату. Мы проговорили – информация не попадет ни к кому, кроме меня и человека, которого этот фидбек касается. Плюс можно обсудить индивидуальные настройки, если хочется больше приватности.
5. «Это долго»
Мы это учли. Не больше двух опросников в неделю, каждый — минут на 15–20. Цикл — раз в полгода. Минимум стресса, максимум пользы.
Список возражений был длинным. Я ожидала лёгкого апгрейда процессов, а получила мини-кризис. Собрала все возражения, подготовила презентацию с ответами, провела встречу. Рассказывала спокойно, приводила примеры, отвечала. Сопротивление осталось.
Второй цикл review
Я начала читать, думать и говорить с людьми, которые умеют лучше. Мне посоветовали книгу Джона Коттера «Наш айсберг тает». Она объясняет, как люди переживают изменения и почему «новая идея» часто вызывает панику. И все это через сказку с пингвинами и большим количеством картинок. А в конце вы найдете алгоритм из 8 шагов, как внедрять изменения. Особенно меня зацепила мысль о том, что если хочешь, чтобы что-то изменилось — начни с союзников.
Так и сделала. Начала с лидов специализаций, и мы вместе доработали инструмент:
– Упростили опрос: оставили только три однотипных вопроса.
– Добавили примеры ответов на каждый вопрос (с кейсами из жизни команды)
– Сделали ответы необязательными — это сняло напряжение.
– Дали больше времени на заполнение и заранее выбрали удобный период (не во время регресса, не перед релизом и пр.)
Провели первый цикл. Возражения остались, особенно базовые, но теперь у меня была возможность говорить с каждым и объяснять. Повторяла с разных сторон, искала другие формулировки. Показывала примеры: вот процесс, который улучшился после review. Это помогало показать, что формат не для галочки — он работает.
Через полгода вернулись к review — уже без паники. Команда восприняла формат спокойно или нейтрально.
Ликбез по фидбеку
Через год провела небольшой ликбез, чтобы команда чувствовала себя увереннее, а фидбек стал более полезным. В презентации собрали две вещи:
1. Как давать обратную связь: основные моменты, примеры + шаблон.
2. Как её получать (и когда не стоит принимать фидбек на свою сторону).
Как давать фидбек?
– Начни с цели: зачем ты это говоришь? Потому что меня бесят тупые истории, которые он постоянно рассказывает на встречах.
Потому что из-за его историй, не относящихся к теме встречи, мы систематически не успеваем обсудить то, для чего собираемся.
– Не на эмоциях.
«Это теперь норм – приходить на работу к 11:00? Я вообще-то со вчерашнего дня жду от тебя задачу на тест». На самом деле мне пофиг на её опоздания и у меня еще есть задачи на тест, просто она меня бесит.
Ничего не сказала по поводу ее опоздания сразу, хотя испытала сильную злость. Позже, когда эмоции поутихли, поняла, что мне вообще-то все равно, и на мою работу это не влияет.
– Формулируй уважительно, без перехода на личности. Ты всегда такой медлительный?
Ты в последнее время отдаешь задачи после дедлайн. Давай обсудим, что пошло не так в последних спринтах.
– Приводи конкретику. Ты плохо работаешь в последнее время. Соберись.
В последнем спринте ты не добавил комментарий к одной из функций. Мы добавляем комментарии, чтобы другие разработчики лучше понимали код. Не забывай это делать.
– Обозначай последствия. Если ты не успеваешь доделать задачу до конца спринта – говори об этом сразу.
Если ты понимаешь, что не успеешь доделать задачу до конца спринта, но не говоришь об этом – тестировщики ждут твою задачу и не могут начать регресс. В результате мы либо не выкатимся вовремя, либо тестировщики будут сидеть по вечерам. Если ты скажешь об этом заранее, у нас будет больше контроля над ситуацией и вариантов решения.
– Предлагай, как улучшить ситуацию. Задача описана плохо.
Мне не хватает use case в задаче, из-за этого я не сразу поняла, как она вообще должна работать. Не было описания валидации полей, пришлось самой это выяснять.
Да, многие примеры карикатурные и выглядят «шаблонно», но так легче понять, о чем идет речь, и запомнить. А на практике уже не нужно доводить текст до идеала, просто важно помнить основные моменты.
Как получать фидбек?
1. Спроси, если что-то непонятно.
2. Попробуй понять или спросить, зачем тебе это сказали.
3. Не бери чужие эмоции на себя, особенно если фидбек подан эмоционально и без конкретики.
Шаблон
Ситуация → Последствия → Предложение → Новый результат
Например: «Ты не сообщил, что задача не успевает. В итоге тестирование подвисло, релиз сдвинулся. В следующий раз скажи заранее — мы либо подвинем задачу либо сроки».
Итог

Через два года performance review и 1:1 стали частью нашей культуры. Мы:
– выстроили стабильные спринты и релизы раз в 2 недели;
– раньше поднимаем проблемы — не ждём, пока всё загорится;
– стали меньше фейлить сроки и задачи;
– начали реально помогать друг другу;
– взяли общую ответственность за результат;
– научились обсуждать, а не замалчивать.
Фидбек стал не отдельным процессом, а частью того, как мы работаем. И это дало команде реальное ускорение. Ко мне подходили и говорили спасибо — стало проще, понятнее, не так страшно.
10 уроков, которые я вынесла
-
Сначала — лиды. Найди союзников, продай им идею, внеси правки по их фидбеку.
-
Отдельная встреча. Расскажи всей команде: что, зачем, как работает.
-
Отработка возражений. Подготовься. Ответь на всё — спокойно, терпеливо.
-
Примеры. Покажи, как должна выглядеть обратная связь.
-
Не отказывайся до первой пробы. Многие критикуют «на всякий случай». Дай попробовать.
-
Собери фидбек о фидбеке. Что зашло, что нет, какие доработки нужны.
-
Отвечай столько раз, сколько нужно. Даже если кажется, что уже говорил.
-
Повтори позже. Через время инструмент станет привычным.
-
Подсвечивай успехи. «Вот это улучшилось благодаря review». Делай отсылки.
-
Прими, что будут «нет-нет» пингвины. Не все поверят или включатся — и это ок.
А с какими сложностями в построении процессов сталкивались вы?
Автор: karinasuslova