Vai al contenuto

Tempi di consegna certi

Per noi una data di consegna non è un auspicio, ma una clausola contrattuale inviolabile

Rifiutiamo la cultura dell'incertezza del settore software.

Quando la data di consegna promessa da un'agenzia al proprio cliente vacilla, è il colpo più duro alla reputazione dell'agenzia. La malattia cronica secolare del settore software, i «rinvii continui», per noi non è un destino da accettare: è il nome di una guerra in cui abbiamo apertamente scelto da che parte stare. Il calendario che le diamo quando lavora con Partnerfy non è una «stima indicativa». Dietro ci sono calcoli matematici, un'analisi del rischio riga per riga (Buffer Time), un piano di team di riserva su due livelli e una chiara clausola di risarcimento scritta nel contratto. Non una stima, ma un impegno. Il resto di questa pagina spiega, punto per punto, come possiamo parlare con tanta sicurezza. Se in passato ha vissuto la delusione di una data di consegna non rispettata, qui non la incontrerà più.

L'«incertezza» è un silenzio che il settore software ha accettato

Ci pensi un momento: quanti responsabili di agenzie digitali, il giorno di consegna di un progetto software, hanno dovuto mandare giù la frase «in realtà ci sarà una settimana di ritardo, ma sono cose che capitano»? Questa frase si è normalizzata a tal punto nel settore che persino i clienti hanno iniziato ad aspettarsela. Aspettare è diventato un'abitudine, l'abitudine è diventata una cultura. Il principio di lavoro di Partnerfy inizia nel punto in cui rifiutiamo questa cultura. Quando è in gioco una data di consegna, l'unica ancora di salvezza che abbiamo è la data «matematicamente convalidata». Non comunichiamo una data senza un calcolo matematico e, una volta comunicata, non la cambiamo senza un altro calcolo matematico. La «flessibilità» del settore arretra di fronte alla nostra «disciplina».
L'«incertezza» è un silenzio che il settore software ha accettato

Una data di consegna passa da tre fasi

Dare una data immaginaria è questione di un'ora. Dare una data matematicamente convalidata è un processo di ingegneria in tre fasi.

1. Analisi e calcolo del buffer

Fin dall'inizio elenchiamo i requisiti tecnici del progetto, lo stato del sistema esistente e le dipendenze esterne (API di terze parti, approvazioni degli store, normative). Il rischio di ogni voce viene moltiplicato per la sua probabilità e al risultato si aggiunge un margine di riserva (Buffer Time). Può fidarsi della data che le comunichiamo, perché a quel punto è una data «matematica».

2. Gestione degli sprint

Dividiamo il progetto in sprint di 2 settimane, ognuno con un risultato visibile alla fine. Se emerge uno scostamento, il punto di controllo non scatta all'inizio dello sprint successivo, ma nello stesso giorno, durante lo sprint in corso. Intercettare presto salva il calendario.

3. QA finale e consegna

Appena termina l'ultimo sprint, il codice passa da un controllo qualità in 100 punti. Azzerato il margine di errore, il progetto viene consegnato nel giorno e nell'ora garantiti. Non alle 23:59: consegniamo all'inizio della giornata lavorativa.

Dare una data è prima di tutto una questione di matematica

Dare una data è prima di tutto una questione di matematica

Calcolare matematicamente una data di consegna significa mettere in fila tre elementi: (1) l'ambito del progetto, convertito in un numero concreto di story point o function point; (2) le prestazioni passate del team (velocity), misurate con i dati su quanto lavoro viene completato in media per sprint; (3) il Buffer Time assegnato alle aree di incertezza, in genere tra il 15% e il 25% del calendario totale, che viene aggiunto al resto. Quando questi tre numeri si incontrano, la data che otteniamo non è «possiamo farlo», ma «matematicamente lo faremo». Due senior engineer diversi che guardano lo stesso progetto danno la stessa data o una molto vicina, perché il calcolo è aperto a tutti ed è identico per tutti.

I numeri sono la sintesi più laconica degli impegni presi. Le metriche raccolte nei progetti passati dimostrano sul campo la nostra disciplina sui tempi.

97%
Consegna puntuale
Negli ultimi 24 mesi
0
Numero di scuse
Penale sempre pagata
8 anni
Stessa disciplina
Mai cambiata

Nel nostro mondo «non ce l'abbiamo fatta» non è una risposta, è una confessione

La penale prevista dal contratto non è un deterrente, ma una regola automatica.

