Как вы относитесь к коллегам, которые постоянно сопротивляются вам?

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

«Конструктивная критика» — это двусторонний процесс; тот, кто критикует, должен уметь слушать того, кого они критикуют, чтобы понять, почему они поступили именно так. Я предлагаю прочитать «7 навыков» Стивена Кови, особенно привычку 5: сначала стремитесь понять, а затем быть понятым .

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

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

Если что-то кажется вам странным, спросите, почему это было сделано. Может быть уважительная причина, и может просто понадобиться переименованная переменная или комментарий к коду, чтобы объяснить это лучше.

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

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

Не превращайте комментарии (непреднамеренно или иным образом) в личные нападки. Такие вещи, как тон и выбор слов, могут определить, как воспринимается фрагмент текста. Например, сравните:

«Это не имеет смысла».

(т.е. это объективно неправильно и ты тупой)

С:

«Это не то, как я ожидал, что это сработает. Не могли бы вы кратко объяснить?»

(т.е. я не обязательно понимаю или согласен с вашим решением, но я не говорю, что вы ошибаетесь, и я готов выслушать ваше объяснение)

Я могу вам сказать, что после того, как вы поработаете таким образом какое-то время, команды действительно раскроются, и код-ревью перестанут вызывать страх; они становятся хорошим способом получить обратную связь, а для других — выявить ошибки, которых вы, возможно, не заметили. Когда кто-то указывает мне, что есть лучший способ сделать что-то, я на самом деле с радостью реализую его, потому что я знаю, что это улучшит общее качество кода, и потому что я знаю, что человек, дающий отзыв, не чтобы лично напасть на меня. Я надеюсь, что вы сможете изменить точку зрения внутри команды от «правильной» и «неправильной» к обоснованным (и ценным) различиям во мнениях и стилях.

Во-первых, будьте осторожны с фразой «поддерживать высокие стандарты кодирования и красивый код». .

О стандартах

Кто решает, что такое стандарты? Существует множество стандартов стилей кода, и большинство из них одинаково применимы, если только один из них последовательно используется в кодовой базе. Если вы являетесь владельцем продукта, менеджером или бесспорно самым старшим разработчиком, то, возможно, у вас есть право выбирать стандарты, но вы должны заранее установить их, а не начинать принимать решения по PR. Документация или файлы readme проектов должны четко указывать, какие стандарты применяются. В общем, это не правило, если это не написано.

По поводу "красивого кода"

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

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

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

По поводу примера из Википедии

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

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

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

Относительно примера глобальных переменных

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

1. ЕСЛИ вы правы: тогда вам, возможно, нужно лучше общаться и иметь хорошо зарекомендовавшую себя точку зрения. Вам нужно преподать человеку урок, но не в смысле «мщения», а в смысле «класса». Вместо того, чтобы бороться за PR, сядьте с ним рядом с компьютером и сделайте презентацию, объективно показывающую, почему он неправ. Желательно написать код, доказывающий его неправоту, и запустить его перед ним. Например, если вам нужно объяснить, что вам нужна конкретная операция копирования для копирования списка на Python, то напишите и запустите пример для нее, как здесь , не просто говорите ему, что «то, что он сделал, просто неправильно ".

2. ЕСЛИ вы ошибаетесь: Вы можете узнать об этом во время упражнения по подготовке вышеупомянутой презентации. Это здорово, потому что вы сделали некоторое понимание, прежде чем критиковать. Всегда помните, что все (включая вас) совершают ошибки. И существуют разные уровни терпимости к разным типам ошибок. Если вы собираетесь публично заявить, что кто-то неправ (вы упомянули публичный пиар), то вам нужно быть очень уверенным в своей правоте. Если нет, личного разговора, в котором вы просите человека объяснить, что он сделал, может быть более чем достаточно, чтобы он/она просветили вас (или в предыдущем случае они могут сами заметить свою ошибку, пытаясь объяснить) .

3. ЕСЛИ ни один из вас не прав и не прав: Тогда вы обсуждаете мнения. Спросите себя: почему вы обсуждаете мнение? Очевидно, вам не нравится обмениваться идеями с этим конкретным коллегой, так как вы ожидаете, что он/она просто подчинится вашим предложениям, а не попытается узнать что-то из того, что он/она вам ответит. Какая разница, если это сделано так, как предпочитает он или она, а не так, как предпочитаете вы? Действительно ли это влияет на другие части кодовой базы? Затем укажите это, чтобы поделиться соответствующей информацией со всей командой, чтобы призвать к решению, которое затрагивает не только один PR, написанный вашим коллегой. В противном случае помните, как и прежде, не исправлять то, что не так.

О публичных PR-дискуссиях

