¿Debo decirle a la gerencia que tengo la intención de irme debido a malas prácticas de desarrollo de software?

En realidad ESTÁS en posición de cambiar esto. Lideras con el ejemplo.

Puede comenzar a usar el control de versiones localmente para sus cambios. Simplemente puede "confirmar" que todos los demás cambien al mismo tiempo. Siempre podrá recuperar versiones anteriores y comparar cosas con versiones anteriores.

También puede ofrecer hacer esto para la empresa. Configurar el control de versiones (en un nivel más pequeño) es bastante fácil de hacer y administrar. Esto puede prepararlo para una promoción en el futuro cercano si se considera valioso.

Puede hacer algo similar para el rastreador de problemas.

No permita que una "oportunidad" para sobresalir sea una razón para irse. Esperar que una persona 'mayor' haga el trabajo garantiza que siempre serás el 'menor'. Una vez que la empresa lo vea como una autoridad para resolver problemas sistémicos, tendrá mucho más poder para implementar cambios en el futuro. Así es como te conviertes en el líder 'senior'. Tienes que demostrar la competencia.

¿Debo informar a la gerencia que considero dejar la empresa debido a estas prácticas?

Nunca digas directamente que estás pensando en irte: tan pronto como la gerencia sepa que no estás comprometido con la empresa, eso siempre te pone en riesgo de quedarte sin trabajo y sin uno nuevo al que ir.

¿O al menos hacerles saber que me estoy frustrando bastante?

Esta es una idea mucho mejor, y un tema ideal para mencionar en cualquier reunión individual o similar que pueda tener con su gerente. Sospecho que es posible que no tenga 1 a 1 regulares (que es un problema diferente), pero siempre puede programar una reunión con su gerente, o quien sea que actúe como su gerente, para informarles que sus preocupaciones.

Por los sonidos de las (malas) prácticas, parece una empresa pequeña. Diría que exprese su frustración de una manera que mejore la empresa. Decir algo como "Oiga, Sr. Gerente: noto que no estamos siguiendo algunas de las mejores prácticas. Esto puede afectar mi eficiencia y la de otros miembros de mi equipo. Me preguntaba si podríamos tener una conversación, tal vez con el equipo, sobre cómo poner algunas de las mejores prácticas en su lugar?" Si en este punto sus ideas están cayendo en oídos sordos y planea irse, hágalo en silencio mientras busca otros trabajos y avise con anticipación (generalmente 2 semanas en los EE. UU.)

También menciona que el gerente ha estado fuera y no hay reemplazo. ¿Y si pudieras ser el reemplazo? Sé que dices I am not very experienced yet. Pero mostrarle a su empresa que le apasiona llevar al equipo a mejores prácticas es muy útil , especialmente en las empresas más pequeñas. Si le preocupa la falta de experiencia, puede solicitar capacitación. Como mínimo, puede tener una discusión sobre el camino de su carrera para pasar a un puesto de gestión. Por supuesto, solo busque esta opción si es algo que desea.

Una cosa que noté en mi carrera es que si esperas que un gerente administre algo útil, te decepcionarás :-)

Lo que sí funciona, en particular, en equipos pequeños es la mejora proactiva. Dices que no hay control de versiones. Así que ponga algo. Obtenga algo simple y fácil de mantener y gratis (ya sea VisualSVN en Windows o git en Linux), simplemente instálelo, muestre a sus colegas cómo usarlo y, con suerte, todos lo usarán sin problemas. No podrá forzar su uso, pero realmente, si puede mostrar un beneficio sin mucho costo (en términos de esfuerzo o tiempo para los desarrolladores), entonces lo usarán. Lo más probable es que ya sepan que es necesario, pero no tienen el tiempo o la inclinación para hacer el esfuerzo de instalarlo.

Un rastreador de problemas se puede hacer de la misma manera: si su VCS viene con uno, utilícelo; de lo contrario, instale un rastreador web y muestre a las personas cómo usarlo.

El problema viene con la superación de la inercia de los demás, pero para eso están las habilidades interpersonales: explicar, alentar, entusiasmarlos para que lo hagan.

