Я сделал возможную ошибку в живом проекте на работе, как справиться с этим беспорядком?

У вас есть вина здесь, но я бы сказал, что это не полностью ваша вина.

Конечно, как разработчик, вы всегда должны тестировать свой собственный код перед регистрацией и НИКОГДА не должны полагаться на QA как на план тестирования. Это само собой разумеется.

С другой стороны, я твердо чувствую, что они должны взять на себя некоторую вину и здесь:

1. Они не сообщили вам, когда код будет развернут на live/production/client.

2. Коллега не просматривал ваши изменения кода до прохождения процесса контроля качества. Это должно быть обязательной политикой в ​​вашей команде, особенно для младших и новых разработчиков в команде.

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

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

Мы все делаем ошибки, каждый из нас.

Определенно признайте свою ошибку - это явно ваша вина, так как вы не сделали анализы, и тот факт, что другие люди тоже могли быть виноваты, не является оправданием. (И в любом случае, возможно, они этого не сделали — возможно, вы должны были знать, что система будет работать в воскресенье, и вы просто не проверили какой-то важный ресурс, чтобы узнать об этом!)

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

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

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

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

Я бы предложил следующее:

1. Не забывайте ВСЕГДА тестировать свой код перед развертыванием. Это правило, которое вы никогда не должны нарушать.

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

3. Узнайте, что такое командная линия. Кто имеет право запрашивать и подписывать изменения? Получив ответ, НИКОГДА не выполняйте запросы на изменение от неуполномоченного лица без согласования с надлежащими полномочиями.

4. Из вашего поста не ясно, где вы реализовали свои изменения. Вы развернули их непосредственно на рабочем сервере? Крайне важно иметь промежуточный сервер или сервер разработки, на котором разработчики могут тестировать свой код перед развертыванием в рабочей среде. Чтобы наилучшим образом предотвратить подобные ошибки, в идеале разработчики не должны иметь прямого доступа к производственным серверам, а протестированный код следует развертывать в рабочей среде только после того, как вопросы и ответы были подписаны. Это должно происходить как часть контролируемого процесса управления изменениями.

Взять на себя ответственность означает не только признать свою ошибку, но и принять участие во внедрении процессов, улучшающих работу.

Удачной встречи!

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

Если время критично, то как минимум два разработчика должны договориться об исправлении. В таких случаях руководство должно понимать, что существует значительная вероятность (> 1%) того, что исправление не удастся.

Вы не прошли обучение, и у вас нет прав на код, который находится в производстве, или процесс развертывания. Никогда не берите на себя ответственность, если у вас нет полномочий. Объясните, что вас попросили сделать, и как вы ответили. Рациональной реакцией руководства было бы проанализировать инцидент, а затем изменить процесс, чтобы предотвратить повторение инцидента в будущем. Все остальное иррационально. Не оставайтесь в иррациональных организациях.

Мне пришлось вернуться и перечитать это, чтобы убедиться, что я правильно истолковал это. Я тоже сделаю некоторые выводы.

В пятницу, когда я собирался уйти с работы, меня остановил коллега и сказал внести изменения в уже работающий код.

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

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

Итак, действуя под предлогом выше, вот как я бы к этому подошел.

Будьте правдивы и объективны

Ваш первоначальный пост уже носит оборонительный характер. «Ну, мне никто не сказал, а QA нормально тестирует, и.. и.. и..» Никого это не волнует. Придерживайтесь фактов. «Меня спросили прямо перед тем, как я ушел работать над XYZ. Я не знал, что в эти выходные будет производственный релиз и что код будет включен. Я проверил некоторые из своих изменений перед отъездом на выходные, поэтому я не не теряйте работы, но они не были завершены или полностью проверены».

Примите на себя ответственность и спросите, как вы могли бы сделать лучше

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

Слушайте ответы

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

Здесь не место критиковать процессы

Было бы совершенно непродуктивно прийти на собрание и сказать: «Ну, если бы наша стратегия ветвления была лучше, и мы бы следовали нашим стандартным процессам, и…» Это выглядит как обвинение. Мне кажется, что проблема с процессом действительно ЕСТЬ (учитывая, что непроверенный/неутвержденный код был запущен в производство), но есть время и место, чтобы выдвинуть эти предложения. Существующая в настоящее время система по крайней мере работает минимально, и хотя более совершенная система могла бы предотвратить проблему, постарайтесь полностью понять текущую систему, прежде чем указывать на нее пальцем.

Имейте сострадание к себе

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

Как код попал в производство? У учетных записей разработчиков не должно быть доступа для развертывания кода в рабочей среде. Любая система, которая полагается на здравый смысл разработчиков, будет настолько же хороша, как и худшее суждение. Если прерывание производства чревато серьезными последствиями (а похоже, что так оно и было), то должна быть серьезная система, гарантирующая утверждение каждого релиза. Не только процесс, которому следуют люди, но и привилегии учетной записи, которые требуют , чтобы соответствующее лицо одобрило изменение. Вы не сможете развернуть плохой код в рабочей среде, даже если захотите. Если да, то конечная проблема в том, что ваша система сломана.

Я согласен со многим из того, что сказали другие, и нет смысла повторять это. Всего несколько дополнительных комментариев:

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

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

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

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

Но в любом случае то, в какой момент вы подключаетесь к библиотеке, зависит от процедур компании. В любом месте, где я работал, программист тестирует на своем рабочем столе, а затем, когда он удовлетворен, делает коммит в библиотеке. Оттуда он направляется в регионы, где QA и/или пользователь могут проводить тестирование. Таким образом, вы не можете обязательно сказать: «Не делайте коммитов, пока они не пройдут контроль качества». ИМХО имеет смысл развернуть в регионе QA из библиотеки, поэтому он должен быть в библиотеке, прежде чем мы сможем QA. Но то, что является хорошей политикой, не является непосредственным вопросом. Вопрос в том, какова политика вашей компании и следуете ли вы ей.

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

Это твоя первая ошибка. Почему есть предварительное условие для тестирования вашего кода? Вы всегда должны тестировать свой код и никогда не полагаться на QA. Это не работа QA.

Что бы вы ни делали, не говорите ничего из того, что вы написали здесь на собрании. Это на 100% ваша вина, и единственное, что вы можете сделать, это на 100% признаться в этом. Допустим, вы сломали его, не тестировали и активно ищете способы выполнения модульных и интеграционных тестов, чтобы этого больше не повторилось.

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

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