В статье о том, как я впала в ступор, когда моя команда из 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». Делай отсылки.
Прими, что будут «нет-нет» пингвины. Не все поверят или включатся — и это ок.
А с какими сложностями в построении процессов сталкивались вы?
