Come scegliere una software house: 8 errori che costano caro

Scegliere un partner tecnologico è la decisione che stabilisce se un progetto software arriverà nei tempi, nel budget e in una forma che si possa mantenere. La maggior parte delle collaborazioni che falliscono non fallisce sulle competenze tecniche: fallisce su ambito, comunicazione e trasparenza, e i segnali si vedono prima della firma. Questo articolo elenca gli otto errori che incontriamo più spesso, come confrontare le proposte in modo corretto e le domande da fare prima di impegnarsi.

TL;DR

• Gli errori costosi si fanno prima che lo sviluppo inizi: ambito poco chiaro, partner scelto solo sul prezzo, proposte che nessuno riesce a confrontare.
• Un buon partner nei primi incontri fa più domande di voi e vi dice cosa non ci sarà nella prima versione.
• Le proposte si confrontano su ciò che definiscono (ambito, deliverable, team, processo, esclusioni), non sulla cifra in prima pagina.
• Sistemi legacy e programmi grandi richiedono un partner con un piano per la complessità, non solo un team.
• Quindici domande, poste prima di firmare, eliminano gran parte del rischio.

Perché la scelta di un partner tecnologico va storta così spesso?

La scelta va storta perché le aziende comprano capacità quando servirebbe giudizio. Ingaggiano un team per costruire ciò che chiedono e scoprono che la richiesta era incompleta, che il partner non l'ha mai messa in discussione e che la proposta lasciava indefinite le parti difficili. Il risultato: ritardi, sforamenti di costo e frustrazione.

Lo schema è comune perché chi acquista sviluppo lo fa raramente. Un'azienda in crescita sceglie un partner per l'infrastruttura cloud, per un programma di modernizzazione o per un nuovo prodotto una volta ogni qualche anno, e le lezioni della volta precedente non sono fresche. Gli otto errori qui sotto sono quelli che si ripetono, e ognuno ha un rimedio economico se viene colto in tempo.

Quali sono gli otto errori più comuni nella scelta di una software house?

Gli otto errori sono: partire senza le competenze interne per giudicare il lavoro, lasciare l'ambito vago, scegliere solo sul prezzo, accettare una comunicazione debole all'inizio, sottovalutare la complessità dei sistemi legacy, accettare proposte opache, ignorare i segnali di fiducia dei progetti passati e aspettarsi che un processo rigido si adatti da solo. Tutti si possono evitare.

1. Partire senza le competenze per giudicare il lavoro. Molte aziende entrano nell'infrastruttura cloud, nel DevOps o nelle architetture scalabili senza nessuno all'interno in grado di valutare ciò che il partner propone. Un buon team di sviluppo non equivale a esperienza con l'orchestrazione di container, il controllo dei costi cloud o i sistemi distribuiti. Se nessuno dalla vostra parte può valutare il piano, fate rivedere la proposta da un esperto indipendente, oppure chiedete al partner di spiegare le sue scelte in termini di business finché non siete in grado di farlo.
2. Lasciare l'ambito vago. L'outsourcing dovrebbe semplificare la vita: spiegate cosa vi serve e ricevete una soluzione funzionante. Nella realtà le aziende faticano a esprimere i requisiti perché non sanno cosa sia possibile, e requisiti ambigui producono infiniti scambi, aspettative disallineate e rifacimenti. Una specifica tecnica scritta e concordata prima dello sviluppo, anche breve, è la protezione più economica che possiate comprare.
3. Scegliere solo sul prezzo. L'opzione più economica porta spesso costi nascosti: debito tecnico, problemi di prestazioni e una fattura di manutenzione che arriva quando il fornitore è già altrove. Le offerte premium sembrano care finché non si conta cosa includono. Il confronto corretto è il costo del sistema funzionante lungo la sua vita, non il preventivo.
4. Accettare una comunicazione debole all'inizio. Alcuni fornitori prendono i requisiti alla lettera senza fare domande; altri seguono un processo fisso a prescindere dalla situazione del cliente. In entrambi i casi le incomprensioni emergono solo in fase di test. I primi incontri dovrebbero assomigliare a un colloquio in entrambe le direzioni.
5. Sottovalutare la complessità dei sistemi legacy. Molte aziende usano sistemi non progettati con le pratiche moderne. Portarli ai microservizi, migliorarne le prestazioni o introdurre architetture modulari è raramente lineare, e un partner che non lo ha mai fatto scoprirà la complessità sul vostro budget. Chiedete lavori di modernizzazione comparabili e valutate un software audit indipendente prima che qualcuno faccia una stima.
6. Accettare proposte opache. Proposte che suonano bene ma lasciano indefiniti prezzi, deliverable e assunzioni non si possono confrontare tra loro e nascondono i costi e i limiti che si scoprono dopo. La fiducia si costruisce con proposte che dicono esattamente cosa viene consegnato, da chi, quando e cosa è escluso.
7. Ignorare i segnali di fiducia. Le esperienze passate con fornitori inaffidabili rendono prudenti, giustamente. Referenze, casi studio pubblicati con risultati verificabili e la disponibilità a mettervi in contatto con un cliente attuale sono i segnali da chiedere; un fornitore che non ne offre nessuno vi chiede di assumervi il rischio da soli.
8. Aspettarsi che un processo rigido si adatti. Le priorità cambiano, gli ostacoli compaiono e i requisiti evolvono in ogni progetto reale. Un partner il cui processo non riesce ad assorbire tutto questo senza rinegoziare ogni cosa vi frustrerà nel giro di settimane. Chiedete come vengono gestiti i cambiamenti prima di averne bisogno.