Есть старая пословица, которая гласит: «Хвалите публично, критикуйте наедине». Публичные комментарии к PR должны быть документацией, а не обсуждением, не говоря уже о критике. Ошибки случаются, и если вы ничего не напишете какому-либо PR, это создаст впечатление, что вы вообще не делаете никаких обзоров, поэтому обзоры PR (иногда) публикуются. Но если вам не нравится публичное обсуждение, то же самое чувствует и другой человек, и нет ничего удивительного в том, что он/она занимает оборонительную позицию. Вы публично критикуете. Мое предложение состоит в том, что если что-то запутается в обзоре, вы должны написать свои собственные заметки и поговорить с человеком наедине, либо через видеозвонок с общим экраном, либо в конференц-зале, а затем просмотреть свои заметки, объяснить свои точки и прийти к соглашению о том, что следует сделать в коде. Затем, эти соглашения могут быть размещены в качестве PR-обзора, но желательно написать их в присутствии другого лица, которое соглашается с содержанием. Это позволяет избежать чрезмерной оборонительной позиции человека и разделяет боевые точки на частные, в то время как соответствующие / прямые замечания могут быть помещены в обзор PR. Это может занять много времени, но если вы приняли к сведению предыдущие пункты, все это должно стоить потраченного времени.

По поводу позиции "пока работает"

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

1. У файлов есть владельцы. Создайте правило, согласно которому у каждого файла в кодовой базе есть владелец. Если необходимо внести изменения в определенный файл, владелец сделает это. Если код в этом файле сломался, владелец исправит его. Кто-то, кроме владельца, несет ответственность за его проверку каждый раз, рецензент должен периодически меняться. Это не означает, что за владельцем остается последнее слово в отношении того, как работает код в этом файле, но, по крайней мере, это дает понять, что плохо написанный материал вернется к тому, кто его написал. Обзоры остаются важными, чтобы никто не производил иероглифы, чтобы сделать себя несгораемым.

2. Хороший код — это взаимозаменяемые люди. Руководители ненавидят незаменимых людей. Если код написан настолько плохо, что его понимает только автор (если вообще кто-либо), то это становится помехой для кода. Я слышал о случаях, когда целые кодовые базы практически умирали, потому что не стоило затрачивать усилий на их поддержку. И это благоприятствует плохим исполнителям, а не тем, кто ищет продвижения по службе. В основном это аргумент в пользу привлечения руководства к улучшению качества кода.

3. Рассмотрите возможность создания отдельного отдела контроля качества. В некоторых компаниях (представьте себе машиностроение, а не кодирование) есть группа обеспечения качества, чья работа заключается в проверке соответствия требованиям (как функциональным/производительным, так и требованиям к качеству и стандартным требованиям к адгезии). Как правило, это ребята, которые подчиняются не менеджеру, а непосредственно операционному директору, так что менеджер не может заставить их замолчать или принять ответные меры, которые требуют уложиться в срок. Они не придумывают правила, они просто применяют их и проверяют, соблюдаются ли они. Может быть, такая команда должна проводить обзоры, а не коллеги.

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

Выясните их мотивы и причины и посмотрите, совместимо ли это с ними.

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

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

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

Часто вы мало что можете сделать, поскольку вы боретесь с основной директивой, заключающейся в том, чтобы сделать руководство счастливым. Я был тем разработчиком, который продвигал плохой код, поскольку кто-то хотел, чтобы он был быстрым, и, на мой взгляд, отталкивание было бессмысленным. Я утвердил плохой код после того, как другой разработчик попытался помешать тому же коду перейти в рабочую среду, и вместо этого разработчик попросил меня поставить ему большой палец вверх. Учитывая то, что хотело руководство и расставило приоритеты, вы не могли бы изменить мое поведение (вы могли бы изменить мое видимое поведение, но это означало бы, что я вступил бы в сговор с другими разработчиками, чтобы обойти вас).

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

TL;DR: Качество кода здесь явно не важно для управления, поэтому вы, вероятно, не сможете это исправить, поскольку тогда разработчикам будет все равно.

Отвечу на общий вопрос "коллеги, которые постоянно вам сопротивляются?" и не комментировать приведенные точные примеры. У меня была такая же ситуация в прошлом, поэтому я попытаюсь объяснить, что сработало для меня. Мои советы:

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

Большинство людей не такие, не теряйте надежды :).

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

Сядьте вместе вдали от повседневных дел (кафе, уличная скамейка/парк), возьмите два стикера и два маркера. Дайте им маркер и стикер, вы используете другой набор. Скажите: «Я хотел проверить, как вы и я работаем. Я хотел бы, чтобы мы оба записали число из десяти того, насколько хорошо, по нашему мнению, работают наши рабочие отношения». «10» — «это не может быть лучше, мирового класса, мы должны написать книгу», «5» — «мы делаем ровно столько, чтобы прожить», а «1» — «единственное, с чем мы согласны». это логотип на нашей расчетной ведомости».

Попросите их написать свой номер, как вы пишете свой. Считайте 3-2-1, а затем покажите их друг другу одновременно. Этот момент будет весьма захватывающим и часто весьма забавным — смех пойдет вам обоим на пользу. Затем обсудите, почему каждый из вас использовал цифры, которые вы использовали, и что помешало вам использовать «10». Для вас будет важно взять на себя свою долю беспорядка, чтобы показать, что вы признаете, что ваши рабочие отношения созданы совместно, и вы оба играете роль в том, что происходит между вами.