Коллега исправляет мои ошибки

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

Недавно я попал в следующую ситуацию:

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

В субботу днем ​​я исправил ошибку и проверил, все ли работает как задумано, и вскоре после этого я получил сообщение от того же коллеги в Slack, лишившее меня дара речи:

я исправил это

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

Итак, вопрос:

Должен ли я поговорить с моим коллегой и попросить его не делать этого? Хотя бы попросите его уведомить меня о своих намерениях. Или я должен проглотить свою гордость и не принимать это на свой счет?

Разве он не уведомил вас о своих намерениях, когда сказал, что разберется с этим в слабине?
Он так и сделал, но после этого я ответил, что посмотрю, и он согласился
Это больше касается моего потраченного впустую времени — я бы не начал работать над исправлением, зная, что кто-то другой пытается это исправить.
@Jesse_b, ты прав. Спасибо
Вы указали сроки, когда сможете это исправить? Я думаю, возможно, они ожидали исправления задолго до вечера воскресенья.
Нет, я не делал. Мы обсудили с QA в том же чате, что проблема может подождать до понедельника. Не то чтобы мы планировали отправить его первым делом в понедельник утром.
Я думаю, что вы немного бесцеремонны со сроками, или, может быть, ваша компания. Код не должен находиться в стадии тестирования в день релиза.
@Jesse_b Если код проходит все тесты QA, то не имеет значения, произойдет ли это за 1 миллисекунду или за 1 месяц до выпуска.
@PeterM: не согласен. Хорошо, что он проходит, но если ошибка будет обнаружена в пятницу перед релизом, релиз должен был быть отложен, потому что полдня, вероятно, недостаточно, чтобы даже сделать надлежащие тесты.
Есть ли у вас официальная система ошибок, в которой проблемы назначаются отдельным разработчикам? Потому что если ваш коллега работает над тем, что официально поручено вам, то это другое дело.
@PeterM да, есть.
@Jesse_b В общем, для неизвестной системы это может быть правдой, но OP и QA OP, казалось, думали, что это незначительно и что это не проблема, которая может отложить выпуск.

Ответы (4)

Если его исправление ошибочно, вы должны поблагодарить его и двигаться дальше. Даже если ошибка находится в написанном вами коде, на самом деле это не ваша ошибка и не ваш код. Это код компании, и миссия компании — внедрить этот код без ошибок. Ваш коллега делает одолжение компании, исправляя ошибки.

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

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

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

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

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

Кроме того: Ошибка исправлена, так в чем проблема?

Проблема в том, как вы сказали: впустую потраченное время. Запросы на вытягивание необязательны, вы все равно можете отправить их в ветку разработки без проверки. Мы думаем, что обязательные пул-реквесты замедлят нашу работу.
пытаюсь решить ту же проблему в нерабочее время. Расскажите об этом во время стендапа в понедельник или на обзоре следующего спринта.
Не обязательно так. Я работал над чем-то одним и понял, что с помощью того же подхода можно быстро исправить совершенно другую ошибку.
«Мы думаем, что обязательные запросы на вытягивание замедлят нас». - Дублирование одной и той же работы также представляется проблемой. Почему задачи не назначаются разработчику?
@nemezis Исправление ошибок, которые были бы обнаружены при проверке кода, значительно замедляет работу. Были времена, когда я работал один (некоторые профессионалы, некоторые частные лица), и если некому было сделать код-ревью, я делал это сам. Что экономит мне много времени.
«Мы думаем, что обязательные пулл-реквесты нас замедлят» — вы ошибаетесь. Ознакомьтесь с концепцией технического долга. Вы испытываете гораздо большее замедление из-за проблем, которые вы создаете, чем из-за контроля качества. Для этого существует QA.
@Mär, это не моя личная точка зрения на проверку кода. Приходя из компании со строгой политикой проверки кода, я настаивал на том, чтобы мы переняли практику проверки кода. Мы пошли на компромисс с необязательными проверками кода для больших функций и пропустили их для небольших «неважных» исправлений. Я думаю, мы должны обсудить это еще раз
@nemezis А, хорошо, понял. Из-за мы это читается как если бы это было ваше мнение, а также мнение компании. Все, что я могу сказать, это то, что я был по обе стороны этого, то есть я был в разработке, где акцент на QA был полностью исключен, а также в компаниях с большим акцентом на QA. Последнее всегда выигрывает в отношении стресса и времени. Это действительно так. Одна непроверенная ошибка, допущенная в продакшене, почти всегда будет стоить вам больше времени и, следовательно, денег, чем целый набор процедур контроля качества. Кроме того, уровень стресса обычно намного выше.
Для нас совершенно невозможна коммитация master— допустимы только мерж-реквесты, и все мерж-реквесты имеют базовые процедуры, касающиеся того, как они обрабатываются, кто над ними работает и т. д. Кроме того, каждый мерж-реквест проверяется. Это, безусловно, самая продуктивная команда, частью которой я был, у нас очень высокая производительность. QA и быстрые производственные циклы определенно не противоречат друг другу. По моему опыту, люди просто не любят адаптироваться к новым процессам, это основная причина, по которой этапы QA часто пропускают.

Я собираюсь заняться этим с организационной стороны.

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

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

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

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

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

Спасибо, договорились, что нам обязательно нужно пересмотреть текущие процедуры

Поскольку я согласен с @Mär, я хотел бы добавить несколько слов,

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

Здесь происходят два злых деяния,

взяв на себя билет, назначенный вам «1-й»,

на самом деле причиной этого билета является код, который вы вводите в кодовую базу «2nd»,

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

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

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