Я довольно зеленый менеджер небольшой команды из 6 разработчиков программного обеспечения. Помимо управления, в мои обязанности входит обеспечение технического руководства, принятие общих решений по архитектуре и реализации, а также регулярное повседневное написание кода.
В рамках нашего процесса разработки у нас есть еще один разработчик в команде, который проверяет код, прежде чем отправить его на проверку качества и последующий выпуск. Это служит быстрой проверкой работоспособности, но также позволяет разработчикам делиться знаниями, как общими, так и об областях нашей кодовой базы, в которых у них может быть больше опыта. Все в команде сказали, что этот процесс ценен, включая меня.
Один из наших менее опытных разработчиков имеет тенденцию злиться, когда его код критикуют, особенно когда я его рецензирую. Этот разработчик запросил дополнительные отзывы, особенно во время этих проверок кода. Тем не менее, когда такая обратная связь предоставляется, реакция разработчика варьируется от спокойного разочарования до откровенного гнева. Обычно меня спокойно благодарят за отзыв, но через неделю я узнаю, что этот разработчик был зол на этот отзыв, не поднимая вопроса. В самом последнем случае разработчик обвинил меня в том, что я указал на недостатки в коде как на своего рода игру, от которой я получаю удовольствие, утверждая, что проблемы, на которые я обратил внимание, были тривиальными. (В этом последнем отзыве указанные проблемы былинезначительные по сравнению с предыдущими проверками кода, где большинство указывалось на критические проблемы. Это хорошо, поскольку разработчик со временем учится и совершенствуется. Тем не менее, указанные вещи были неприемлемы как есть и должны были быть исправлены до выпуска.)
Во время проверки кода я вижу себя равным другим разработчикам. (На самом деле, мы всегда называли их коллегиальными проверками кода. Любой член команды может проверять чужой код. Хотя я просматриваю очень много кода, это потому, что я часто могу сделать это в перерывах между встречами, а что нет.) Это Разработчик сказал мне, что он считает мое одобрение своего кода обязательным, хотя это не является политикой, и было сказано много раз, что он может попросить любого члена команды просмотреть его код.
Этот особенно разработчик немного нестабилен и, как известно, время от времени вспыхивает на людях. Его продуктивность во многом зависит от его настроения на конкретной неделе. Он принимает любые отзывы лично, даже если это незначительные отзывы с четкими решениями. Он заметил сложные социальные ситуации и заговоры между людьми в офисе, которых, насколько мне известно, не существует.
Я вижу свою управленческую роль как поддерживающую роль команды, делая все возможное, чтобы они могли добиться успеха в том, что они делают. Такая же ситуация во всей компании. Мы призываем сотрудников общаться с кем угодно (нет необходимости проходить «цепочку подчинения»), мы предоставляем все необходимое обучение, и почти все восприимчивы к обратной связи, положительной или отрицательной. Я смотрю на вещи объективно и стараюсь предлагать четкие решения четких проблем. Этот разработчик, по-видимому, смотрит на вещи с межличностной точки зрения и сосредоточен на определении основных мотивов каждого, а не на текущей работе.
Я надеюсь, что это дает достаточно информации, чтобы установить сцену. Если нет, попросите разъяснений. Мои вопросы:
Как всегда, взаимодействие с отдельными людьми будет варьироваться в зависимости от человека и вас. Я предлагаю предложения, основанные на моем опыте на обоих концах связи.
Как я могу предоставить отзыв этому разработчику таким образом, чтобы этот человек воспринял его таким, какой он есть на самом деле... отзыв, а не личные нападки?
Похоже, вы не общаетесь в своем обзоре. Вы говорите, что эти три вещи должны быть исправлены, но я не слышу никаких признаков того, что вы спрашиваете разработчика, согласны ли они. Рецензирование идет в обе стороны — вы указываете на то, что нужно исправить, но часто есть причины, по которым разработчики делают вещи так, как они это делают. Часто это веские причины, с которыми укоренившиеся разработчики просто не сталкивались. Я также слышу много вещей, которые являются "неправильными".
Итак, убедитесь, что вы объясняете, почему что- то не так. Некоторые люди (особенно программисты) ненавидят слепо следовать указаниям, даже для их же блага. Убедитесь, что вы даете им возможность высказать свое мнение — прямо попросите об этом. Без такого рода «туда-сюда» указание кому-то, как писать код, может быть воспринято как микроуправление. Обычно это микроменеджмент. Наконец, укажите и на хорошие вещи. Вы упоминаете, что разработчик стал лучше, но если вы не сообщите об этом, они могут плохо вас воспринять.
О, и особенно для начинающих, важно объяснить преимущества процесса проверки кода. Это не просто свалка на n00b-фестивале. Это нужно для того, чтобы сократить количество ошибок, которые раздражают и требуют больших затрат на исправление позже в процессе.
Я, конечно, могу снизить свои ожидания, но я считаю, что это плохая услуга для разработчика и компании.
Это зависит. Если их роль — роль с более низкой ответственностью, то ваши ожидания должны соответствовать этой роли.
Но вы обязательно должны скорректировать свое взаимодействие с этим человеком. Люди разные. То, что работает для одного, может не работать для другого.
Я понимаю, что из этого поста сложно составить полную картину, но так ли безвыходна ситуация?
Возможно. Если сотрудник не снижает боевой дух команды, постоянно злясь на разумные процессы, это нехорошо. Если у сотрудника проблемы с психикой, когда он превращает предполагаемое пренебрежение в заговор, это нехорошо.
Но с таким же успехом может случиться так, что у вашего сотрудника необычная личность, а вы не спешит распознать это или приспособиться к этому. Конечно, кажется преждевременным терять надежду, не зная, в чем на самом деле заключается проблема.
particularly when I am reviewing itвопрос в вопросе заставляет меня поверить, что большее признание того, что разработчик делает правильно, было бы большим шагом к улучшению качества обзоров, поэтому я хотел это подчеркнуть. Я интуитивно чувствую, что менее опытный разработчик очень уважает менеджера и хочет произвести на него впечатление, но у него есть некоторые проблемы со зрелостью, и он расстраивается, когда не получает более бурного положительного подкрепления, чем «ты становишься лучше». ".Есть много причин, по которым люди могут защищаться от любой критики. Это может быть связано с неуверенностью в себе, прошлой травмой и т. д. В конечном счете, может быть полезно понять, что является щекотливой темой, если вы это знаете, вы можете соответствующим образом скорректировать свой подход.
Ключ к критике состоит в том, чтобы никогда не заставлять человека защищаться. Это означает, что вы должны избегать отрицательных слов, таких как «неправильный», «плохой», «ужасный», «худший» и т. д. Избегание «лучше» также является хорошей идеей, поскольку подразумевает «плохое».
Плохой пример :
Привет, Боб, я просматривал этот метод контроллера, который ты написал. Это действительно не очень хорошая идея, чтобы это напрямую вызывало базу данных.
Почему? Вы хорошо указали что, но вы рискуете заставить Боба защищаться, и вы не объяснили ему, почему. По сути, вы сказали: «Вы пишете ужасный код» с точки зрения Боба.
Хорошо пример :
Привет, Боб, я просматривал этот метод контроллера, который ты написал. Я думаю, было бы лучше, если бы мы обращались к базе данных через отдельный репозиторий, чтобы предотвратить SQL-инъекцию.
Почему? Ну, теперь вы отлично справились с тем, что и почему, и вы не обвиняете Боба напрямую в плохом коде. Он все еще может защищаться, но, по крайней мере, вы немного смягчили его.
Хороший пример :
Привет, Боб, я просматривал этот метод контроллера. Я беспокоюсь, что это может быть SQL-инъекция; как вы думаете, имеет ли смысл обращаться к базе данных через отдельный репозиторий, чтобы предотвратить это?
Почему? Во-первых, вы даже не указали, что это его код, он знает, что это так, но не показывать пальцами (даже когда вы это делаете) действительно помогает. В дополнение к этому вы не сразу перешли к тому, что не так с кодом, вы указали на проблему, а затем на то, где эта проблема. Это означает, что его разум уже обдумывает реальную проблему, а не сразу занимает оборону.
Быть честным с кем-то — это всегда плюс, хотя часто вам нужно управлять тем, как передается сообщение. Некоторым нравится прямолинейный подход без глупостей, когда вы просто говорите: «Ваше отношение на прошлой неделе было ужасным, я знаю, что у вас была тяжелая неделя, но давайте вернемся к игре, хорошо?» Я предпочитаю это, никаких танцев вокруг этой проблемы, я также знаю, что вы говорите это не тому человеку, и они будут очень расстроены этим.
В этом случае этот человек довольно легко переходит в оборону, прямой подход не сработает. Вместо этого попытайтесь устранить симптом и позвольте ему разобраться в проблеме. (если он не спросит напрямую) Скажем, у него есть кусок кода, и он работает неоправданно медленно из-за простой честной ошибки.
Когда он попросит вашего одобрения, найдите время, чтобы просмотреть все в соответствии с нормой. Просмотрите код, объяснив, что вам в нем нравится. «Это расширение, которое вы добавили сюда, пригодится позже», «Этот запрос действительно хорош, его легко адаптировать, если нам когда-нибудь понадобится получить дополнительные данные» и т. д.
Когда вы нажмете на то место, которое имеет некоторый запах кода, вы скажете: «Хммм… это работает, вы не рассматривали возможность сделать это оператором case Switch? Я беспокоюсь, если мы решим добавить больше значений, это может стать загроможденным».
В этом случае вы не сказали: «Эй, Боб, эти четыре варианта «иначе-если» — беспорядок», вы выразили это как озабоченность, над которой вы оба работаете, и спрашиваете его мнение. Это действительно может помочь, поскольку вы не указываете пальцами на свое сотрудничество. (хотя вы эффективно подталкиваете его к тому, чего хотите, вы также объясняете ему, почему, и помогаете ему обдумать это)
Ваш текст содержал две красноречивые фразы: «Я вижу себя равным другим разработчикам» и «Я вижу свою руководящую роль в качестве вспомогательной роли команды».
Другими словами: «Я не менеджер, я сотрудник службы поддержки».
Это может быть приятной расслабляющей работой, но это не то, за что вам платят, и это означает, что ваши сотрудники чувствуют себя способными раздражаться, если им не нравится то, что вы им говорите.
Важная роль менеджера заключается в установлении границ, и эти эмоциональные всплески недопустимы. Конечно, вы должны делать код-ревью как можно более неконфронтационным, но рано или поздно вам придется установить закон, по сути, сказав (в самой милой форме), что вы не приемлете инфантильного поведения - это серьезное рабочее место. , и вам платят за серьезную работу, так что делайте это.
Если это означает, что вы должны иметь более отдаленные отношения со своим персоналом, то добро пожаловать в реальный мир — это действительно серьезная ошибка — пытаться подружиться с вашим персоналом, так как рано или поздно вам придется поднять дисциплинарный вопрос с ним. их, и любое подобие дружбы рухнет.
Значит, вы им не ровесник; вы их менеджер, и иногда вам нужно напоминать им (и себе) об этом факте.
Я бы занялся самоанализом. Во-первых, проверка кода может превратиться в придирчивое личное мнение о том, как что-то должно быть сделано. Прежде чем комментировать или критиковать его код, подумайте о серьезности проблемы. Это личное мнение, будет ли код лучше, но в конечном итоге будет выполняться точно так же, код неправильный или это критично.
С обзорами кода у вас есть ограниченное количество социальной валюты, прежде чем вы будете помечены этим разработчиком, всегда придирающимся к мелочам и не добавляющим ценности. Важно то, что обзоры кода добавляют ценность. Если у вас есть придирки, пометьте комментарий как придирку.
В более широком смысле, чем просто обзоры кода. Немногие люди будут в порядке, если вы всегда будете давать негативные отзывы, поэтому время от времени давайте положительные отзывы, особенно в обзорах кода. "Интересный подход, мне нравится" и т.д.
Еще одна вещь, может быть, просто начните звонить ему с отзывами о проверке кода, этот разработчик может быть обеспокоен тем, как это выглядит для команды, когда вы разбираете его код, поэтому позвоните ему, чтобы обсудить это. Таким образом, у вас будет больше возможностей для разговора, и ставки будут менее высокими, чем если бы вы делали это перед всей командой.
Обычно это интерпретируется как личная критика, потому что так оно и есть. По мнению многих программистов, проверка кода — одна из самых напряженных и токсичных частей работы программиста. Многие решения и выбор в области разработки программного обеспечения на самом деле являются мнениями. Проблема «кто рецензирует рецензентов» тоже актуальна; рецензенты, как правило, не понимают, заходят ли они слишком далеко при рецензировании. На бумаге «проверка кода» действительно могла бы стать модным словечком, но на практике она часто изо всех сил пытается выполнить свое предназначение, не портя атмосферу.
Несколько принципов, которые должны принять все рецензенты немедленно:
Кроме того, переоценена так называемая «культура обратной связи». По моему опыту, к сожалению, многие люди интерпретируют это как «разрешение на снисходительное умничество». Как руководитель, внимательно изучите культуру проверки кода в своей команде и прекратите такое поведение, четко сообщив, что оно неприемлемо.
Со временем, надеюсь, должно быть улучшение.
Джей Би Кинг
пользователь0123456789abcdef
Грегори Карри