Preventivare modifiche su un progetto ereditato senza perdere il margine

Un cliente arriva in agenzia con un sito, un gestionale o un’app fatti da qualcun altro e chiede “solo qualche modifica”. Oppure chiede un lavoro che il vostro team di solito non fa: un’integrazione con il gestionale di magazzino, un’area riservata, un plugin su misura. In tutti e due i casi il preventivo parte da una richiesta di due righe e da un’idea vaga di cosa c’è sotto.

Nel lavoro con le agenzie i problemi che vedo più spesso nascono proprio lì, prima del progetto. Si promettono tempi e costi senza aver capito la parte tecnica, oppure si preventivano modifiche su codice ereditato come se fosse in ordine. A lavori avviati saltano fuori integrazioni, dati da migrare o codice da sistemare che nessuno aveva messo in conto, e il margine se ne va.

In breve

• Prima di fare un prezzo chiedete gli accessi a codice, hosting e dati, e chiedete chi ha realizzato il progetto.
• Su un progetto ereditato fate una verifica tecnica breve, poi dividete il lavoro in parti, ciascuna con stima e rischio.
• Le parti che non si possono stimare non vanno a prezzo fisso: preventivo a fasi o analisi a pagamento.
• Scrivete nell’offerta le assunzioni su cui si regge il prezzo e cosa succede se si rivelano false.

Perché il margine sparisce dopo la firma

Il prezzo si fa sulla parte visibile, cioè la modifica richiesta. Il costo invece dipende da quella che non si vede: lo stato del codice, i dati, le integrazioni, le versioni del software sul server.

Construx, società di consulenza specializzata nella stima del software, descrive il fenomeno con il “cono di incertezza”: una stima fatta quando esiste solo l’idea iniziale può sbagliare fino a 4 volte in più o in meno, e quello è il caso migliore, con stimatori esperti. L’incertezza cala solo man mano che il lavoro viene definito, e chi si impegna su tempi e costi troppo presto si complica il progetto da solo (Construx). Un preventivo a corpo firmato su una richiesta di due righe è proprio un impegno preso a quel punto.

Un esempio tipico: il cliente vuole aggiungere un campo al modulo di iscrizione. Sembra mezza giornata. Poi si scopre che il modulo scrive in una tabella letta anche da un gestionale esterno, che il plugin dei moduli è stato modificato a mano e non si può aggiornare, e che il server gira su una versione di PHP che il nuovo codice non supporta.

Cosa chiedere al cliente prima di fare un prezzo

Queste domande servono prima del preventivo, finché le risposte possono ancora cambiare il prezzo.

1. Chi ha realizzato il progetto, e se è ancora raggiungibile.
2. Dov’è il codice. Un repository Git, una cartella sul server, un archivio zip? Il codice in produzione è lo stesso che vi consegnano?
3. Hosting e dominio. A chi sono intestati, chi ha le credenziali del pannello, dove sono i DNS, se le email girano sullo stesso dominio.
4. Backup. Esiste un backup recente? Qualcuno ha mai provato a ripristinarlo?
5. Dati. Cosa contiene il database, se ci sono dati personali, se una parte va migrata o importata da un altro sistema.
6. Integrazioni. Pagamenti, gestionale, CRM, newsletter, servizi esterni: chi ha le chiavi di accesso e a nome di chi sono gli account.
7. Licenze. Temi, plugin o librerie a pagamento: a chi sono intestate e se scadono.
8. Documentazione e ambiente di test. Se mancano, crearli è lavoro da preventivare.

Se il cliente non riesce a darvi gli accessi prima del preventivo, non fate un prezzo fisso su una cosa che non avete visto.

Sulla privacy: se l’agenzia tratta dati personali per conto del cliente è responsabile del trattamento, e il rapporto va regolato da un contratto o da un altro atto giuridico. Il responsabile, inoltre, non può coinvolgere un altro responsabile senza un’autorizzazione scritta del titolare, specifica o generale (GDPR, art. 28). Se vi servirà un consulente esterno che vede quei dati, chiaritelo con il cliente subito.

La verifica tecnica minima su un progetto ereditato

Qui lo scopo è più stretto di un audit del codice: trovare quello che cambia il prezzo. Io guardo questi punti:

