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

40

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?

ereOn
fuente
10
"Decidí, hace unos meses, hacer algo al respecto" ... "Le mostré el resultado a mi jefe". Parece que te equivocaste de orden allí.
3
@ ThorbjørnRavnAndersen: No estoy seguro de obtenerlo: ¿cómo se supone que debo mostrar algo que aún no he hecho? ¿O tal vez quisiste decir que debería haberte preguntado antes de hacerlo?
antes del
21
He estado allí, y en mi opinión, debes salir de allí, porque, como dice el refrán, "un idiota siempre te vencerá, primero te dejará boquiabierto a su nivel y luego te superará con su experiencia ". Si las personas no reconocen la necesidad de actualizar, eso es un estancamiento profesional, y el estancamiento en nuestro campo es la muerte. Puede poner las cosas que ha hecho en su CV y, si es bueno, probablemente obtendrá un buen trabajo dentro de un mes de todos modos.
TC1
8
Santa vaca, 8000 desarrolladores? ¿Para quién trabajas, Facebook? Google? Microsoft?
Kyralessa
55
@ Kyralessa: no creo que Facebook ni Google usen VSS.
Jake Berger

Respuestas:

46

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.

Theo Lenndorff
fuente
3
Relacionado con "crecer masa crítica": youtube.com/watch?v=V74AxCqOTvg
back2dos
2
@Farmor si no puedes convencerlos sin decir "ve a leer una página web", tal vez eres tú quien necesita repasar las habilidades de comunicación.
1
Quiero decir si son tercos y no escuchan a los jóvenes. Puede expresar su punto haciendo referencia a la documentación. Por ejemplo, si dicen que sus puntos no son correctos y casi todos los expertos en versiones escriben su punto, se verán obligados a enviarlos. Y me gusta burlarse de los arrogantes. Por ejemplo, si les gusta Torvalds, puedes decir que Torvals dice "Si te gusta SVN, eres estúpido y feo", como lo hizo en su discurso de Google. No entiendo por qué referirse a la documentación cuando una persona obstinada no te creerá es lo incorrecto. Incluso puede hacerlo en su teléfono y mostrarlos de inmediato.
Farmor
66
-1 para el ageismo. A veces necesitas escuchar atentamente al "experto en fósiles" y permitirte tener un poco de humildad. Luego, con el conocimiento que ha adquirido, haga que su idea sea aún mejor. Dejar de lado a los demás solo porque son viejos es una forma segura de perder valiosos conocimientos y el apoyo de desarrolladores senior influyentes.
Doug T.
1
@Lundin: los gerentes deben tener experiencia técnica, pero cuanto más asciendes en la escala, más dinero y tiempo se vuelven importantes. No tiene nada de malo, porque alguien necesita hacer un seguimiento de los aspectos comerciales de una empresa. Es vital dar a los gerentes los argumentos correctos en sus manos para que puedan justificar sus decisiones ante sus gerentes. Como desarrollador, puede ganarse a un gerente si le sirve los argumentos correctos.
Theo Lenndorff
30

¿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.

maple_shaft
fuente
44
Gracias. Para ser sincero, al principio, cuando llegué, durante algunas semanas dije: "¡Qué demonios, estos tipos no tienen idea!" Entonces me di cuenta de lo equivocado que estaba en muchos puntos. Pero después de dos años allí, estoy bastante seguro de que algunos procesos pueden mejorarse y podrían resolver muchas de las quejas que escuché. Entiendo que también es una cuestión de opinión, pero si alguien viniera a mí con evidencia de que estoy haciendo algo ineficiente, al menos lo escucharía porque me está haciendo un favor. Mi departamento solo está compuesto por 40 personas, y solo nosotros hacemos este tipo de desarrollo.
antes del
1
Estoy seguro de que pueden mejorar, pero como dije, es diferente para mí cambiar mis comportamientos y prácticas para mejorar, que entrenar y obligar a 40 desarrolladores a hacerlo. Un gerente no técnico no te va a escuchar sin personas de alto nivel político que respalden la idea.
maple_shaft
No es solo "¿podrían hacerse mejor las cosas?". Reemplazar un repositorio fuente es un gran cambio. Hay un gran costo para hacer el cambio, entre los cuales se encuentra la recapacitación de todo el personal. Luego está el riesgo. ¿Está 100% seguro de que no habrá alguna capacidad que necesite el antiguo repositorio de código fuente, que desconozca y que no tenga el nuevo?
DJClayworth
@DJClayworth: El repositorio VSS solo se usa como un sistema de almacenamiento básico. Nadie mira el historial y generalmente borran todo antes de volver a copiar todo el directorio.
antes del
1
@ereOn Recuerde que trabaja para un negocio, y un negocio es ganar dinero, no codificar. A menos que sea un sin fines de lucro. En cualquier caso, su valor principal para sus clientes probablemente no sea "le entregaremos el código con los makefiles de compilación más rápidos de la industria". Debe resolver lo que le importa a su jefe (por ejemplo, reducir costos) y luego calcular los costos. Tenga en cuenta las personas y los costos de las herramientas.
jasonk
7

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.

