Listen to your heart (developers)

"¡Malditos desarrolladores que nunca llegan a tiempo! ¡Vaya cagada de seguridad! ¿Cómo puede estar esto así? Desastre total." Bonitas frases de blasfemia que he oído en más de una ocasión sobre un equipo de desarrollo. Sobre los developers. Sobre por qué se canta un retraso en la planificación por culpa del equipo de desarrollo, porqué ha habido un fallo de seguridad "big time", o por qué está algo manga por hombro cuando algo funciona mal.

Figura 1: Listen to your heart (developers)

Sí, muchas veces tiene que ver con los desarrolladores, los programadores, el equipo e ingeniería, el equipo que tira las líneas de código, que mantiene el software, ese programa, plataforma, web, app, que es tan importante para ti y que te hace expeler dioses cuando no te funciona. Ese grupo de personas que hace esa cosa que para ti es tan importante. Tanto, que cuando falla - no como cuando falla una tipografía en una ppt de una reunión - te enfadas tanto.

Los conflictos entre el equipo de desarrollo, y aquí permitidme que meta a todo el equipo de ingeniería de un proyecto, pasando UX, Project Managers, QA, DevOps, Seguridad, programadores, etcétera con los equipos de negocio, producto, marketing y ventas son habituales. En cada empresa el balance de poder entre quién manda más está cambiado, pero lo cierto es que ese conflicto existe siempre, y seguirá existiendo, porque es lo que mantiene la tensión que tira de los proyectos hacia delante. En toda mi carrera, en todas las empresas, ha existido ese conflicto, y seguirá teniendo que existir para mantener el ritmo en el pico de la ola.

Yo he tenido que jugar en los dos lados. En el equipo de producto y en el equipo de ingeniería, y eso me ha llevado a entender algo lo que pasa en los dos sitios, y traeros como aprendizaje personal el título de este artículo: "Listen to your heart" . Escucha a tus desarrolladores, escucha al corazón de los crean la tecnología, porque si no los escuchas, no los vas a entender, y si no los entiendes, tomarás decisiones que pueden ser las culpables de las exclamaciones de la primera línea.

El software envejece. Sí, se hace mayor. Se queda con librerías obsoletas, con bugs, sin soporte de seguridad, pero tampoco de evolución, lo que les elimina capacidades de hacer cosas. También se muere. Se discontinúa. Se cambia. Muta, se mete en otros proyectos. Así que, tus desarrolladores van a necesitar tiempo en trabajar en cuidar tu bonsai. En quitar las librerías antiguas, en actualizar el código para que funcionen las nuevas, en actualizar el software. El mantenimiento de la juventud de un software lleva tiempo a tus desarrolladores, si se quejan mucho... date por enterado de que en cualquier momento te topas contigo mismo diciendo:"¡Vaya cagada de seguridad!".

El software tiene deudas. Sí. Son técnicas. Son deudas que se pagan por no haber implementado correctamente algo. Por haber puesto en producción un software pero sabiendo que hay "corner cases" que no están soportados. Es decir, el programa funciona para lo que tú quieres, y si sigues el golden path de uso, puede que no te de ningún problema, pero... habrá situaciones en las que no lo hará. Si tus programadores se empiezan a quejar de la "deuda técnica", párate a escucharlo, porque puede que en el peor de los momentos tu plataforma estire la lengua. De la peor de las maneras, y digas eso de "¿Cómo puede estar esto así?".

Los programadores viven con incertidumbre siempre. Y puede que se equivoquen en las planificaciones. Como tú en los business cases. Y eso no tiene porque ser malo. Los equipos entrenados suelen conocer muy bien los colchones de tiempo con que juegan, y tienes que aprender a escuchar a los desarrolladores, porque si cuando se pasan en las fechas, la bronca que les cae es enorme, entonces aprenderán y nunca más fallarán, solo que estirarán los colchones de tiempo al máximo, y será peor para ti. En ingeniería, cuando se hace algo nuevo hay siempre un grado de incertidumbre. Una planificación exige que hagan especulaciones basados en situaciones desconocidas con gran incertidumbre, y para ello los desarrolladores tienen sprints, y backlog para gestionar los tiempos, pero si tus desarrolladores no llegan de vez en cuando, entiende por qué, y no seas malo con ellos, porque si siempre llegan a tiempo sin estrés... es que no tienes una buena relación con ellos.  Así que cuidado con cuántas veces dices eso de "¡Malditos desarrolladores que nunca llegan a tiempo!"

Cada día se necesitan más desarrolladores, así que, cada día hay más ofertas para ellos, y con la apertura del teletrabajo a todo el mundo, aún mucho más y en un mercado muy competitivo y con muchas ofertas. Así que si tus desarrolladores no se sienten parte del equipo, valorados, e importantes.... se irán a otro sitio. Equivocarte en valorar la importancia de lo que es importante solo porque no los veas en las reuniones interminables, es un error. Así que, si quieres saber si son importantes o no, escucha las teclas de sus programas.... si no suenan teclas es que no tienes programadores. Y tu plan de negocio basado en piezas de tecnología, simplemente será una bonita presentación o un Excel chulísimo. "Desastre total".

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)