¿Cómo promuevo mejores prácticas de desarrollo cuando me enfrento a la oposición de la gerencia?

Haz lo que se requiere de ti, ante todo. Si no puede, es hora de actualizar su currículum y seguir adelante. Rebelarse contra los estándares de la tienda no es una colina en la que quieras morir. Le dará una mala reputación en la industria.

Si está convencido de que hay mejores formas de hacer las cosas, diséñelas en su tiempo libre y luego muéstreselas a sus superiores cuando tenga la oportunidad. Supongo que eres joven y bastante nuevo en la industria (menos de 5 años). Si ese es el caso, las personas más experimentadas de su equipo no lo tomarán en serio a menos que realmente pueda mostrarles algo.

En teoría, tienen todo el derecho de decirme cómo hacer las cosas, porque es su departamento, sus reglas. Pero estoy fuertemente inclinado a negarme a hacer simplemente lo que me dicen, particularmente si puedo justificar mejores formas de lograr el mismo objetivo.

Esta es una gran bandera roja para mí, porque 1) No es teoría, es realidad. Usted no es quien tendrá que rendir cuentas cuando las cosas salgan mal. 2) Demuestra una mala actitud de su parte.

En aras del argumento, voy a tomar todo lo que dices como la verdad absoluta:

Las tiendas deben cumplir con los estándares. Preferiría un codificador mediocre con una buena actitud cualquier día antes que un codificador altamente calificado que esté dispuesto a ignorar las reglas porque sabe más. Mis otros codificadores no podrán mantener el código, y el codificador altamente calificado está empleando nuevas formas de hacer las cosas con las que el resto del personal no estará familiarizado, lo que requiere una nueva capacitación, expone a la empresa a riesgos, ya que el antiguo personal estará en un territorio desconocido y, por lo tanto, propenso a cometer errores.

Dado todo eso, el programador altamente calificado no sería un activo, sino una desventaja.

La respuesta simple a su pregunta es que retrocede . No es su lugar oponerse a los estándares de la tienda de la compañía. Obtenga más experiencia, ascienda en la empresa, haga algo de desarrollo en su tiempo de inactividad y demuéstrelo si tiene tanta confianza, pero no interrumpa los estándares del taller porque tiene formas de hacer las cosas que cree que son mejores. Incluso si sus métodos son mejores, serán una interrupción. Convencer a la gerencia a través de una acción autorizada, no una interrupción.

Si le preocupa que le digan que haga las cosas de una manera que cree que está mal, cree un registro en papel. Haz lo que te digan, pero envía un correo electrónico expresando tus preocupaciones. "Al implementar esto, tengo las siguientes preocupaciones..." luego expóngalas. Si te dicen que lo hagas de todos modos, es culpa suya.

En su pregunta, menciona varias veces que está en fuerte desacuerdo con algunas de sus órdenes. Citándote: se espera que haga cosas que considero peligrosas, estúpidas o incorrectas por cualquier motivo. También menciona que tiene muchas ideas buenas y mejores, pero que las personas más experimentadas no quieren escuchar sus consejos.

Sin embargo, no puedo encontrar una mención de usted preguntando a alguien por qué están haciendo estas cosas de esta manera. Menciona tener menos experiencia, pero no menciona tratar de entender su punto de vista.

Debes empezar por ponerte en la piel de quien te está dando la orden. ¿Por qué te están dando esta orden específica? Si no puede entender por qué, pregúnteles. Por lo general, a las personas no les importa explicar sus razones cuando se les pregunta, especialmente si son junior con menos de 2 años en la empresa. Pero decir "No estoy de acuerdo, esta es mi opinión" probablemente traerá una respuesta similar a "No pedí tu opinión", especialmente porque aún no eres un estudiante de último año.

Tu papel como junior no es iluminar a tus seniors, es entender cómo funciona el trabajo para poder realizarlo más adelante, y comienza con pequeñas tareas.

EDITAR: Tu comentario me consuela en el análisis de que no te enfocas lo suficiente en entender antes de intentar mejorar las cosas.

