Mi administrador de TI viola las políticas de TI comunes y no se adhiere a las prácticas estándar [cerrado]

Estoy trabajando como desarrollador senior de Oracle ERP en alta mar con una empresa de BPO y tengo un gerente en tierra ("MM"). Llevo más de dos años trabajando aquí y una cosa que noté desde el principio fue la falta de estándares de TI en términos de gestión de servicios, estándares de codificación y mejores prácticas. Esto nos genera muchos problemas, reelaboraciones y conflictos. Incluso MM, mi gerente directo, no se adhiere a las reglas.

Durante una de nuestras sesiones de pantalla compartida, incluso modificó y compiló el código directamente en producción. Las políticas de TI habituales establecen que solo los administradores de la base de datos deben compilar el código en producción si hay una solicitud de cambio aprobada. Le mencioné esto, pero dijo que tiene el privilegio de la base de datos y que sabe lo que está haciendo.

Por citar algunos ejemplos más:

  1. Durante otra sesión de pantalla compartida, quería que pusiera un COMMIT dentro de mi procedimiento almacenado, pero esto se considera una mala práctica. A pesar de mis protestas y citando algunos casos en los que esto puede ser catastrófico, insistió en poner el COMMIT y no me quedó más remedio que hacerlo. Cuando el procedimiento se ejecutó al día siguiente, falló y no se pudieron recuperar los registros actualizados. Tuvimos que obtener datos de una copia de seguridad y volver a crear la tabla.

  2. Durante otra sesión de pantalla compartida, quería que excluyera una identificación de nómina determinada de una consulta. Traté de poner una subconsulta para evitar la codificación fija de la identificación, pero él insistió en que solo debía poner "Payroll_ID <> 31" porque sabía que 31 era Payroll_ID. A pesar de mis numerosas protestas, insistió y no tuve más remedio que hacer lo que él quiere una vez más.

  3. El tercer escenario es similar al segundo escenario anterior, pero la única diferencia es que le dije que no:

Yo: "MM, lo siento, pero realmente tengo que estar en desacuerdo contigo aquí. No codificaré la identificación como ya te mencioné que esta no es la mejor práctica y puede generar problemas".

MM: "Las mejores prácticas no son ciertas, se basan en libros y conceptos. Tengo más de 30 años de experiencia en este campo, así que no me hables de las mejores prácticas".

Entonces, una vez más, no me quedó más remedio que adherirme a lo que él quería.

  1. No crea especificaciones documentadas y cambia sus requisitos literalmente antes de la implementación real de un código completamente desarrollado y probado.

Incluso le he dado demostraciones y sugerencias sobre cómo las mejores prácticas tendrán un impacto positivo en nuestro trabajo, pero él hace la vista gorda.

¿Sigo tratando de presionarlo para que se adhiera a las prácticas estándar y las políticas de TI, o simplemente debo informarlo a la gerencia superior?

¿ Está haciendo esto de tal manera que su nombre está debajo de todas las confirmaciones/cambios?
@Erik Creo que está usando una cuenta de superusuario como SYSDBA o DBA, no bajo su propio Usuario.
"¿Hay otras formas de convencerlo de que se adhiera a las prácticas estándar para no violar las políticas de TI?" Respuesta corta: no. Respuesta larga: no.
Esta es la pregunta más común en este sitio. "Sorprendentemente, el desarrollo de software es un desastre". Se ha discutido tantas veces que no hay nada más que decir.
Ahora sería un buen momento para comenzar a asegurarse de que todas estas solicitudes de "MM" se le envíen por correo electrónico en lugar de solo solicitudes verbales. Vas a querer un rastro en papel si alguno de estos cambios vuelve a afectar a la empresa en el ya sabes dónde y, por lo tanto, a ti, por extensión.
El caos es una escalera.
¿Quién es ID 31? ¿Podría ser esto algún desfalco?

Respuestas (2)

Es casi imposible cambiar el comportamiento de cualquier jefe.

Es más imposible cambiar la cultura corporativa a menos que esté en una posición relativamente alta y/o tenga la aceptación de otros que están en una posición relativamente alta.

Su única opción real es buscar otro trabajo en un lugar donde su cultura se ajuste a su propia perspectiva y mantener la cabeza baja hasta que se mude.

La única forma en que vas a convencer a alguien tan tonto es demostrar que tu camino es mejor a través del ejemplo . Sugiero usar incidentes de producción de alta visibilidad o solicitudes de nuevas funciones que son difíciles de implementar debido a la falta de estándares. Tírale esto a la cara (amablemente, no con una actitud de "ya te lo dije") y déjalo discutir con hechos fríos y duros.

Por ejemplo, si se está implementando directamente en producción, ¿alguna vez esto hace que algo se derrumbe y enfade a los clientes/ejecutivos de su empresa? Debe comunicar profesionalmente la falta de estándares que están causando estos problemas y sugerir su enfoque para solucionarlo. Si él no tiene nada de eso, creo que es posible que desee pasar por encima de su cabeza en este caso, aunque no se sorprenda si eso le resulta contraproducente.

Como último recurso, cambias de trabajo, pero eso no era realmente lo que estabas pidiendo.