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