• Si installa da zero? Provate a far girare il progetto in locale o su un ambiente di test. Se ci vuole un giorno solo per avviarlo, anche quel giorno è un costo.
• Versioni. Linguaggio, framework, CMS, plugin. Per PHP, oggi le versioni supportate sono dalla 8.2 alla 8.5, e la 8.2 riceve solo correzioni di sicurezza fino al 31 dicembre 2026 (php.net). Le versioni precedenti non ricevono più correzioni di sicurezza. Se la modifica richiede un aggiornamento, l’aggiornamento è una voce di lavoro a sé.
• Codice di terzi modificato a mano. Le modifiche fatte direttamente su plugin, temi o librerie si perdono al primo aggiornamento. Vanno trovate prima.
• Test automatici. Se non ci sono, ogni modifica va verificata a mano su tutte le funzioni collegate, e quel tempo va stimato.
• Dove arriva la modifica. Quanti file e quante funzioni tocca, cosa dipende da quei punti.
• Dati da migrare. Struttura, volumi, qualità: duplicati, campi usati per scopi diversi da quelli previsti, formati non uniformi.
• Processi nascosti. Operazioni pianificate, webhook, script lanciati a mano da qualcuno ogni lunedì.

Come dare un prezzo all’incertezza

Nella stima che preparo per un’agenzia divido il lavoro in parti e assegno a ciascuna tempi e rischio. Le parti chiare possono andare a prezzo fisso, quelle incerte solo con un’assunzione scritta. Quelle che non si possono stimare le segnalo come tali, senza un numero inventato.

Parte	Rischio	Come la preventivo
Ambiente di test e backup verificato	basso	prezzo fisso
Nuovo campo nel modulo e nel database	basso	prezzo fisso
Aggiornamento di PHP e dei plugin	medio	prezzo fisso con assunzioni dichiarate
Sincronizzazione con il gestionale esterno	alto	fase separata, dopo l’analisi

Per prezzare le parti incerte ci sono tre strumenti, che si possono combinare.

Preventivo a fasi. La prima fase comprende la verifica, la messa in sicurezza e le parti chiare, a prezzo fisso. Le fasi successive si quotano quando la prima ha tolto le incognite. Il cliente sa da subito quanto costa partire e vede come si arriva al resto.

Analisi a pagamento. Quando l’incertezza è tanta, l’analisi diventa un lavoro a sé, con un documento da consegnare. La guida del governo britannico per chi progetta servizi digitali pubblici chiede lo stesso: prima di impegnarsi a costruire un servizio bisogna capire il problema, e durante questa fase di “discovery” non si costruisce nulla (GOV.UK Service Manual). Al cliente il documento resta comunque, anche se poi decide di non andare avanti.

Ore con un tetto. Per le parti che si scoprono solo lavorandoci, come la correzione di errori di cui non si conosce la causa, si può lavorare a ore con un massimo concordato. Raggiunto il tetto ci si ferma e si decide insieme.

Come scrivere le assunzioni nell’offerta

Un’assunzione utile si può verificare e dice cosa succede se è falsa. Alcuni esempi da adattare:

• “Il preventivo si basa sul codice consegnato nel repository indicato alla data del [giorno]. Se il codice in produzione è diverso, l’allineamento verrà stimato a parte.”
• “Sono escluse la migrazione dei dati esistenti e la correzione dei malfunzionamenti presenti prima del nostro intervento. Se richieste, saranno stimate a parte.”
• “La migrazione prevede fino a [numero] record in un unico formato. Dati in formati diversi saranno stimati separatamente.”
• “Se durante il lavoro emergono problemi del codice esistente che impediscono la modifica, li segnaliamo con una stima prima di intervenire.”
• “Il cliente fornisce entro [data] gli accessi a hosting, repository e servizi esterni. I tempi di consegna partono da quella data.”

Le esclusioni vanno nominate una per una. Io evito formule come “tutto quanto non espressamente indicato”: quando nasce una discussione, ognuno la legge a modo suo. E il modello di offerta, nella parte contrattuale, fatelo rivedere da un legale.

Dove entro io

Quando un’agenzia mi coinvolge parto dall’analisi e, se il progetto esiste già, dallo stato in cui si trova. Vi consegno un documento su cui costruire il preventivo, anche con il vostro marchio se dovete girarlo al cliente, e se una parte è incerta ve lo dico prima che arrivi a lui. Se invece vi serve un giudizio completo sulla qualità di un codice, il lavoro giusto è l’audit del codice.

Come lavoro con le agenzie, dal brief alla consegna, lo trovate nella pagina sulla consulenza tecnica white label.