Cómo tratar con un empleado que quiere usar nuevos marcos en software para sistemas críticos, pero no lo hago

Creo que inicialmente acepté usar un nuevo marco, pero después del análisis de riesgos y las auditorías en el software actual, dudo en usar un nuevo marco (por ejemplo, Angular) para sistemas críticos.

  • La pila de desarrollo actual puede ser respaldada tanto por mí como por el empleado.
  • Contratar personal de "nuevo marco" costaría mucho, no tenemos el presupuesto para contratar a estos desarrolladores (soy consciente de que este empleado quiere irse de todos modos).
  • Si usamos un nuevo marco, tendría que aprenderlo (no tengo tiempo ni interés).
  • El marco ya ha tenido una actualización no compatible con versiones anteriores, me preocupa si vuelve a suceder.
  • Los requisitos de auditoría externa son altos, "papeleo"/validación pesada, por lo que preferiría administrar un sistema/pila tan simple como sea posible, fácil de mantener.
  • Incluso el tema visual, estoy diciendo que nos quedemos con nuestro "bootstrap" de 5 años, no tiene sentido agregar uno nuevo.

Les he hecho saber esto pero todavía no lo entienden. Son mejores desarrolladores que yo y dicen que el "nuevo marco" permitirá un desarrollo "más rápido". Pero desde mi punto de vista, la entrega sólida y la mantenibilidad son más importantes. Especialmente si el personal va a cambiar.

Les dejé desarrollar algunas aplicaciones en un "nuevo marco" (paneles de control/widgets), ya que entiendo que debería haber algún desarrollador de carrera, pero para los sistemas críticos es demasiado arriesgado.

¿El desarrollador solo se preocupa por sí mismo y no por el equipo/proyecto? Si no están contentos aquí, ¿debo presionarlos para que se vayan?

Por "rápido" desde su perspectiva es la implementación, la codificación y la capacidad de adaptarse a futuras solicitudes de cambio, lo veo. Pero para mí no es solo la codificación, tenemos pruebas y documentación, nuevos errores al pasar a una nueva pila, etc. Las herramientas antiguas/la pila actual que tenemos hemos solucionado los problemas: es "maduro". Con un conjunto nuevo, habrá nuevos problemas que resolver, al igual que cuando pasamos por primera vez a la pila actual, había problemas que resolver.

Actualización: este desarrollador me dijo que lo que estaba diciendo era tonterías, en voz alta en el pasillo, de manera similar en un área común frente a la gente. Entiendo que hay conflicto, pero ¿es esa una buena manera de tratar con su gerente o incluso con alguien a quien usted administra? Se sentía como tratar con un niño/adolescente. Si no estoy de acuerdo con el director de operaciones, le enviaría algunos enlaces y fuentes.

Para hacer de esto una pregunta sobre el lugar de trabajo, ¿cuál es su relación profesional? ¿Compañero de trabajo, líder de equipo, gerente, dueño de la empresa?
Dijiste que hiciste un análisis de riesgo y auditorías. Entonces, ¿no le dio a los hombres de negocios los costos y los costos de riesgo de cambiar de marco? Los hombres de negocios son los que tienen el dinero, si es demasiado, no procederán. A menos que los desarrolladores puedan hacer una auditoría para demostrar que costaría menos que quedarse con la solución actual, que dudo que se pueda mantener con dos personas.
Los buenos marcos no rompen la compatibilidad con versiones anteriores en sus versiones LTS. Solo correcciones de seguridad/errores que pueden aparecer y, en términos generales, un buen marco tendrá LTS al menos 2-3 años y ofrecerá pautas de obsolescencia para actualizar a la próxima versión de LTS.
@Trevor Puede crear conocimiento tribal con cualquier marco. Los marcos no resuelven ese problema.
Podría ser que estén sintiendo presiones de obsolescencia. Tuve un gran equipo que eligió abrumadoramente un nuevo marco con el único motivo de que no querían pasar la próxima década trabajando en algo que tenía 10 años. El beneficio adicional fue que teníamos candidatos golpeando la puerta para unirse a nuestro equipo porque todos escucharon que era lo nuevo. ¿Fue técnicamente la mejor decisión? Quizás. ¿Pero fue la decisión de personal correcta? Sí. Irónicamente, hace que sea menos probable que los miembros del equipo se vayan si sienten que están en la última tecnología, a pesar de que mejoró sus currículums.
Sólo curioso. ¿Cuál es su stack tecnológico actual? Puede haber otras pilas que sean más simples y tan modernas como Angular (por ejemplo, vue.js?) que podría usar.

