Al març vam escriure per què vam començar MeteoTrail. Al juny, com el vam construir. Aquest article és diferent: parla menys d'arquitectura i més d'una cosa que ens ha costat una temporada sencera d'entendre de debò. Val d'Aran by UTMB va ser el primer client nostre en què el programari que fem no només informa la gent, sinó que sosté decisions que no es poden desfer: si una etapa comença a l'hora, si es desvia un tram, si es retiren corredors d'una carena abans que arribi una tempesta. Passar una temporada de cursa sencera amb un client així ens va canviar la manera de pensar l'enginyeria, i no té res a veure amb frameworks ni infraestructura.
1. Quan el programari sosté una decisió que no es pot desfer
La majoria de fallades de programari es poden arreglar. Es publica un bug, algú es queixa, el pegues, n'aprens i continues. És el ritme amb què construïm gairebé tots els nostres hàbits, i és sa, fins que allò que construeixes deixa de ser una eina que la gent consulta i passa a ser el que hi ha sota una decisió presa en temps real, en terreny exposat, sense manera de fer marxa enrere. El director de la cursa de Val d'Aran by UTMB ens ho va dir un cop de manera senzilla: ell no pot controlar el temps, però ha de prendre decisions a partir d'ell, i la nostra feina no era donar-li un dashboard bonic, sinó ser prou fiables per sostenir aquella decisió. Quan això cala de debò, la pregunta que et fas sobre cada funcionalitat canvia. Deixa de ser "això funciona?" i passa a ser "què passa si això falla, ara mateix, amb algú en una carena per sobre del bosc?".
2. Falses alarmes contra avisos que falten
La majoria del pensament de producte optimitza contra el soroll. Ajustes les alertes perquè siguin discretes, perquè els usuaris deixen de fer cas a qui crida llop massa vegades, i cada fals positiu erosiona la confiança en el proper avís real. Aquí vam haver de desaprendre bona part d'aquest instint. En una cursa d'ultra trail en directe, no detectar un risc real de llamps no és un error simètric davant d'enviar una alerta de més: és categòricament pitjor. Així que vam canviar com pensem els llindars: quan les condicions d'un checkpoint, les previsions a 48 hores i 7 dies, o les dades de llamps en temps real s'acosten a un límit de risc, preferim mostrar-ho i que el director de cursa i el meteoròleg contractat ho valorin amb tot el context, abans que suprimir-ho en silenci perquè la interfície quedi neta. Pecar de cautelosos de tant en tant és un cost que assumim. Que falti un avís durant un esdeveniment amb corredors ja al circuit no és un cost: és exactament la fallada que tot el sistema existeix per evitar.
3. No ho pots provar del tot per al dia de la cursa
Pots fer proves de càrrega a la infraestructura. Pots assajar els fluxos de checkpoint, fer simulacres amb l'organització abans de l'esdeveniment, i repassar què passa quan les alertes oficials de diferents països no coincideixen entre elles, o quan una font de dades queda desactualitzada just quan més falta fa. El que no pots fer és recrear una tempesta real travessant un port de muntanya amb centenars de corredors ja endinsats en un tram del recorregut i un meteoròleg escrivint un informe manual sota pressió de debò. Vam deixar de perseguir la il·lusió d'una certesa total abans de la cursa i vam començar a construir per a la resiliència: fonts de dades per capes perquè cap sigui un punt únic de fallada, un override manual que sempre permet al meteoròleg humà publicar un informe que preval sobre qualsevol cosa automàtica, i ser honestos amb l'equip organitzador, abans del tret de sortida, sobre què havíem provat de debò i què passaria per primer cop de veritat.
4. Què va canviar en com construïm
En concret, això és el que ens va deixar una temporada així:
- Tractem explícitament les dades que no coincideixen o que queden desactualitzades, en lloc de triar una font en silenci i confiar que sigui la correcta.
- Durant el cap de setmana real de l'esdeveniment, algú de l'estudi és localitzable i mirant els panells en temps real, no revisant logs l'endemà al matí.
- Tot el relacionat amb alertes parteix d'un valor conservador per defecte i es relaxa després, mai al revés.
- El backoffice del meteoròleg contractat mai és un extra: és l'override manual que sempre és per sobre de l'automàtic.
- Fem un debrief després de cada esdeveniment com es faria després d'un incident a qualsevol altre lloc, hagi passat res o no.
Res d'això surt en un changelog. No és una funcionalitat de la qual puguis fer una captura de pantalla. Però és el que realment va canviar després d'aquesta primera temporada completa amb Val d'Aran by UTMB, i és com pensem per defecte qualsevol eina nostra que acabi sota la decisió real d'algú. La responsabilitat pesa més del que esperàvem al principi. També ens va fer millors en això.