Come scegliere una software house: domande, contratto, codice
Scegliendo una software house, chieda di chi è il codice sorgente, come avviene la consegna, chi fa la manutenzione e se il team resta lo stesso.
Team rabbitclipPubblicato: 6 min di lettura
In breve
Quando sceglie una software house, la prova decisiva non sono le schermate accattivanti del portfolio, ma ciò che accade dopo la consegna: a chi appartiene il codice sorgente, chi tiene il rilascio e le credenziali di accesso, chi corregge un guasto e con quale rapidità, e se la conoscenza va persa quando il team cambia. Se queste quattro domande hanno risposte scritte fin dall'inizio, gli altri criteri di selezione diventano secondari. Se non le hanno, anche la migliore presentazione comporta un rischio.
Questo articolo riguarda la scelta dell'azienda che costruisce il Suo software, non la scelta di un'agenzia digitale generalista. La differenza è che una campagna finisce e si chiude, mentre un software vive per anni, viene aggiornato e deve poter essere trasferito a qualcun altro. La scelta dovrebbe quindi guardare meno alla prima consegna e più a come andrà il terzo anno.
A chi dovrebbe appartenere il codice sorgente?
È la domanda più importante. Se il contratto non afferma chiaramente che il codice sorgente passa al cliente a pagamento completato, il codice può restare all'agenzia. Se in seguito Lei volesse lavorare con un altro team, o se Lei e l'agenzia vi separaste, il Suo accesso al Suo stesso prodotto sarebbe a rischio. Immagini un produttore di pavimenti che litiga con l'agenzia che ha scritto il suo sistema di ordini. Se il codice si trova sul server dell'agenzia, il produttore potrebbe non riuscire nemmeno ad accedere al proprio flusso di lavoro.
Oltre alla proprietà conta l'accesso. A nome di chi sono aperti il repository del codice, il server, il nome di dominio e gli account di terzi? Aprirli a nome del cliente risolve fin dall'inizio il punto che causa più guai in seguito. Per la redazione giuridica dettagliata è opportuno consultare un avvocato.
Come dovrebbe avvenire la consegna?
La consegna è più della messa online. Una buona consegna comprende il trasferimento ordinato del codice sorgente, delle note di installazione, dei dettagli dell'ambiente e dell'accesso amministratore. Se un altro sviluppatore può mettere in funzione il prodotto a partire da quei documenti, la consegna è completa. Un modo pratico per verificarlo è far leggere le note di installazione a uno sviluppatore indipendente prima della consegna.
I criteri di accettazione e il processo di test vanno messi per iscritto in anticipo. Va discusso anche un periodo di garanzia: correggere gratuitamente, per un tempo stabilito, i difetti che emergono dopo la consegna è una tutela offerta dalla maggior parte delle aziende serie.
- Il codice sorgente e la sua cronologia delle versioni vengono trasferiti al cliente.
- Le note di installazione e di ambiente vengono fornite per iscritto.
- L'accesso amministratore viene creato sull'account del cliente.
- I criteri di accettazione e il processo di test vengono scritti in anticipo.
- Il periodo per correggere i difetti dopo la consegna è definito.
Come vanno organizzati manutenzione e supporto?
Il software non finisce con la consegna. Ha bisogno di aggiornamenti di sicurezza, rinnovo delle dipendenze e piccoli miglioramenti. L'accordo di manutenzione dovrebbe dire chiaramente che cosa copre, come si segnala un guasto e quale sarà il tempo di risposta. Altrimenti ogni piccola richiesta diventa una trattativa a parte, e in un guasto urgente si discute su chi sia responsabile.
L'azienda che mantiene il sistema non deve essere necessariamente quella che lo ha costruito, ma un codice ordinato e documentato è ciò che rende possibile un simile passaggio. Un'azienda che non parla di manutenzione all'inizio di un progetto di solito non ne parla nemmeno dopo. Chiederne conto al primo incontro è quindi il modo più rapido per capire se un'azienda risponde del proprio prodotto.
Perché la continuità del team è importante?
Se il lavoro di una piccola azienda dipende da un solo sviluppatore, il progetto può fermarsi quando quella persona se ne va. Occorre quindi chiedere chi guiderà il progetto, se esiste una persona di riserva e come viene condivisa la conoscenza.
Documentazione scritta, revisione del codice e una routine di sviluppo condivisa sono i segni concreti della continuità. Altrettanto importante è sapere se la persona presente all'incontro commerciale è quella che svolgerà il lavoro. Se può, parli una volta direttamente con lo sviluppatore che lo eseguirà; saper spiegare le questioni tecniche con parole semplici è un buon segno.
Quali errori si commettono scegliendo una software house?
L'errore più comune è scegliere solo in base alla cifra indicata. Un preventivo basso di solito significa un ambito ristretto, una definizione vaga o richieste aggiuntive che arrivano dopo. Il secondo errore è non verificare le referenze. Parlare con clienti precedenti di ciò che è accaduto dopo la consegna è più istruttivo della maggior parte delle presentazioni.
Il terzo errore è non mettere in discussione le scelte tecniche. La tecnologia con cui è costruito il prodotto decide se un altro team potrà portarlo avanti in seguito. Le tecnologie diffuse e ben documentate comportano in genere meno rischio. Una struttura molto recente, o che solo quell'azienda comprende, può rendere la manutenzione costosa e difficile.
- Guardare solo il prezzo: vanno confrontati ambito e presupposti.
- Non chiedere referenze: parli con un cliente precedente.
- Non leggere il contratto: le clausole su proprietà e manutenzione vengono saltate.
- Confondere il venditore con lo sviluppatore: chieda chi svolgerà il lavoro.
Quando una software house è la scelta sbagliata?
Un'azienda che indica subito un prezzo, senza chiedere dell'ambito, va valutata con attenzione. Un'azienda che propone soluzioni senza ascoltare, rifiuta di consegnare il codice sorgente o insiste per tenere le credenziali di accesso sul proprio account può renderLa dipendente in seguito. Nessuno di questi punti è da solo prova di malafede, ma ciascuno richiede una spiegazione prima che Lei firmi.
Una grande software house è superflua per un lavoro piccolo e una tantum, e un team di una sola persona è rischioso per un sistema critico e di lunga durata. La scelta giusta è quella in cui dimensioni e struttura dell'azienda corrispondono alle dimensioni e alla durata del lavoro.
Scegliere una software house non è un concorso di presentazioni. È un piano di consegna. Se la proprietà del codice sorgente, il contenuto della consegna, l'estensione della manutenzione e la continuità del team sono messi per iscritto all'inizio, la Sua scelta poggia su terreno solido. Se desidera misurare il Suo progetto su questi criteri, può fissare un colloquio di scoperta con rabbitclip.
Domande frequenti
Quali domande devo fare a una software house?
Chieda a chi apparterrà il codice sorgente, che cosa viene consegnato alla fine, come funzionerà la manutenzione e quali persone guideranno il progetto. Ottenga tutte e quattro le risposte per iscritto.
Il codice sorgente resta all'agenzia o a me?
Dipende dal contratto. Se il trasferimento non è scritto chiaramente, il codice può restare all'agenzia, quindi proprietà e accesso vanno stabiliti come del cliente fin dall'inizio. Consulti un avvocato per i dettagli legali.
C'è differenza tra agenzia di sviluppo e software house?
Oltre al nome non esiste un confine netto. Contano la struttura dell'azienda, il suo team e la sua forma di contratto, non l'etichetta.
Serve un accordo di manutenzione?
Ogni software in produzione ha bisogno di aggiornamenti di sicurezza e controlli regolari. Che li svolga la stessa azienda o un altro team, ambito e tempo di risposta vanno messi per iscritto.
L'azienda dovrebbe trovarsi vicino a me?
La sede non è il criterio principale. Incontrarsi di persona è comodo, ma le vere misure sono la disciplina di consegna dell'azienda, il suo contratto e la continuità del suo team.