Respuestas (6)

¿El desarrollador solo se preocupa por sí mismo y no por el equipo/proyecto?

Esto es algo común para las personas orientadas a los negocios. En mi larga experiencia nunca ha sido cierto. Los desarrolladores se preocupan por el sistema: el negocio depende de que el sistema funcione, por lo que quieren producir un sistema de calidad. También esperan que les pidan cosas nuevas en el futuro, muchas veces durante un largo período. Dado que son ellos los que tienen que implementar las solicitudes, están muy conscientes de cualquier cosa que lo haga más difícil. El desarrollador, naturalmente, trata de establecer soluciones a estos problemas anticipados. Están tratando de prepararse para las necesidades comerciales.

Son mejores desarrolladores que yo y dicen que el "nuevo marco" permitirá un desarrollo "más rápido".

Citas "más rápido" aquí. No estoy seguro si no le crees al desarrollador en ese punto o tienes dudas sobre su valor.

Pero desde mi punto de vista, la entrega sólida y la mantenibilidad son más importantes.

Esto presenta una falsa dicotomía con más rápido. El desarrollador probablemente esté considerando estas cosas implícitas. En otras palabras: actualmente podemos proporcionar una entrega y mantenibilidad sólidas. Si cambiamos al nuevo marco, podemos proporcionar una entrega sólida y una capacidad de mantenimiento más rápida .

Por otro lado planteas puntos técnicos válidos. Cambiar de plataforma es realmente una gran empresa. No lo haría a la ligera.

Propongo preguntarle al desarrollador por puntos débiles específicos en el sistema actual. Suponga que tienen buenas razones para pensar lo que hacen y pregunte por ellas. ¿Se han visto obligados a usar hacks desagradables que se están acumulando en todo el sistema? ¿Están dedicando tiempo a crear capacidades que ya existen en los sistemas modernos? ¿El sistema actual está mal estructurado y tienen que luchar con él para lograr cosas que deberían ser fáciles?

Si hay cuestiones puntuales, lo que quieren es solucionar esas cuestiones. Si cambiar de plataforma es demasiado, pregunte si pueden sugerir formas menos drásticas de resolverlos. Ellos pueden tener algunas ideas. O puede encontrar que los problemas son realmente significativos y quedarse con el sistema actual es el mayor riesgo.

Escribes: "los desarrolladores se preocupan por el sistema". Sí estoy de acuerdo. Pero especialmente los desarrolladores más jóvenes tienen quizás otras prioridades que los desarrolladores más experimentados. Y la dirección ya tiene de nuevo otras prioridades. Creo que no debemos asumir que todos tienen las mismas prioridades.
Sin duda he conocido a desarrolladores que han estado interesados ​​en explorar el nuevo shiny porque era nuevo y brillante, fuera o no la respuesta correcta para la empresa. Aún así, el consejo de preguntar sobre motivos específicos de conducción es excelente.
@BenBarden Tendré que duplicar tus palabras. He visto una buena cantidad de desarrolladores que impulsaron nuevas tecnologías (y algunas veces, muy antiguas) solo porque era lo que les gustaba, no lo que sería mejor para el problema en cuestión. Aprender nuevas tecnologías es bueno; forzarlas a resolver un problema sin la atención adecuada no lo es.
Después de ver a tantos empresarios que no logran comprender las implicaciones técnicas de algo y descartan al desarrollador exactamente en estos términos, me he vuelto escéptico. Cuando un desarrollador habla de hacer algo "más rápido" es porque la situación actual lo está haciendo terriblemente lento. Ese es un impacto comercial que la gente de negocios a menudo no ve.
Como una persona técnica que actualmente está limpiando el desorden de un desarrollador que insistió en usar las cosas nuevas y brillantes sin considerar su valor real, diría que definitivamente hay dos caras en esta moneda. Algunas de las cosas nuevas y brillantes que presentó son, de hecho, bastante útiles, pero algunas fueron una gran pérdida de tiempo. Está claro que no estaba pensando mucho en las necesidades comerciales reales, por lo que las cosas que tuvieron éxito parecen tener tanta suerte como cualquier otra cosa...
Hay toneladas de casos de negocios que van en ambos sentidos. Si las personas persiguieron "NoSQL" y luego lo hicieron funcionar con PHP y su negocio se basa en gran medida en transacciones, entonces es simplemente una estupidez. Si insiste en usar RDBMS tradicional pero luego va a almacenar blobs JSON, entonces también es estúpido.

