Без своевременной обратной связи не решить рабочих задач, особенно если речь о вовремя замеченных недостатков и багов: 72% работников уверены, что правильная критика поможет им работать лучше. В бизнес-книгах часто говорят о том, что сначала надо хвалить, только потом ругать, а потом снова хвалить. Однако исследования говорят, что это не работает. Разобрались, почему не стоит всегда искать плюсы в ошибках, и как же критиковать, чтобы не приходилось ни делать этого второй раз, ни извиняться за бестактные комментарии.

Почему так важно говорить о минусах

Ошибаются все, это аксиома. И стажёры, и мидлы, и руководители. Любые замеченные недочёты лучше сразу проработать: в противном случае их объём вырастет, накопится недовольство по отношению к коллеге. Высказывайте претензии сразу и предлагайте, как можно решить проблемы, по мере их поступления.

Был у меня на одной из прошлых работ программист. Разрабатывал самую, наверное, важную часть продукта и занимался этим годами. Но никакого внятного тестирования и вообще контроля его работы не было. В итоге человек вместо релиза выкатил непонятное глючное нечто, которое ещё и падало на реальных системах. Я решил протестировать то, что у него получилось, написал нужный софт, отдал коллегам и ушёл в отпуск. Вернулся — а они нашли 100 уникальных падений сверх моих находок. Тут-то человеку и высказали всё, что о нём думают, не стесняясь в выражениях, и отстранили от фактической разработки.

Владимир, тестировщик, Санкт-Петербург

Почему хвалить и критиковать одновременно — плохая идея

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

Однако, уже в 2014 году исследователи установили, что принцип гамбургера полезен не больше, чем сам фастфуд, и вот почему:

  • Это костыль, который помогает начать неприятную беседу, а не средство мотивации.

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

  • Если постоянно использовать метод, то при любой похвале сотрудники начинают ждать подвоха. Люди прекрасно понимают, что это за психологический трюк, и со временем он начинает только раздражать. Скорее всего, положительные моменты работы будут оставаться неизменными, а вот отрицательные — каждый раз меняться.

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

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

Правило конструктивной критики 1: нужно говорить о работе и о себе, а не о другом человеке

Критика бывает конструктивной и деструктивной. Конструктивная направлена на то, чтобы устранить ошибки или недостатки и добиться лучшего результата. Деструктивная — на личность и качества критикуемого.

«Код ты пишешь так себе», «так последние лет пять уже никто не делает», «тебе ещё учиться и учиться» или даже «ты ничего не делаешь» — примеры деструктивной критики. Человек не станет работать лучше, если указывать ему на профессиональную несостоятельность и не давать возможность исправиться.

«Выглядит как костыль, его однозначно придётся убрать», — конструктивное замечание. «Мне бы хотелось, чтобы вы работали быстрее, как мы можем ускорить процесс?» — тоже полезное замечание, которое включает в себя предложение помочь коллеге.

На рабочем месте важна даже не критика, а обратная связь. Критика редко воспринимается нейтрально, а обратная связь — вполне. Правило простое: уравновесить сообщение пунктом «вот это я сделал бы по-другому». Любую негативную оценку человек чаще всего воспринимает на свой счёт, то есть слышит не «я сделал что-то недостаточно хорошо», а «я плохой, я виноват». От критики, даже если она находится в профессиональном поле, страдает самооценка. Будь это не так, вряд ли кто-то в моём кабинете вообще говорил бы о своих начальниках и коллегах.

Вадим Чернов, психолог

Правило конструктивной критики 2: говорите лично, с глазу на глаз

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

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

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

Татьяна Гилева, психолог

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

Как-то раз на рабочей планёрке всем устроили разбор полётов: нужно было рассказать, что за неделю сделать удалось, а что не вышло или вышло не до конца. Я отчиталась, после чего одна из коллег стала повышать на меня голос: то я сделала не так, это не так, не использовала её контакты, ей пришлось связываться с людьми само́й. Я высказалась в ответ, попросив на меня не орать. Начальница сначала поддержала меня, но потом в приватной беседе в курилке отметила, что коллега по форме была неправа, но сказала всё по делу. Мне было очень обидно. Через месяц я с этой работы ушла, а неприятный осадок, увы, остался.

