TLDR: я внедрил (сломанную) функциональность без одобрения, что в конечном итоге было поймано QA, и мой босс (справедливо) расстроен. Что я должен делать?
Я работаю разработчиком цифрового продукта.
Недавно, в сжатые сроки, мы отправили сборку на проверку нашей команде контроля качества, и вчера вечером пришел отчет о том, что они обнаружили ошибку в продукте. Эта ошибка была функциональностью, которую я добавил без одобрения в качестве теста для будущей версии продукта.
Я поместил эту функциональность за своего рода код доступа, который нужно было вводить, взаимодействуя с элементом в продукте в определенной последовательности, при этом я исходил из того, что только я смогу активировать его, и никто другой не сможет вижу это. Позже я понял, что код, который я изначально вставил, на самом деле активирует неутвержденную функциональность, даже если последовательность будет включена в более крупную последовательность, а это означает, что серия случайных взаимодействий будет иметь возможность активировать функциональность (хотя я думал, что это все еще будет редко). ). Я сделал исправление, чтобы разрешить только точную последовательность, но этот код не попал в разосланную сборку.
Через несколько дней после этого (вчера), после того как QA протестировал продукт, они случайно запустили последовательность и сообщили о полученной функциональности как об ошибке. Мой босс показал его нашему креативному директору, который также смог активировать функциональность. Затем он говорил со мной об этом сегодня утром.
Когда мой босс говорил со мной об этом, он выразил несколько опасений:
В дополнение к вышесказанному он сказал, что теперь ему придется поговорить со своим собственным боссом, чтобы решить, что они будут делать по этому поводу. Как оказалось, вскоре после этого он подошел ко мне и спросил, смогу ли я внести минимально возможное изменение кода, чтобы удалить функциональность, возможно, обойти полную проверку качества и спасти наше окно выпуска. Я сразу же отправил однострочное изменение, которое удалило функциональность, показав ему код, который я изменил для этого. Он поблагодарил меня, но с тех пор (сегодня утром) я с ним не разговаривал.
Хотя сейчас я осознаю ошибочность своих суждений, в то время мои действия были продиктованы этим мышлением: к сожалению, много раз мой босс и директор увидят частично завершенную функцию (мной или другим разработчиком) или услышат словесно описанную идею, и отклонить функцию или функциональность из-за того, что я чувствую, это отсутствие видения того, какой функция может быть в ее окончательной форме. Когда я вместо этого использую подход, представляющий им что-то более изысканное, это почти всегда одобряют. Недавно мы обсуждали функцию, подобную той, о которой идет речь, и поэтому я потратил час работы, чтобы просто получить грубую функциональность, чтобы использовать ее в качестве демонстрации. Я думал, что с моей стеной с кодом доступа никто ее случайно не увидит.
Теперь я понимаю, насколько это может быть серьезно. В прошлом, даже если я работал над вещами, чтобы доказать их ценность, я всегда показывал то, над чем работал, и представлял их на окончательное утверждение задолго до финальной сборки. Я понимаю, что переступил черту, позволив чему-то выйти в эфир, даже если я думал, что не дам никому увидеть это случайно.
Я думаю, из-за этого мой босс может меня уволить. Хотя я один из лучших исполнителей в команде, может быть, этого нарушения доверия достаточно, чтобы оправдать мое увольнение.
Я не хочу терять эту работу. Мне нравится моя работа, она сложная и творческая, и я благодарен за оплату и гибкость. Я отправил сообщение своему начальнику с извинениями, сказав, что осознаю серьезность своих действий и что я нарушил доверие и никогда больше не буду делать что-то подобное, выходить за рамки спецификации без одобрения и т. д. Он пока не ответил.
Любые советы относительно того, что делать в этот момент, будут очень признательны! Заранее спасибо.
В будущем при работе с подобными вещами проверяйте их в ветке, а не в мастере. Или используйте низкие технологии и сохраните его в другом месте на вашем личном жестком диске. Если вы не в кризисе, проблема была не в затраченном времени, а в риске выхода чего-то неизвестного, непроверенного и потенциально ломающегося.
Что делать - поговори с начальством. Объясните ему, что вы понимаете, что поступили неправильно. Скажи ему, почему, чтобы он знал, что ты понимаешь. Предложите процесс, чтобы убедиться, что это никогда не повторится (этот процесс — проверка кода. С проверками кода это никогда не пройдет. Если у вас нет проверки кода и вы не сможете их обойти, в этом случае ответом является техническая блокировка, предотвращающая слияния для мастеринга, если только это не был проверен - и в этом случае вы находитесь в гораздо более глубоком дерьме, потому что обход проверки кода выглядит подозрительно). И смирись с тем, что какое-то время ты будешь в немилости.
Сколько у вас проблем, зависит от вашей работы и того, что делает функциональность. Если вы работаете в чем-то вроде обороны, банковского дела и т. д., вам конец. Если вы создаете веб-сайт и ваш код не имеет ничего общего с доступом к чужим учетным записям или платежной информации, скорее всего, все в порядке. Недостаточно информации, чтобы рассказать здесь.
То, что ты сделал, было плохо, на самом деле, я бы даже сказал , ужасно , но тогда я уверен, что тебе не нужно, чтобы я говорил тебе это. И вам, конечно же, не нужен интернет-случайник, пытающийся напасть на вас.
В значительной степени оставайтесь в том же духе, которому вы уже следовали:
Извинитесь безоговорочно, объясните, что вы понимаете, что то, что вы сделали, было неправильно, и что вы знаете, почему. И, пожалуй, самое главное подчеркнуть, что это больше никогда не повторится.
Не пытайтесь оправдать то, что вы сделали . Проявление инициативы и набросок PoC для демонстрации идей само по себе не является чем-то плохим, и я всегда призывал разработчиков, работающих на меня, делать именно это. Но когда вы работаете в сжатые сроки выпуска, это не время, и отправка его в сборку для работы определенно не место, и попытка объяснить ваши мысли в этом направлении мне (будь я вашим менеджером) в этом случае было бы просто раздражать меня еще больше.
Не пытайтесь распространять какую-либо вину. Как указывали другие ответы, это подчеркивает потенциальную слабость в процессе проверки кода вашей организации, и я не говорю, что они неправы, но вы не тот человек, который говорит им это прямо сейчас. Поступая таким образом, вы только скажете: «Я не должен был совершить это «преступление», вы должны были поймать меня», что в лучшем случае незрело, а в худшем — обвинение жертвы.
Принесите извинения и команде QA, вы не только потратили их время впустую, но и пытались пропустить мимо них что-то принципиально нечестное. Вы должны быть на одной «стороне»!
Предполагая, что график выпуска может быть восстановлен без слишком значительных затрат для бизнеса, и ваш послужной список в остальном очень хорош, поскольку этот инцидент не соответствует характеру, тогда вы могли бы пережить его, но я ожидаю, что вам потребуется довольно много времени, чтобы вы стали белее белого. чтобы восстановить доверие организации к вам. Удачи!
Что ж, вы на собственном горьком опыте усвоили, что вам всегда нужно обращаться за советом, прежде чем включать функциональность.
Первым делом нужно будет рассказать об этом своему боссу, чтобы показать, что вы полностью понимаете, насколько это серьезно, и больше так не будете делать. Открыто признать ошибку — это действительно профессиональная вещь.
Следующий шаг, вернуть доверие вашего босса. Возможно, вам придется затаиться на некоторое время. Но тогда вы можете показать ему, что его мнение имеет значение, спросить у него совета, даже для решений, которые не являются такими масштабными, как запуск нового функционала в производство.
Вы облажались, вы знаете почему, будьте терпеливы и хороши в своей работе, и вы должны быть хороши.
Сообщение вашему боссу: Босс, ваш процесс проверки кода полностью нарушен. Ваши процессы должны быть настроены таким образом, чтобы разработчик не мог добавить код, который будет добавлен в рабочую среду, без проверки и принятия самого кода другим разработчиком. Так что это ваша вина не меньше, чем вина разработчика.
Сообщение для вас: Это не так, как это работает. Вы не можете просто идти вперед и делать что-то самостоятельно. Если у вас есть идея, подойдите к своему боссу и расскажите ему об этом. И если это хорошая идея, он или она прикажет вам ее реализовать, и все в порядке. Но вы должны понимать, что то, что вы считаете хорошей идеей, и то, что считает хорошей идеей компания, могут сильно отличаться. Первый вопрос, который следует задать каждой идее: будем ли мы зарабатывать больше денег? Будем ли мы продавать больше товаров? Будут ли клиенты счастливее и оставят нам лучшие отзывы? С другой стороны: нужна ли нам документация? Не создаст ли это проблем для службы поддержки? Не затруднит ли это дальнейшую разработку? Это все, что ваш босс будет рассматривать. Это не ваша работа - рассматривать такие вещи, но вы должны обсудить это со своим боссом.
Хорошая новость: это не то, за что вас обычно увольняют. Проблему поймали, поломки не нанесли (там повезло, купите тестеру пива, когда будет возможность). Это был познавательный момент для вас. Ваш босс может обрушиться на вас сильнее, чем необходимо, чтобы сделать образовательную часть этой палки лучше, без каких-либо реальных последствий для вашей карьеры. Если бы это дошло до клиентов, все было бы по-другому.
@Lilienthal: Если боссу говорят, что его процесс разработки, за который он отвечает, нарушен, это никогда не бывает несвоевременным советом.
Во-первых, плохие новости: вы поступили очень глупо и импульсивно.
Вы знаете это, нет необходимости говорить больше.
А теперь хорошие новости: вас, вероятно, не уволят.
Подождите несколько дней, извинитесь и подробно расскажите своему боссу следующее.
Если бы я был твоим боссом, я бы, скорее всего, не уволил тебя, но я бы внимательно следил за тобой в обозримом будущем. Я, вероятно, также немного посмеюсь про себя, когда пыль уляжется, а затем я подумаю о том, как направить ваше творчество.
Программисты - озорники, и это довольно общеизвестно, так что то, что вы сделали, не было полностью из области ожиданий. К сожалению, времена изменились, и в наши дни это зло осуждается.
Восстановите доверие своего менеджера и в будущем научитесь отстаивать свои изменения/функции. Будьте в состоянии количественно оценить то, что вы продвигаете, и следуйте изложенным процедурам. Продемонстрируйте в демоверсии, но никогда не пытайтесь снова внедрить что-либо в производство.
Прежде всего: дышать
Размотаем цепочку событий:
Я думаю, из-за этого мой босс может меня уволить. Хотя я один из лучших исполнителей в команде, может быть, этого нарушения доверия достаточно, чтобы оправдать мое увольнение.
Это могло привести к твоему увольнению, но этого не произошло . На самом деле, он дал вам шанс исправить свою ошибку в краткосрочной перспективе. Он даже дал вам положительный отзыв.
В дополнение к вышесказанному он сказал, что теперь ему придется поговорить со своим собственным боссом, чтобы решить, что они будут делать по этому поводу. Как оказалось, вскоре после этого он подошел ко мне и спросил, смогу ли я внести минимально возможное изменение кода, чтобы удалить функциональность, возможно, обойти полную проверку качества и спасти наше окно выпуска. Я сразу же отправил однострочное изменение, которое удалило функциональность, показав ему код, который я изменил для этого. Он поблагодарил меня , но с тех пор (сегодня ранее) я с ним не разговаривал.
Небольшое техническое примечание:
Я думал, что с моей стеной с кодом доступа никто ее случайно не увидит.
Посмотрите на правильное переключение функций . Его поддерживают многие фреймворки. При правильном выполнении это поможет вам быстро отключить функции с ошибками в режиме реального времени, пока вы исправите основную проблему, и эта ошибка вполне может стать поворотным моментом для вашей команды разработчиков программного обеспечения.
К сожалению, много раз мой босс и директор видят частично завершенную функцию (мной или другим разработчиком) или слышат словесное описание идеи и отвергают функцию или функциональность из-за того, что я чувствую, что у меня нет видения того, что это за функция. может быть в окончательном виде. Когда я вместо этого использую подход, представляющий им что-то более изысканное, это почти всегда одобряют. Недавно мы обсуждали функцию, подобную той, о которой идет речь, и поэтому я потратил час работы, чтобы просто получить грубую функциональность, чтобы использовать ее в качестве демонстрации.
Вот это и есть одна из моих самых больших слабостей (недостаточно частое завершение идей). Признайте эту слабость и выясните, как с ней бороться. Заставьте себя не работать над новыми захватывающими вещами, пока вы не проработаете определенное количество незавершенных задач.
Наконец, попросите вашего босса о встрече и скажите, что вы хотели бы поговорить. Затем объясните, как вы собираетесь работать над тем, чтобы не повторять подобных ошибок. Составьте список практических пунктов (например): - посмотрите на переключение функций - посмотрите на завершение работы над проблемами перед отправкой - Не забудьте также рассказать о своих чувствах (неуверенность в своей работе). Любой хороший, сочувствующий человек (я предполагаю, что ваш босс один из них) наверняка не будет считать вас ответственным за неуверенность в себе после совершения ошибки.
Удачи!
Эрик
пользователь34587
курт1893
Стив-О
Крис Э
Стефан Бранчик
Лвелья