Si usted es el administrador de personas, entonces usted toma la decisión. Es bueno si todos están de acuerdo, es importante que todos respeten la decisión.

Debe tomar la decisión que sea mejor para la empresa. Es bueno tener un código que pueda ser manejado por usted si es necesario, o por un nuevo desarrollador sin conocimientos especializados . Por otro lado, es bueno usar un marco si realmente ayuda y no solo está de moda. Cualquier cosa que requiera cambiar su código existente es negativa. Tener un empleado entusiasta que esté dispuesto a producir buenos resultados para demostrar que tiene razón es bueno. Es su trabajo sopesar los pros y los contras, decidir qué es lo mejor y tomar la decisión.

¿Qué tal si creas una lista con los pros y los contras de los diferentes marcos junto con todos? Debe incluir aspectos técnicos, qué se puede hacer o no con los marcos, qué tan rápido se pueden hacer las cosas, problemas de estabilidad, historial (un marco es quizás estable, el otro es nuevo y quizás todavía tenga algunos errores) etc.

Creo que es mejor crear esto junto con el equipo en un orden más o menos aleatorio. Tal vez los desarrolladores quieran hablar primero sobre las cosas buenas del nuevo marco y luego les preguntas sobre problemas de estabilidad, etc. En esa etapa, solo se trata de recopilar información.

Y una vez hecho esto, puede ver las prioridades. Es decir, para un proyecto o una parte del proyecto, tal vez la interfaz debería verse moderna y tal vez sea más fácil hacerlo con el nuevo marco. Y por otra parte quizás sea más importante que todo sea 100% estable aunque tarde más, etc.

Si hace esto junto con el equipo, todos deberían llegar a la misma conclusión sobre qué marco se debe usar para qué.

Pero al final del día, usted es el administrador y el responsable de esto. Así que es tu cabeza si algo sale mal. Tienes que decidir, mejor con el equipo pero si es necesario en contra de su consejo (después de que todos conozcan los pros y los contras).

y el costo de redesarrollar los sistemas
Estoy totalmente de acuerdo, excepto que el OP debe hacer que el desarrollador en cuestión realice este trabajo. Permítales resolver los pros y los contras y hacer una presentación frente a todo el equipo, tratando de convencer a todos por qué su enfoque es beneficioso.
@TheoTiger: Si quieres que ese desarrollador se vea mal, entonces hazlo. Si quieres un equipo feliz, estoy seguro de que es mejor dejar que el equipo trabaje en conjunto y descubran juntos qué es lo mejor.
@Edgar Dejar que el equipo lo descubra es en realidad parte de lo que estaba sugiriendo: si ese desarrollador tiene una idea para mejorar la estrategia de desarrollo de la empresa, déjalo que haga una presentación y que el equipo la discuta. Si pueden persuadir a todos por qué su enfoque es bueno, está bien. De lo contrario, recibirán comentarios sobre por qué su idea no es superior en todos los aspectos y aprenderán cómo se toman las decisiones en la empresa. Ambas son lecciones importantes que podrían aprender a través de esta práctica.

¿El desarrollador solo se preocupa por sí mismo y no por el equipo/proyecto?

