Tratar con programadores inflexibles

A veces, los programadores que trabajan en un proyecto durante mucho tiempo se vuelven inflexibles y resulta difícil razonar con ellos. Incluso si logramos convencerlos, es poco probable que implementen nuestras sugerencias.

Por ejemplo, recientemente me uní a un proyecto donde el proceso de compilación y lanzamiento es demasiado complicado y tiene obstáculos innecesarios.

Sugerí que elimináramos parte de la sobrecarga del desarrollo (como llenar algunas hojas de cálculo) simplemente integrando herramientas de gestión de defectos y control de versiones (ambas son herramientas de IBM-Rational, por lo que la integración puede ser un esfuerzo único muy sencillo). Además, si utilizamos herramientas como Maven & Ant (el proyecto involucra Java y algunos productos COTS), la compilación y el lanzamiento pueden simplificarse, lo que debería reducir los errores e intervenciones manuales.

Me las arreglé para convencer a los demás y estoy listo para hacer el esfuerzo de desarrollar una prueba de concepto. Pero el desarrollador 'Senior' no está dispuesto, posiblemente porque el proceso actual lo hace más valioso.

¿Cómo manejamos esta situación sin desarrollar fricción en el equipo?

Eres el nuevo miembro del equipo y quieres cambiar algunos aspectos fundamentales de cómo funciona el equipo. Buena suerte, siento un equipo feliz en tu futuro.

Ok, algunos consejos prácticos:

Demuestra tu valía al equipo. Deberá hacerlo desde una perspectiva técnica y de confiabilidad. Si desea que la gente lo siga, debe darles una razón para hacerlo.

Comprender la historia de la metodología. ¿Por qué existe? ¿Qué problema estaba resolviendo en ese momento? Asegúrese de que su solución sea realmente un beneficio para el equipo. Tal vez sus cambios sean mejores, pero en realidad podrían no resolver un problema que tiene el equipo.

Conozca sus obstáculos. Descubra las razones de su resistencia y trabaje en esos artículos.

Si quiere ser un agente de cambio, aprenda a ser un agente de cambio exitoso . Docenas de libros y otras fuentes disponibles para proporcionarle mucha más información de la que obtendrá aquí.

Y sí, te deseo suerte. Pero por favor, por el bien de su felicidad y la felicidad de su equipo, sea inteligente al respecto. Su deseo de hacer un cambio de proceso, sin invertir la energía para diseñar el camino correcto, podría hacer mucho más daño que bien.

He estado en la posición que has mencionado. Pasé años como desarrollador de Java y eventualmente entré en un trabajo donde todos usaban Smalltalk. Mi primera reacción fue "OMG, están utilizando esta tecnología anticuada" y comencé a intentar resolver problemas específicos de Smalltalk con soluciones Java. Solo puedo imaginar el dolor de cabeza que debo haberles causado a los otros desarrolladores y odiaban Java con pasión.

No fue sino hasta que me dieron un proyecto de tamaño mediano para trabajar mientras me orientaban dos desarrolladores senior en el transcurso de unos meses que comencé a acostumbrarme al lenguaje Smalltalk y aprendí a que me gustara. Desde que dejé ese trabajo y volví a desarrollar Java, me siento mucho más flexible en cuanto a que puedo tomar un proyecto e implementarlo en cualquier idioma que use la compañía. Lo esencial para que estas personas entiendan es que el idioma no es más que el medio. También me he tomado el tiempo de enseñarme a mí mismo a Lisp y Erlang, pero eso podría no funcionar con todos.

Como estrategia de trabajo en equipo, recomendaría Siete idiomas en siete semanas a las personas con las que tienes problemas.

Supongo que también se reduce a cuánto tiempo estas personas están dispuestas a invertir para ser más flexibles. El problema con la mayoría de las universidades (al menos las que he visto) es que están sesgadas hacia un idioma específico y sus estudiantes se 'institucionalizan' como usted mencionó. Creo que parte de su estrategia debería ser cultivar la flexibilidad en su equipo. Esto podría complementarse con el desarrollo impulsado por dominio .

(1) Modelar un dominio (uno simple) (2) Implementarlo usando dos lenguajes diferentes (es decir, Java y Lisp)

Nuevamente, esto se supone que están motivados para hacer lo anterior y están dispuestos a invertir su propio tiempo para lograrlo.

Espero que esto ayude

Podría estar en un camino totalmente equivocado aquí, pero me parece que los mismos problemas son comunes en una escala más amplia y se relacionan con el conservadurismo humano. Las personas a menudo se niegan a cambiar los patrones de comportamiento bien conocidos, por razones que son demasiado numerosas para mencionarlas.

Al ser un desarrollador ruso (y, por lo tanto, ver menos pragmatismo occidental racional), veo que el razonamiento práctico es mucho menos convincente que tratar de caminar en los zapatos de otra persona.

