Los desarrolladores no pueden ver lo que están haciendo mal

Me gustaría que entendieran por qué quiero hacer algo. [...] ¿Algún consejo?

No teorices, muéstrales.

Su estado mental actual es que saben que lo que hacen funciona . Y te acercas y les dices que teóricamente esto es malo. Nunca ganará a nadie diciéndole que está haciendo un mal trabajo, mientras que usted podría hacer uno mucho mejor. Todo el mundo puede decir eso. Es como si la gente sentada en su sofá viendo la televisión le gritara a los atletas profesionales que podrían haber mejorado su juego.

Si quieres que te sigan, predica con el ejemplo. Si ve algo que necesita mejorar, muéstreles cómo falla. Proporcióneles una solución práctica del mundo real.

¿Quiere un código que se adhiera más a los principios SOLID? Luego bríndeles un ejemplo práctico de por qué el código actual no es óptimo ("Si hago esto, se rompe") y luego sugiera una alternativa real ("Lo he cambiado a esto, ahora ya no puede suceder").

¿Tiene muchos errores de regresión que no ocurrirían con mejores pruebas? Bueno, compila una lista y haz que prueben todos y cada uno de ellos con cada lanzamiento. Eso es lo que es necesario para el negocio. Y luego escriba uno de esos como una prueba unitaria, muéstreles lo simple que podría ser su vida y déjelos decidir si quieren pasar su tiempo haciendo trabajo pesado revisando manualmente una lista de pruebas durante horas o si quieren tener un sofisticado automatizado. conjunto de pruebas que pueden ejecutar con solo chasquear los dedos.

El punto aquí es no decirles qué podría ser mejor. En teoría, todo podría ser mejor para ellos si simplemente ganaran la lotería. Elija un caso específico, muéstreles por qué es malo y luego proporcione una solución funcional. No es una palabra de moda o una teoría, sino un primer paso práctico que pueden tomar ahora mismo.

Decir simplemente a sus subordinados que hagan algo de lo que no pueden ver el beneficio es una receta para el desastre, que usted ya reconoce, así que hágalo divertido para ellos. La gamificación puede no ser fácil para ti, pero puede funcionar para suavizar otros puntos más ásperos.

En un estudio realizado por Sharp et al. (2009), los investigadores sugieren que el factor más influyente en la motivación de los desarrolladores fue su capacidad para identificarse con su trabajo. Esto significa que la mayoría de los desarrolladores deben encontrar un sentido de propósito en el trabajo que realizan, o su motivación para seguir trabajando disminuirá.

https://medium.com/gameful-design/does-gamification-work-in-the-software-development-process-76780e49e545

También es posible que desee reservar algo de tiempo para mostrarles no solo cómo hacer algo, sino también cómo mejora su código, su capacidad para mantenerlo y cómo puede acelerar su proceso de desarrollo. Otra respuesta de nvoigt habla de eso, pero lo diré de manera ligeramente diferente: mostrar, no decir.

Probablemente deba comenzar lentamente, como 2-3 horas un día a la semana. Comience con algo que sea un completo desastre, o simplemente demasiado complicado y difícil de entender. Tal vez sea algo en lo que todos odien trabajar, pero aún no les muestres cómo solucionarlo. Solo úselo como ejemplo, luego tenga algo más, algo más simple, para mostrarles cómo hacer mejoras menores en el código que pueden tener efectos importantes. Una vez que haya pasado por 2 o 4 de estas pequeñas mejoras en un par de semanas, vuelva al "lío de monstruos" y use las mismas técnicas que les mostró anteriormente para reducir, reutilizar y, en general, simplificar el código de espagueti que primero les mostró.

Es posible que incluso desee iterar a través de este enfoque. Enséñales un par de cosas y luego úsalas en el "desastre de monstruos". Enséñales algunas cosas más, luego úsalas para mejorar aún más al monstruo. Hacer espuma, enjuagar, repetir.

