Антон Ларичев
Когда делаешь код ревью иногда встречаешь с тем, что даешь конструктивную критику и она воспринимается в штыки, словно это личное оскорбление. Человек всеми силами пытается сопротивляться обратной связи и не готов слушать аргументы. Тут варианта два: или обратная связь дана некорректно, или человек не воспринимает критику. В этом посте я хочу сосредоточиться на том, как работать с критикой. Мне самому приходиться с ней работать, так как не могу быть везде прав и потому расскажу как я для себя её вижу. Особенно это ощущается, когда ты высказываешь свои мнения публично на большую аудиторию.
Предметность
В первую очередь надо понимать, что любая критика может быть предметной или нет.
- Предметная – указывается на конкретную ошибку или не точность и предлагается как её улучшить.
- Частично предметная – указывается на то, где можно улучшить, но не предлагается решение.
- Не предметная – комментарии вида: «этот код - кусок говна».
Самая ценная, от которой не надо закрываться это предметная. Именно на неё надо обратить внимание и понимая, что она принесет пользу обмозговать. Она тоже может быть не верной, но перед тем, как спорить, постарайтесь посмотреть на проблему с предложенной стороны. Именно это дает нам рост и развитие.
Второй тип тоже бывает полезен, как пища для размышления. А вот третий надо уточнять. Что побудило оставить этот комментарий? Об этом чуть дальше.
Цель критики
Второе деление, которые я бы выделил для себя – это то, что является целью критики:
- Само ваше решение – когда критика направлена на оценку принятого решения или написанного кода. Это правильная критика, так как она оценивает именно предмет, а не вас как личность. Часто цель такой критики именно улучшить что-то, а не оскорбить или задеть. Поэтому и обижаться на неё не стоит, она полезна. Что делать? Принять к размышлению. Пример: "Мне кажется этот код можно переписать иначе, избавившись от лишнего цикла".
- Вы как личность – эта критика скорее призвана вас задеть, показать превосходство другого человека или унизить. В ней тоже может быть польза, если она предметная, но скорее всего конструктивного диалога может не получиться. Что делать? В первую очередь не вестись и попытаться конкретизировать возражение и свести её к обсуждению решения. Если это не удаётся, просто игнорировать. Что самое важное, не надо поддаваться чувствам. Этот человек важен для вас? Нет, ну и забейте на него) Если важен, скажем это ваш близкий человек, то тогда нужно подумать что побудило его к действиям. Пример: "Только дебил мог написать так функцию".
Мотивация
У каждой критики всегда есть мотивация человека, который её высказывает. Зачем он говорит это? Что ему это даёт?
- Улучшение – когда критика направлена на улучшение совместных процессов, общей кодовой базы или чего-то ещё. Значит ему не всё равно, значит он хочет улучшений и тогда следует критику обдумать. Пример: "Лучше использовать линтер, чтобы у нас был единый стиль кода".
- Наставничество – когда цель скорее поделиться опытом, передать знания и уберечь от ошибок. Как и в первом случае полезна, если под этой критикой лежит опыт, которым человек хочет поделиться. Пример: "В прошлый раз, когда мы писали приложения у нас были проблемы с библиотекой Х, поэтому давай не будем её использовать".
- Самоутверждение – когда человек хочет показать своё превосходство. Если критика при этом конструктивная, она может быть полезна, но часто принимает форму общих тезисов: "Ну видно, что пишет джун, кто же так пишет". Потому следует игнорировать или конкретизировать.
- Преследование цели – возможно за счёт критики он хочет показать себя крутым в команде или хочет повышения? Тогда стоит ли критика того, чтобы вы к ней прислушивались?
- Внешние факторы – человек может быть неконструктивен, так как утром его укусила кошка, а потом он опоздал на поезд. Тогда следует отодвинуть обсуждение, пока человек снова не придёт в норму. Конечно это не все возможные варианты. Важно, чтобы вы задумывались, что мотивирует людей говорить те или иные вещи и не давали легко вывести себя из равновесия.
Поэтому когда критикуют, сначала сделайте паузу, проанализируйте её, а уже затем или прислушивайтесь или конкретизируйте или просто забейте на неё 😀. Главное чтобы она приносила пользу, а не выбивали вас из душевного равновесия.
Карта развития разработчика
Получите полную карту развития разработчика по всем направлениям: frontend, backend, devops, mobile
Комментарии
0