¿Qué se puede hacer cuando "liderar con el ejemplo" no funciona? [cerrado]

He trabajado para una gran empresa (más de 8000 empleados) durante casi 2 años y me contrataron justo después de terminar mi curso de estudio.

Todos aquí tienen que lidiar diariamente con el código heredado, que a menudo está muy mal diseñado y lleno de hacks. Al principio, mantuve un perfil bajo, tratando de no criticar demasiado las cosas. Pero la situación, tal como está, se ha vuelto muy difícil de vivir y parece que nadie está dispuesto a mejorar / reemplazar las herramientas que utilizamos.

Para ser más explícitos tenemos:

• Una herramienta de control de fuente obsoleta (Visual SourceSafe)
• Makefiles viejos y simples que solo admiten la reconstrucción completa
• .def archivos que deben mantenerse manualmente y por separado para todas las arquitecturas existentes
• archivos de encabezados monolíticos y proyectos con muy pocos archivos diferentes (pero cada uno tiene alrededor de 3000 líneas de código, que a veces se ocupa de tareas muy diferentes)
• no se utilizan las instalaciones de idiomas "nuevos" (bueno, std::stringno es tan nuevo, pero nadie excepto yo lo usa)

Hace unos meses decidí hacer algo al respecto, diseñando un nuevo entorno de compilación. Podría obtener compilaciones incrementales para trabajar de manera confiable, tiempos de compilación más rápidos, proyectos mejor estructurados, .defgeneración automática de archivos. Incluso creé un puente de / a Git a / de Visual SourceSafe.

Mostré mis logros a varios colegas y a nuestro jefe, pero fue como si a nadie le importara. Todos decían "Bueno ... la gente está acostumbrada a hacerlo así ahora. ¿Por qué cambiaríamos las cosas?

Los cambios que sugerí fueron diseñados para que pudiéramos tener una transición suave del sistema antiguo al nuevo. Cada mejora podría aplicarse por separado y de forma segura.

Incluso intenté involucrar a algunos de mis compañeros de trabajo en los cambios. Pero hasta ahora, no hay éxito.

¿Ya te has enfrentado a una situación similar? ¿Qué se puede hacer cuando "liderar con el ejemplo" no funciona?

Apunte a la cabeza : "Liderar con el ejemplo" debe tener en mente la mejora, pero debe estar dirigido a personas que no están en tecnología. Tal vez haya invertido demasiado tiempo en mejorar la tecnología, pero no lo suficiente en lo que está pasando por sus cabezas. Piense en los factores impulsores por los que existe una oposición a las cosas nuevas. En muchos casos, solo temen algún riesgo. Identifique esos riesgos y encuentre argumentos en contra de ellos.

Tome la carne fresca : es más fácil ganarse a los empleados que quieren cambiar las cosas. Los notas inmediatamente cuando los ves.

Evite la carne podrida : algunos nunca simpatizarán con sus ideas. Déjalos a un lado.

Crezca a una masa crítica : encuentre personas que simpaticen con sus ideas. Gana el uno por uno. En algún momento, si se alcanza una masa crítica, cada vez más personas seguirán su ejemplo voluntariamente.

Vocabulario de gestión : los gerentes no están interesados ​​en mejores diseños. Su lenguaje es el dinero y el tiempo. Aclare cuántas horas de trabajo se desperdician por los insectos. Deje en claro que los clientes insatisfechos que encuentran errores no son rentables. Demuestre cuánto más rápido puede implementar una nueva característica. Debe elegir otro vocabulario para gerentes.

Se trata de procesos : mejores tecnologías no hacen mejores programadores y programas. Si tiene buenos procesos de ejecución, incluso las tecnologías obsoletas conducen a buenos resultados. Piense en el esfuerzo y el tiempo perdido. Tal vez no sea la tecnología, pero algo en los procesos está yendo terriblemente mal. En la mayoría de los casos es una falta de comunicación.

