Outsourcing IT
Automazione QA e release engineering per una piattaforma SaaS B2B statunitense
In sintesi
- Settore
- Tecnologia e SaaS
- Geografia del cliente
- Stati Uniti, sede a Boston
- Dimensione del cliente
- Fase di crescita, circa 68 mln USD di ARR, Serie C
- Linea di servizio
- Outsourcing IT, automazione QA, DevOps, release engineering
- Lingua principale
- Inglese, con spagnolo in tutto il team
- Sede di delivery
- Medellín
- Durata dell'incarico
- 15 mesi, in corso
- Dimensione del team
- 22 ingegneri, 2 responsabili, 6 senior, 10 intermedi, 4 junior
Profilo del cliente
Il cliente è un'azienda software B2B con sede a Boston che fornisce una piattaforma di automazione dei flussi di lavoro a clienti di fascia media ed enterprise in Nord America. All'avvio dell'incarico l'azienda aveva circa 68 milioni di dollari di ricavi ricorrenti annui a seguito di un round di Serie C, con un'organizzazione di ingegneria di 82 persone. Il suo piano di crescita richiedeva un aumento rilevante della velocità di rilascio senza un corrispondente aumento degli incidenti in produzione.
La sfida
La velocità di rilascio era diventata il vincolo determinante sulla roadmap. L'azienda rilasciava circa 3,4 versioni in produzione al mese contro un obiettivo di rilasci settimanali per team. Il collo di bottiglia era un ciclo di regressione manuale che consumava da cinque a sette giorni prima di ogni rilascio. L'automazione dei test esisteva ma non era affidabile. La copertura si attestava a circa il 35% e la suite presentava un tasso di instabilità abbastanza alto da spingere gli ingegneri a rieseguire i fallimenti anziché indagarli, così i fallimenti genuini venivano talvolta liquidati. Una suite di cui non ci si fida è peggiore di nessuna, perché consuma tempo fornendo al contempo una falsa garanzia.
I difetti sfuggiti aumentavano con il volume dei rilasci, con sei difetti sfuggiti critici e diciotto ad alta gravità nel trimestre precedente all'incarico, diversi dei quali raggiungevano clienti enterprise.
Le assunzioni non erano riuscite a risolverlo. Gli ingegneri di automazione QA di Boston richiedevano una retribuzione che l'azienda faceva fatica a giustificare rispetto alle assunzioni per le funzionalità, e due assunti QA erano entrambi passati ai team di prodotto entro pochi mesi.
Perché Corpshore Colombia
Il cliente ha selezionato Corpshore Colombia principalmente per il fuso orario e il talento. Medellín è un polo tecnologico riconosciuto con una solida base ingegneristica, e QA e release engineering sono funzioni intensive in collaborazione in cui il cliente aveva concluso, da una precedente esperienza offshore, che la consegna asincrona, anziché la competenza, era la causa radice del fallimento. Corpshore ha proposto di trattare l'incarico come trasferimento di capacità anziché come noleggio di capacità, impegnandosi a lasciare al cliente una suite di test affidabile e documentata e un processo di rilascio che i suoi stessi ingegneri potessero gestire, con traguardi definiti di trasferimento delle conoscenze. Il responsabile proposto da Corpshore ha trascorso due giorni con il team di piattaforma del cliente e ha individuato il tasso di instabilità anziché la copertura come problema principale, riformulando la comprensione del cliente.
L'incarico
Ventidue ingegneri a Medellín: due responsabili tecnici, sei senior, dieci di livello intermedio e quattro junior, che coprono automazione QA, DevOps e release engineering. Il team lavora dalle 09:00 alle 18:00 ora orientale statunitense, lo stesso orario di Boston, partecipando agli standup in diretta. Stack: TypeScript, Playwright, Jest, GitHub Actions, Terraform, AWS, Datadog. Tutti gli ingegneri sono dedicati all'account.
Approccio e metodologia
Correggere l'instabilità prima di aggiungere copertura. Le prime otto settimane hanno affrontato l'affidabilità della suite anziché la copertura, sulla base del ragionamento che aggiungere test a una suite inaffidabile aggrava il problema. Il tasso di instabilità è sceso dal 32% a meno del 3% prima che iniziasse il lavoro sulla copertura. Copertura dove risiede il rischio. L'espansione della copertura è stata prioritizzata in base allo storico degli incidenti in produzione e al turnover del codice anziché per modulo, concentrando l'impegno dove i difetti sfuggiti avevano effettivamente avuto origine.
Infrastruttura di delivery progressiva. Il feature flagging e l'infrastruttura di rilascio canary hanno disaccoppiato i rilasci dalle distribuzioni e consentito il rollback senza un ciclo di rilascio completo, il che ha permesso alla frequenza di salire senza un corrispondente aumento della gravità degli incidenti.
Trasferimento documentato delle conoscenze. Quattro traguardi di trasferimento definiti con documentazione e approvazione del cliente garantiscono che il team del cliente stesso possa gestire la pipeline.
Frequenza di rilascio
Risultati
I rilasci in produzione sono saliti da 3,4 al mese a 24,6 entro il mese 12, superando l'obiettivo di rilasci settimanali per team. Il ciclo di regressione manuale è sceso da cinque a sette giorni a meno di quattro ore. I difetti sfuggiti sono calati in ogni fascia di gravità nonostante l'aumento del volume, con i critici scesi da sei per trimestre a uno e quelli ad alta gravità da diciotto a quattro.
La copertura dei test è salita dal 35% all'87% con il tasso di instabilità mantenuto sotto il 3%, e gli ingegneri del cliente stesso ora estendono la suite in modo indipendente, l'obiettivo dichiarato di trasferimento di capacità.
Valore duraturo
La suite di test, la pipeline di rilascio e l'infrastruttura di delivery progressiva sono di proprietà del cliente e gestite congiuntamente. Tutti e quattro i traguardi di trasferimento delle conoscenze sono stati completati. Il cliente ha esteso l'incarico all'ingegneria dell'affidabilità della piattaforma, che il suo VP descrive come una scelta anziché una dipendenza.
Indicatori chiave
| Metrica | Punto di partenza | Mese 12 | Variazione |
|---|---|---|---|
| Rilasci in produzione al mese | 3.4 | 24.6 | +624% |
| Tempo di ciclo della regressione | 5-7 days | < 4 hours | -97% |
| Copertura dell'automazione dei test | 35% | 87% | +52 pts |
| Tasso di instabilità della suite di test | 32% | 2.5% | -92% |
| Difetti sfuggiti critici per trimestre | 6 | 1 | -83% |
| Difetti sfuggiti ad alta gravità per trimestre | 18 | 4 | -78% |
| Tempo medio di ripristino | 4 h 30 m | 30 min | -89% |
Quando una metrica ha rivelato solo una variazione, le cifre assolute sono mostrate con un trattino. Le cifre sono riportate dal cliente o misurate in modo congiunto.
Il loro responsabile ci disse durante la valutazione che il nostro problema era l'instabilità, non la copertura. Tutti gli altri offerenti ci quotavano un numero di copertura. Quella singola osservazione valeva più di tutto il resto del processo messo insieme.
Temi correlati