Mensajes en una botella desde el frontend.

Este post es con seguridad el más personal que he escrito. La naturaleza y la complejidad de los proyectos en los que participo hace difícil expresar ciertas reflexiones con claridad. En este post pretendo exponer estos asuntos vistos desde el punto de vista del desarrollador.

No voy a hablar solo del frontend. Por ello lo primero es aclarar que mi intención no es cuestionar el trabajo de otros perfiles intermedios (necesarios) que conforman el proyecto, véase comerciales, expertos UX, Service Deliveries, Scrum Master, etc. Este post también es para ellos que, seguro, en muchas ocasiones saben escalar los mismos asuntos.

¿Qué hace falta para que un proyecto web sea un éxito?

Lo primero es saber hacia dónde queremos ir con nuestro producto web. No es lo mismo una tienda de comercio electrónico que una intranet para empleados. Y no es lo mismo que tu cliente seas tú mismo (startup) o que el cliente sea una gran empresa o una pyme. Y cada tipo de app web tiene sus métricas que miden si se va por buen o mal camino (en las cuales no voy a entrar).

Teniendo los requisitos y las métricas de calidad claros, lo cierto es que hay aspectos de un proyecto web (de tamaño medio-grande) que siempre debemos cuidar en cualquier caso:

• Experiencia de usuario (UX).
• Tecnologías frontend.
• Herramientas colaborativas.
• Recursos humanos.
• Metodología.

Y es de estos puntos de los que vamos a hablar a continuación.

Experiencia de usuario (UX)

No soy experto en UI/UX pero me toca trabajar muy cerca de ellos. Y estoy encantado de que me hagan trabajar con ellos porque eso significa que la experiencia del usuario ha sido considerada importante por los responsables.

Si nos olvidamos de la UX nos olvidamos de los usuarios. Solo por la importancia que tiene hoy día la visualización de nuestra web en móviles, el experto UX se hace fundamental en la participación del proyecto.

Paradigma siempre ha apostado por hacer una fase de descubrimiento o Sprint 0 en la planificación de los proyectos donde normalmente intervienen estos perfiles UX/UI.

Cuando no se ha hecho esta fase en un proyecto, los desarrolladores frontend nos encontramos con dilemas no resueltos, como por ejemplo:

• La forma de mostrar los errores de validación de un formulario de entrada de datos: ¿ir molestando al usuario con errores según escribe?, ¿esperar a que le dé al botón de submit?
• Cómo se muestra una tabla de datos en móviles, ¿nos vamos al incómodo scroll horizontal?
• Qué pasa cuando un usuario le da al botón de atrás del navegador. Aunque parezca algo muy trivial, algunos funcionalidades lo hacen complejo y en móviles más porque unos tienen botón de atrás físico y otros no (como iPhone)

No tener estos asuntos resueltos puede desembocar en que los programadores front tomemos decisiones que no son del gusto de los usuarios o que no son del gusto del equipo de calidad que evalúa la aplicación y terminan poniendo defectos cuando no son tales, sino falta de definición en la usabilidad del interfaz web en cuestión.

Y, por cierto, si el experto UX pudiera entrevistar a una muestra de los que serán los usuarios finales, este podría recoger una información muy valiosa para llegar a diseñar la web de éxito.

Tecnologías frontend

Sobre el mundo de tecnologías frontend no quiero entrar en las batallas típicas: Vanilla JS vs Framework JS, Angular vs React, Tailwind vs Vanilla CSS, etc. Me gustaría aportar mi punto de vista en otros aspectos.

• Desarrollar para Internet Explorer incrementa el coste de los desarrollos web y cada día tiene menos sentido: los usuarios casi siempre pueden actualizar como mínimo a Microsoft Edge.

• Apuesta por las últimas versiones de navegadores: las últimas versiones de los navegadores incorporan de serie APIs como es Progressive Web App o Web Components que puede suponer un valor añadido a tu producto como tener una versión offline de tu app o poder organizarse en sistemas de diseño respectivamente.

• Pide calidad al proyecto con Test Automáticos, Unitarios y End2End: permite tener un código limpio y un producto robusto y escalable. Lo mejor es tener un Equipo QA no solo dedicado a hacer tests de regresión sino para que desarrollen tests automáticos.

• Los frontends que disponemos de un Swagger o de colecciones Postman para mirar y probar la definición de los servicios backend trabajamos mucho más rápido.

• Refactorizar es bueno: es fundamental que la bola de la deuda técnica no se convierta en inmanejable; refactorizar es curar la deuda técnica. Si hay que reservar parte del tiempo del desarrollo del proyecto a refactorizar tu producto, este será más mantenible, más robusto y seguramente hasta más rápido. Y pensando en los desarrolladores: no hay nada que desmotive más que tener que programar sobre código sucio y desorganizado.

Herramientas colaborativas

Hablemos de herramientas para facilitar la comunicación del día a día entre los distintos perfiles que participamos en el proyecto: creo que ha llegado el momento de superar los hilos de email infinitos y las Excel para todo.