Y no lo hagas todo tú solo. Pregunte por las formas en que las personas pueden ver para mejorar el código. Es solo en parte una conferencia, necesita involucrar a su gente en el proceso. Para respuestas correctas o incluso conceptos cercanos, puede entregar mini barras de chocolate , como dulces de Halloween (las cosas buenas, no la chatarra barata). Esto también les da un impulso extra de azúcar para que el cerebro funcione mejor.

Puede encontrar que algunos de ellos ya saben lo que quiere usar, pero tienen la impresión de que no lo saben. Soy sobre todo un programador autodidacta. He investigado mucho a lo largo de los años y entiendo todo tipo de conceptos, pero no necesariamente conozco los términos para esos conceptos. (Recientemente arruiné una entrevista debido a esto). También es posible que ya usen los conceptos y piensen que no los está reconociendo por ello. O los están usando incorrectamente y solo necesitan pequeños ajustes para hacerlo correctamente, en lugar de una revisión de su proceso. Hay muchos problemas sociales o culturales diferentes con los que te puedes encontrar que son la causa de la fricción, en lugar de tener algo que ver con la tecnología.

ayuda externa

También hay muchos sitios web que se centran en la codificación de juegos, incluso si no necesariamente enseñan SOLID o los otros principios que está tratando de implementar. Solo tendrás que investigar para encontrar uno que lo haga. He usado CodinGame para mejorar mis habilidades de codificación, pero no recuerdo específicamente qué principios, si es que hubo alguno, enseñaron los desafíos. Hay muchos desafíos en el sitio y la mayoría son creados por miembros, por lo que se siguen agregando, por lo que es posible que haya algo que pueda usar. Solo asegúrese de obtener la aprobación para hacer esto en el horario de la empresa primero. Y sí, debe hacerse en el horario de la empresa, de lo contrario se convierte en una "tarea" que probablemente no se hará.

La implementación de la programación entre pares también puede ayudar. Juntar a un senior y un junior para trabajar en una tarea puede enseñarles a ambos cosas nuevas. También puede ayudarlos a superar un obstáculo en su aprendizaje. Esto puede ser el equivalente a la enseñanza 1 a 1, sin que usted tenga que hacer la enseñanza. Además, una de las mejores formas de aprender es enseñando. Si puedes explicárselo a alguien más, lo entiendes. Y cuanto más fácil puedas explicárselo a otra persona, más probable es que realmente lo entiendas y no estés simplemente repitiendo lo que dice un libro o un artículo.

no lo fuerces

No importa lo que haga mientras intenta que su equipo aplique estos "nuevos" principios, hágalo atractivo para ellos como desarrollador. No utilice un Plan de mejora del rendimiento (PIP), como sugiere otra respuesta. Poner los trabajos de las personas en la línea es casi una forma garantizada de lograr que se vayan independientemente de si completan el PIP. Y si se quedan, no confiarán en usted para intentar implementar más cambios y otro PIP. Al igual que cualquier otra parte de la vida, los ultimátum rara vez funcionan y casi nunca mejoran la confianza.

Explíqueles cómo va a mejorar su trabajo y su vida personal. Una contraseña expuesta/no encriptada puede dar lugar a infracciones que los dejarán trabajando las 24 horas del día para tratar de parchear y restaurar cualquier cosa dañada por el hackeo. No deje esto al azar o en algún momento lejano imaginario/no especificado en el futuro, pregúnteles cómo reaccionarían si esto sucediera durante un momento importante en su vida, como una boda, vacaciones, un juego deportivo infantil o lo que sea. Que sea un ejemplo práctico, relevante para ellos. Luego recuérdeles que arreglarlo ahora previene ese tipo de desastre.

Explique cómo hacer las cosas más simples reduce su carga mental al hacer cambios futuros. Explique cómo reutilizar los mismos métodos no solo puede simplificar el código, sino que también facilita encontrar el código que están buscando. Explique cómo el polimorfismo puede reducir las líneas de código y cómo a veces puede no ser apropiado. Sí, explique cómo algunos de los conceptos que desea implementar no siempre son necesarios o, a veces, complican demasiado las cosas innecesariamente. También explique que la mayoría de estos cambios se pueden hacer iterativamente a medida que se necesiten, no "solo porque yo lo diga". La mayoría de estos conceptos son solo "reglas empíricas", en lugar de ser inamovibles, que es probablemente lo que realmente están rechazando.

