Software Imposible

El pasado 14 de Mayo de 2018 cambié el rumbo de mi vida profesional, aceptando el puesto como Director de Software en la empresa con el mayor ritmo de crecimiento que conozco (ha triplicado facturación y plantilla en el último año de manera orgánica), dedicada a un sector con un potencial desmedido como es el de la Carga de Vehículos híbridos y eléctricos.

Asumí un reto auto impuesto y a priori imposible: construir prácticamente de cero un equipo y en un tiempo récord de aproximadamente cuatro meses renovar por completo todo su software: el backend (una plataforma expuesta en servicios para consumo de aplicaciones móviles, web e incluso miles de dispositivos físicos de Carga Eléctrica), el frontend (una aplicación web de gestión para usuarios) y sendas aplicaciones móviles nativas iOS y Android llenas de funcionalidades, además de una aplicación de asistente conversacional sobre Google Assistant y aplicaciones nativas para smartwatch en ambas plataformas.

Descubriendo el Diseño de Software

Cuando llegué a la empresa el Departamento de Software era el más pequeño de todos, había cuatro desarrolladores sin más planificación que superar el día a día, bombardeados por peticiones del resto de departamentos.

Tuve poco tiempo para el análisis. Hacían falta una estructura clara y una misión. La primera decisión que tomé fue centralizar la llegada de peticiones a través de mí para permitir al equipo respirar y poder tener un criterio coherente de definición de tareas y priorización.

La segunda decisión fue definir el objetivo del cambio. Apostar por una transformación tecnológica con sentido que permitiese sentar las bases de lo que deberían ser Productos de Software con un potencial de crecimiento sin límites.

Mi aproximación es holística, no entiendo el Software separándolo del Diseño de Producto (el qué) ni obviando su Arquitectura Tecnológica (el cómo) ni al margen de su Planificación y evolución iterativa (el cuándo). Cuanto más separes el qué, del cómo y el cuándo en capas llenas de innecesaria burocracia administrativa y teléfonos rotos, por no hablar de luchas de egos y presupuestos, más te equivocarás. El Desarrollo de Software moderno más exitoso se construye desde la convergencia de estos tres puntos.

A la hora de abordar el Diseño de Equipos creo firmemente en la Orientación a Producto y en la especialización. En este caso aplicaba definir tres productos principales: Aplicación Móvil, Portal de Usuario y Plataforma Cloud o, como solemos conocerlos, App, Portal y Cloud. Además de un equipo por cada uno de estos Productos, configuré un equipo transversal de Producto con perfiles QA, UX y Diseño (que con el crecimiento puede integrarse en cada equipo de Producto pero lógicamente en una etapa inicial es más óptimo que sea transversal) para la definición de casos de uso y de interfaces.

Hay tantas lecturas interesantes sobre Diseño de Producto y Experiencia de Usuario que no os aburriré con excesivas referencias, tan sólo destacaré dos que se alinean muy bien con mi visión: Lean Startup y su implementación en interfaces, Lean UX.

Maximización del valor entregado al usuario, minimización del esfuerzo perdido en tareas estériles, desarrollo iterativo con feedback del cliente, ciclo continuo de construir, medir y aprender.

La teoría está al alcance de todos, la implementación satisfactoria al alcance de muy pocos. Siempre la trampa se encuentra en los detalles de la implementación. Para escapar a esta trampa ayuda mucho disponer de la experiencia de años participando en todo tipo de proyectos de software (y de otros ámbitos, al final la abstracción de diseño de un producto y su aprendizaje pueden verse de modo ajeno a su plataforma).

Mi trasfondo principal proviene de la esfera técnica, pero he procurado formarme e inmiscuirme en otras áreas como el diseño de producto, la definición de interfaces y el desarrollo de negocio. En resumen, amo tanto el software que me preocupo de estudiar todas las facetas que intervienen en su construcción. Porque quiero concebir el mejor software posible.

Desde este trasfondo técnico (desde mi punto de vista necesario para dirigir un equipo de software, entender sus diatribas y sus motivaciones) surge mi amor por las aproximaciones lógicas al diseño de producto (os sorprendería saber que la mayor parte de decisiones sobre productos de software se basan en opiniones irracionales), por los principios de Extreme Programming (técnicas como la Refactorización o el Pair Programming y valores como la comunicación, la simplicidad, el valor o el respeto) y por los principios fundacionales del Manifiesto Ágil (que no tienen nada que ver con la explotación mercantilista posterior de sus implementaciones).

El estándar actual en metodología de desarrollo de software suele incluir una variante más o menos acertada de implementación de Scrum. Scrum no es agile (frase de un padre fundacional del agilismo como Ron Jeffries o de ilustres developers como Eric Elliot), es un concepto de ticket tracking y medición de la velocidad que hemos asumido como mal menor, desde luego mejor que la clásica metodología en cascada que tantos desastres ha producido, pero también fuente de numerosas frustraciones y confusiones, debido sobretodo a sus habituales implementaciones cuyo objetivo principal es el control y la monitorización y no la entrega de valor ni la fidelidad a los principios agilistas.