No necesitas un administrador para nada de esto. Y no necesita irse porque su equipo no tiene un entorno devops. Así que mejore las cosas, no se limite a huir, y no haga suposiciones de que no puede cambiarlo usted mismo: puede, tome esa pelota y corra con ella.

Su pregunta es en realidad doble:

1. ¿Debería decirle a la gerencia que está considerando dejar la empresa?
2. Cómo mejorar/aplicar las mejores prácticas.

Ahora, estos dos han sido respondidos abundantemente en este sitio, pero aquí están los conceptos básicos.

1. Nunca le diga a la gerencia que está considerando dejar la empresa antes de tener un contrato firmado por su nuevo empleador. Y cuando lo haga, no acepte contraofertas.

2. Sea el cambio. Configure el control de versiones, use patrones de software siempre que sea útil, configure linters, etc. usted mismo. Notarás que esto es tan divertido como que tu equipo lo haga o más.

Estoy en una posición similar (y en realidad estaba considerando publicar esto para obtener sugerencias), excepto por el hecho de que en realidad tengo problemas para convencer a MI PROPIO EQUIPO Y GERENTES para que usen herramientas de control de versiones y gestión de proyectos. Y si bien esto puede no ser exactamente lo que está buscando (respondí al final de la publicación), tal vez pueda ayudarlo a comprender por qué algunas empresas son así.

He estado en esta empresa durante más de 5 años y antes de convertirme en el líder del equipo, vi que el líder del equipo anterior intentaba hacer lo mismo sin obtener casi ningún resultado.

En mi caso la situación es frustrante ya que:

a) la mayoría de los miembros de mi equipo tratan de evitar asumir la responsabilidad cada vez que les dan el cambio

b) cada vez que alguien la pifia (y pasa), yo soy el que echa la culpa porque el gerente (que no es técnico) cree que el éxito de uno es de todos (incluido él) y el error de uno (incluido él) es la falla de los cables, lo que lleva a a)

c) el gerente a menudo organiza reuniones con miembros individuales de mi equipo para asignar nuevas tareas (cambiar la funcionalidad y el diseño) en proyectos en los que trabaja todo el equipo o para quitarlos del proyecto por un período de tiempo indefinido y no notifica al resto del equipo (o yo, en este caso) y rellenar los cambios en Trello/Freedcamp

Intenté todo lo que se me ocurrió:

• Configuramos equipos de BitBucket, pero terminamos estropeando las cosas porque algunos se niegan a comprometerse y enviar su código
• Intenté configurar herramientas de gestión de proyectos (Trello / Freedcamp) pero, como mencioné anteriormente (c), parecen inútiles
• Los miembros del equipo olvidan o se niegan a cambiar el estado de sus tareas o a completar tareas nuevas si es necesario (errores, posibles problemas, etc.) porque piensan que es una pérdida de tiempo (después de todo, si pueden guardar sus notas en un Sublime Text o Notepad, está bien) por lo tanto, dejando a todo el equipo inconsciente de estas cosas (y esto causó muchos problemas en el pasado). Sin mencionar que nadie en el diseño de UI / UX completó nada NUNCA (los artistas no tienen tiempo para esto, dicen), lo que resultó en que los desarrolladores trabajaran en características de UI que estaban a punto de eliminarse o cambiarse de todos modos. Ocasionalmente, el gerente envía algunas hojas de cálculo o correos electrónicos a ciertos miembros del equipo, dejando al resto fuera de juego.
• Configuramos Facebook Workplace para mejorar la comunicación y creamos grupos para todos los proyectos, equipos, departamentos, etc. Sin embargo, el único grupo utilizado es el asado.
• Durante un tiempo, tuve que obtener manualmente los archivos de las aplicaciones en mi estación de trabajo y verificar manualmente cada línea de código para fusionar los cambios. Además, traté de hablar con mis gerentes todas las mañanas y después de cada reunión que tenía con los miembros de mi equipo para obtener todas las tareas y completarlas yo mismo. Todo esto resultó en que dedique la mitad de mi tiempo a revisar el trabajo de otras personas en lugar de hacer el mío, por lo tanto, b) arriba.
• Terminé organizando reuniones con todo el personal de administración y les expliqué la situación y, como resultado, decidimos tener reuniones de pie todos los días y una reunión al final de la semana, para que todos hicieran su trabajo, pero al final , no funcionó.
• Incluso escribí una guía práctica de sentido común que incluso incluía Cómo en BitBucket, Trello y otras herramientas que estamos usando, pero la gente simplemente la ignoró.