Come si confrontano le proposte in modo corretto?

Le proposte si confrontano correttamente solo se rispondono alle stesse domande: inviate a ogni fornitore lo stesso brief e lo stesso elenco di cosa una proposta deve indicare. Giudicate ognuna su quanto definisce con precisione ambito, deliverable, team, processo ed esclusioni. Un prezzo basso legato a un ambito vago non è un prezzo basso: è un prezzo sconosciuto.

Quando una proposta lascia una riga vuota, chiedete di compilarla prima di confrontare i prezzi. Le risposte di solito separano i partner che hanno riflettuto sul vostro progetto da quelli che hanno inviato un modello.

Quali domande fare a una software house prima di firmare?

Fate quindici domande, su come il partner definisce l'ambito, chi fa il lavoro, come gestisce i cambiamenti, come testa e rilascia, cosa succede dopo il lancio e come tratta i vostri dati. Le risposte contano più del listino, e un partner che accoglie le domande vi sta già dicendo qualcosa.

1. Come ci aiuterete a decidere cosa entra nella prima versione, e su cosa ci direte di no?
2. Quali progetti simili per dimensione, settore e tecnologia potete mostrarci, con risultati misurabili?
3. Possiamo parlare con un vostro cliente attuale?
4. Chi lavorerà esattamente sul nostro progetto, con quale seniority e allocazione?
5. Come comunicheremo, con quale frequenza e chi è il nostro referente unico?
6. Come pianificate e mostrate l'avanzamento: cadenza degli sprint, demo, reportistica?
7. Come testate, revisionate e rilasciate il software?
8. Cosa è escluso dalla proposta e come vengono prezzati i cambiamenti?
9. Su quali assunzioni si basa la vostra stima?
10. Come gestite sistemi legacy, migrazione dei dati e integrazioni?
11. Chi possiede il codice, i repository, gli account cloud e i dati?
12. Come gestite la sicurezza e, se trattate dati personali per nostro conto, firmerete un accordo di trattamento? Il GDPR richiede che il responsabile del trattamento sia vincolato da un contratto che ne definisce gli obblighi. (eur-lex.europa.eu)
13. Come sarà il primo mese dopo il lancio e quanto costa la manutenzione?
14. Cosa succede se vogliamo fermarci o cambiare partner?
15. Cosa fareste di diverso se il budget fosse la metà, o il doppio?

La sede del partner cambia il rischio?

La sede cambia costi, sovrapposizione di fuso orario e abitudini di comunicazione, non i fondamentali. Un team nearshore in un fuso vicino mantiene facile il contatto quotidiano e costa meno di un team locale; un team offshore costa ancora meno ma rende più difficile la collaborazione in tempo reale. Gli otto errori e le quindici domande valgono in ogni caso.

I nostri articoli sui servizi di sviluppo nearshore e sull'outsourcing IT per i lean team approfondiscono i modelli di delivery; la pagina team augmentation descrive come aggiungiamo persone senior a un team esistente invece di sostituirlo.

Come lavora WWG con i propri clienti?

WWG lavora con un flusso strutturato: una roadmap concordata all'inizio, una stima dei costi ripartita per fase di sviluppo, cambiamenti assorbiti nel piano invece che rinegoziati, e checkpoint regolari con demo perché non ci siano lunghi periodi al buio. I clienti sanno cosa è stato completato, cosa è in corso e quando arriva il prossimo risultato.

Questa struttura è esattamente ciò che manca negli otto errori. Una roadmap con scadenze e requisiti tecnici dettagliati fissa l'ambito; una stima per fasi rende la proposta confrontabile; la procedura di cambio evita che la flessibilità diventi caos; i checkpoint tengono viva la comunicazione dopo i primi incontri. La pagina sviluppo software su misura descrive i modelli di collaborazione.

State scegliendo un partner per il prossimo progetto? Parlatene con un ingegnere WWG per capire come lo imposteremmo: business@wwg.it.

Fonti

• Regolamento (UE) 2016/679 (GDPR), articolo 28 sul responsabile del trattamento, EUR-Lex