Para dar un ejemplo reciente, "Quiero que podamos cambiar esto más fácilmente en el futuro". Cuando señalé que hacerlo introducía una forma de hacer un cambio descontrolado que podría causar problemas más adelante, me dijeron que no importaba, que lo hiciera de todos modos.

Parece que saltas a las soluciones demasiado rápido. Escuche y trate de entender por qué la gente pregunta lo que pregunta. No estás preguntando "¿Por qué?" , estás preguntando "¿No es esto mejor?" . Este es un defecto común cuando crees que sabes, pero todavía tienes mucho que aprender. No digo que no estés capacitado , pero creo que aún no tienes experiencia .

Se espera que siga el ejemplo y haga lo que me digan. El problema es que muy a menudo se espera que haga cosas que considero peligrosas, estúpidas o incorrectas por cualquier motivo. A menudo puedo justificar mejores formas de hacer las cosas, pero me dicen "Quiero..." y se espera que me alinee.

Deberías seguir adelante. He estado allí, las personas trabajan en una empresa durante más de 15 años y no ven la necesidad/beneficio del cambio, por lo que seguirán como siempre lo han hecho.

Pero estoy fuertemente inclinado a negarme a hacer simplemente lo que me dicen, particularmente si puedo justificar mejores formas de lograr el mismo objetivo.

Si se niega a hacer el trabajo, podrían denunciarlo a Recursos Humanos. Tienes que aguantarte y hacer el trabajo.

Probé la razón, probé la educación, nada parece funcionar. ¿Cómo sigo trabajando de una manera "mejor", pero sin ser insubordinado?

No puedes arreglar esto. Si no están abiertos al cambio, es muy poco lo que puedes hacer. Podría esperar un error importante causado por x y luego citar que mencionó "Y" hace un tiempo que podría haber solucionado esto, pero no mejorará su entorno de trabajo.

Desempolve el traje y llegue a un lugar donde se desee y aprecie su aporte. Este tipo de lugares existen. Solo intente averiguar a través del proceso de entrevista si el próximo equipo es así. Pregunte sobre metodologías (Agile, Scrum, etc.) e intente mostrar si parecen más receptivos a las aportaciones de todos los niveles.

Sin embargo, diría que todavía eres un desarrollador junior. Puede que seas muy capaz, pero aún te falta experiencia. Tenga esto en cuenta en el futuro como algo que "teóricamente" es mejor, puede que no sea tanto en la práctica, o puede plantear problemas con la mantenibilidad del código, etc. en el futuro.

No, por "peligroso" me refiero a cosas que están causando directamente o podrían causar vulnerabilidades en nuestro sistema de software. Estoy en el Reino Unido. – comentario de Ashilta

Si sabe que hay formas de corregir las responsabilidades, escríbalas, compílelas en una lista de problemas y posibles soluciones con referencias a documentos/prácticas/tecnologías en línea y presente esa compilación directamente al gerente.

Tus intenciones parecen apropiadas, pero cuanto más empujas tus ideas a tus compañeros de trabajo mientras no tienen ningún conocimiento sobre lo que estás hablando, es natural que te hagan retroceder de manera recíproca. También es natural que un departamento que ha realizado con éxito el trabajo de la misma manera durante un largo período de tiempo se resista al cambio.

En lugar de justificar lo que cree que está mal y lo que está bien hablando con ellos, si aún no ha ido demasiado lejos, espere a que el gerente lea su compilación y déjele darse cuenta de que lo mejor para él es resolver las vulnerabilidades que usted señaló. Él/Ella puede voluntariamente programar sesiones de capacitación para todo el equipo en las prácticas/tecnologías que el departamento eligió de sus referencias para resolver esas vulnerabilidades.

Es responsabilidad de su gerente sopesar los riesgos y realizar análisis de costo/beneficio. Puedo aceptar plenamente que sus métodos son "mejores", pero es responsabilidad de sus gerentes decidir si son "suficientemente mejores".