Después de todo este tiempo y todas las molestias, llegué a una conclusión simple: se necesita mucho para convencer a las personas de que jueguen bien y sigan algunas pautas simples y, si realmente no quieren, no puedes cambiar esto. Predicar con el ejemplo funciona con personas que están listas para aceptar cambios y, en este caso, cuando está respaldado por el equipo de administración o cualquier persona que realmente pueda hacer cumplir las reglas (aunque considero que es mejor explicar su punto de vista y por qué crees que las cosas deberían ser así, incluso si tienes razón, hacer cumplir es a veces necesario aunque desagradable).

Ahora para responder a sus preguntas:

1) ¿Debo informar a la gerencia que considero dejar la empresa debido a estas prácticas?

NO. Nunca les haga saber que planea irse hasta que esté seguro de que tiene un nuevo trabajo. Es arriesgado para usted, ya que la gerencia asumirá que ya no está comprometido y que solo está tratando de encontrar algunas excusas para no hacer su trabajo. Y si realmente quiere decirles la razón por la que se va, hágalo después de asegurarse un nuevo trabajo. Y asegúrese de no hacerlo culpando a la gerencia oa sus colegas. Si empiezas a culpar a los demás, te puede morder en el futuro. Ser cortés.

2) ¿O al menos hacerles saber que me estoy frustrando bastante?

Seguro. De hecho, creo que es una buena idea. También puede pedirles que expliquen por qué creen que esas prácticas son una buena idea. Tal vez en realidad tienen una razón para seguir así y te la estás perdiendo. Pero al final, no espere demasiados cambios y ciertamente, no de la noche a la mañana.

No subestimes tu capacidad para tener un impacto positivo en tu equipo. No importa cuánta o poca experiencia tengas, todos tienen un conjunto diferente de conocimientos y habilidades y pueden usarlos para mejorar las cosas.

Cuando comencé a trabajar después de la universidad, trabajé en el código base de un producto que se desarrolló originalmente en la década de 1980. El estilo de codificación, los procesos de desarrollo, etc. no habían cambiado mucho en el cuarto de siglo transcurrido desde entonces. No teníamos un control de versiones real, la documentación no existía y muchos procesos de desarrollo eran mucho más complicados y requerían más tiempo de lo necesario. La gerencia estaba lo suficientemente alejada de los aspectos técnicos de las cosas que acordaron que las cosas podían mejorar, pero no estaban demasiado motivados para hacer nada al respecto. Superar esta inercia y realizar cambios significativos requería comprender las motivaciones de las partes interesadas y aprender a comunicarse de la manera que hablara con más fuerza a cada uno de ellos.

La mayoría de las personas son como los gatos. Puedes pedirles que hagan algo, pero en gran medida te ignorarán. Harán algo felizmente si fue su idea, pero protestarán y se negarán a hacer exactamente lo mismo si fue una instrucción que viene de ti. La clave para convencer a otros de cambiar un proceso profundamente arraigado es hacer que quieran cambiar, lo que implica que entiendan verdaderamente cómo los beneficiará personalmente.

Por ejemplo, uno de mis grandes puntos débiles fue nuestro sistema de compilación. Era un lío improvisado que era extremadamente propenso a errores y lento. Una compilación completa podía tardar entre 35 y 45 minutos, y las iteraciones de desarrollo/prueba eran lentas. Reescribí el sistema de compilación usando Makefiles, pero nadie estaba interesado en aprender una nueva herramienta. Al menos, no lo eran hasta que estaba trabajando con un desarrollador senior en una corrección de errores. Hicimos un cambio e iniciamos una compilación para poder probarlo. El senior sugirió que fuéramos a almorzar mientras esperábamos en la construcción. Le pedí que esperara y cuando mi compilación se completó en unos 90 segundos, estaba visiblemente confundido. Le dije "ese es el nuevo sistema de compilación del que te hablé antes, realmente deberías probarlo, ahorra mucho tiempo". En el tiempo que esperaba tomar para hacer una sola compilación, hicimos media docena de ciclos de edición/compilación/prueba. Pudimos resolver el problema y entregar una solución al cliente varios días completos antes de lo prometido. Después de ver claramente cuánto tiempo y frustración ahorraría diariamente, cambió al nuevo sistema.

