Soy un desarrollador de software en los Estados Unidos. Trabajo en un equipo muy, muy pequeño, y estamos a cargo de desarrollar y dar soporte a una aplicación móvil personalizada para uno de los clientes más importantes de nuestra empresa. La aplicación en sí se ha implementado para el cliente y les encanta. Sin embargo, algunas veces al día, un usuario llamará o enviará un correo electrónico para solicitar soporte técnico, lo que generalmente requiere una modificación de algunos datos en la base de datos. Estas actualizaciones requieren que saltemos al servidor de producción del cliente y modifiquemos los datos manualmente.
Para la gran mayoría de estas solicitudes, tenemos algunas secuencias de comandos SQL estándar que podemos ejecutar para encontrar y actualizar los datos apropiados. Sin embargo, estos scripts son propensos a errores porque hay muchos pasos manuales para cada script. Por ejemplo, debe buscar un número de pedido, luego buscar qué estados son válidos para ese tipo de pedido, luego actualizar el pedido a uno de esos estados (en varios lugares); la actualización a un estado no válido provoca una gran cantidad de corrupción de datos. el camino... Hemos tenido que trabajar tiempo extra más de una vez para corregir los errores tipográficos que han eliminado/cambiado más registros de los que deberían. Teníamos una herramienta creada por mi gerente que podía manejar uno o dos de los escenarios más complicados, pero esa herramienta era algo tediosa de usar y no manejaba muy bien los errores. (Mi gerente lo admite él mismo).
Para remediar esto, pensé que sería bueno automatizar el proceso. Entonces, durante mi tiempo libre los fines de semana, armé una nueva herramienta usando algunas piezas de la anterior como base. Usando el ejemplo anterior, la herramienta nos permitiría seleccionar un pedido y luego simplemente elegir un estado. La herramienta se encargaría de encontrar estados válidos y realiza toda la verificación "entre bastidores".
La nueva herramienta tiene muchas más características y opciones disponibles. Además de ser mucho más a prueba de errores, también registra todas las acciones realizadas, por lo que en caso de que modifiquemos accidentalmente datos que no deberían haberse cambiado, es fácil buscarlos y volver a cambiarlos. Lo diseñé específicamente para que fuera fácil de usar, de modo que si nuestro equipo alguna vez contratara a una nueva persona, sería muy sencillo capacitarla para atender nuestras solicitudes de soporte más básicas.
Algunos detalles que pueden importar:
Resultó que mi gerente me hizo saber recientemente que de hecho íbamos a contratar a un nuevo desarrollador pronto. Pensando que este sería un buen momento para mostrarle mi progreso, le mostré las capacidades de esta nueva herramienta. Su reacción no fue exactamente la que esperaba. Aunque estaba impresionado por lo robusta y versátil que era la herramienta, e incluso dijo que estaría encantado de reemplazar la herramienta antigua con mi versión actualizada, también expresó cierta decepción porque no le había contado sobre el proyecto mucho antes. Dijo que era improductivo para mí trabajar en él sin su aprobación, ya que él podría no haber aprobado este trabajo. Me ha pedido explícitamente que no trabaje más en ningún proyecto "extra" en mi tiempo libre, a menos que hable con él primero. Aunque no salió directamente y lo dijo,
Honestamente, no consideré esta perspectiva mientras creaba la herramienta, pero ahora entiendo completamente su posición. Quizás estaba mirando este proyecto con ingenuidad infantil, con la esperanza de sorprender a mi gerente con un "regalo" que facilitaría un poco nuestro trabajo. Obviamente eso no funcionó. Ahora me preocupa que, a pesar de mis mejores intenciones, me excedí en mis límites como empleado. ¿Hice? ¿Cuál sería un curso de acción apropiado en este punto?
Parece que hizo un muy buen trabajo al hacer que la herramienta fuera versátil, pero hablar de ello con su gerente en una etapa anterior le habría permitido aportar algo de información sobre el diseño, y él podría haber agregado algunas ideas que tal vez usted no tenía. consideró. Es posible que él también haya conocido algunos factores que usted no sabía, como que planeaban reemplazar todo el sistema en 2 meses de todos modos, o que el trabajo que ha realizado estaba realmente en su plan para hacerlo oficialmente en tiempo de trabajo el próximo trimestre. .
Lo que es más preocupante, las pruebas en los servidores internos de la empresa, incluso fuera del horario de atención, pueden haber causado problemas. En ese momento estabas afectando a la empresa, sin decírselo a tu jefe. ¿Qué pasa si se suponía que alguien más estaba trabajando en eso en ese momento que no entendía por qué estabas cambiando los datos? O qué pasaría si otro gerente hubiera visto que usted estaba accediendo tarde a la base de datos y le hubiera preguntado al respecto. Lo habrían pillado desprevenido, lo que puede ser vergonzoso.
Dijiste: "Nuestras bases de datos se restauran fácilmente a partir de copias de seguridad, por lo que si hubiera destruido datos accidentalmente (que no es muy probable para empezar, pero aun así), no habría sido un problema importante". Pero su gerente tuvo que explicarle a la gente por qué se destruyó la base de datos y tener que restaurarla a partir de copias de seguridad podría haber sido importante.
No se preocupe demasiado por eso ahora que parece que las cosas están bien, solo aprenda del error y discuta su próxima idea con su gerente. Incluso podría autorizar que la próxima herramienta se realice en el horario de trabajo si puede mostrarle los beneficios.
Sí, te pasaste de los límites aquí.
El problema no es que trabajaras en tu propio tiempo: como desarrolladores es algo muy común que trabajemos en casa, tarde en la noche, quién sabe. Es parte del trabajo.
El problema no es que hayas creado una herramienta que te ayudará en tu trabajo. Como desarrolladores, esto también es muy común: como ejemplo extremo, las personas contribuyen a Firefox, Git, incluso Linux, en su tiempo libre y, en muchos casos, esas contribuciones los ayudan en sus propios trabajos y, a menudo, son la razón por la que lo hacen. la obra.
El problema es que hiciste algo que razonablemente podría considerarse parte de tu trabajo. Usó el código de la empresa, presumiblemente el hardware de la empresa, e hizo algo que podría haber hecho durante las horas de trabajo. Si hubiera hecho esto durante las horas de trabajo, en el proceso de desarrollo normal, probablemente lo habrían elogiado por hacerlo.
En cambio, hiciste algo que es bastante común para los desarrolladores más nuevos. Yo también lo hice una vez. Apuesto a que la mayoría de nosotros lo hacemos, una vez, con suerte.
Lo que parece esto es que crees que sabes lo que deberías estar haciendo mejor que tu gerente y tu equipo. Dijiste: "Creo que este proceso es malo", y decidiste arreglarlo. Probablemente tengas razón, probablemente sea malo, pero esa no es tu decisión: depende de tu gerente y de tu equipo.
El hecho de que hayas usado tu propio tiempo no importa aquí. Mostraste una falta de respeto a tu gerente y a tu equipo, porque no seguiste el proceso.
La buena noticia es que esto no es gran cosa a largo plazo, si lo manejas bien. Si deja en claro que comprende por qué cometió un error y que comprende que no está bien hacer este tipo de cosas, incluso si cree que tiene razón , y se abstiene de decir cosas como "Hice bien en hacerlo". pero está mal hacerlo a tus espaldas", lo que suena como si realmente no lo entendieras.
Qué hacer ahora: nada en particular. No has dañado tu relación con tu jefe, y cualquier otra cosa que no sea eso es su trabajo arreglarlo.
Pero trabajar para la empresa fuera del horario de trabajo (en su propio tiempo) puede ser un problema, según su contrato y las leyes locales. En los EE. UU., las horas extras no pagadas pueden resultar en fuertes multas y posibles cargos penales para la empresa/gerente.
Al mencionar sus planes a su gerente, le habría dado la oportunidad de opinar sobre lo que se necesitaba hacer y si estaba permitido o no. Posiblemente hubiera preferido que usted hiciera este trabajo como horas extra regulares.
Para el futuro, simplemente ejecútelo antes de comenzar.
Las mejores respuestas no se aplican a esto porque esta es una empresa pequeña, estas no funcionan igual que las grandes. En las pequeñas empresas, los desarrolladores tienen acceso a muchos roles y no hay nada de malo en trabajar en proyectos personales después de las horas de trabajo.
Lo que sucedió aquí es que hiciste que tu gerente se sintiera inferior y eso siempre es problemático. Deberías haberlo incluido en esto desde el principio, pero quizás no sabías que la herramienta sería tan útil. De todos modos, le sugiero que no lo use ni hable de eso por un tiempo, deje que las cosas se enfríen y se ciña a su proceso de gerente.
No. Tu tiempo es tu tiempo, su tiempo es el de ellos. Siempre que lo haga fuera del horario laboral (ni siquiera "cuando no estoy ocupado", sino estrictamente fuera del horario laboral), entonces es su proyecto y su tiempo. Los trabajos no son tuyos, son un lugar que te paga por un cierto tiempo en el trabajo. No consulto con mi empleador si decido escribir un sitio web para un amigo (observándose la no competencia), por lo tanto, no necesito autorización para trabajar en ningún proyecto que considere lo suficientemente interesante como para dedicarle mi tiempo.
Lo único que veo mal es que utilizó datos internos de la empresa para sus pruebas. Ese es su equipo y sus datos, incluso si son datos de prueba. Su mejor apuesta en este caso habría sido recrear el esquema y algunos otros datos de prueba localmente en su caja de desarrollo y usarlos para probar.
No entiendo el problema del jefe aquí, aparte de eso. ¿Por qué alguien estaría descontento con un trabajador que está dispuesto a trabajar horas sin gritar que le paguen por ello?
jane s