Nei contratti tradizionali applicati al software development si rischia che tra il fornitore e il cliente non avvenga uno scambio di valore equo: i contratti Agile cambiano le carte in gioco.
Qualche mese fa in questo articolo ti parlavo di come vengono realizzate le app che utilizzi tutti i giorni. In esso ti elencavo anche alcuni metodi di sviluppo software che ormai vengono considerati pressoché obsoleti, spiegandoti poi in linea generale come funziona la metodologia Agile, quella che utilizziamo a DevInterface. Quest’ultima, in confronto alle altre, nasce da una mentalità tutta nuova e volta ad apportare valore alle persone, grazie anche ad un rapporto di completa fiducia tra fornitore e cliente.
Il nuovo modo di lavorare ha portato con sé alcune necessità che non riguardano soltanto la diversa organizzazione delle mansioni, ma anche lo strumento chiave che regola i rapporti tra fornitore e cliente: il contratto.
Nei contratti tradizionali, prezzi e tempi per la realizzazione di un’applicazione venivano definiti a priori, e ciò comportava diversi svantaggi per entrambe le parti coinvolte: da parte degli sviluppatori poteva capitare che una certa funzione richiedesse più tempo del previsto per essere implementata (venivano quindi pagati per 10 ore di lavoro quando invece ne impiegavano 20); inoltre il rischio verteva solamente sul fornitore poiché il cliente pagava soltanto ad applicazione ultimata e talvolta unicamente se essa soddisfaceva ciò che avevano concordato molti mesi prima. Purtroppo in tal modo era facile perdere di vista ciò che il cliente voleva veramente perché le interazioni e i confronti erano molto pochi, perciò si venivano a creare situazioni del seguente tipo:
- win-lose: win per il cliente a cui veniva rilasciato un software con le caratteristiche desiderate, ma lose per lo sviluppatore che aveva lavorato il doppio del previsto guadagnando la somma pattuita inizialmente;
- lose-win: lose per il cliente che si ritrovava con un software per lui inutile ma era costretto comunque a pagare, win per il fornitore che riceveva la sua parcella senza però aver costruito alcun valore;
- lose-lose: software scadente per il cliente che non pagava e produttore che aveva lavorato gratis per mesi.
Ciò non va per nulla d’accordo con l’Agile development, perciò si è dovuto ideare una modalità contrattualistica alternativa, in linea con l’obiettivo di costruire valore per le persone: una situazione win-win, dove sia fornitore sia cliente traggono il maggior vantaggio in un clima di completa collaborazione, fiducia reciproca e quindi scambio di valore.
In che modo?
Mentre il contratto tradizionale era visto come una maniera per tutelarsi da eventuali inadempimenti della parte opposta, il contratto Agile è uno strumento che permette alle parti di venirsi incontro reciprocamente, in base alle necessità di ognuna. Lo sviluppatore ha bisogno innanzitutto di capire in profondità gli obiettivi del cliente per consegnargli un’applicazione in linea con essi; inoltre deve avere il tempo per costruire questa app. A sua volta il cliente ha bisogno di “toccare con mano” il prodotto per mantenere alta la fiducia riposta nello sviluppatore e ovviamente per capire se quest’ultimo sta seguendo la giusta strada. Come abbiamo detto in diversi articoli, l’Agile software development è caratterizzato da sessioni di lavoro più o meno lunghe (gli sprint), seguite da rilasci di porzioni di software funzionanti, e interazioni periodiche con il cliente che può dare il suo feedback sul lavoro in corso d’opera. Lo sviluppatore ha così la possibilità di capire in profondità la volontà del cliente ed esso a sua volta può capire come sta procedendo lo sviluppo dell’app.
In sostituzione al contratto tradizionale dove si pattuiscono all’inizio scadenze e prezzi, abbiamo un contratto Agile dove il cliente paga ogni porzione di software funzionante al termine di ogni sprint. In questo modo i rischi precedentemente illustrati vengono minimizzati, perché:
- è difficile che lo sviluppatore non riesca a rispettare le scadenze, poiché avendo delle finestre temporali ristrette gli risulterà più facile calcolare il tempo che impiegherà a svolgere una determinata mansione;
- se il cliente vede che lo sviluppo non sta andando come desiderava lo può comunicare allo sviluppatore che potrà agevolmente sistemare i problemi riscontrati;
- nel caso in cui il cliente non paghi, il fornitore perderà soltanto il denaro pattuito per uno sprint, diminuendo in modo esponenziale il rischio; in questo modo il cliente sarà anche più stimolato a corrispondere la somma poiché altrimenti lo sviluppo del software in questione non proseguirebbe.
Questo approccio aiuta quindi a limitare gli inadempimenti delle parti coinvolte nel contratto e, in caso essi abbiano luogo, a ridurre al minimo i rischi per entrambe, incentivando invece la fiducia reciproca.
Cosa ne pensi di questa modalità contrattuale? Credi che ci siano modi migliori per negoziare un accordo in ambito di sviluppo software? Faccelo sapere nei commenti!
Grazie per aver letto l’articolo.
Per maggiori informazioni contattaci qui oppure su Facebook o Twitter, dove potrai anche seguirci per rimanere aggiornato sui nostri articoli.
.jpg)