Algunos sabréis que estoy desarrollando mi propia metodología basada en los conceptos originales del Manifiesto Ágil, adaptados al siglo XXI. La denomino Forum y entronca con el movimiento #NoEstimates y el Desarrollo Orientado a Producto (no a Proyecto), en un contexto de trabajo colaborativo y distribuido basado en las personas. Entre sus conceptos principales se encuentran la Comunicación Asíncrona, la Horizontalidad del Equipo, la Definición Colaborativa o los Roles Adaptativos y entre sus valores fundamentales están la Confianza, la Comunicación, el Respeto, el Compañerismo y la Alegría (sí, lo habéis leído bien).

Os contaré más sobre Forum en cuanto supere la versión alfa a la que será sometida lo que queda de año, para poder ofrecerla en beta pública a principios del que viene. Tengo muchas ganas de que podáis conocerla.

Construyendo el Equipo

Construir software trata, sobretodo, de personas. Nos gusta mucho, a mí el primero, hablar de tecnologías, arquitecturas e infraestructuras. Y son importantes, claro que sí, muy importantes; la elección correcta de tecnologías es un arte (no una ciencia) que marca la diferencia y en el día a día lidiamos con innumerables problemas tecnológicos. Pero el mayor reto de la construcción de software radica en la construcción del equipo humano necesario para llevarlo a cabo.

Cuando el nivel de exigencia de los retos definidos es altísimo como era el caso, tanto en tiempo como en forma, todas las variables involucradas se agudizan. Expectativas, rendimiento, motivación, esfuerzo.

El diseñar un buen flujo de trabajo se vuelve crucial. Y esto no tiene nada que ver con complejas configuraciones de herramientas, ni con añadir columnas con decenas de estados para las tareas, ni con realizar decenas de reuniones semanales. Tiene que ver con que cada miembro del equipo tenga claro su papel y tenga las condiciones adecuadas para desempeñarlo.

Personalmente estoy en contra del habitual culto a las herramientas y los procesos. Quizá porque he visto fracasar a las metodologías y aplicaciones de gestión más sofisticadas y he visto triunfar a los procesos más sencillos. Sé positivamente que la clave no está ahí, son elementos que lógicamente pueden ayudar o entorpecer pero su impacto es siempre menor que tres variables que siempre he detectado en equipos de alto rendimiento: Ambiente (valores de Alegría y Comunicación), Misión (valores de Definición y Transparencia) y Motivación (valores de Concentración y Confianza).

La ocupación principal de un manager debe ser velar por mantener estas tres variables lo más elevadas posible y no caer en la habitual trampa de cegarse por los detalles de la ejecución de tareas. Y es más fácil caer en esta trampa cuanto más pegado te encuentras a la ejecución. Es importante, por tanto, distribuir el trabajo organizativo en personas especializadas y evaluar regularmente estos indicadores, que requieren un mantenimiento y unas medidas constantes.

Algunas medidas concretas que recomiendo para mantener altos estos valores:

• Sé honesto. La Honestidad fortalece el valor de Confianza.
• Da ejemplo. La Motivación no se explica, se vive y se contagia.
• Explica las decisiones. La Transparencia fortalece la Misión.
• Habla con todos. La Comunicación favorece el buen Ambiente.
• Enseña el futuro. La Definición da forma a la Misión.

Da igual lo que hagas, si la exigencia es elevada eso conllevará que no todo el mundo encajará en el equipo, ni todo el mundo estará dispuesto a contribuir a esas variables en las condiciones necesarias para que el equipo funcione como debe. Cuando eso ocurre lo mejor para ambas partes es tomar caminos diferentes, con entendimiento y respeto.

Asumiendo el Reto

En unos tres meses desde mi llegada tripliqué el Departamento de Software, aposté por la Orientación a Producto y por la Especialización, por el Diseño, la Experiencia de Usuario y la Definición de Casos de Uso integrados en el equipo. Definimos un Flujo de Trabajo y lo llevamos a cabo desde el buen Ambiente, la Misión clara y la Motivación.

Y aún así encontramos dificultades en la recta final, siempre debido a puntuales desvíos sobre esas tres variables, fundamentalmente por caer en la trampa de poner todo el foco en la ejecución, como ya he mencionado, y no sacar tiempo para las medidas de mantenimiento constante que necesitan.

Lo importante es aprender, corregir y mejorar. Escuchar. Recalibrar esas variables y recuperarlas con acciones concretas. Entender que son mucho más delicadas de lo que creemos. Una sola conversación obviada puede marcar la diferencia.

El resultado de este emocionante e intenso trabajo de equipo está a punto de ver la luz con la salida de las nuevas Apps nativas para iOS y Android de Wallbox completamente reescritas de cero en Swift y Kotlin con Clean Architecture, el nuevo Portal completamente reescrito en VueJS y NodeJS, y el nuevo API en Symfony con Redis y autoescalado.

Todos los involucrados hemos aprendido mucho en el proceso. Personalmente he constatado la necesidad constante de mantenimiento de estas variables y valores antes mencionados, cada semana, cada día y lo importante que es tomar medidas inmediatas ante cualquier desvío.

El futuro 2019 se presenta más ilusionante que nunca. En un par de meses el área que tengo el placer de dirigir alcanzará y superará los veinticinco profesionales de múltiples disciplinas con un objetivo común: realizar la mejor solución de Experiencia de Carga Eléctrica del mundo, gestionando miles de usuarios y puntos de carga en todo el planeta como parte de la Revolución Eléctrica que ya es imparable.

Asumimos el reto.