Guida
Come scegliere un'agenzia di sviluppo software
Guardate come vi fanno le domande, non come vi mostrano i lavori. Un fornitore che nel primo incontro vi chiede solo cosa volete costruire, e mai perché, vi consegnerà esattamente quello che avete chiesto anche quando era la cosa sbagliata.
Se la domanda mette a disagio, avete già la risposta.
Le domande da fare prima di firmare
Chi lavorerà concretamente al progetto? Non chi lo segue commercialmente. È normale che la persona che vi convince non sia quella che scrive il codice, ma dovreste poterla incontrare prima di firmare, non dopo.
A chi appartiene il codice? La risposta deve essere «a voi», e deve essere scritta nel contratto. Chiedete anche dove risiede: un repository che controllate voi è diverso da uno che vi viene consegnato alla fine, perché nel secondo caso non potete vedere niente finché non è troppo tardi.
Cosa succede se ci lasciamo? Un fornitore sereno risponde subito e nel dettaglio.
Come gestite le richieste di modifica? Ogni progetto ne genera. Ciò che distingue è se esiste un modo dichiarato di valutarle e quantificarle prima di svilupparle, o se si scopre tutto in fattura.
Cosa non è compreso? È la domanda più utile e la meno fatta. Analisi, test, migrazione dei dati, formazione, manutenzione: se non sono nel preventivo non sono spariti, arriveranno dopo.
I segnali che anticipano un progetto difficile
Vi danno un prezzo subito. Un numero prima di aver capito il problema serve a farsi scegliere, non a essere accurato. Verrà rinegoziato, e la rinegoziazione avverrà quando avrete già investito e sarete meno liberi di andarvene.
Dicono sì a tutto. Un fornitore che in due ore non ha mai obiettato, ridimensionato o proposto un'alternativa non vi sta ascoltando, vi sta vendendo. Le obiezioni nella fase di vendita sono il migliore indicatore di onestà nella fase di esecuzione.
Promettono il primo posto su Google. Nessuno può garantirlo. Si può garantire una struttura tecnica corretta, e chi promette il posizionamento sta promettendo qualcosa che non controlla.
Non parlano mai di manutenzione. Il software non finisce alla consegna. Chi vende un progetto come se avesse una data di fine non vi ha detto tutto, o non lo sa.
Non fanno domande sui vostri processi. Chi progetta uno strumento senza chiedere come lavorate davvero, e non solo come dovrebbe funzionare in teoria, costruirà qualcosa che le vostre persone aggireranno tornando ai fogli di calcolo.
Agenzia creativa e software house, o un team solo
Molti progetti coinvolgono due fornitori: uno che disegna e uno che sviluppa. Funziona, ma il punto di fragilità è sempre lo stesso: il passaggio di consegne. Il design arriva come immagini, chi sviluppa interpreta ciò che non era specificato, e le decisioni prese in quel momento non tornano mai indietro a chi aveva progettato.
Il risultato tipico non è un disastro visibile: è una lenta perdita di precisione. Spaziature approssimate, stati non previsti, animazioni tagliate perché costose. Ognuna è piccola, e insieme fanno la differenza fra un prodotto curato e uno che sembra quasi giusto.
Un team unico elimina quel passaggio, ma non è automaticamente migliore: va verificato che sappia fare davvero entrambe le cose, e non che faccia bene una e a sufficienza l'altra. Chiedete di vedere lavori dove si vedano sia la qualità visiva sia il comportamento tecnico.
Come lo affrontiamo noi
Nel primo incontro facciamo domande sul problema, non sul progetto, e se pensiamo che vi serva qualcosa di più piccolo di quello che avete chiesto lo diciamo. È capitato di sconsigliare un'app e di suggerire un sito, perdendo il lavoro più grande.
Design e sviluppo sono nello stesso team, quindi non esiste il passaggio di consegne descritto sopra. Codice, dati e documentazione restano vostri in un repository che controllate voi, dal primo giorno e non alla consegna.
Domande frequenti
Meglio un'agenzia grande o piccola?
Dipende da chi lavorerà davvero sul progetto. Le strutture grandi danno continuità ma spesso assegnano le persone più esperte alla vendita e le meno esperte all'esecuzione. Le piccole danno accesso diretto a chi costruisce, ma vanno verificate sulla capacità di reggere un'assenza.
Il portfolio conta?
Conta meno di quanto sembri, perché mostra il risultato e non il processo, e non dice chi di quel team c'è ancora. Vale di più chiedere di raccontare un progetto andato male e cosa hanno cambiato dopo: la risposta distingue chi ha esperienza da chi ha solo referenze.
Quanto conta il prezzo?
Conta, ma il preventivo più basso è spesso il più caro. Va confrontato a parità di attività incluse: se uno comprende analisi, test e manutenzione e l'altro no, non state confrontando due prezzi ma due cose diverse.
Cosa deve restare nostro?
Il codice sorgente, i dati, la documentazione, i nomi di dominio e gli account degli store e dei servizi cloud. Se qualcuno di questi resta intestato al fornitore, il costo di cambiare fornitore non è più una vostra decisione.
Parliamone
Se state valutando più fornitori, usate queste domande anche con noi. Se le risposte di qualcun altro vi convincono di più, è la scelta giusta.