Los profesionales siempre están preocupados por ellos mismos y sus carreras, y si el proyecto/equipo se alinea con eso, mejor que mejor. Eso es perfectamente aceptable. Su colega quiere ir a algún lugar donde usen estas nuevas tecnologías y probablemente paguen mucho mejor que usted.

Si no están contentos aquí, ¿debo presionarlos para que se vayan?

No empujas a alguien a irse. Habla con ellos sobre su futura carrera en su empresa, establece expectativas, escucha quejas y habla sobre cómo trabajar mejor para ellos como gerente. Si la única forma en que alguien va a ser feliz es irse a donde se usa la tecnología brillante y sexy, eso es algo que tienes que intuir, no algo que les digas.

Parece que ya está permitiendo que el desarrollador practique sus habilidades en nuevos proyectos, y ha explicado la razón por la que no migra el sistema sensible a una tecnología más nueva. Tal vez no lo entendieron, tal vez no lo explicaste bien. Asegúrese de enfatizar que tiene poco que ver con el tiempo de desarrollo real y todo que ver con la presión externa.

En realidad, no. Diría que, como profesional, siempre estoy preocupado por el proyecto/equipo y si mi carrera/interés se alinea con eso, mucho mejor.

Tiene dos problemas que podrían estar en conflicto entre sí.

  1. Gestión de la "pila técnica"
  2. Gestión de una persona técnica.

Administrar la "pila técnica" es decidir qué lenguajes, herramientas, marcos y sistemas de prueba utilizará la empresa, especialmente para el trabajo de producción crítico. No se debe permitir que ningún desarrollador cambie esa pila. Esta es una decisión que asciende en la cadena de mando, ya que afecta el cumplimiento y la auditoría de su empresa. Muchos desarrolladores no son conscientes de todos los costos que entran en juego. Si su alta gerencia no ha estado involucrada antes de esto, recomiendo hacerles una presentación de cuáles son realmente los problemas: por qué tiene la pila de tecnología actual, cuáles son los costos para realizar cualquier cambio y cómo presentará cambios a ellos en el futuro. En resumen, está tirando de toda su cadena de gestión para respaldarlo en sus elecciones. "Desarrollador, esta es la pila técnica de la corporación XYZ.

Ahora, una vez que una empresa ha tomado una decisión sobre la "pila técnica", se trata de tratar con un desarrollador que quiere usar un nuevo marco. Ciertamente, esto puede usarse para tareas no críticas con el fin de descubrir cuál podría ser la gama completa de costos. Sin embargo, recomiendo tener un proceso escrito para evaluar nuevas tecnologías que podrían considerarse para el trabajo de producción crítico. Una vez más, los resultados de esa evaluación tendrán que ascender en la cadena de mando con un análisis de costo/beneficio para convencer a la alta dirección de cambiar.

Digo eso después de ser un desarrollador que ocultó nuevas tecnologías en proyectos y usó tales cosas para tratar de convertir la gestión a nuevas tecnologías. No sabía todos los costos que estaba tratando de imponer a la empresa. Estaba equivocado. Ese es un comportamiento que debe suceder, no en proyectos críticos.

Como un profesional de software que ha estado en este negocio por... (koff, koff, jadeo) ... "bastante tiempo ahora", la situación básica que ahora está describiendo es: " sistemas heredados ".

Por ejemplo, "mi empleador actual fabrica sofás desde hace más de 85 años". Cuando IBM presentó por primera vez el " Sistema/36 ", compraron uno. Cuando "RPG" era el mejor lenguaje de elección, escribieron montañas de código usándolo... ¡y todavía venden sofás!" (Y: "esos sofás siguen siendo cómodos, apuesto a que conoces a alguien que tiene uno").

Por lo tanto, hay, y siempre habrá, "una dicotomía" entre las tecnologías que decidimos usar y las tecnologías que hoy preferiríamos haber usado si ya se hubieran inventado. Pero nunca podemos esperar que los "nuevos programadores" entiendan esto... todavía. 🤷‍♂️

Cómo tratar con un empleado que quiere usar nuevos marcos en software para sistemas críticos, pero no lo hago
RespuestasAquíPolítica de privacidad1y, 0v