Como otro ejemplo, noté que muchos de nuestros informes de errores se reducían a que cometíamos errores evitables. Configuré un software de análisis estático para verificar nuestra base de código y encontré una cantidad increíble de problemas. Después de investigar un poco, me reuní con mi gerente, le expliqué lo que hacía el analizador estático y le mostré una lista de informes de errores de los últimos meses causados ​​por problemas que el analizador estático podría haber encontrado. Luego le mostré la lista de problemas pendientes encontrados por el analizador. Estaba bastante preocupado por la cantidad de errores que podrían estar esperando para salir a la superficie. Lancé la idea de que si cambiábamos a un sistema de control de versiones real, podríamos configurar un servidor CI para realizar compilaciones nocturnas automáticas, ejecutar análisis estáticos y enviar informes por correo electrónico que mostraran cualquier problema nuevo encontrado.

Incluso el chico nuevo sin experiencia puede hacer mejoras significativas en su equipo. Sin embargo, para llegar allí, debe usar esas "habilidades blandas". Piense en ello más como si estuviera creando una campaña publicitaria y menos como una discusión técnica.

1. Si no está 100% seguro de querer irse, puede intentar resolver los problemas como ya se sugirió. Si la empresa goza de buena salud, esta podría ser una oportunidad importante para que usted crezca profesionalmente. Es posible que también esté en la vía rápida para (¿grandes?) promociones.

2. Si está decidido a irse, aquí hay algunas discusiones que vale la pena leer, solo para asegurarse de no dispararse en el pie:

Que contar al salir

Cuándo decir acerca de irse

Nota: agregó a la pregunta que hablamos de una gran empresa internacional. Significa que hay una gran inercia para implementar cambios. Combina con "jefe de equipo a la izquierda" y con "malas prácticas". Por lo tanto, olvidaría (más o menos) la opción uno.

La respuesta aceptada es buena y muchos de los demás tienen buenos puntos, pero no abordan el peor de los casos.

Le debo mucho a mi primer trabajo importante para mí en ese momento como desarrollador front-end en una reconocible empresa estadounidense de un siglo de antigüedad. Los reclutadores no han dejado de molestarme desde que lo incluí en mi currículum. También resulta ser el trabajo más estúpido y ridículo que he tenido y la peor empresa para la que he trabajado. En comparación, ha hecho que todas las situaciones que eran malas en el lugar de trabajo no fueran tan malas desde entonces.

¿Qué tan malo fue? (nota: esto fue hace más de 10 años)

• Me tomó dos semanas conseguir una computadora y lo que obtuve fue basura. Había PM y becarios con mejores portátiles que el mío. IIRC, mi primer trabajo fue hacer cosas triviales en mi propia computadora portátil y enviar archivos por correo electrónico a la gente.

• El acceso a la red era solo wi-fi y superaba la capacidad máxima de unas 200 personas. Compré una engarzadora y algunas cat-5 y gorras en un Radio Shack (RIP) para poder hacer un cable de ethernet de 30 pies para llegar a un puerto de ethernet desde mi lugar en la mesa larga estilo cafetería en la que trabajaba. Ya había aprendido de la primera semana esperando la computadora portátil para esperar ayuda de algo parecido a una TI dedicada. En el año cercano que estuve allí, esta situación nunca se solucionó. En realidad empeoró.

• Hubo una real defensa deliberada de la mediocridad. A nadie le importaba si un proyecto terminado se reducía a un pedazo ardiente de escoria fundida por tontería cuando se declaraba terminado. Todo lo que tenía que hacer era declarar que se hizo uno o dos días antes y ellos lo celebrarían, sin tomar nota del hecho de que los proyectos de seguimiento siempre fueron conjuntos masivos de reparaciones y correcciones de errores en proyectos anteriores que en realidad no estaban ni cerca de completarse el examen superficial.