Bill el lagarto
fuente
5

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.

Emilio Garavaglia
fuente
1
Sus conjeturas son acertadas: de hecho, soy uno de los más jóvenes de mi departamento. Algunos de ellos parecen darse cuenta de que a pesar de mi corta edad, tengo algunos conocimientos valiosos. Sé y entiendo que todavía tengo mucho que aprender (y creo que será así hasta el día de mi muerte), pero muchos de ellos parecen ofendidos por cosas que no saben. No quiero alejarlos o robarles su trabajo o lo que sea: solo quiero mejorar las cosas para que todos puedan trabajar / vivir mejor. ¿Tendré que esperar para ser mayor para subir de peso?
antes del
1
@ereOn: su conducción es tan noble que toda persona sensata debería querer trabajar con usted.
o0 '.
@ereOn: "¿Tendré que esperar para ser mayor para subir de peso?" No necesariamente. La edad es un valor en términos de experiencia en la gestión de la complejidad. No es un valor comprender cosas nuevas (son nuevas para cualquiera y no tener una acumulación puede ser una ventaja). No es un problema "personal". Es un problema de "masa crítica". Hasta que las personas que deseen el cambio sean inferiores al 20%, se asfixiarán. Si son más, el liderazgo se hace visible (y no es una cuestión de edad). Si un líder puede llegar al 40% de una población, la "cosa nueva" tendrá la ciudadanía adecuada. A partir del 60% el cambio es espontáneo.
Emilio Garavaglia
3

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".

Joshua Drake
fuente
2
Encontré que GTDWYOG no era muy útil. En mi opinión, al menos el título es engañoso: alguien que "está involucrado en la contratación" o tiene la libertad de ignorar al resto del mundo mientras trabaja en la cafetería no es un gruñido. Un gruñido es alguien que tiene que hacer lo que se le dice, con poco o ningún control sobre las circunstancias en que se encuentra. En mi experiencia, a pesar de la imagen idealista pintada aquí en stackexchange, ese es el caso para la mayoría de los desarrolladores. Y para aquellos, GTDWYOG es más una receta para ser despedido por desobediencia.
keppla
1

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á.

Amy
fuente
2
ah, pero la cantidad de veces que escuché "vamos a reescribirlo, será mucho mejor y más genial en la nueva tecnología x" solo para descubrir que la nueva no era mejor que la anterior (y en muchos casos peor). Muy a menudo, hasta que sea necesario , es mejor no romper algo que funcione.
gbjbaanb
1

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.

Lionel Barret
fuente
Gracias por tus consejos. El asunto es que a la persona a cargo parece gustarle mucho a todos los desarrolladores antiguos (porque al final, hacen el trabajo y no cuentan las horas). Siento que tengo muy poco peso porque soy joven. Sin embargo, varias personas en mi departamento vienen a preguntarme cosas sobre buenas prácticas, pero incluso cuando explico las cosas con mucha humildad, en algún momento no quieren demostrar que no saben mucho al respecto e intentan defender sus viejas costumbres.
antes del
1

¿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.

Ben DeMott
fuente
-1

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!

Wavedrop
fuente