Claro, esto deja la puerta abierta a que los cambios sucedan más lentamente, pero eso probablemente hará que funcione mejor. Al igual que con una dieta, si hace demasiados cambios demasiado rápido, dejará la dieta más rápido de lo que la empezó y nunca podrá volver a la dieta.

Advertencia

No trate de hacer demasiado de una vez. Hice que un gerente le diera a mi departamento un libro de varios cientos de páginas sobre los principios de SOLID y nos hizo leerlo a todos. Era tan aburrido que no podía pasar ni 5 páginas sin quedarme dormido. Esto fue mientras el gerente intentaba hacernos cambiar una cantidad muy significativa de cómo escribimos el código casi de la noche a la mañana. Sí, necesitábamos hacer esos cambios, pero hubo tantos cambios que no pudimos seguir el ritmo de todo. Y todo fue una orden, sin espacio para preguntas o incluso explicaciones de qué o por qué se necesitaban los cambios. Junto con otros cambios significativos en la actitud de la gerencia, esto me llevó a encontrar un trabajo diferente después de 4 años de estar allí.

Es probable que su gente se haya sentido cómoda en sus posiciones. Eso no es necesariamente algo malo, pero los cambios que está intentando hacer los hacen sentir incómodos. Estar incómodo es generalmente cuando las personas aprenden cosas, simplemente no lo hagas demasiado incómodo o perderás a la gente. Y puedes perderlos sin que realmente encuentren un trabajo diferente. Asegúrese de trabajar con ellos cuando tengan dificultades y sea comprensivo cuando tengan reservas.

No estoy diciendo que los mimen o los mimen, simplemente no sean una pared de ladrillos, donde todo rebota y no pueden obtener ninguna respuesta.

Parece que estás estresado por esto. Necesitas sacarte este estrés de encima. Esto es lo que recomendaría:

Parece que el equipo no conoce la importancia de todos los problemas técnicos que ha señalado. Hay dos maneras de hacer que la gente entienda:

1. Haz que solucionen esos problemas y luego realiza un seguimiento de los resultados.
2. Usted se ocupa de esas correcciones y muestra los resultados.

Esto último siempre me ha funcionado. Cuando lo haces bien y cuando el equipo ve el valor de lo que has hecho. Se ven obligados a cuidarlo en el futuro, naturalmente.

Puede elegir uno de esos problemas técnicos con los que está familiarizado y en los que cree que puede marcar la diferencia.

Comience y manténganos actualizados...

Necesita atacar este problema en múltiples frentes:

Primero, ofrezca pagar clases que enseñen las prácticas y las razones para usarlas. Ofrecer un bono y/o aumento de sueldo a cualquiera de ellos que obtenga certificados. No le des más de dos meses para comenzar a obtener algo de tracción. Puede encontrar que algunos de ellos están dispuestos a hacer al menos un poco de esfuerzo.

Tape los agujeros de datos. Necesita pruebas para respaldar sus afirmaciones. Todos los registros de código deben asignarse a un error, característica o historia de usuario. Comience a medir el tiempo dedicado a trabajar con esos errores y características. Agregue autopsias frecuentes. Todos necesitan saber exactamente cuánto esfuerzo se dedica a reescribir el código frente a agregar código nuevo, para cada tarea. Regrese y analice errores antiguos. ¿Cuál fue la causa raíz? ¿Fue un error del día cero o se introdujo porque el "código que funciona" se dobló para agregar algo nuevo?

Contrate a un consultor para revisar su base de código y prácticas de desarrollo, y escriba una lista de las diez cosas que la empresa debería arreglar.

Empieza a prepararte para despedir gente. En primer lugar, contrate a un ingeniero sénior de temporal a permanente (preferiblemente uno con dicha(s) certificación(es)) y comience a trabajar con él para solucionar algunos de los problemas más graves. Después de unos meses, cuando el trabajador temporal controle la base del código, contrátelos y traiga al siguiente trabajador temporal, luego despida al desarrollador que trabajó más duro para bloquear sus esfuerzos. Enjuague y repita.