Encuentra una nueva empresa : ya has hecho mucho. Todavía puede intentar mejorar las cosas, pero también depende de usted decidir cuánto tiempo desea probarlo y cuánta energía desea invertir. Recuerde: incluso si no puede lograr muchas mejoras, aprenderá mucho de sus esfuerzos. En algún momento necesitas seguir adelante.

¿Alguna vez te has detenido a pensar que podrías estar equivocado?

Entonces lees algunos libros de diseños y patrones en la escuela y no tienes derecho a lo que parecen prácticas anticuadas en el trabajo. Sin duda, probablemente sean mejores ideas y los nuevos proyectos deberían comenzar con estos en mente, pero parece que estás en un nivel completamente diferente.

Los desarrolladores de pastoreo son como tratar de criar gatos, tienen una mente propia y una forma preferida de hacer las cosas, sean correctas o no. Me cuesta mucho aplicar las mejores prácticas y administrar un equipo de 2 desarrolladores, pero trabajas para una empresa que tiene 8000.

Ese es un número asombrosamente enorme. Incluso un simple cambio de proceso que establece que todos los desarrolladores deben programar reuniones y tiempo fuera de la oficina en el calendario público se convierte en una política enormemente compleja y difícil de implementar en todos los ámbitos. También requeriría un impulso significativo de la administración para asegurarse de que la política sea aceptada y adoptada en todos los ámbitos.

Puede que no lo piense, pero algo tan simple como pasar de monolíticos a múltiples archivos de encabezado, o mover el control de versiones de SourceSafe a Git requiere un enorme esfuerzo e inversión por parte de todos los involucrados. Requeriría:

• Apoyo significativo de gestión

• Amplia aceptación de la empresa

• Inversión de horas de reunión para todos los desarrolladores para informarles sobre las nuevas iniciativas (las reuniones cuestan horas hombre, las horas hombre cuestan dinero)

• La capacitación debe planificarse y establecerse para garantizar que incluso los desarrolladores más estúpidos sepan lo que están haciendo.

• Incluso suponiendo una hora de capacitación, en 8000 desarrolladores x € 50 / h = costo de capacitación de € 400000. Esto es más dinero de lo que mi equipo de desarrollo de software obtiene presupuestado en un año entero para salario, software y hardware. Esa es una inversión excepcional que está proponiendo.

Pero usted dice: "Piense en todo el tiempo que podría ahorrarse mediante aumentos de productividad". Con razón, pero una inversión significativa es un riesgo significativo, así que mejor me aseguro de que tengas razón sobre esto antes de que lo apruebe. Si ninguno de los hombres mayores te respalda, entonces no puedo justificar el gasto. En última instancia, podemos ser ineficientes, pero somos consistentes y con 8000 desarrolladores en toda la compañía, la consistencia es lo más importante.

Para hacer esto, debe cerrar la sesión de varias personas de nivel superior, y debe encontrar de manera precisa y objetiva una forma de medir el tiempo perdido del desarrollador a la ineficiencia. Ese tiempo equivale a dólares y solo los dólares y la política te ayudarán a ganar esta batalla.

Lo que has descrito no me suena a "dar ejemplo", parece que hiciste una propuesta y fuiste rechazado. Para liderar con el ejemplo, debe mostrarle a la gente que su camino es mejor. De los problemas que enumeró, veo tres que puede comenzar a usar sus propios cambios.

Makefiles viejos y simples que solo admiten la reconstrucción completa.

Cree sus propios archivos MAKE localmente y muestre cuánto más eficientemente puede trabajar con ellos.

archivos de encabezados monolíticos y proyectos con muy pocos archivos diferentes (pero cada uno tiene alrededor de 3000 líneas de código, que a veces se ocupa de tareas muy diferentes)

Divida los existentes cuando los toque (sin romper la compilación) o introduzca archivos de encabezado más pequeños cuando escriba un código nuevo. A medida que las personas comienzan a trabajar con ellos, se darán cuenta de que no necesitan la duplicación.

no se utilizan las "nuevas" instalaciones de idiomas (bueno std :: string no es tan nuevo pero nadie excepto yo lo usa)