En otras palabras, mencionó que el programador senior valora su propia posición relacionada con el esquema de trabajo actual. Quizás debería convencerlo de que la nueva forma de hacer las cosas hará que su posición sea aún más valiosa, y hay muchas maneras de hacerlo. Por ejemplo, puede hacer que él en realidad pronuncie su idea y obtener crédito por ella, o puede encontrar un lugar específico en el proceso que pueda controlar exclusivamente, etc.

Creo que ser flexible fuera de las ventajas aparentes de tu idea, podría ser tu hechizo mágico aquí.

Me las arreglé para convencer a los demás y estoy listo para hacer el esfuerzo de desarrollar una prueba de concepto. Pero el desarrollador 'Senior' no está dispuesto, posiblemente porque el proceso actual lo hace más valioso.

En lugar de echar aspersiones sobre el personaje del desarrollador principal (mala jugada), tal vez deberías tratar de entender por qué no está entusiasmado:

• Tal vez él piensa que usted es una de esas personas que vende demasiado sus ideas. Tal vez él duda de que puedas cumplir con ellos.

• Tal vez él piensa que estás exagerando los problemas. (No pueden ser tan malos ...)

• Tal vez él piensa que usted no comprende completamente los riesgos técnicos.

• Tal vez él piensa (sabe) que hay cosas más importantes que hacer en este momento.

• Tal vez solo lo frotas de la manera incorrecta.

Mi consejo sería probarle a usted. Por ejemplo, entregando los proyectos que realmente le han dado. Cuando él confía más en tu habilidad y criterio, vuelve a visitar este tema.

Si desea seguir la línea de "mejora de procesos" en este momento, mi consejo sería hacerlo lentamente, en pequeños pasos.

Tenga en cuenta que, sin duda, existe el riesgo de que los cambios propuestos tengan un impacto masivo en la productividad de su grupo e incluso en su capacidad para mantener el software existente. Si eso sucede, es probable que la persona a cargo obtenga el mayor impacto de la alta gerencia.

¿Institucionalizado sobre qué en particular? ¿Tecnologías, patrones, prácticas?

Si han estado en la organización / proyecto durante mucho tiempo, es probable que sean desarrolladores senior y tengan la responsabilidad / experiencia para hacer esas llamadas, y hayan tenido experiencias en el proyecto en lugar de estar condicionados como el experimento de los 5 monos .

La solución para convencerlos dependerá de cuál sea el tema, ya que si ya se eligió un patrón / tecnología, habrá una buena razón, y tendrá que haber una mejor razón para cambiar para justificar desechar el trabajo y volver a familiarizarse, etc. ., de ser así, una solución es que un arquitecto / desarrollador senior organice una reunión para decidir democráticamente la mejor solución.

Si el equipo realmente TIENE obstáculos innecesarios, entonces probablemente estarán más felices de que los ayudes a solucionarlos. Sin embargo, tenga en cuenta que puede haber una muy buena razón para que estén allí, y se verá estúpido si tiene que decir "oh, bueno, mi idea fantástica no funciona entonces" después de venderlo a todos durante mucho tiempo.

Investigue primero, y luego presente. También tenga en cuenta que poder MOSTRAR cómo sugiere que mejoró es mucho mejor que agitar a mano.

Me inclino a decir que usted es el "Programador inflexible". Usted es nuevo en el proyecto, pero insiste en que su idea es la mejor y que el hombre que lidera el proyecto, que ha estado más tiempo y conoce el sistema por dentro y por fuera, está fuera de control.

Soy bastante experimentado y bastante bien considerado y con frecuencia me asignan para arreglar proyectos difíciles como miembro del equipo de tigres. Incluso entonces todavía me tomo el tiempo para aprender los cómo, los porqués, la dinámica del equipo, el proyecto y sus prácticas, y no entrando y diciéndoles cómo esto y aquello están mal. En realidad, nunca digo que lo que están haciendo está mal porque eso no obtiene la respuesta que quiero y, por lo general, lo que están haciendo no está mal, solo necesita algunos ajustes.

Cada proyecto es único. Cada equipo es único. Su solución puede ser mejor para usted y los desarrolladores, pero puede no ser mejor para el cliente potencial, el cliente, la empresa o el proyecto, pero como no tiene la experiencia con el proyecto para conocerlo mejor, no lo sabría La respuesta a eso.

La mejor manera de hacer que la gente haga lo que quieres es hacerles pensar que todo es idea suya. Entonces, en lugar de hacer sugerencias directamente, presente opciones. Si tus ideas son claramente mejores que las alternativas, dale al desarrollador senior la oportunidad de elegirlas y hacerlas suyas. No te preocupes por obtener crédito. La gente que importa sabrá lo que está pasando.