Quando si firma un contratto non si mettono per iscritto solo le intenzioni delle parti, ma anche il prezzo da pagare se quelle intenzioni non si realizzano. Nel contratto Partnerfy la clausola «Penale per ritardo» per noi non è un deterrente: è una regola economica che scatta automaticamente se non rispettiamo i tempi. «Non ce l'abbiamo fatta», «ci è sfuggito», «è sorto un problema imprevisto», «l'API di terze parti non ha risposto», «un collega si è ammalato»: nel nostro mondo nessuna di queste frasi è una scusa accettabile. Sono tutte voci di rischio che dovevano già essere calcolate matematicamente al momento di definire il calendario. Che un rischio si verifichi non è una sorpresa; che non lo avessimo previsto è, dal punto di vista contrattuale, un errore nostro. Se si verifica un ritardo, preferiamo pagarne noi il prezzo piuttosto che far perdere reputazione alla sua agenzia davanti al cliente. Questa preferenza non è una clausola contrattuale: per noi è un principio irrinunciabile.

Tre misure che tolgono al rischio l'effetto sorpresa

Un rischio non calcolato matematicamente si trasforma in una sorpresa nel momento in cui si verifica. Le tre misure seguenti ci impediscono di lasciare fuori dai calcoli qualsiasi rischio.

Buffer Time

Ogni calendario viene calcolato riservando un margine aggiuntivo alle aree di incertezza oltre l'ambito definito. In un progetto tipico, tra il 15% e il 25% del calendario complessivo è destinato al Buffer. Questa riserva trasforma gli imprevisti in eventi matematicamente previsti.

Piano con team di riserva

Dietro ogni ruolo critico c'è uno specialista di riserva. Se un ingegnere backend si ammala, il calendario non vacilla: lo stesso giorno subentra un'altra persona. Per noi un progetto che dipende da una sola persona non è fail-safe.

Registro dei rischi e moltiplicatore di probabilità

All'avvio del progetto elenchiamo tutti i rischi noti (approvazioni di API di terze parti, rifiuti degli store, modifiche normative, stanchezza del team) e assegniamo a ciascuno un moltiplicatore di probabilità e di impatto. Il registro non è statico: viene rimisurato nelle retrospettive di fine sprint. Un rischio che si concretizza non è una sorpresa, è ordinaria amministrazione.

La clausola «Penale per ritardo» nel nostro contratto: una regola che scatta da sola

Se non rispettiamo la data promessa — nonostante il Buffer Time, nonostante il team di riserva, nonostante i punti di controllo degli sprint — la penale prevista dal contratto scatta automaticamente. La clausola è numerica, si calcola con una formula stabilita in anticipo e cresce moltiplicandosi con il passare dei giorni. Funziona così: un ritardo nella prima settimana equivale al 10% del valore del contratto. Nella seconda settimana la penale sale al 20%, nella terza al 35%. Se il ritardo prosegue oltre la fine della quarta settimana, viene rimborsato l'intero valore del contratto, più la parte del danno subito dalla sua agenzia nei confronti del cliente che ricade su di noi. Questa clausola non è uno spauracchio: è la prova esterna della nostra disciplina sui tempi. Un'azienda tecnologica che accetta di lavorare con una clausola così severa è costretta a essere matematica quando calcola una data. A noi la severità, a Lei la tranquillità.
La clausola «Penale per ritardo» nel nostro contratto: una regola che scatta da sola

Una data di consegna non è una promessa del cuore, è un numero firmato

Un impegno vincolato dal calcolo, non dalla convinzione.

In questi anni abbiamo visto una cosa: nel settore del software non mancano le buone intenzioni, manca la disciplina. Quando uno sviluppatore dice «finirò questo progetto in 6 settimane», spesso lo crede davvero. Ma una data non si regge sulla convinzione, si regge sul calcolo. Per questo in Partnerfy il calendario nasce, all'avvio del progetto, non dalle intenzioni di un ingegnere senior ma dal risultato di una formula. Quella formula mette insieme la velocity storica del team, il numero concreto che esprime l'ambito, i rischi aperti e il Buffer. Il numero che ne risulta lo scriviamo nel contratto. Per Lei cambia una sola cosa: la frase «speriamo di farcela» non si sente più, né da noi né da Lei verso il suo cliente. Perché «ce la faremo o no» non è più una questione di speranza, ma di matematica. E quella l'abbiamo già risolta noi.

Ci contatti per un calendario matematico

Compili il modulo qui sotto: in un breve incontro preliminare comprenderemo l'ambito e i rischi del suo progetto. Al termine dell'incontro avrà in mano una data di consegna calcolata matematicamente. Può contattarci anche direttamente al numero 0850 259 30 04.

Per qualsiasi domanda può contattarci in ogni momento: [email protected]

Abbiamo ricevuto la sua candidatura!

Esamineremo la sua candidatura partner e la ricontatteremo al numero al più presto.

—

Che tipo di azienda ha?

In quali ambiti ha bisogno di supporto?

500
1 1.000

Numero stimato di clienti da acquisire ogni mese (1 – 1.000)

Bölüm Tipi Seç

Eklemek istediğiniz bölüm tipini seçin

Eklendikten sonra Filament admin'den içeriği düzenleyebilirsiniz.

risultati