A volte quando parlo di agilità mi rendo conto di inviare un numero eccessivo di messaggi, lasciando che il messaggio principale si perda tra tutti gli altri: la riduzione dei costi per il committente e quindi una maggiore competività per il fornitore! Ecco riassunto questo aspetto in sei punti fondamentali:
- Possibilità di stabilire un tetto di spese limitato perché negoziato frequentemente e monitorato su base costante.
- Forte riduzione del rischio che il cliente si ritrovi in mano funzionalità che non utilizzerà MAI o molto raramente –> in questo modo risparmia un sacco di soldi, infatti è qui che si registrano gli sprechi più incredibili.
- Garanzia che il cliente spenderà soldi solo per ciò che realmente gli serve nel momento in cui viene rilasciato (non ciò che gli serviva sei mesi fa)!
- Il cliente non attende il termine del progetto (tipicamente quindi mooolto a lungo) per cominciare a vedere un ritorno dell’investimento fatto, ma ogni settimana è in grado di misurare il ritorno economico delle nuove funzionalità rilasciate!
- Possibilità per il cliente di decidere in ogni momento di far cambiare completamente rotta al progetto: se sono cambiate le condizioni “ambientali” rispetto al documento di analisi di un anno fa, perché continuare su quella strada?
- Con un approccio agile, i diritti del committente diventano questi!
Aggiungo inoltre che un team xp avendo trai i valori fondamentali quello del feedback verso il cliente, avrà un grado di trasparenza (ad esempio con report giornarlieri di quanto fatto inviati al cliente) maggiore rispetto alla media di altri team. Questo aspetto si lega al potere di controllare i team che il cliente assume, nonché ad un discorso di fiducia.
La domanda ora può essere: come trasferire su una proposta di gara questi punti? La mia idea (ma non è il mio mestiere, quindi mi aspetterei che chi si occupa di questo aspetto sappia sfruttare meglio di me questi punti forti) è di aggiungere nella proposta stessa la carta dei diritti del committente unita alla richiesta di una forte interazione tra team e cliente, di puntare sul fatto che il committente può recedere dal contratto più facilmente che con un approccio classico, di dividere il contratto in sottocontratti che impegnano il cliente per periodi di tempo limitati, che il cliente sarà in grado di monitorare il progetto, e non ultimo che verranno fortemente ridotti i costi di manutenzione.
Per garantire tutto questo è ovviamente necessario da parte del team che fornisce il servizio un’adeguata preparazione e soprattutto un forte spirito di team: tutte cose che non si possono improvvisare, ma che necessitano di supporto e volontà dai cerchi superiori, e di persone motivate e di qualità.
In questo interessante post viene riportata una definizione in pillole di agilità:
“Reduce the gap in time between doing some activity and gaining feedback.”
Questo come dici tu non può che tradursi anche in una riduzione di costi.
Per quanto riguarda le gare, queste possono essere fatte per progetto o per risorsa.
Le gare per i progetti chiavi in mano sottintendono un grosso fattore di rischio dovuto proprio all’impossibilità di comprendere la reale complessità del problema sulla base delle informazione fornite nel capitolato d’appalto.
Questo fattore di rischio viene ovviamente calcolato nell’offerta dal fornitore, per cui i vari concorrenti possono ribassare solo se dispongono di esperienza, tecnologie e metodi competitive.
Diversamente le gare per risorsa presentano bassissimi fattori di rischio per il fornitore, proprio perchè il lavoro che ne deriva è intrinsecamente agile, di conseguenza i margini di ribasso aumentano notevolmente.
Sintetizzando, due casi e tre attori:
Progetto chiavi in mano
– Fornitore: alto rischio d’impresa, grandi guadagni o grandi perdite
– Committente: risparmio risorse interne, alto rischio bassa qualità o utilità progetto
– Consulente: alto rischio utente poco collaborativo, pressione del fornitore per rispetto contratto.
Body rental
– Fornitore: basso rischio d’impresa, pochi guadagni o poche perdite
– Committente: risparmio risorse esterne, controllo su qualità e utilità progetto
– Consulente: basso rischio utente poco collaborativo, pressione dal committente per rispetto contratto.
In conclusione:
Un fornitore che vuole massimizzare i guadagni deve puntare su un progetto chiavi in mano, le probabilità di successo aumentano se riesce ad applicare un approccio agile.
Un committente che vuole controllare la qualità e l’utilità di un progetto deve assumersi la responsabilità di progetto, le probabilità di successo aumentano se riesce ad applicare un approccio agile.
Un consulente che non vuole essere schiacciato tra committente e fornitore deve stimolare la collaborazione degli utenti, le probabilità di successo aumentano se riesce ad applicare un approccio agile.
Sicuramente la mia analisi è superficiale, però potrebbe essere un punto di partenza per una discussione più approfondita.
Commento di Tom — 7 Luglio, 2006 @ 5:58 pm
Bel post davvero. Il primo paragrafo è sacrosanto.
I punti successivi potrebbero essere rifattorizzati un po’ per eliminare la duplicazione e diventare un semplice documento per “vendere” le metodologie agili. Mi piacerebbe scrivere un documento così, ma in meno di tre pagine è difficile essere convincenti, e in più di tre pagine è difficile essere letti.
Però c’è un problema, ed è quello del target. A chi stai parlando? Il tuo elenco di punti sembra strettamente rivolto al cliente. Di solito quando cerco di convincere qualcuno a diventare agile, questo non è il cliente, ma il fornitore (ad esempio un project manager). In un mondo perfetto, i desideri del fornitore sarebbero sempre allineati a quelli del cliente. Nel nostro, invece, succedono cose come questa:
Tu: “Possibilità per il cliente di decidere in ogni momento di far cambiare completamente rotta al progetto!”
Il tuo capo: “E chi se ne frega? Io non voglio che il cliente possa cambiare rotta quando vuole. Voglio che si impegni, firmi un documento che garantisce tutti dal punto di vista legale e poi si prenda quello che produciamo, conforme a quanto è scritto nel documento. Se no ci mettono nelle condizioni di dover soddisfare ogni loro buffo desiderio, e noi siamo i loro umili schiavi, e se non ci va bene mollano il progetto da un giorno all’altro e perdiamo la commissione”.
Oppure (dialogo che ho avuto davvero circa un mese fa):
Io: “Possibilità di stabilire un tetto di spese limitato perché negoziato frequentemente e monitorato su base costante!”
Lui (proprietario di azienda di software che sviluppa per il settore pubblico): “Non so di cosa tu stia parlando. A me serve sapere subito quanto spenderò per tutto il progetto, niente escluso. Devo scrivere quella cifra su un foglio e competere con altri concorrenti che faranno i loro prezzi, e non posso competere se non so quanto devo chiedere”.
Quindi, se sto parlando direttamente con il cliente la tua bulleted list mi sembra un ottimo punto di partenza. Dovendo parlare con un fornitore, credo che i punti da sottolineare siano altri. Quali?
Boh. Ci penso…
Commento di Paolo "Nusco" Perrotta — 9 Luglio, 2006 @ 8:59 pm
Tom, sicuramente ci sono spunti molto interessanti nella tua risposta…spero avremo il tempo per svilupparli qui.
Paolo, sono d’accordo con te che ci andrebbe un po’ di refactoring. Cercavo un pairer per farlo…
Il taglio del post è “verso il cliente” perché è stato “stimolato” dal mio boss che mi ha chiesto in che modo “concretamente” l’agilità dà qualcosa in più in termini di competitività, ed in che modo proporre quel di più.
Comunque il dialogo che riporti è davvero un template molto comune.
Penso che la diffusione dei metodi agili e di XP dipenda molto da quel dialogo.
Commento di Enri — 10 Luglio, 2006 @ 10:12 am
Pascal Van Cauwenberghe dice che a lui generalmente piace il contratto con scope, data e prezzo fissati. Con la esplicità possibilità, per il cliente, di sostituire un pezzo di funzionalità con un altro, purché il team di sviluppo lo reputi possibile e purché lo scope venga valutato (dal team) di pari difficoltà. In questi contratti il funzionamento del planning game viene esplicitato in legalese.
In questo modo si riducono i rischi per il committente. Ma è un vantaggio anche per il fornitore. Infatti se la funzionalità originariamente richiesta si scopre non essere quella giusta, in un progetto ordinario fornitore e cliente sono su posizioni contrapposte e diventa difficile arrivare a un win-win. Il vantaggio reciproco invece è uno dei principi di XP
Commento di Matteo — 10 Luglio, 2006 @ 11:52 am
Interessante perché in questo modo si possono comunque fare proposte “time and material” con costi fissi, anche se ovviamente non in senso classico, ma facendo leva sulla “sostituibilità” delle storie tipica di un processo xp. Ad ogni modo però mi chiedo come faccia Pascal a gestire il “continuous planning”, dal momento che mi pare di capire che prevede che solo il cliente possa chiedere una sostituzione di funzionalità. Non esiste per lui il concetto di raffinamento delle stime?
Tra l’altro il problema è che spesso, come dice Paolo, al cliente non interessa molto questo aspetto, vuoi per miopia, vuoi perché le gare spesso si fanno al ribasso dei costi o poco più. Per questo motivo nel post cercavo una soluzione che abbassasse i costi totali, ad esempio con un tetto di spese limitato. Magari vado a rileggermi i papers di Poppendieck.
Alla fine una delle domande fondamentali che mi sto ponendo è: esistono aziende in Italia che applicano XP e che riescono ad essere competitive in gare nelle quali il ribasso dei costi ha un ruolo fondamentale? Magari pongo la domanda in lista…
Commento di Enri — 10 Luglio, 2006 @ 12:36 pm
Questi post sono belli perchè stimolano commenti che portano a galla la realtà.
Ad esempio mi piacerebbe fare un commento estremo, provocatorio:
Se si potessero realmente conoscere i veri costi di un progetto prima di iniziarlo, quanti progetti non verrebbero neanche iniziati ?
Il Committente vuole massimizzare l’investimento.
Il Fornitore vuole massimizzare il guadagno.
Tipicamente la trattiva economica avviene una sola volta prima dell’inizio del progetto, poi è solo questione di rispetto del contratto ed è qui che il team entra in gioco, oserei dire a giochi fatti.
La trattativa economica consiste nel trovare il punto di equilibrio tra l’offerta del Fornitore e la richiesta del Committente.
Le metodologie agili non fanno altro che introdurre il concetto di approssimazioni successive per raggiungere iterativamente questo punto di equilibrio, portando al centro della trattativa il prodotto reale, basandosi sui feedback emersi durante le fasi di realizzazione.
Per dirla tutta poi tipicamente le metodologie agili parlano dello sviluppo, ma il costo totale di un progetto, il famoso TCO, è dato anche da moltissimi altri fattori. Ad esempio, un progetto può costare pochissimo in termini di sviluppo, ma costare poi tantissimo in termini di gestione.
Le metodologie agili penso che vengano viste con diffidenza proprio perchè portano a misurare in modo molto preciso costi e qualità del prodotto.
E qui mi verrebbe facile un paragone tra una borsa di plastica, una di Luis Pitton ed una di Luis Vitton, ma lascio perdere …
Commento di Tom — 10 Luglio, 2006 @ 1:04 pm
ciao a tutti,
da qualche tempo cerco di capire come si potrebbe “vendere” un progetto “agile”.
purtroppo noto – nel mio piccolo e da discussioni con altri simili – che alla fine i progetti vengano acquisiti “alla moda vecchia” con un uomo-marketing che stima a pancia un prezzo ed un tempo.
un team poi manovra “agilmente” nelle tenebre – negoziando le funzionalità non proprio essenziali per arrivare in tempo.
discussione infinita già emersa più volte anche in sede dell’xpug-milano, normalmente al risto-pizzaro cinese.
belli i valori/principi/pratiche, belli i diritti da una parte e dall’altra…
però forse i clienti non sono ancora “maturi” per acquisire un progetto “agilmente”.
fintanto che però i clienti non aderiscono ai valori in gioco (penso in particolare al “coraggio”) e continuano a “giocare per non perdere” non penso sia possibile trattare con loro nei termini esposti (più o meno quanto ribadito da tom)
in fondo, come scrive paolo parlando del cliente: “non mi interessa risparmiare dei soldi, dimmi quanto costa e firma qui sotto che io sono scagionato”. se poi viene usato o no, se serve o no non è un vero problema.
il discorso “ridurre i costi” tende quindi un po’ a cadere…
quindi forse esiste:
- il “cliente”
- il “cliente agile”
- il “cliente agile suo malgrado”
quindi cosa facciamo? aspettiamo che arrivino i “clienti agili”, cerchiamo di trasformarli in “clienti agili loro malgrado” oppure chiudiamo baracca?
non ho una soluzione, anche se escluderei la terza per ovvi motivi. (c:
personalmente passerei dall’inconsapevolezza (viva la comunicazione onesta) – per ottenere la sua fiducia – e poi proverei gradualmente a trasformarlo in “cliente agile”.
o forse suona troppo cinico?
un altro spunto, forse…
bella l’idea di mostrare che con metodi agili si possono ridurre i costi… ma come fa il cliente a valutare due team agili a confronto?
“noi costiamo meno”
“anche noi”
“noi ti diamo il feedback”
“anche noi”
“…”
solo per dire che magari i vantaggi di un team agile su di un altro potrebbero anche convincere un cliente a scegliere quel team anche se si trovasse “contro” un team classico, evitando le battaglie teoriche sulle metodologie (alle quali il cliente sembri essere poco interessato)
che dite?
ciao
simone
Commento di simone — 10 Luglio, 2006 @ 1:56 pm
Se si potessero realmente conoscere i veri costi di un progetto prima di iniziarlo, quanti progetti non verrebbero neanche iniziati ?
Ottimo appunto. Qui credo che l’agilità abbia molto da dire.
Il Committente vuole massimizzare l’investimento.
Il Fornitore vuole massimizzare il guadagno.
Quindi interessi contrastanti: “Io vinco se te perdi”. Ma questo è proprio degli approcci classici, non degli approcci Agili.
L’approccio Agile si pone invece come obiettivo principale quello del mutuo beneficio: “per vincere davvero dobbiamo vincere insieme!”: se io committente ti voglio solo spremere, alla fine avrò un prodotto che fa acqua da tutte le parti, e sarà ingestibile anche negli sviluppi futuri; se io fornitore decido di nascondere il reale andamento del progetto, tirare fumo negli occhi e rilasciare funzionalità di bassa qualità, il committente non vorrà più rinnovare la fiducia che ha posto in me.
Una delle armi principali per ottenere invece un approccio win-win è avere uno scope variabile, fissando invece in maniera rigorosa tempi, costi e qualità. In questo modo gli interessi sono allineati, citando Beck:
Customer: Interprets requirements as broadly as possible, to get as much for their money as possible.
Supplier: Happy to accept customer’s changing interpretation of the requirements
Customer: Wants the work done as quickly as possible.
Supplier: Wants to deliver on time. Happy to get through as much functionality as possible, without risk to quality.
Customer: Wants superlative quality.
Supplier: Wants quality before all else.
Customer: want programmers to want to come back for the next 2 months.
Supplier: Wants the team members to be successful on this project, and to stick around for the next one. If this is a year-long project, the supplier only has 1/6 of the money after the first contract.
Per dirla tutta poi tipicamente le metodologie agili parlano dello sviluppo, ma il costo totale di un progetto, il famoso TCO, è dato anche da moltissimi altri fattori.
Secondo me invece, le metodologie Agili vogliono minimizzare il costo totale: ad esempio pensa ai costi di manutenzione, o ai costi di piccole estensioni…
E qui mi verrebbe facile un paragone tra una borsa di plastica, una di Luis Pitton ed una di Luis Vitton, ma lascio perdere …
Sicuramente il discorso qualità percepita è importante, e secondo me una delle cartine tornasole di tale qualità è proprio l’abilitare ad una drastica diminuzione del costo del cambiamento: in due parole la qualità permette al cliente da un lato di saper reagire in modo pronto ai diversi scenari di business e dall’altro quindi porta ad un sapere sfruttare meglio le occasioni che gli si presentano, quindi ad aumentare i ricavi! Questo è l’obiettivo finale della qualità nell’Extreme Programming, non quello di produrre qualità fine a se stessa, ed è questo che dovremmo imparare a comunicare e che il cliente dovrebbe comprendere: qualità per minimizzare gli sprechi!
Commento di Enri — 10 Luglio, 2006 @ 2:23 pm
Mai come oggi dovremmo parlare di SQUADRA CHE VINCE
Secondo me invece, le metodologie Agili vogliono minimizzare il costo totale: ad esempio pensa ai costi di manutenzione, o ai costi di piccole estensioni…
Certo, quello che volevo enfatizzare è che i piccoli ralasci delle metodologie agili devono essere intesi veramente come rilasci tutto compreso.
Se il progetto X può essere suddiviso in 3 fasi A – B – C, con un approccio agile gli utenti cominceranno ad usare X non appena A è finito.
Durante l’utilizzo reale, non solo i test, della fase A si scopriranno i problemi di A e si potrà correggere il tiro per B e C.
A me questo ricorda qualcosa e a te
Commento di Tom — 10 Luglio, 2006 @ 3:50 pm
Enri: il lavoro di refactoring lo possiamo fare insieme. Non subito, perché attualmente ho poco tempo – ma presto, spero. Skype: paoloperrotta.
Matteo: non sono d’accordo con Van Cauwenberghe. Scusa se mi cito da solo, ma qualche tempo fa in un posting sulla mailing list extremeprogramming ho scritto perché a mio modesto avviso senza esplicite e brevi iterazioni tutto il sistema agile perde di senso. Se sei su YahooGroups:
http://groups.yahoo.com/group/extremeprogramming/message/117618
Per restare ancorati alla realtà del mercato italiano: credo che il motivo per cui qui da noi l’approccio agile non si diffonde è proprio perché la concorrenza si fa esclusivamente sul prezzo, e un approccio agile non è in grado di dare garanzie sul prezzo finale. Un approccio tradizionale invece le dà – sbagliate, ovviamente, ma quando l’unica cosa che conta è spendere poco non ci sono altri punti di riferimento su cui basare la concorrenza.
Commento di Paolo "Nusco" Perrotta — 10 Luglio, 2006 @ 7:56 pm
Bel post Enrico, grazie per il contributo che stai dando al panorama Italiano delle metodologie agili (Dio solo sa quanto ne abbiamo bisogno ;-D)
Anche se un po’ in ritardo, esprimo anch’io la mia opinione
Devo dire che purtroppo nel passato ho perso più di un potenziale cliente a causa dell’approcio “alternativo” di XP sul calcolo del “costo” di progetto, e proprio grazie a queste brutte esperienze mi sono fatto un paio di idee
Le aziende che “giocano per non perdere” sono da evitare a priori (a meno che non si giochi dall’interno, ma questo è un’altro discorso)
Le aziende che “giocano per vincere” sono quelle che hanno da trarre i maggiori vantaggi, ma sono anche quelle con meno disponibilità economica, sono quelle che rischiano di più ad ogni decisione e quindi tendono ad essere rigide per proteggersi
La carta sulla quale punto (visto che il non dare un prezzo fisso non è nemmeno pensabile) è lo scope variabile, sottolineando il fatto (importantissimo) che le metodologie tradizionali hanno come obiettivo quello di implementare delle specifiche, mentre invece le metodologie agili hanno come obiettivo quello di raggiungere gli obiettivi del cliente
Per farla breve l’idea è quella concordare con il cliente:
- degli obiettivi (l’ideale sarebbe poter individuare delle metriche per questi obiettivi)
- un prezzo per il raggiungimento di questi obiettivi (va precisato che gli obiettivi non sono un tutto o niente, fin dalla prima iterazione il prodotto deve in qualche misura “raggiungere gli obiettivi”, l’impegno è quello, di iterazione in iterazione, di fare un passo (il migliore) verso quegli obiettivi)
- eventuali vincoli di progetto (ad esempio tempistiche per le release dettate da fattori esterni, integrazioni con altri prodotti, ecc…)
Questo perchè presumo che il cliente sappia sempre quanto vale per lui il raggiungimento di determinati obiettivi, altrimenti non saprebbe valutare l’opportunità di realizzare un progetto o meno, quindi questo prezzo mi sembra un’ottima basa contrattuale dalla quale partire, con ovviamente la possibilità di poter cancellare il progetto in qualsiasi momento (qualora il ritorno dell’investimento non fosse dell’entità prevista = risparimo + dimunuzione del rischio d’impresa), ottenendo comunque un prodotto funzionante ed utilizzabile
E’ ovvio che in quest’ottica le funzionalità sono perfettamente trasparenti rispetto al “contratto” con il cliente, in quanto non sono un fine, ma un mezzo. Riuscendo a far partecipare il cliente nella scelta delle funzionalità (planning game) e nel processo di valutazione della funzionalità stessa nell’ottica delle metriche adottate, il rischio dell’impegno contrattuale sul raggiungimento degli obiettivi viene ridotto (scegli tu cliente quali storie implementare, scegli tu cliente quando una storia è implementata, verifichi tu cliente “quanto” valore ha apportato una storia)
Quest’ultimo discorso è importante, in quanto spesso (sopratutto in Italia) le metriche di business sono pesantemente influenzate da fattori che non dipendono dallo sviluppo software, ed assumersene il rischio attraverso la firma di un contratto, sarebbe da folli
Commento di Gabriele Lana — 11 Luglio, 2006 @ 11:39 pm
Gabriele discorso molto interessante e che ne stimola molti altri.
Per ora mi piacerebbe arrivare insieme a qualche esempio di contratto.
Ad esempio quali sono stati nel tuo passato gli obiettivi che hai contrattato con i clienti?
Quali metriche ti sono state utili a questo fine?
Commento di Enri — 12 Luglio, 2006 @ 10:02 am
… le metriche di business sono pesantemente influenzate da fattori che non dipendono dallo sviluppo software, ed assumersene il rischio attraverso la firma di un contratto, sarebbe da folli
Questa frase di Gabriele sintetizza benissimo il problema.
Tipicamente ad esempio vengono dati ad una struttura dei budget per migliorare la produttività della struttura stessa, sono budget a fondo perduto, non devono essere restituiti in qualche modo, per cui il beneficio che ne deriva può alla fine anche essere zero.
Per fare un esempio tutto il budget potrebbe essere speso su una analisi dei processi che produca un manuale operativo volto a migliorare la produttività della struttura.
Se poi il manuale non viene applicato o non produce i risultati sperati il beneficio dell’investimento sarà nullo.
Tutto questo si può fare senza introdurre alcun software e sopratutto senza scrivere nessuna riga di codice.
La mia senzazione, fortunatamente per noi, è che ci sia poca sensibilità sul TCO di un software. Se si potesse misurare con precisione il TCO e soprattutto valutarlo a priori, nessuna struttura si imbarcherebbe nella scrittura di un software proprietario, valuterebbe con attenzione i software già disponibili, eviterebbe il più possibile le customizzazioni e modellerebbe il proprio processo su quello imposto dal software.
In una riunione ho sentito una frase molto realistica:
“Posso chiedere 10 operai in più, ma non posso chiedere 5 persone in più che controllino i 10 operai e 5 persone in più che sviluppano e gestiscono i sistemi che utilizzano i 5 controllori degli operai”
Business is business.
Commento di Tom — 13 Luglio, 2006 @ 11:46 am
Tipicamente ad esempio vengono dati ad una struttura dei budget per migliorare la produttività della struttura stessa, sono budget a fondo perduto, non devono essere restituiti in qualche modo, per cui il beneficio che ne deriva può alla fine anche essere zero.
Perché invece non misurare il ritorno dell’investimento, misurando in questo caso il “miglioramento della produttività”?
La mia senzazione, fortunatamente per noi, è che ci sia poca sensibilità sul TCO di un software. Se si potesse misurare con precisione il TCO e soprattutto valutarlo a priori, nessuna struttura si imbarcherebbe nella scrittura di un software proprietario, valuterebbe con attenzione i software già disponibili, eviterebbe il più possibile le customizzazioni e modellerebbe il proprio processo su quello imposto dal software.
Personalmente invece preferirei ci fosse questa sensibilità. Non solo, mi piacerebbe esistesse anche la sensibilità di comprendere quanto un software può portare di buona ad un’azienda. E’ chiaro che noi informatici dobbiamo costruire credibilità rispetto a quanto facciamo e dimostrare che siamo a supporto ed al servizio del business dell’azienda, e che ci muoviamo per minimizzare costantemente gli sprechi nel nostro processo.
Credo poi molto nell’andare a risolvere problemi concreti per il mondo del business, assistere con le mie conoscenze la ricerca delle migliori e più efficaci soluzioni per mezzo della scienza informatica. Questo spesso non è possibile con prodotti preconfezionati, proprio perché manca l’interazione stretta tra chi pone il problema e chi lo risolve.
Il punto è cercare, avere e creare cultura informatica. Personalmente credo molto nell’informatica a supporto dell’uomo, altrimenti che ci starei a fare qui?
Commento di Enri — 13 Luglio, 2006 @ 3:26 pm
quali sono stati nel tuo passato gli obiettivi che hai contrattato con i clienti? Quali metriche ti sono state utili a questo fine?
Magari avessi un passato così roseo
Fino ad ora l’unica metrica che ho utilizzato per lo sviluppo e “visibile” al cliente è stata la RTF (Running Tested Features) basata sui test di accettazione scritti dal cliente, che è meglio di niente, ma sono ancora lontano da quello che vorrei ottenere
Però posso immaginare alcune metriche che potrebbero essere utili e meno rischiose del calcolo del ROI o della diminuzione del TCO [*]
- usabilità
- tempo impiegato dall’utente per completare una user story (ovvero se il software è stato realizzato per velocizzare/automatizzare un processo, di quanto lo velocizza? Da qui poi si possono ricavare anche metriche che evidenziano il risparmio e quindi metriche di business)
- tempo impiegato dall’utente per capire come completare una user story (come il precedente dove però l’utente non è stato istruito sull’utilizzo di quel software)
- ecc…
In generale penso che questo tipo di metriche che misurano l’efficacia sul campo del prodotto sviluppato siano un buon compromesso fra le metriche del prodotto (inteso come software), le metriche di processo, e le metriche di business (le metriche più interessanti, ma come già detto, molto pericolose)
[*] In alcuni contesti il TCO a mio parere è una misura della qualità dell’applicazione molto più di quanto lo sia il ROI, infatti attualmente il TCO è elevatissimo (come diceva Tom) proprio perchè per l’utente finale il software sviluppato risulta complesso, rigido e in generale poco usabile
Commento di Gabriele Lana — 14 Luglio, 2006 @ 7:51 am