De una forma u otra, debe tener el equipo adecuado en el trabajo. Si no son los trucos actuales, entonces tienes que reemplazarlos. Si bien puede ser un mentor y promover el aprendizaje permanente y la mejora continua, no es su lugar educarlos, porque ese no es su conjunto de habilidades.

Prefacio

Dado que esta pregunta se publicó en Project Managment Stack Exchange y no en The Workplace ni en ningún otro sitio relevante, la única forma válida de responder a esto desde la perspectiva de la gestión de proyectos es centrarse en las responsabilidades organizativas y de gestión de proyectos. Eso significa eliminar muchas de las partes no esenciales de su pregunta y centrarse en los aspectos centrales de la gestión de proyectos que tienen respuestas canónicas o, al menos, las mejores prácticas ampliamente aceptadas.

TL;DR

Puede o no estar involucrado con una organización disfuncional, pero ciertamente está malinterpretando su rol dentro del espacio de gestión de proyectos y puede carecer de las habilidades adecuadas y el empoderamiento organizacional para hacer su trabajo con éxito. Su objetivo principal debe ser colaborar tanto con su equipo de liderazgo como con sus desarrolladores para lograr acuerdos de trabajo funcionales que cumplan con los objetivos de la organización para el proyecto y, al mismo tiempo, empoderar a todos (incluido usted) para refinar continuamente el proceso hasta que cumpla con sus objetivos basados ​​en resultados. .

Análisis situacional

Hay mucho material en su pregunta que básicamente se reduce a algunos elementos clave:

1. Es posible que esté lidiando con algunas diferencias entre las culturas laborales europeas y estadounidenses. Incluso si ese no es un problema directo, ciertamente está coloreando parte de la perspectiva y el marco de su situación, y debe reconocer este aspecto del problema.
2. El CTO no se está apropiando del problema ni está dispuesto a ejercer autoridad directa. Cuando un ejecutivo de nivel C dice que las personas son libres de renunciar (en lugar de que puedan ser despedidas), esa persona se niega a ejercer autoridad directa y lo pone a usted en la posición de tener que resolver el problema a través de la influencia en lugar de la autoridad delegada.
3. Su equipo de desarrollo se resiste a su enfoque recomendado, ya sea que se presente en forma de sugerencias, directivas, principios de diseño o cualquier otra cosa que pueda estar en cuestión. El hecho de que lo hagan de una manera que usted perciba como grosera es una indicación de que no se ha ganado su respeto a través de la autoridad delegada o la influencia de habilidades blandas. El resultado final es que no tiene la capacidad de efectuar un cambio significativo, si es que ese es un objetivo organizacional para usted.
4. Desde una perspectiva de gestión de proyectos, nada en su publicación aborda métricas, KPI, controles de proyectos o cualquier otra cosa medible. El cambio es difícil y necesita ser liderado desde un lugar de visión ya través de la aplicación de un interés propio ilustrado. La gestión de proyectos como profesional suele ser una función difícil precisamente porque es una función con mucha responsabilidad, pero con muy poca autoridad directa o delegada. Como resultado, los gerentes de proyecto suelen tener más éxito cuando se enfocan en los controles del proyecto en torno al presupuesto, el alcance, el cronograma y la calidad, en lugar de en cuestiones arquitectónicas o de ingeniería.
5. Su concepción de su papel necesita aclaración. ¿Está destinado a ser un gerente intermedio, un líder de servicio, un entrenador, un líder de pensamiento de procesos comerciales o algo completamente diferente? El hecho de que no tenga una idea clara de cómo se supone que debe liderar el equipo, y que el liderazgo senior no le dé instrucciones sobre lo que se supone que debe lograr que el equipo logre, son siempre indicadores de un proceso organizacional. problema.

Sin duda, hay muchos otros problemas planteados por su publicación, así como la forma en que los enmarca. Sin embargo, creo firmemente que la breve lista anterior cubre la mayoría de los temas procesables y aquellos en los que debe centrar su energía inmediata.

