Reconstruir l’arquitectura de dades de Tech Barcelona, i la confiança per migrar-hi

L’organització

Tech Barcelona és una de les institucions que mantenen unida la comunitat tecnològica de la ciutat, connectant empreses, startups, inversors i organismes públics. Marina Saurí n’és la Director of Strategy.

Una organització així funciona a base de relacions, i les relacions viuen a les dades. Socis, partners, esdeveniments, programes, sol·licituds. Cadascun d’ells és un registre en què algú ha de poder confiar.

La situació

Les eines s’havien triat d’una en una, cadascuna per una bona raó, cap triada juntament amb les altres. Així es construeix gairebé qualsevol stack.

Amb el ritme que porta una empresa en el dia a dia, el que passa és que mai no t’atures a endreçar les coses: per on t’entren les dades i per on et surten.

Marina Saurí, Director of Strategy, Tech Barcelona

La paraula que va fer servir per al resultat va ser desquadrat, fora d’escaire. No es va enfonsar res. Simplement les coses no quadraven, i cada pregunta trigava més a respondre’s del que caldria.

El problema real

Una migració és una feina tècnica amb un final clar. Moure els registres, redirigir les integracions, apagar el sistema antic.

Aquesta mai no va ser la part difícil aquí.

Si haguéssim fet primer la migració, Tech Barcelona hauria pagat un canvi de software i s’hauria quedat amb el problema. L’arquitectura s’havia de decidir abans de moure un sol registre, perquè l’arquitectura és el que la migració havia de transportar.

Així que la feina va començar un pas abans del que demanava el brief: mapar per on entraven les dades, per on sortien, qui n’era el propietari entremig i quins d’aquests camins existien a propòsit.

El risc que no era tècnic

Hi ha una part d’aquesta feina que cap document d’abast no cobreix, i la Marina la va anomenar abans que haguéssim fet res.

Sempre és més difícil treballar amb gent que no veus cada dia. Amb el teu propi equip mantens el control: qualsevol dubte, qualsevol problema que sorgeixi, el resols al moment. Treballar amb algú extern sempre porta aquesta por que les coses siguin menys fluides, menys àgils.

Aquesta por és encertada. És la posició per defecte correcta per a qualsevol que ja hagi contractat abans un equip extern.

Tampoc no es pot respondre amb un discurs comercial. Només es pot respondre amb com funciona de debò la feina, setmana rere setmana, i per això les dues coses que ella va acabar assenyalant no eren entregables en absolut.

Què vam construir

Una arquitectura de dades, decidida abans del trasllat. Per on entren els registres, per on surten, quin sistema és propietari de quin objecte i què passa a cada traspàs. Escrita com un model, no com a coneixement tribal.

La migració en si. Executada contra aquest model, perquè el que aterrés al nou stack fos l’estructura que havíem acordat i no una còpia del desordre antic.

Documentació de cada pas. No un document de traspàs escrit al final, sinó la construcció registrada a mesura que es construïa.

Un flux diari d’informació. El problema de l’equip remot resolt de l’única manera possible, eliminant l’espera.

Com va funcionar la feina

Aquestes dues últimes són la raó per la qual el projecte va funcionar, i són del que parla la Marina quan li pregunten com va anar.

M’agrada treballar amb l’Oriol perquè té aquesta estructura mental de deixar-ho tot documentat. Quan treballes amb una empresa externa és molt difícil mantenir aquest seguiment, i tenir-ho tot documentat, el pas a pas, i aquest flux directe d’informació diari, això ens va ajudar moltíssim.

La documentació se sol vendre com un entregable. És més útil pensar-la com allò que fa que contractar un equip extern sigui segur. El client pot veure com es construeix el sistema, pot revisar-lo sense preguntar i n’és el propietari en el moment que s’acaba el projecte.

El flux diari fa la mateixa feina per a la velocitat. La por era que un equip de fora fos més lent que un de dins. La resposta no és prometre el contrari, és fer el cicle prou curt perquè la pregunta deixi de sorgir.

Què va canviar

De moment, les dades són al seu lloc, que ja és molt.

Aquesta frase és tot el resultat, i val la pena llegir-la a poc a poc. Dades al seu lloc vol dir que cada pregunta posterior es torna més fàcil: reporting, segmentació, seguiment, qualsevol cosa que algú vulgui construir després.

La Marina també té clar quina part no està acabada, i fa bé.

Sempre hem tingut un cert pànic a deixar eines que coneixem i passar a unes de noves, i l’adaptació de tot l’equip va més enllà del projecte mateix. Però estic convençuda que vam fer bé la feina, tot és on ha de ser, i a partir d’aquí anirà molt millor.

Una migració s’acaba. L’adopció no. El sistema pot ser correcte el dia que es lliura i tot i així costar-li a un equip setmanes habitar-lo amb comoditat, i fer veure el contrari és com es donen per acabats projectes que encara no han aterrat.

El que fa una bona arquitectura és que aquesta adaptació valgui la pena fer-la una sola vegada. L’equip aprèn una estructura que aguantarà, en lloc d’aprendre un altre apedaçament que caldrà reconstruir d’aquí a dos anys.

Per què importa

Aquest cas no té mètriques de campanya, i no és un descuit.

Res d’això no anava de generar demanda. Anava de garantir que una organització pogués confiar en els seus propis registres, i de demostrar que un equip extern pot fer feina estructural sense convertir-se en una caixa negra. Aquestes són les dues coses que decideixen si val la pena començar el projecte següent.

Per a qui és

Organitzacions que fa prou temps que funcionen per acumular eines, i que mai no han tingut un trimestre lliure per decidir com haurien d’encaixar aquestes eines entre si.

On res no està trencat però res no acaba d’encaixar. On hi ha una migració sobre la taula i la pregunta de fons encara no s’ha fet. On l’equip ja s’ha cremat abans amb un partner extern que va lliurar una cosa que només ell entenia.

Si us sona, el problema no és l’eina que esteu deixant. És que ningú no va dibuixar mai el mapa.