Nei progetti software la proprietà non riguarda soltanto il codice. Repository, account App Store e Google Play, cloud, dominio, certificati, librerie, design e dati possono essere distribuiti tra soggetti diversi. Chiarirlo tardi rende un cambio fornitore molto più difficile.
Gli asset da mappare
Una checklist di ownership dovrebbe coprire tutto ciò che serve a costruire, distribuire e gestire il prodotto.
- Repository sorgenti
- Account Apple e Google
- Cloud e database
- Domini e DNS
- Certificati e chiavi
- Asset grafici e design source
- Servizi terzi e analytics
Contratto e controllo operativo
Le condizioni contrattuali vanno lette insieme alla situazione pratica. Anche con diritti chiari, un account intestato a terzi o credenziali mancanti possono creare problemi immediati.
Preparare un handover verificabile
La consegna dovrebbe essere testata: un nuovo team deve riuscire ad accedere, costruire e pubblicare il progetto senza dipendere da passaggi informali.
La vera ownership si verifica chiedendo: se il fornitore domani non fosse disponibile, potrei continuare a operare?
Vuoi applicarlo al tuo progetto?
Possiamo partire da una valutazione del contesto attuale e capire quali decisioni hanno priorità.
Approfondisci Cambio software houseDomande frequenti
Il codice sorgente è sempre del cliente?
Dipende dal contratto e dal contesto giuridico. È importante definire espressamente diritti, consegna e utilizzo con un professionista legale quando necessario.
Gli account store dovrebbero essere del cliente?
Per prodotti proprietari è generalmente preferibile che l’azienda mantenga controllo amministrativo degli account di distribuzione.