Durante la negoziazione dei prezzi di un progetto di sviluppo software personalizzato, le due parti, A e B, concordano più spesso sull’unità di misura che è«Uomo e Cielo»: Quanti ingegneri, per quanti giorni, a quale prezzo unitario. Questo modello funziona quando le esigenze sono stabili e i confini della consegna sono chiari; ma non appena le regole sul campo cambiano di frequente, gli strumenti di intelligenza artificiale aumentano l’efficienza della codifica, e il committente continua a effettuare la verifica basandosi su un “accumulo di persone”, le contraddizioni esplodono: la parte B ritiene che le richieste si siano estese, mentre la parte A pensa che “non siano stati aggiunti più uomini, ma che il risultato non sia migliorato”.
Segnali di politica: dal vendere manodopera al vendere risultati
Nel settembre 2026, il Ministero dell’Industria e delle Tecnologie dell’Informazione ha pubblicato il “Piano di attuazione per l’iniziativa speciale ‘Intelligenza artificiale + Software’”, che menziona più volte la necessità di promuovere la trasformazione dei modelli di produzione software e lo sviluppo di “Modello come servizio” e “Agente intelligente come servizio”, specificando inoltre che entro il 2028 dovranno essere realizzate applicazioni di riferimento nel settore degli agenti intelligenti nei principali comparti industriali. Il documento non esclude lo sviluppo su misura, ma indica chiaramente una direzione:Nella valutazione del valore dei software, si dà sempre più importanza ai risultati concreti, piuttosto che al solo numero di uomini‑giorno impiegati.。
Per le aziende che stanno implementando sistemi ERP, MES, CRM e gestionali settoriali, ciò significa che, se nei contratti si continua a indicare soltanto «XX persone × XX giorni», dopo la messa in produzione sarà facile incorrere in lunghe discussioni del tipo «il codice è stato completato, ma il sistema non viene utilizzato». Una modalità di redazione più sostenibile consiste nel suddividere la consegna inRisultati aziendali accettabili。
Logica di business: i traguardi devono essere più specifici delle giornate lavorative
Aggiornare il progetto da “pagamento a fase” a “pagamento per traguardo”; ogni traguardo deve soddisfare contemporaneamente quattro requisiti:
- Scenario di business: Chi lo utilizza e quale operazione risolve (ad esempio, «il magazziniere scansiona il codice per l’ingresso in magazzino» anziché «completa il modulo di ingresso in magazzino»).
- Calibro dei dati: Quali sono i dati principali, i campi di stato e l’ambito delle autorizzazioni, e qual è la regola di campionamento?
- Script di accettazione: Date le informazioni di test, quali flussi vengono eseguiti e quali documenti o report vengono generati.
- Gestione delle eccezioni: Come viene visualizzato il messaggio di errore nel sistema, chi ha il diritto di apportare modifiche e se vengono registrate le tracce.
I traguardi non dovrebbero superare2–4 settimaneUno; se è troppo lungo, si torna allo “sviluppo a scatola nera”. Esempio tipico di suddivisione: dati anagrafici e autorizzazioni → ciclo chiuso dei documenti principali → report e riconciliazione → interfaccia e passaggio alla produzione.
Logica di progettazione: ambito, modifiche e «assistenza intelligente» inseriti nel contratto
La codifica assistita dall’IA, la generazione automatica di casi di test e la compilazione intelligente dei documenti cambieranno il consumo di giorni‑uomo per le stesse funzionalità, maNon modifica automaticamente la complessità del business. Nel contratto e nelle specifiche dei requisiti si suggerisce di inserirlo separatamente:
- Linea di base (Baseline): Elenco delle funzionalità + elenco degli elementi fuori ambito (Out of Scope); le modifiche devono essere gestite tramite un modulo di modifica.
- Modifica delle regole di tariffazione: È stato aggiunto il criterio di valutazione dei traguardi basato su “scenario + script di accettazione”, anziché sull’aggiunta temporanea di giornate lavorative.
- Assistenza intelligente ai confini: In quali fasi l’IA può migliorare l’efficienza (generazione del codice, bozze di documenti), e in quali è necessaria la firma umana (sicurezza, conformità, impegni verso l’esterno)?
- Attribuzione della sedimentazione delle conoscenze: Chi detiene i documenti di processo, le configurazioni e gli script, per evitare una discontinuità nella fase di operazione e manutenzione dopo la consegna.
Sviluppo e implementazione: automazione della verifica e monitorabilità
Per rendere attuabile l’approccio “orientato ai risultati”, il reparto tecnico deve collaborare su tre fronti:
- Inserimento nel database dei casi di accettazione: Ogni traguardo corrisponde a un insieme di casi d’uso automatizzati o semiautomatici, che possono essere eseguiti nuovamente in modo ripetibile.
- Isolamento ambientale e dei dati: I dati dell’ambiente UAT possono essere ripristinati, evitando che “funzioni solo nell’ambiente di demo”.
- Log osservabili: Le operazioni chiave sono registrate nei log di audit, così in caso di controversia è possibile risalire chi ha modificato cosa.
Se il progetto include agenti intelligenti o un motore di regole, la verifica finale dovrebbe essere arricchita daMeccanismo di campionamento casuale: Inserire casualmente casi limite per verificare se il rifiuto di risposta, l’escalation all’assistenza umana e il blocco delle autorizzazioni sono conformi alla progettazione, anziché limitarsi a verificare solo la funzionalità di “poter chattare”.
Tre tipi di controversie comuni e le relative misure di prevenzione
Controversia n. 1: «Sono state implementate tutte le funzionalità, perché i dipartimenti aziendali non le utilizzano?»——Prevenzione: i traguardi sono collegati alle operazioni di ruolo e alla registrazione della formazione; durante la verifica, si effettuano sopralluoghi in loco, non ci si limita a presentare solo la presentazione PowerPoint.
Controversia n. 2: «Perché bisogna pagare di più per aggiungere una piccola richiesta?»——Prevenzione: nella modifica del progetto vanno chiaramente indicati i traguardi, gli script e la durata dell’attività interessati; lo sviluppo può procedere solo dopo la firma di entrambe le parti.
Controversia n. 3: «L’IA ha aumentato l’efficienza, è possibile ridurre il numero di persone?»——Prevenzione: il contratto distingue tra “costi di realizzazione” e “complessità operativa”; i benefici in termini di efficienza possono essere riflessi nel prezzo totale o nella durata, ma i criteri di accettazione non vengono abbassati.
Proposta pilota: iniziare con un modulo a ciclo chiuso
Non è necessario attendere la riscrittura completa del sistema dei contratti. Scegli uno2–3 settimane per chiudere il ciclodei moduli (come l’entrata e l’uscita dal magazzino, la registrazione del lavoro tramite ticket, l’approvazione delle spese), utilizzando il nuovo modello per firmare gli accordi integrativi: elencare i casi d’uso, gli scenari, le eccezioni e i passaggi di pagamento. Dopo aver verificato il corretto funzionamento, procedere con la diffusione a tutti i progetti. Per valutare il successo, si guarda aIl modulo di modifica riduce il tempo perso in discussioni?、Il tasso di successo della prima prova UAT è aumentato?, piuttosto che guardare quanti giorni lavorativi in meno ha dichiarato la parte B. Se il modulo pilota viene scelto bene, solo allora la modifica del contratto per l’intero progetto avrà credibilità.
L’uomo non scompare da un giorno all’altro, ma sta passando dall’essere “l’unità di misura unica per la determinazione del prezzo” a diventare “un riferimento per la stima dei costi”. Inserire le milestone e gli script di accettazione nel contratto è la competenza fondamentale che consente ai software personalizzati di continuare a fornire risultati affidabili nel contesto di “intelligenza artificiale + software”.
In collaborazione con il prezzo fisso e l’iterazione agile
La verifica dei traguardi non esclude l’agilità: ogni Sprint può comunque consegnare un incremento dimostrabile, maPagamento e accettazione ufficialeCollegato a una pietra miliare più ampia. Nei contratti a prezzo fisso è particolarmente importante specificare chiaramente il “punto di congelamento del perimetro”: dopo quale revisione le nuove esigenze vanno gestite tramite ordini di modifica, così da evitare aggiunte di funzionalità fatte solo a parole. Per i moduli che includono agenti intelligenti, si consiglia di prevedere una verifica a sé stante alla pietra miliare, basata su “versione delle regole + tasso di passaggio dei controlli a campione”, evitando di legarla in modo rigido all’intera messa in produzione del sito.
I dati del settore indicano che circa il … dei progetti software fallisceUn terzoDeriva da una scarsa chiarezza nelle specifiche e nei criteri di accettazione, piuttosto che dalla realizzazione tecnica in sé. Iniziare col mettere per iscritto nel contratto “cosa significa ‘completato’” è più utile che discutere su quanti programmatori siano stati sostituiti dall’IA. Alla prossima revisione della proposta di progetto, si potrebbe innanzitutto chiedere: se domani tutto il team del fornitore fosse in ferie, riusciremmo a stabilire, sulla base di uno script, se l’attuale milestone sia stata raggiunta? Se non si sa rispondere, vuol dire che i criteri di accettazione non sono ancora stati definiti con chiarezza. Inserire le milestone nel contratto non serve a rendere difficile la vita al fornitore, ma a far sì che entrambe le parti discutano sulla stessa pagina riguardo al fatto che “il lavoro sia davvero finito o meno”. Questo aspetto è ancor più importante nei progetti in cui l’efficienza dell’IA è evidente: va chiarito sin dall’inizio.