Ирина, менеджер, Москва

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

Правило конструктивной критики 3: измеряйте ошибки

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

Даже если сотрудника критикуют за дисциплинарные нарушения, лучше указать на них конкретно. Не «вы постоянно опаздываете», а «на этой неделе вы опоздали три раза». Не «когда ты начнёшь соблюдать сроки», а «работа должна была быть готова третьего числа, сегодня пятое, сколько дней ещё нужно на доработку». Такие формулировки помогают сместить фокус с личности коллеги на предмет критики.

Правило конструктивной критики 4: выявляйте причины и объясняйте последствия

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

На первой работе в мои обязанности входила вычитка за другими коллегами. Признаюсь, с задачей я справлялась с переменным успехом, часто косячила из-за невнимательности. К счастью, руководитель проекта вовремя это заметил и переключил меня на другие задачи: перевод и модерирование. Эта работа оказалась менее монотонной, и я с ней справлялась легче.

Анна, редактор, Санкт-Петербург

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

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

Правило конструктивной критики 5: используйте вежливые формы

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

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

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

Высказывайте собственное мнение, используя «я-послания»: я думаю, мне кажется, я бы обратил внимание. «А вот так будет надёжнее», «сюда лучше подойдёт» — это языковые формулы, которые делают любую дискуссию уважительной. «Будет удобнее и проще, если…», «можете со мной не согласиться, но…», «я могу сделать что-то, если вы сделаете вот то» — допустимые фразы.

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

Почему не нужно решать проблемы за других

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

Во-вторых, люди гораздо чаще вспоминают оценочную обратную связь — то есть отзыв о том, что они сделали, — чем информацию о том, как они могли бы улучшить работу. Так что не сто́ит путать критику с обучением.

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