Continúe introduciendo nuevas instalaciones de idiomas cada vez que toque el código antiguo o introduzca un código nuevo. Asegúrate de simplificar las cosas. No se desanime de este. La mayoría de nosotros somos flojos. Si vemos que una nueva función de lenguaje facilita las cosas, la adoptaremos.

Después de unos meses, si otros desarrolladores comienzan a adoptar sus mejoras, entonces puede acercarse a su jefe nuevamente sobre cambios más radicales como la actualización de su sistema de control de código fuente. Sin embargo, debe asegurarse de que los otros desarrolladores vean el beneficio, o de lo contrario nunca lo logrará. Una forma de abordarlo podría ser sugerir probar Git en un pequeño proyecto en el que solo unos pocos desarrolladores están activos. De esa manera, puede promocionarlo como una evaluación, no como una transición a gran escala a un sistema desconocido.

Finalmente, si después de varios meses de intentarlo, nadie parece interesado en mejorar la forma en que se hacen las cosas en su empresa, debe considerar realmente si es adecuado para usted.

Además de Lionel Barret (que estoy de acuerdo en su mayoría), considere también la posible motivación para la resistencia.

• Evaluar el costo del proceso real
• Evalúe el costo del proceso, ya que será como el suyo.

Pero también:

• Evaluar el costo del cambio en términos de
  • Dinero para gastar para configurar el nuevo entorno para cualquiera
  • Tiempo para dedicar a capacitar a todos para que se acostumbren al nuevo modo (puede ser fácil para usted, pero no tan fácil para las personas que no saben lo que está haciendo)
  • Tiempo transcurrido requerido para gestionar el cambio de manera no disruptiva.

Tengo un sospechoso: ¿cuántos hay en su compañía a las personas como usted en términos de edad y cultura (yo "escuela" y "tipo de escuela")? ¿Cuántas personas como usted se espera que sean contratadas en los próximos 2/3 años y cuántas se jubilarán o cambiarán su rol en la organización?

Mi sospechoso es que usted está en una posición sin suficiente fuerza para cambiar la compañía. En esa situación, la compañía lo cambiará o lo "expulsará" (en el sentido de que se convertirá en su propio deseo de irse), si no puede esperar más tiempo.

Pero puede ser que la compañía esté evaluando que los costos adicionales que le dije pueden ahorrarse permitiendo que el proceso de cambio ocurra espontáneamente al esperar que ocurra el reemplazo natural de las personas. Estás justo al comienzo de un proceso que no puedes ver porque no tiene nada (todavía) detrás de ti.

En este punto, solo puedo agregar una referencia al artículo de Joel Cómo hacer las cosas cuando solo eres un gruñido . Las secciones incluyen:

Estrategia 1 Solo hazlo

Estrategia 2 Aproveche el poder del marketing viral

Estrategia 3 Crear un bolsillo de excelencia

Estrategia 4 Neutralizar Los Bozos

Estrategia 5 Alejarse de las interrupciones

Estrategia 6 Hazte invaluable

Resumiría el artículo como "El cambio tiene que comenzar contigo".

Lamentablemente, las personas se quedan atrapadas en la rutina y desarrollan la mentalidad de que "funciona, todo el mundo lo usa bien, por qué cambiarlo" Y se vuelve irritante.

Lo ha hecho de la manera correcta no solo quejándose, sino desarrollando una solución viable como reemplazo, ahora solo necesita la aceptación.

Muestre a su gerente de línea directa (o líder técnico). Si no les interesa, ¿tiene a alguien a cargo del control de cambios o la innovación?

Sin embargo, sus ideas y su trabajo podrían ignorarse y la situación se mantendrá como está.

Debe exponer su caso de manera que su jefe esté de su lado. Por cierto, este tipo de cambio es propuesto por un director técnico o gerente de proyecto, por lo que deberá comprometerse con el proyecto. (Como una ruta alternativa, puede proponer una auditoría técnica, es probable que un extraño diga las mismas cosas que usted pero tendrá más peso).

