Я ценю свое свободное время и стараюсь не работать из дома по выходным, как один из моих коллег.
Недавно я попал в следующую ситуацию:
В пятницу вечером (в нерабочее время) служба контроля качества сообщила мне в Slack о небольшой ошибке в функции, над которой я работал. Прежде чем я успел ответить, мой коллега ответил, что он «рассмотрит это», потому что это единственное, что мешало нам выпустить следующий релиз. Через несколько минут я пообещал это исправить, напомнив всем, что следующий релиз будет выпущен не раньше понедельника. Он согласился, что будет лучше, если я займусь этим вместо этого.
В субботу днем я исправил ошибку и проверил, все ли работает как задумано, и вскоре после этого я получил сообщение от того же коллеги в Slack, лишившее меня дара речи:
я исправил это
Я помню, что подобное уже случалось в прошлом: я (невежественный о намерениях моего коллеги) и этот самый коллега параллельно работаем над одной и той же проблемой.
Итак, вопрос:
Должен ли я поговорить с моим коллегой и попросить его не делать этого? Хотя бы попросите его уведомить меня о своих намерениях. Или я должен проглотить свою гордость и не принимать это на свой счет?
Если его исправление ошибочно, вы должны поблагодарить его и двигаться дальше. Даже если ошибка находится в написанном вами коде, на самом деле это не ваша ошибка и не ваш код. Это код компании, и миссия компании — внедрить этот код без ошибок. Ваш коллега делает одолжение компании, исправляя ошибки.
Это здорово, что вы хотите нести ответственность за весь код, который вы выпускаете, включая ошибки, но это также немного эгоистично, если у вас есть проблемы с коллегами, предлагающими помощь. Опять же, не так важно, что вы делаете (в целом); это то, чем занимается компания в целом. Если вас больше волнует миссия компании, чем ваша собственная, у вас не будет с этим проблем.
Единственная потенциальная проблема, которую я вижу в этом, заключается в том, что ваш коллега отстает от своих собственных обязанностей, предлагая незапрошенную помощь другим, и в этом случае это не ваша забота, если вы не являетесь их менеджером.
Кроме того, вы упомянули, что ошибка была обнаружена в пятницу, и вы не могли разобраться с ней до воскресенья. Если ваш коллега смог поработать над ним в пятницу, вы не должны были возражать. Также вы говорите, что код должен был быть выпущен в понедельник, и его исправление поздно вечером в воскресенье кажется недостаточно хорошим, IMO. Ваше исправление потребует дополнительного тестирования, которое следует начать как можно скорее, а не поздно вечером.
Вашей команде нужно лучше организоваться. Два человека, пытающиеся решить одну и ту же проблему, — пустая трата времени. И то, как вы рассказываете эту историю, кажется, что вы не проводите проверки кода — это то, что вы должны изменить.
Кроме того: Ошибка исправлена, так в чем проблема?
master
— допустимы только мерж-реквесты, и все мерж-реквесты имеют базовые процедуры, касающиеся того, как они обрабатываются, кто над ними работает и т. д. Кроме того, каждый мерж-реквест проверяется. Это, безусловно, самая продуктивная команда, частью которой я был, у нас очень высокая производительность. QA и быстрые производственные циклы определенно не противоречат друг другу. По моему опыту, люди просто не любят адаптироваться к новым процессам, это основная причина, по которой этапы QA часто пропускают.Я собираюсь заняться этим с организационной стороны.
Способ, которым это должно быть сделано, даже для исправлений ошибок, даже для небольших, — через тикет/выпуск.
Если это так, убедитесь, что человеку назначена заявка, и ясно, обрабатывается ли заявка в данный момент. Обязательно установите политику на случай, если вы хотите, чтобы несколько человек работали над проблемой, чего я лично не советую. Если вам нужно назначить несколько человек, потому что проблема достаточно велика, разделите ее на подзадачи.
В любом случае это как минимум предотвратит ненужную работу. Легко может случиться так, что два человека тратят время на решение одной и той же проблемы по-разному из-за недостатка общения. Убедитесь, что этого не происходит.
Кроме того, я был по обе стороны этого на протяжении всей своей карьеры, и это определенно считается грубым, если есть четкий правопреемник. Я понимаю, что не следует эмоционально относиться к таким вещам, но я видел, как из-за этого возникают конфликты, так что это просто происходит, поэтому с этим нужно бороться.
Вы могли бы сказать своему коллеге, дружелюбно, что вы чувствовали, что это было грубо. Я не уверен, есть ли смысл в конфронтации, однако это во многом зависит от того, как с такими вещами обращаются у вас дома. Как бы то ни было, я все же советую поставить процедуры на место. Если вы получили этот билет, даже если вас не было на выходных, то ваш коллега не имеет права вмешиваться без вашего согласия, т. е. если политика, которую вы установили, такова.
Поскольку я согласен с @Mär, я хотел бы добавить несколько слов,
Ваш коллега ведет себя как стерва во второй раз, это может быть не намеренно, чтобы задеть ваши чувства и репутацию на вашем рабочем месте, но это определенный результат для таких действий,
Здесь происходят два злых деяния,
взяв на себя билет, назначенный вам «1-й»,
на самом деле причиной этого билета является код, который вы вводите в кодовую базу «2nd»,
Второй пункт с точки зрения команды зависит от вашей команды, организации, руководителя группы, рассматривать ли второй пункт как проблему или нет, с некоторыми менеджерами по продукту, которых я знаю, это оставит отрицательные ярлыки на ваших возможностях, с некоторыми другими это просто обычно рабочий процесс, и вы ничего не можете с этим поделать в любом случае,
Первый пункт, это в высшей степени непрофессиональные действия со стороны вашего коллеги, я бы поговорил с ним, рассказал свою версию истории (не упоминайте второй пункт, так как вы оба не можете его контролировать, и он мог бы использовать его в качестве защиты). вот ваша команда на самом деле имеет открытую культуру), но осветите его действие с вашей точки зрения, объясните ему свои чувства, и ваше предположение, что закрепленный за вами билет - это ваша территория и есть только два пути входа на нее, по приказу от команды, менеджера по продукту, когда вы просите помощи с согласия менеджера/руководителя группы.
Просто ps: если вы решили поговорить об этом со своим коллегой, вообще не упоминайте о намерениях, а если он/она использовал это в защите, дайте понять, что это не может быть упражнением, а сосредоточьтесь на действиях и чувствах как последствия.
Джесси_б
заклятый враг
заклятый враг
заклятый враг
Джесси_б
заклятый враг
Джесси_б
Питер М
Джесси_б
Питер М
заклятый враг
Питер М