Комментарии (24)


  1. dopusteam
    18.09.2022 18:54
    +1

    Разрабатывал самую, наверное, важную часть продукта и занимался этим годами. Но никакого внятного тестирования и вообще контроля его работы не было. В итоге человек вместо релиза выкатил непонятное глючное нечто,

    Как это возможно вообще? Годами писал и выкатил один релиз?


    1. Areso
      18.09.2022 19:29

      Как это возможно вообще? Годами писал и выкатил один релиз?

      "Водопад".

      Кто-то где-то когда-то написал ТЗ (за полгода) размером с книгу или две, потом программист или несколько написали по ТЗ какую-то программу. За полгода, год, или даже два.

      Потом это как бы отдали на тестовую эксплуатацию и тут могут быть нюансы (в зависимости от усердности этой тестовой эксплуатации). Наконец, релиз, NN или даже NNN рабочих мест на новой программе с понедельника - и вот тут приходит он - полярный лис.


      1. lymes
        18.09.2022 19:37
        +6

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


        1. Areso
          18.09.2022 19:43
          +4

          Проверять менеджером и проверять релизом на реальных пользователях - сильно разные вещи.

          Если ИС монолитна, разработка ведется водопадом - в конце будут круглые глаза.

          А успех измеряется диаметром круглых глаз. Чем меньше диаметр, список багов и список доработок "вы не так поняли ТЗ" - тем успешнее релиз, и, в целом, проект :)

          У водопада есть недостатки. В частности, повышенная ответственность на каждом этапе, потому что цена ошибки возрастает - и чем раньше совершена ошибка, тем сильнее. Поэтому требуется высокая дисциплина участников проекта.

          У аджайла, напротив, дисциплина вообще может отсутствовать. В следующем спринте "как-нибудь" исправят, как-нибудь добавят и как-нибудь пофиксят. Кек.


      1. dopusteam
        18.09.2022 19:45
        +3

        Это не ответ. Если это самая важная часть системы, то почему она пилилась годами одним человеком и всем было всё равно что там? Что то не договаривают


        1. Areso
          18.09.2022 19:48
          +2

          Зависит от ситуации. Всю правду нам тут всё ровно не расскажут.

          Просто я присутствовал при таком однажды (биллинговая система предприятия в сфере ЖКХ), вот там всё так и было. Программистов было несколько, но каждый отвечал за свой участок: у кого-то ядро, у кого-то отчеты и печатные формы, у кого-то АРМы операторов.


          1. dopusteam
            19.09.2022 08:44

            Я ж не против разбиения по разработчикам. Ваш программист, отвечающий за ядро, мог писать код два года и не релизить ничего? Явно все отчеты/формы/... дёргают что то из ядра

            Тут-то человеку и высказали всё, что о нём думают, не стесняясь в выражениях, и отстранили от фактической разработки.

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


            1. Areso
              19.09.2022 12:08

              Там дергали из БД, БД была предзаполнена.


            1. thevlad
              19.09.2022 17:23

              Водопад это аджайл с одной единственной итерацией. Видел такое когда разработкой руководили люди далекие от программирования. Для них концепция: "Давайте все заранее продумаем и запланируем. А потом просто разделим на куски и раздадим людям. И конечно чтобы все сразу заработало", при этом не имея до этого обширного опыта в заданной области. Не выглядела абсурдно.


  1. lymes
    18.09.2022 19:00
    +3

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


    1. Moraiatw
      19.09.2022 14:54

      «Расскажешь, почему мы сделали кнопку такого размера? Кажется, что она должна быть в два раза больше, если верить гайдам. Как думаешь, можем поправить, чтобы не смутить пользователей?»

      Как так жить...


  1. AlexZaharow
    18.09.2022 19:14
    +6

    А вот интересно, а если человек не согласен с такой критикой? Хороший специалист может доказать, что работа сделана качественна (если он действительно делал на совесть). Как будет тогда чувствовать себя менеджер, если окажется, что разработчик прав, а он - нет? Фэйлы не случаются на ровном месте, для них всегда есть признаки. И хороший менеджер этого не может не видеть. Если такой неприятный разговор произошёл, то виноваты оба. Почему обсуждается вина только разработчика? А его руководителя?


  1. saipr
    18.09.2022 20:15

    А если человек избегает обратной связи?
    На вопрос как дела, ответ — всё хорошо!
    Успеваем — а как же, конечно и т.д.
    А когда приходит время, выясняется, что работа не сделана.
    И оправдания — я не успел, я не знал как…
    Как внушить человеку, что самое плохое — это подвести, что лучше вовремя отказаться от задания, что незнание устранимо и т.д.


    1. omichkun
      18.09.2022 21:35
      +1

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

      – Как дела?

      – Все хорошо.

      – Что именно хорошо? Что конкретно сделано за <промежуток времени>? Сложностей/стоперов никаких сейчас нет? Всего хватает для выполнения задачи?

      ...

      – Успеваем?

      – Конечно!

      – А что успел сделать? А что осталось? Асколько тебе времени на каждую из этих задач надо? Какие могут сложности возникнуть?

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


      1. AlexZaharow
        19.09.2022 10:02

        – Успеваем?

        – Конечно!

        - А что успел сделать? А что осталось?

        А что ты успел сделать за этот же промежуток времени?

        А спрашивающий кого имеет в виду под "успеваем?" Он так спрашивает, словно принимал участие в разработке и не понял, что успевает или не успевает? Может надо поменьше употреблять слово "мы" задавая вопросы, к которым не имеешь отношения от слова никак?

        Что за мода пошла? На словах проявлять участие, а на деле вежливо вытирать о человека ноги.


  1. RPG18
    18.09.2022 21:47
    +2

    Если человека взяли на работу, и он прошёл испытательный срок — он профпригоден.

    Зависит от уровня нанимающего человека. Попал в ситуацию, когда в команде 2 "мидла", 1 тимлид, 1 QA. Несколько сервисов, отсутствие понимания SOLID и полностью отсутствие каких либо тестов. QA к описанию багов прикладывал скриншот логов.


  1. PereslavlFoto
    18.09.2022 23:01
    +4

    нужно говорить о работе и о себе, а не о другом человеке

    — Вы правы, я не успел купить стол и оборудование для рабочего места. Только лампу и чашку принёс.

    измеряйте ошибки

    — Вы правы, я за месяц ничего не сделал. Это потому что не успел купить стол и оборудование для рабочего места.

    выявляйте причины и объясняйте последствия

    — Моя зарплата не позволила купить и компьютер, и стол, и монитор, и смежное оборудование, и удлинитель, и клавиатуру за один месяц. Я их сразу куплю, как только накоплю денег.

    используйте вежливые формы

    — Спасибо. Да, здесь ошибка. Надо было сначала накопить денег, а потом искать работу.


  1. funca
    19.09.2022 00:58
    +1

    нужно говорить о работе и о себе, а не о другом человеке

    "Код ты пишешь так себе" — примеры деструктивной критики.

    "Мне бы хотелось, чтобы вы работали быстрее, как мы можем ускорить процесс?" — тоже полезное замечание,

    Честно говоря я не понял, чем первый пример в этом смысле принципиально отличается от второго.


  1. PereslavlFoto
    19.09.2022 01:38

    (В ответ на реплику funca .)

    «Код лично ты пишешь так себе». — Обвинение в адрес «лично ты», в адрес другого человека. Это пример неверного поведения, потому что другой человек игнорирует атаку.

    «Лично я хотел бы, чтобы вы работали быстрее, хотя вы ведь этого не сделаете; как лично я могу ускорить процесс, если мне такое позволят?» — Высказано желание от «лично я», речь идёт только о себе. Это пример правильного поведения, потому что реплика не касается других людей, они попросту не заметят вопроса и ничего не позволят.

    Неверный поступок приводит к нулевому результату. Верный поступок тоже приводит к нулевому результату. Результат одинаков, а значит, верный поступок ничему не повредит.


  1. steelratty
    19.09.2022 06:49

    «Выглядит как костыль, его однозначно придётся убрать», — конструктивное замечание

    Это не конструктивное замечание, это субъективизм. Однако, по субъективной причине говорят, что твой код говно и его однозначно убираем... Мдаа..

    Должно быть обоснование, почему это костыль и почему такое решение неприемлемо - тогда это конструктив.


    1. funca
      19.09.2022 10:16

      В английском есть два похожих слова:

      Criticism - негативное суждение в отношении чего-либо.

      Critique - детальный анализ, рецензия.

      В фидбеках рекомендуют делать акцент на положительном изменении ситуации - что бы вы рекомендовали коллеге перестать/продолжить/начать делать. Описанная в статье sandwich model показывает как из первого сделать подобие второго, когда вы по какой-то причине не можете обойтись без этого самого негатива.


    1. thevlad
      19.09.2022 17:54
      +2

      Бхх. Как то давно я пытался джуну первокласному любителю писать спагетти объяснить, что так делать не надо. Все мои философские замечания про невозможность поддержки подобного кода, разбивались про вполне конкретное "у меня все работает", а критика подобного подхода приводила к троллингу с его стороны в духе "ха,ха ну ты и дурачек". Методов административного воздействия у меня тогда не было. Это к тому, что если доказывать, то нужен какой-то минимальный общий "аксиоматический"/культурный бэкграунд. Сложно доказать людоеду, что есть людей плохо.


      1. PereslavlFoto
        19.09.2022 22:07

        общий «аксиоматический»/культурный бэкграунд.

        А там нужна была поддержка кода, да? То есть заказчик был заранее уверен, что программу придётся доделывать и переделывать?


        1. thevlad
          19.09.2022 22:52

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