Para usar su ejemplo reciente, su gerente parece haber decidido que el beneficio obtenido al permitir cambios más fáciles en el futuro supera con creces el riesgo de introducir la capacidad de realizar un cambio descontrolado que podría causar problemas en el futuro .

No dejes que lo perfecto se convierta en enemigo de lo bueno.

Esto no debería ser una cuestión de fuerza.

Como ingeniero, es posible que sepa más sobre los aspectos técnicos del software, pero su gerencia sabe mejor cómo ese software crea valor empresarial. Para maximizar el beneficio de su software, que es el valor comercial menos el costo de desarrollo, se deben considerar ambos aspectos.

Si tuviera que tomar estas decisiones, ¿sabría qué necesita la administración? Su dirección no parece pensar así...

Por otro lado, si la gerencia toma estas decisiones, ¿saben lo que haces? Después de todo, si la gestión no lo hace, los resultados pueden ser bastante espectaculares .

Para tomar mejores decisiones, puede esforzarse por saber qué necesita el negocio o comunicar su información pertinente a la gerencia. Recomiendo hacer ambos.

Para saber qué necesita la empresa, pídale comentarios a su gerente (o al cliente). Si toma decisiones o afirmaciones sorprendentes, pregúntale "por qué" para entender sus razones (si esto no es bien recibido, trata de aclarar que solo estás preguntando para que puedas ayudarlo a alcanzar mejor sus objetivos).

Para comunicar información pertinente a la gerencia, exprésela en términos que puedan entender y muéstreles cómo impacta en sus objetivos. Así que no digas "esto es torpe", pero di "Esto probablemente permitirá a los hackers robar los números de tarjetas de crédito de nuestros clientes". También trate de sugerir alternativas.

Si se trata de un asunto grave, infórmeles por escrito, para que pueda demostrar que cumplió con su deber si las cosas van mal.

En cualquier caso, negarse a hacer lo que su jefe le indica socavará su relación laboral hasta el punto en que él o usted tendrán que irse. Por lo general, serás tú.

He experimentado lo que puede ser una situación similar en el pasado:

Se nos asignó la tarea de realizar una tarea y, después de escuchar cómo se esperaba que implementáramos la solución, pregunté por qué estábamos siguiendo esa dirección en lugar de seguir los estándares de la industria. La respuesta que obtuve fue "Esa es la forma correcta de hacerlo normalmente, pero en este caso, esto es mejor. Confía en mí".

Ese no parecía ser el caso para mí, pero hice lo que me dijeron . También seguí preguntando por qué y sugiriendo soluciones alternativas a los problemas... por correo electrónico cuando quería asegurarme de que se registrara mi desacuerdo, pero seguí haciéndolo según me dijeron. En algún tiempo libre escribí una solución para uno de los problemas que esperaba que encontraría nuestro código actual.

Avance rápido un mes, y ese problema surgió. Y, como desarrollador de software junior en el equipo, pude decir "Tengo una solución que puedo enviar para revisión de código ahora mismo que soluciona el problema". El resultado de esto es que mi supervisor directo recibió elogios porque el problema se resolvió casi de inmediato y sabía que yo era quien salvó su trasero.

Avance rápido otros seis meses y ahora estamos bien encaminados para practicar esos estándares de la industria, porque he demostrado que funcionan mejor .

En última instancia, solo tiene una pequeña cantidad de timón que puede aplicar hacia donde se dirige este barco, así que elija sus batallas y elija batallas que pueda ganar: no podrá alterar el paradigma de desarrollo como desarrollador junior. Usted, como marinero de cubierta, no tiene mucho que decir sobre hacia dónde se dirige el barco -> pero puede influir en quienes sí lo hacen.

Hay un libro interesante que tal vez quiera leer, llamado The 360 ​​Degree Leader , de John C. Maxwell, que ofrece consejos sobre cómo influir en las personas que no le responden. Recomiendo leerlo: lo usé durante mi tiempo en el ejército y en todos los trabajos que he tenido desde entonces.

La mejor conclusión/estrategia individual de ese libro: si puede convencerlos de que pensaron en una idea, habrá ganado la batalla antes de que comience.