• Estaba en un equipo que tenía una reunión de una hora todos los días para prepararse para la reunión de seguimiento de una hora que fue ordenada por el amigo del tipo que había comprado la empresa. Como era de esperar, quería eludir unas 18 capas de mandos medios para llegar directamente a los desarrolladores, quemando alrededor del 30 % de nuestros días de trabajo y, en última instancia, saboteando sus propios objetivos. Este equipo en particular, irónicamente, estaba haciendo un trabajo de rendimiento.

• ¿El factor más importante en el bajo rendimiento de nuestro sitio? Nuestras solicitudes estaban siendo ahogadas hasta la muerte por algo así como una docena de plataformas de análisis redundantes que se usaban para ver cómo estábamos (podría haberles dicho: no muy bien). En mi mandato de 11 meses allí, nunca pudimos lograr que alguien dejara de lado una sola de las cosas tontas porque de alguna manera no había un guardián. Piénsalo. Estaban asfixiando el rendimiento y, como resultado, las ventas, por lo que podían controlar qué tan bien no podían hacerlo porque nadie quería aprender una plataforma de análisis que no fuera la primera a la que habían estado expuestos. En lugar de eso, enfocamos la mayor parte de nuestro tiempo sin reuniones en frutos pendientes mucho más altos para ganancias de rendimiento muy modestas. Recibí un premio por los ridículos fracasos que pude lograr en este equipo. Llegó con un certificado de regalo de 10 dólares en la cafetería de la empresa, que se parecía mucho a la cafetería de una escuela secundaria pública, solo que sin dar un !@#$. Para recibir el premio, se necesitaron alrededor de 4 horas de viaje para llegar a la sede corporativa, que se mudó hace mucho tiempo fuera de la ciudad, probablemente porque alguien de alto rango quería que estuviera más cerca de su casa en algún momento. Pista: solía estar en un edificio bastante alto de la misma marca.

• La iniciativa de rendimiento en sí fue una desviación de otro problema muy real, que era que después de que un cliente decidiera que quería comprar un producto, dependiendo de quién estuviera en posición de hacer los cambios y se saliera con la suya esa semana, pasaría por no- broma, de 5 a 11 pantallas de ventas adicionales, verificaciones de direcciones, posibilidades de realizar cambios en sus compras, etc. cosa que buscabas en primer lugar. En mi máquina doméstica, a menudo veía tiempos de carga de 30 segundos para cada pantalla.

• El desarrollo de back-end se subcontrató a la mayor empresa de subcontratación en el extranjero del planeta (el fundador de esa empresa era amigo de la universidad con la persona adecuada, aparentemente). El nivel de habilidad de los empleados de esta empresa variaba desde realmente analfabetos en código hasta nivel de entrada y total y desesperanzadamente no estaban en condiciones de cambiar nada, ya que los tipos analfabetos en código tendían a subir a la cima. No usaron el control de versiones. Tenían un directorio de red compartido masivo. Sus aproximadamente 200 desarrolladores (sin contar en el extranjero) copiaban regularmente directorios completos, lo que provocaba que partes del sitio en las que nadie estaba trabajando activamente se revirtieran, mutaran y se desmoronaran. Gran parte de nuestro trabajo consistía en doblar, doblar y mutilar el front-end en su lugar con un control limitado sobre el HTML para que nadie de su lado tuviera que aceptar la responsabilidad por su incompetencia. I' Desde entonces he comparado historias con otras personas que han tenido experiencia con esta empresa en otras empresas. Si bien sus historias ciertamente no fueron positivas, tampoco fueron tan malas y ahora estoy convencido de que nos estaban usando como campo de pruebas para los desarrolladores que no podían molestarse en examinar para que pudieran ascender a tareas más exigentes en otros empresas mientras ocultan a sus empleados inútiles detrás del juego de la culpa, que fue un juego fácil en nuestra empresa.

