I problemi per cui ci chiamano, e come li affrontiamo.

La situazione. Qualche centinaio di posizioni aperte vive nell'ATS. Il sito careers è un CMS separato, aggiornato a mano. Le posizioni vanno online in ritardo, quelle chiuse continuano a raccogliere candidature e la stessa vacancy esiste due volte con fasce retributive diverse. I recruiter hanno iniziato a mandare ai candidati direttamente il link dell'ATS, e così si perdono l'employer brand e tutti gli eventi di analytics.

L'approccio. Trattare l'ATS come unica fonte di verità e smettere di scrivere dati sulle posizioni da qualsiasi altra parte. Le posizioni arrivano dalle API documentate a intervalli pianificati, ogni record viene validato al confine così che una posizione malformata o pubblicata a metà fallisca in modo evidente invece di comparire sbagliata, e al sito resta il suo livello per le cose per cui l'ATS non ha un campo: pagine delle sedi, benefit, testi sul processo di selezione.

Cosa cambia. Pubblicare una posizione diventa un'azione nell'ATS, non un ticket per il sito. Il tracciamento delle candidature resta intatto perché i candidati non lasciano mai il dominio.

La situazione. Due sistemi che non erano fatti per parlarsi — mettiamo un ERP e un CRM — vengono riconciliati ogni settimana da qualcuno che esporta CSV e li incolla in un foglio con regole che conosce solo lui. Funziona finché quella persona non va in ferie. E quando i due sistemi non concordano, nessuno sa dire quale dei due ha ragione.

L'approccio. Prima si mappa quello che si muove davvero oggi, passaggi manuali ed eccezioni non documentate comprese, e si conferma quella lettura con la persona che fa il lavoro, prima di scrivere una riga di codice. Poi un livello di middleware con le proprietà noiose che servono: un contratto esplicito campo per campo, scritture idempotenti così che un retry non possa duplicare un record, una dead letter queue per ciò che fallisce e log che una persona delle operations possa leggere senza di noi.

Cosa cambia. La riconciliazione smette di essere sapere non scritto. Quando un fornitore cambia le sue API, si rompe in un punto noto e con un alert, non in silenzio nella reportistica del trimestre dopo.

La situazione. Uno stack di CMS e shop scelto quando il catalogo era un decimo di quello attuale. Le pagine di categoria sono lente, ogni modifica ai contenuti richiede uno sviluppatore e una finestra di rilascio, e il plugin che gestisce i prezzi non viene aggiornato da anni. La riscrittura completa è stata proposta due volte e annullata due volte, perché nessuno può permettersi di far restare al buio gli URL e il checkout per un intero weekend.

L'approccio. Nessun passaggio in blocco. Prima l'inventario di ciò che esiste — URL, redirect, dati strutturati, integrazioni che nessuno ricorda — poi lo si sposta a fette sotto lo stesso dominio, tenendo vecchio e nuovo stack in servizio in parallelo finché l'ultima fetta non è verificata. Le mappe dei redirect e i controlli sulla visibilità nei motori di ricerca fanno parte del lavoro, non sono una sorpresa post-lancio.

Cosa cambia. I redattori pubblicano senza un deploy. La migrazione diventa una sequenza di passi reversibili invece di quel weekend che tutti temono.