„È solo un attimo”
Chiunque lavori alla creazione o manutenzione di un sito web, app o sistema conosce questo messaggio.
„Potete solo cambiare quel pulsante?”
„È davvero una piccola correzione.”
„Per favore, spostate solo quell'elemento.”
„Si può fare in fretta?”
„Sarà cinque minuti di lavoro, giusto?”
E a volte lo è davvero.
A volte cambiare il colore di un pulsante richiede pochi minuti. A volte correggere un refuso richiede un solo clic. A volte lo sviluppatore apre il codice, guarda, cambia una riga e il gioco è fatto.
Il problema è che non tutte le modifiche che appaiono piccole all'utente sono piccole dal punto di vista del sistema.
E il problema diventa ancora più grande quando queste "piccole modifiche" sono dieci, cinquanta o centinaia al mese. Allora inizia ad accadere qualcosa di interessante.
L'azienda può avere l'impressione di non ordinare nulla di rilevante. E allo stesso tempo il team IT trascorre una parte significativa del tempo proprio su queste piccole attività.
E qui sorge la domanda: Quanto costa davvero un pulsante "Correggetelo in fretta"?
Partiamo da un esempio semplice
Immaginiamo che il reparto marketing invii al software house il messaggio:
„Ehi, dobbiamo solo cambiare il testo sul pulsante. Invece di „Controlla l'offerta” dovrebbe essere „Scopri l'offerta”. È una cosa piccola, per favore fatelo in fretta.”
Sembra banale. Ma dal punto di vista del team tecnico può sembrare completamente diverso.
Lo sviluppatore deve:
1. Analizzare la richiesta
Dove si trova quel pulsante?
È presente in un unico punto?
Compare in diverse versioni della pagina?
Il testo è inserito direttamente nel codice?
È gestito dal CMS?
La modifica riguarda le versioni desktop e mobile?
Il pulsante fa parte di un componente riutilizzato altrove?
2. Introdurre la modifica
Cambiare il testo.
Rifattorizzare il componente.
Aggiornare il contenuto nel CMS.
Oppure modificare il codice.
3. Verificare l'effetto
Il pulsante appare ancora corretto?
Il testo non esce dai suoi limiti?
Su mobile tutto funziona?
La modifica non ha impatto su altre parti?
4. Testare
Si può cliccare?
Il link porta dove deve?
Non è comparso un errore?
5. Deployare la modifica
Se la modifica richiede un deploy, va pubblicata in produzione.
E all'improvviso risulta che: „Solo cambiare il testo”
non equivale necessariamente a: „Solo 5 minuti di lavoro”.
Quanto può costare una singola piccola modifica?
Prendiamo uno scenario molto conservativo.
Lo sviluppatore dedica:
- 15 minuti per l'analisi,
- 20 minuti per l'implementazione,
- 15 minuti per i test,
- 10 minuti per la preparazione e il deployment.
Totale: 60 minuti di lavoro.
E qui arriviamo a un punto importante. Se la tariffa oraria del team è ad esempio 200 zł netti, una modifica apparentemente piccola costa circa: 200 zł netti.
Ma non è tutto. Nel processo reale possono comparire:
- passaggi di consegna del task,
- definizioni più precise del scope,
- domande al cliente,
- attesa di risposte,
- verifica dell'effetto da parte del richiedente,
- correzione dopo feedback,
- nuovo deploy.
Un'ora può facilmente raddoppiare. E una singola piccola modifica può trasformarsi in qualche ora di lavoro dell'intero team.
La parte più costosa non è l'esecuzione
Questo può apparire paradossale. A volte l'esecuzione impiega 10 minuti. Ma la preparazione richiede altri 20. Poi arrivano i test, il deploy, la comunicazione e il cambio di contesto.
Ed è proprio quest'ultimo elemento spesso sottovalutato.
Context switching - il costo nascosto dei piccoli task
Lo sviluppatore sta lavorando su una grande funzionalità. Ha il codice aperto. Sta analizzando il problema. È concentrato.
All'improvviso arriva un messaggio: „Ehi, solo una cosa piccola. Puoi correggere il pulsante?”
Lo sviluppatore interrompe il lavoro. Apre la segnalazione. Controlla la pagina. Cerca il punto nel codice. Introduce la modifica. Testa. Deploya. Torna al compito precedente...
E allora deve ricordarsi: „Ma su cosa stavo lavorando?”
Questo è proprio il context switching, lo spostamento di contesto. E può essere molto costoso. Non perché ogni singola modifica richieda tanto lavoro, ma perché ogni interruzione frantuma il flusso mentale.
Più è complesso il task originale, maggiore è il costo per riprendere il lavoro. Quindi 10 micro-task non sono sempre 10 × 10 minuti. In pratica possono significare molto di più.
Un pulsante è niente. Cento pulsanti diventano un processo.
Supponiamo che l'azienda invii al team tecnico:
- 20 piccole modifiche al mese,
- ognuna richiede in media 45 minuti.
Questo fa: 15 ore di lavoro al mese.
A tariffa di 200 zł netti: 3000 zł netti al mese.
All'anno: 36.000 zł netti.
E stiamo parlando solo di 20 piccoli task al mese. Senza funzionalità grandi. Senza sviluppo di prodotto. Senza nuovi moduli. Senza integrazioni. Senza progettazione.
Solo: „cambiate”, „correggete”, „spostate”, „aggiungete”, „rimuovete”.
Ora immaginate un'organizzazione in cui questi task sono 50 al mese. O 100.
La scala comincia ad apparire completamente diversa...
I micro-task hanno un altro costo: bloccano lo sviluppo
Questo è uno degli elementi più importanti del puzzle.
Se il team di sviluppo spende il 20% del tempo in piccole correzioni, non può dedicare quel 20% allo sviluppo del prodotto. Sembra ovvio. Ma nella pratica spesso non si vede.
L'azienda chiede: „Perché la nuova funzionalità non è pronta?”
Lo sviluppatore risponde: „Perché avevamo tanti temi correnti.”
„Che temi?”
„Correzioni, piccole modifiche, aggiornamenti, task minori.”
Ognuno di questi era piccolo. Ma insieme hanno creato un grande blocco di lavoro. È un po' come le notifiche sul telefono. Una notifica non disturba. Dieci già un po'. Cento? Improvvisamente si scopre che hai passato la giornata a reagire.
Con i micro-task accade la stessa cosa.
"Piccolo task" non è sempre un task piccolo
Vale anche capire che non tutte le modifiche sono uguali. Cambiare un testo nel CMS può davvero richiedere pochi minuti.
Ma cambiare un testo in un'app può richiedere:
- trovare il componente,
- modificare il codice,
- aggiornare le traduzioni,
- test,
- ricompilare l'app,
- deploy.
Cambiare un campo può richiedere modifiche a:
- front-end,
- back-end,
- database,
- API.
Una modifica a un singolo elemento del sistema può influenzarne altri.
Perciò la domanda: „Quanto ci vorrà per cambiare questo pulsante?” senza conoscere l'architettura del sistema spesso non ha una risposta sensata.
Prima bisogna controllare. Solo dopo si può stimare.
Perché lo sviluppatore a volte dice: „Devo controllare”?
Non è per evitare una risposta. Spesso è segno di professionalità.
Un buon sviluppatore non dovrebbe promettere: „Sì, certo, cinque minuti.”
se non sa cosa c'è sotto il cofano.
Dovrebbe dire: „Controllo dove viene usato questo elemento e ti faccio sapere.”
Questo può richiedere 10 minuti. Ma quei 10 minuti possono risparmiare ore di problemi. Perché la modifica più costosa spesso non è quella che richiede un'ora.
La più costosa è quella che:
- rompe un'altra funzionalità,
- genera un errore in produzione,
- richiede un rollback urgente,
- genera ulteriori segnalazioni,
- richiede l'intervento di più persone.
Per questo l'analisi prima della modifica è parte del lavoro, non una perdita di tempo.
Come il cliente può ridurre i costi dei micro-task?
Non si tratta di smettere di segnalare piccole modifiche. Le piccole modifiche sono una parte normale dello sviluppo di un prodotto. Si tratta di gestirle meglio.
1. Raggruppa le piccole richieste
Invece di inviare:
„Cambiate il pulsante.”
„Poi correggete il titolo.”
„E per favore aggiungete questo link.”
„E spostate anche quell'elemento.”
Meglio raccoglierle in un unico pacchetto.
Il team può allora eseguire più modifiche in un unico ciclo di lavoro.
Meno cambi di contesto.
Meno comunicazione.
Meno deploy.
Costi inferiori.
2. Stabilisci le priorità
Non tutto è urgente.
Se tutto ha lo status:
URGENT
allora nulla lo è davvero.
Vale la pena dividere i task in:
- critici,
- importanti,
- programmati,
- cosmetici.
Così il team può lavorare più efficacemente.
3. Valuta se serve una modifica al codice
Se l'azienda cambia regolarmente:
- testi,
- immagini,
- banner,
- link,
- messaggi,
forse il problema non è la velocità dello sviluppatore.
Potrebbe essere l'architettura.
Se ogni cambiamento di contenuto richiede uno sviluppatore, vale la pena considerare un CMS o un pannello amministrativo.
Un sistema ben progettato dovrebbe permettere al business di gestire autonomamente ciò che non richiede l'intervento di uno sviluppatore.
Un buon sistema dovrebbe rispondere alla domanda: chi dovrebbe fare questa modifica?
È una regola di progettazione importante. Non ogni modifica dovrebbe andare allo sviluppatore.
Se il marketing può autonomamente:
- cambiare testi,
- sostituire immagini,
- aggiungere articoli,
- cambiare l'ordine delle sezioni,
non ha senso coinvolgere lo sviluppatore.
Lo sviluppatore dovrebbe occuparsi di ciò che richiede la sua competenza.
Ad esempio:
- creare nuove funzionalità,
- sviluppare il sistema,
- integrazioni,
- ottimizzazione,
- sicurezza,
- architettura,
- risolvere problemi tecnici.
Altrimenti l'azienda paga lo sviluppatore per un lavoro che potrebbe fare l'utente del sistema.
È un po' come assumere un meccanico per fare il rifornimento: sa farlo, ma davvero ne abbiamo bisogno?
Quando conviene dire: „Facciamolo diversamente”?
Se la stessa richiesta ricorre regolarmente, vale la pena fermarsi e chiedersi:
Perché dobbiamo farlo manualmente ogni volta?
Se ogni settimana chiediamo di cambiare lo stesso elemento, forse dovremmo creare:
- un'impostazione nel CMS,
- una configurazione,
- un pannello amministrativo,
- un'automazione,
- un meccanismo self-service.
Il costo una tantum per creare questa soluzione può essere più alto. Ma successivamente ogni modifica può richiedere pochi secondi invece che ore.
Questa è la differenza tra: pagare per ogni modifica e investire in un sistema che permette di fare le modifiche autonomamente.
Micro-task e modelli di collaborazione con il software house
È un tema importante anche per i clienti.
Se la collaborazione si basa solo sul modello: „segnaliamo - voi preventivate - accettiamo - eseguite”, ogni piccola modifica può generare overhead organizzativo aggiuntivo.
Per questo con rapporti continuativi funzionano spesso meglio:
- pacchetti orari,
- abbonamenti di manutenzione,
- team dedicati,
- backlog di attività,
- sprint regolari,
- finestre di deploy stabilite.
Non significa che ogni cliente debba scegliere lo stesso modello. Si tratta di adattare il modo di collaborazione alla natura del progetto.
Se l'azienda ha bisogno di una modifica al mese, processi complessi possono essere inutili. Se invece invia 50 task al mese, l'assenza di un processo può risultare costosa.
Ogni modifica va conteggiata?
Dipende.
In alcuni progetti conteggiare ogni minuto ha senso. In altri può generare più amministrazione che risparmi.
Perciò è utile guardare alla collaborazione più in generale.
La domanda più importante non è: „Quanto è costata questa singola modifica?”
Domanda migliore: „Quanto ci costa il modo in cui gestiamo tutte le modifiche?”
Se l'azienda paga 200 zł per una modifica ma così evita errori e ha la certezza che tutto funziona correttamente, può essere un costo sensato.
Se invece ogni mese paga migliaia di zł per decine di micro-task simili, vale la pena chiedersi se il problema non può essere risolto a livello sistemico.
Le parole più costose in IT?
Forse sono: „È solo una piccola modifica.”
Non perché le piccole modifiche siano cattive. Sono necessarie.
Un prodotto digitale vive. Cambiano i bisogni dei clienti. Cambiano il mercato. Cambia il marketing. Cambia la tecnologia. Le modifiche sono naturali.
Il problema nasce quando l'organizzazione non vede il costo cumulativo.
Una piccola modifica? - Niente di che.
Dieci? - Ancora poco.
Cento? - Diventa un processo.
E se ci sono più processi del genere? Improvvisamente si scopre che l'azienda non spende soldi per lo sviluppo del prodotto. Li spende per correggere continuamente dettagli.
Invece di contare i pulsanti, contiamo il tempo
Un buon sviluppo di prodotto digitale non consiste nel vietare al cliente di segnalare piccole modifiche.
Consiste nel sapere:
- quali modifiche richiedono davvero uno sviluppatore,
- quali si possono fare autonomamente,
- quali vale la pena automatizzare,
- quali raggruppare,
- quali sono veramente urgenti,
- quali si possono pianificare,
- quali conviene risolvere sistemicamente.
Perché a volte la migliore risposta a: „Correggetelo in fretta.”
non è: „Va bene, lo facciamo.”
ma: „Chiediamoci perché tra un mese dovremo di nuovo correggerlo.”
È qui che il software house smette di essere solo un esecutore e diventa un partner tecnologico. Un buon partner non solo esegue le segnalazioni.
Aiuta anche a vedere che a volte la modifica più economica non è quella che eseguiamo più velocemente. La più economica è quella che non dovremo eseguire per la centesima volta.
Ed è per questo che un pulsante "Correggetelo in fretta" può costare un'ora.
Ma un sistema ben progettato può far sì che le prossime cento modifiche simili le esegui tu stesso in pochi minuti.
Non è un risparmio sugli sviluppatori. È un investimento in un processo migliore, un'architettura migliore e un uso più intelligente del tempo dell'intero team.