Hasta ahora, no ve la necesidad de cambiar, parece que los cosméticos cambian para él: costoso sin beneficios obvios, excepto para satisfacer la fantasía de un desarrollador. Solo dos cosas le importan: el flujo de dinero y un equipo estable. La tecnología es una caja negra, si funciona, es suficiente.

Primero dinero, debes probar que la configuración actual le está costando dinero. ¿Cuál es el costo / hora de un desarrollador y cuántas horas los tiempos de compilación más rápidos le ahorrarían? Haz las matematicas. Además, compile artículos o testimonios sobre los riesgos del canal de código actual y muéstrele números aterradores: "debido a SourceSafe / Bad Coding Practices, nuestra compañía perdió $ XXXK".

En segundo lugar del equipo, su jefe puede estar atrapado con viejos codificadores gruñones que no quieren cambiar sus formas. Si se establece el primer punto, también debe proponer una solución a este problema. Cuantos son ustedes ? Podría ser interesante subrayar que será difícil reemplazar a alguien porque la tubería de codificación actual es bizantina. Debe proponer un plan para actualizar el equipo. Aprenda las mejores prácticas de la industria y verifique que estén siguiendo las nuevas reglas.

Finalmente, debe proponer un plan para cambiar la base de código, dividida en pequeños proyectos, con hitos y asignación de recursos. De hecho, te estás vendiendo a ti mismo como gerente de proyecto y los cambios son obligatorios para tener un canal de código sólido.

¿Trabaja en una organización que cree que hacer las cosas bien, la eficiencia y la innovación conducen al éxito y la rentabilidad; o que la búsqueda de ingresos y la concentración en mantener las ventas son los inquilinos del éxito?

Las empresas que se comportan como usted describe están tecnológicamente arraigadas. En un mercado competitivo, no podrían competir con una compañía que se enfoca en individuos e innovación.

Si eres la persona que dices que eres, entonces trabaja en un lugar que honre y recompense tu espíritu. Finalmente, después de años de asentarse, comenzará a comprometerse con la misma filosofía que sus superiores adoptan. Vaya a trabajar a otro lugar (probablemente una organización más pequeña) que valora el trabajo duro, la inspiración, la creatividad y el progreso.

Si no se arriesga y lo hace pronto, eventualmente se conformará y no podrá continuar alimentando su curiosidad y creatividad porque es filosóficamente opuesto en su grupo de pares actual.

La excelencia es una actitud y una visión del mundo.

Solo sepa que esta experiencia le dio la idea de saber qué evitar, vigile la complacencia y el proteccionismo para que pueda detectarlo temprano.

En su próxima entrevista, haga preguntas como "¿Qué tipo de innovaciones provienen de sus empleados", "¿Cuáles son algunos cambios que surgieron de la creatividad individual?", "¿Qué talentos individuales puedo aportar a este equipo?", "¿Qué impulsa el éxito de su organización? ? "," ¿Cómo está su organización adoptando continuamente la innovación tecnológica? "... Las respuestas a preguntas como esta son extremadamente reveladoras. Muchas organizaciones no tienen visión, o las que crearon la visión se han ido, y la organización está dirigida por contadores. Si se entrevista con el Director de Tecnología, pregúntele si ve a la organización como una empresa de tecnología.

Si no le gusta el entorno en el que está trabajando, se está perjudicando a sí mismo. Debe estar rodeado de personas que tengan intereses y objetivos similares a los que tiene profesionalmente. Sé que a veces es más fácil decirlo que hacerlo, pero la sensación de mirar hacia atrás varios años y sentir que has perdido el tiempo es peor que el miedo a arriesgarte.

Como alternativa, si desea desarrollarse en un sistema o un entorno que utiliza tecnología y / o metodologías específicas, le sugiero que encuentre un proyecto fuera del trabajo en el que pueda contribuir. Por lo menos, la variedad de trabajo en ambos sistemas satisfará la necesidad de algo diferente mientras encuentras a dónde perteneces.

Me parece que eres un pez fuera del agua. ¡Ve a buscar tu cuerpo de océano y nada!