• En este post se exponen varias razones para no utilizar el email como herramienta colaborativa. Mi favorita es que el email es un dolor de muelas cuando quieres buscar alguna información en hilos de conversación de 100 emails.
• No hace falta siempre una excel o Google Sheet para organizar el trabajo y reportar los errores: cuando pruebas Jira, la productividad sube.
• No hace falta siempre Words o Google Docs para documentar. Hay algo mejor: Confluence.
• Y, por favor, si dos técnicos de dos equipos distintos trabajan en localizaciones distintas y se tienen que intercambiar configuraciones para integrar sistemas en ambos lados, lo mejor es usar un chat. ¡Slacks, Google Meet, Google Chat, Skype y Zoom están esperándote!

Recursos humanos

Diversificando entre varios proveedores

Hablemos de los perfiles/proveedores que participan en tu proyecto. Si trabajas con varios proveedores que deben coordinarse para sacar adelante el proyecto, hay que pagar un precio en cuestión de fluidez en la comunicación (más intermediarios, más reuniones, más teléfono escacharrado, etc). No todos comparten la misma metodología/cultura y el esfuerzo en coordinación es un coste extra.

¿Más madera? No, gracias

Aumentar las personas que trabajan en un equipo para crear subequipos que trabajen en paralelo no es la solución siempre (de hecho casi nunca): provoca más esfuerzo en mentorizar a los nuevos, coordinación y comunicación.

Si se ha hecho una etapa de descubrimiento/Sprint 0, el dimensionado de los equipos viene ya determinado de forma correcta y poco habrá que retocarlo. De hecho según la metodología Scrum el número de desarrolladores de un equipo suele estar en el rango entre 2 y 5.

¿Quieres tener un equipo de trabajo motivado?

Un equipo de desarrollo motivado es un seguro de buenos resultados y con poco coste si no hay rotaciones (que aumenta la deuda técnica). Veamos algunas claves sobre este asunto.

• Si el cliente nos pone un Product Owner conocedor del negocio e implicado en las ceremonias de Scrum como las planning y las reviews hace que los programadores sintamos que se tiene en cuenta nuestra opinión y que se valora nuestro trabajo.
• Trabajar en remoto se ha naturalizado mucho en los últimos tiempos (ya sea desde sus propias oficinas o desde sus casas) es perfectamente eficiente, sobre todo en frontend, donde la integración con sistemas es más liviana y el presentismo tiene menos sentido.
• Desmoraliza mucho que te pidan un esfuerzo en horas extras para luego no ver justificación a esas prisas: fechas que finalmente no eran el fin del mundo, proyectos que se guardan en un cajón, etc. Pero, incluso, si ha ocurrido.... ¡Pedir disculpas es posible!

¿Pagar a gente cruzada de brazos?

Igual que en la construcción de un edificio, no tiene sentido disponer de todo el equipo de desarrollo desde el segundo cero de un proyecto.

La construcción de los cimientos del proyecto (requisitos, alcance, etc.) requiere la presencia de expertos UX, arquitectos, analistas y QAs. Esta fase es justamente la que se realiza en el Sprint 0.

Después de los cimientos vienen los pilares: desarrollo de los servicios esenciales (autenticación, por ejemplo) con los necesarios perfiles backend, juegos de datos básicos y entornos de trabajo y despliegue.

Tanto en los cimientos como en los pilares puede venir bien tener algún frontend cerca (uno como mucho). Es finalmente cuando llega la hora de realizar las paredes, el encofrado, etc., cuando entra el resto de desarrolladores backend, y todos los frontend.

Metodología

En Paradigma tenemos un reto: la transformación digital de nuestros clientes para su propio beneficio. Eso no siempre es fácil y supone cambios organizativos en el cliente. Pero pensamos que es el camino del éxito a la hora de encarar proyectos de cierta complejidad.

Las fechas, en muchas ocasiones, marcan la relación de empresas y proveedores/consultoras en los proyectos que emprenden un proyecto de forma conjunta. Pero no se pueden poner fechas sin tener en cuenta el triángulo de hierro, el cual es distinto según sigamos metodologías clásicas (Waterfall) o Agile:

En ambos casos las fechas o tiempo es tan solo una de las esquinas. Esto quiere decir que, por ejemplo, acortar fechas tiene un impacto directo en los recursos y en el alcance. Lo mejor es recortar el alcance (para no caer en el error de amontonar recursos humanos): es la apuesta de Paradigma; iterar desde Productos Mínimos Viables y que van creciendo con solidez en cada sprint (estrategia de la derecha).

Campo de la respuesta con qué dato de pantalla

A la hora de integrar servicios de backend en el frontal nos ayuda mucho disponer de algún tipo de documento que, por cada pantalla, responda a la pregunta: ¿De qué campo de la respuesta del servicio viene cada dato de esta pantalla?

Y si queremos ir a un punto de calidad superior: diseñar APIs es diseñar UIs.

Conclusiones

De todo lo dicho y a modo de resumen, propongo esta checklist a revisar en los proyectos (tanto en la propuesta como en el curso del mismo):

• Product Owner del cliente preparado e implicado.
• Hay expertos UX y QA (calidad).
• Hay Analistas funcionales y técnicos.
• Últimos navegadores.
• Nº de Proveedores participantes bajo.
• Perfiles participantes apropiados para cada fase del proyecto.
• Baja rotación en el equipo.
• Test automáticos en el pipeline de integración continua.

Convencido de que este post puede abrir mucha controversia y debate, estaré encantado en aprender y debatir sobre vuestros comentarios.

PD: Juegos de datos para pruebas 🙏!