• Una vez nos detuvieron en la línea de meta de un proyecto que ya estaba atrasado debido a una severa rotación de diseños para regresar y cambiar algunos logotipos que no les gustaban a los abogados. Preguntamos cuál era el problema legal y nos dijeron que no lo había. Simplemente no les gustó el aspecto de los logotipos. No había abogados en nuestro edificio ni en ninguna reunión a la que asistiera.

• La deserción del diseñador gráfico, principalmente debido a la frustración con demasiados cocineros en cada cocina que causan cambios constantes en su trabajo después de la fecha límite, fue tan mala que en un momento se nos acabó. Treinta desarrolladores front-end. 0 diseñadores. Una proporción más típica sería alrededor de 1:4 de diseñador a desarrollador. Nada más que correcciones de errores durante semanas. A veces, los mismos errores repetidamente (consulte la situación de sobrescritura de carpetas anterior).

Créeme. Traté de ser positivo. Probé la razón. Traté de revelar una mejor manera. Traté de enmarcar mis solicitudes de cordura en términos de éxito para la empresa sobre nociones abstractas como "mejores prácticas ampliamente aceptadas y practicadas por todos". Lo que finalmente me di cuenta fue que acababa de pasar los últimos 11 meses pasando por las 5 etapas del duelo como en:

• Negación
• Enojo
• Negociación
• Depresión
• Aceptación

Solo que nunca terminó porque me daría cuenta de que las cosas eran incluso peores de lo que parecían en la fase de aceptación a través de alguna nueva revelación y luego todo comenzaría de nuevo. Me di cuenta de que en realidad estaba de duelo por mi ridícula situación laboral cuando di mi aviso de 2 semanas sin haber encontrado otro trabajo todavía. Solo faltaban 4 semanas para la meta de 12 meses que me había fijado cuando me di cuenta de lo absurda que estaba siendo la situación.

So before you give it your all and decide to be positive and lead by example, ask yourself. How are they getting away with it? Does it actually serve somebody for them to continue to get away with it? Are the powers that be too afraid of the political cost of acknowledging a problem in order to fix it? Is the overall experience a lot like discovering some institution or person you cared about, died every single day? Is it worth continuing to expose yourself to such a sham if it might leave you an angrier person for like nine months after you finally leave the job?

para mi lo fue Apenas. Pero debería haber aprendido a reírme de eso, abandonar todo orgullo por mi propio trabajo (que sería destrozado por la rotura en la parte trasera, sin importar cuánto lo intentara) y CYA hasta que terminara mi año. Porque a veces simplemente no hay nada que puedas hacer sobre estas situaciones. La incompetencia y la mediocridad deliberada pueden no ser algo de lo que enorgullecerse, pero eso no significa que no puedan ser fuerzas a tener en cuenta. Demasiado grande para no rechazar cualquier intento de cambio por parte de un desarrollador, un gerente o incluso un equipo dedicado con las mejores intenciones y uno o dos aliados en la alta dirección.

Cuando finalmente termine, toma lo que puedas de él. Aprendí mucho sobre cómo escribir una interfaz de usuario que seguía intentándolo en circunstancias totalmente irrazonables, como el HTML y el CSS básico que lo rodeaba mutando al azar. Y no importa cuán tonto sea, he visto y puedo tolerar cosas peores y entiendo mucho más acerca de por qué esas mejores prácticas que se ignoraron están ahí en primer lugar. Lo más importante es que he aprendido cuándo dejar de fumar. Renuncias cuando en realidad no quieren tu ayuda o te das cuenta de que la única forma de "tener éxito" es volverte mucho más como ellos.

Huye y nunca mires atrás, por muchas razones. Liderar con el ejemplo... Mm nah, cosas como configurar un control de fuente y básicamente tratar de obligar a otros a usarlo provocará un incendio ya que otros lo verán tratando de convertirse en el alfa y luego tendrá problemas de confianza y mala sangre.

Informar a la alta gerencia sobre las malas prácticas laborales actuales, lo obligará a establecer ejemplos de alguien que está haciendo algo y sigue una mala práctica y su miembro del equipo sabrá que los delató a la alta gerencia y será un traidor a los ojos de todos. uno, e incluso otros equipos te evitarán.