Recomendaciones

No existe una lista completamente canónica posible para los problemas de personas e influencia, pero enmarcarlos como problemas organizacionales conduce a soluciones bastante claras. Si bien no es exhaustivo, sin duda recomendaría alguna combinación de las siguientes actividades:

1. Asegúrese de obtener una guía clara del liderazgo ejecutivo sobre el alcance de su autoridad (si corresponde), así como expectativas y métricas claras sobre cómo se evaluará su desempeño en el puesto.
2. Cualquier problema que no pueda resolverse dentro del alcance de su autoridad o influencia debe comunicarse claramente al liderazgo superior junto con las métricas y recomendaciones de apoyo. Lo que elijan hacer con esa información (si es que lo hacen) es su responsabilidad y no la tuya.
3. A menos que se haya hecho explícitamente parte de su trabajo, no piense en términos de gestión del cambio. Piense en términos de resultados medibles . Trabaje con el equipo para identificar los resultados deseados, los indicadores clave de rendimiento que miden el progreso hacia esos resultados y cualquier control de proceso necesario para lograr esos resultados. En otras palabras, cree responsabilidad compartida para resultados claramente definidos en lugar de intentar generar un cambio de arriba hacia abajo que no puede crear sin la colaboración activa del equipo.
4. Deje de aceptar la responsabilidad por los problemas que le faltan las herramientas, las habilidades, la autoridad u otros medios para controlar. Cree responsabilidades compartidas donde pueda, refiera otros problemas al nivel organizacional donde puedan resolverse y asegúrese de que todas las partes (incluido usted, los desarrolladores y el CTO) tengan muy claro quién es responsable de qué dentro de su organización existente. cultura.
5. Recuerde que ahora es un "Gerente de proyectos tecnológicos" (lo que sea que eso signifique dentro de su empresa), y no un desarrollador. Así como usted quiere ganarse su confianza en usted mientras desempeña su función, también necesita generar y demostrar la confianza que ellos necesitan para desempeñar la suya. Si eso no está sucediendo, eso es parte de lo que todos ustedes deben arreglar colectivamente .

Los roles, las responsabilidades, la confianza, la colaboración y los acuerdos de trabajo nunca son iguales para todos. Estas son cosas que deben discutirse honesta y abiertamente, especialmente en puntos de inflexión clave, como cambios en la composición del equipo o cambios organizacionales en roles y responsabilidades. No resolverá estos problemas de la noche a la mañana, pero si estas cosas no son fundamentales para su plan para abordar los problemas que ha identificado, entonces finalmente está resolviendo el conjunto equivocado de problemas. La transparencia, la comunicación y la colaboración son sus mejores herramientas, así que utilícelas con la mayor frecuencia y eficacia posible.

De su publicación, parece que todo el equipo no está a bordo. Por lo tanto, no son ellos; es usted y su gestión.

• ¿Cómo está trabajando el equipo?
• ¿Cómo se manejan las estimaciones, por quién?
• ¿Son las consecuencias de la deuda técnica una preocupación real de gestión?
• ¿Se detendrá el nuevo desarrollo hasta que se corrija toda esta deuda técnica?

Póngalos en Planes de Mejora del Desempeño.

Actualmente no se están desempeñando adecuadamente y tiene una lista de las formas en que su rendimiento es deficiente. Afortunadamente, existe una herramienta para mejorar el rendimiento que utiliza exactamente ese tipo de listas: el Plan de mejora del rendimiento.

La motivación se clasifica en dos tipos, intrínseca y extrínseca, y como parece que carecen de motivación intrínseca, es necesario utilizar la motivación extrínseca, y eso se rige por los incentivos. Puede hacer esto ofreciendo bonificaciones por alto rendimiento, pero parece que su principal problema es que su rendimiento ni siquiera es adecuado, y eso es lo que el Plan de mejora del rendimiento está diseñado para abordar. El Plan de mejora del rendimiento establece los incentivos muy claramente: complete los siguientes objetivos en el tiempo indicado y evitará perder su trabajo.