Come scegliere una software house: le domande giuste

«Come scegliere una software house» è una ricerca che nasconde spesso un’ansia molto specifica: aver già sentito, o vissuto, un progetto che è andato male — tempi raddoppiati, comunicazione persa, un fornitore che spariva per settimane. Un bel portfolio non previene nessuno di questi problemi. Le domande giuste, poste prima di firmare, sì.

Chiedete chi scrive davvero il codice

Molte software house vendono con un team senior in call di vendita e assegnano il progetto a chi è disponibile in quel momento, spesso persone più giovani con meno esperienza sul tipo di problema specifico che avete. Non è necessariamente un male — ma dovreste saperlo prima, non scoprirlo a metà progetto. Chiedete direttamente: chi scriverà il codice, e sarà la stessa persona con cui state parlando ora?

Team piccoli tendono a rispondere meglio a questa domanda, per una ragione strutturale: meno persone significa meno passaggi di consegne, e meno passaggi significa meno occasioni perché il progetto si allontani da quello che avevate realmente chiesto.

Chiedete con quale frequenza vedrete software funzionante

Una software house seria non mostra una presentazione a metà progetto — mostra schermate reali, cliccabili, ogni poche settimane. Questo non è solo trasparenza di facciata: è il meccanismo che permette di correggere un’ipotesi sbagliata alla seconda settimana invece che alla decima, quando cambiarla costa molto di più.

Se la risposta a «quando vedremo qualcosa di funzionante» è «alla fine», è un segnale da prendere sul serio, non un dettaglio organizzativo.

Chiedete cosa succede al codice dopo la consegna

Un preventivo che non menziona codice sorgente, accesso al repository e documentazione non è un preventivo completo — manca la parte che determina cosa succede dopo il lancio. Un software di cui non siete proprietari è un abbonamento travestito: ogni modifica futura passa da chi detiene il codice, al prezzo che quella parte deciderà quando non avrete più alternative.

Chiedete esplicitamente: riceverete il codice sorgente completo, l’accesso al repository, e la documentazione — e a che punto del progetto, non solo alla fine?

Chiedete come vengono gestite le integrazioni

Se il progetto deve parlare con sistemi che già usate — un gestionale, un CRM, una piattaforma di e-commerce — chiedete come la software house valuta quel lato del lavoro prima di dare un numero. Un fornitore che quota un’integrazione senza aver guardato cosa espone davvero l’altro sistema sta indovinando, non stimando.

Domanda	Cosa rivela
Chi scriverà davvero il codice	Dimensione reale del team, continuità
Con che frequenza vedrò software funzionante	Rischio di scoperte tardive
Riceverò codice sorgente e documentazione	Proprietà reale del software
Come stimate un’integrazione con i nostri sistemi	Serietà del processo di analisi
Cosa succede se lo scopo cambia in corsa	Onestà sul modello di prezzo

Diffidate di un numero dato troppo presto

Un prezzo fornito prima che lo scopo del progetto sia scritto — schermate, ruoli, flussi di dati, cosa è incluso e cosa esplicitamente no — non è un preventivo. È un segnaposto in attesa della conversazione che lo renderà reale. Una software house seria propone prima una fase di analisi, anche breve, e solo dopo un numero legato a quello che ha effettivamente capito del progetto.

Questo vale anche per il modello di prezzo stesso: un prezzo fisso per fase ha senso per un progetto con un punto d’arrivo definito, una capacità mensile ha senso per un prodotto che continuerà a evolversi dopo il lancio. Nessuno dei due è intrinsecamente più economico — sono risposte a domande diverse, e confonderli è uno dei modi più comuni in cui un progetto «su misura» diventa una fattura senza fine.

Chiedete a chi ha già lavorato con loro cosa è successo a metà progetto

Le referenze contano, ma solo se si fanno le domande giuste. Chiedere «siete stati contenti» produce quasi sempre un sì educato. Chiedere «cosa è successo quando qualcosa è andato storto a metà progetto» produce una risposta molto più utile: ogni progetto, in un modo o nell’altro, incontra un imprevisto — un requisito che cambia, un’integrazione più complicata del previsto, una scadenza che slitta. Quello che distingue un fornitore serio non è l’assenza di questi momenti, è come vengono comunicati quando accadono: subito, con una proposta concreta, o solo quando ormai è troppo tardi per correggere la rotta.

Diffidate anche del preventivo perfettamente rotondo

Un progetto reale, con integrazioni verso sistemi non ancora esplorati del tutto, raramente produce un numero perfettamente tondo al primo incontro. Un preventivo che arriva già suddiviso in voci dettagliate, coerenti con quanto discusso, con margini di incertezza dichiarati apertamente dove esistono, è generalmente un segnale migliore di un numero secco consegnato nella stessa telefonata in cui il progetto è stato descritto per la prima volta.

Come lavoriamo noi, per confronto

Teniamo i team piccoli di proposito, consegniamo software utilizzabile ogni poche settimane, e trasferiamo codice sorgente, accesso al repository e documentazione a ogni tappa del progetto, non solo alla fine. Non lo diciamo per differenziarci a parole — è il criterio che useremmo anche noi, da committenti, per valutare un fornitore.

Da dove partire

Se state valutando più fornitori, portate a ciascuno le stesse domande di questo articolo e confrontate le risposte, non solo i preventivi. Potete vedere esempi concreti del nostro modo di lavorare nella pagina lavori, o leggere di più sul nostro approccio al software su misura.

Un portfolio mostra cosa è stato consegnato. Non mostra come ci si è arrivati — e quello, più del risultato finale, è ciò che determina se il vostro progetto andrà bene.

Se il progetto in mente coinvolge anche la fatturazione elettronica, l’articolo su cosa significa integrare lo SDI approfondisce quella parte specifica. Per il resto, una conversazione diretta è il modo più rapido per capire se siamo il fornitore giusto per voi.