Come misuri il valore del tuo software?

Ecco come definisco il valore in generale (anche al di fuori dello sviluppo del software)

definisci quale valore è .

Se il valore è l'importo di denaro guadagnato / salvato grazie al software, il valore sarà:

Revenue - Cost of development = Value

o

Saved Operational Costs - Cost of development = Value

Può essere girata. Sai cosa costa il fatturato nella tua azienda? Se riesci a misurarlo, una riduzione del 50% del tuo giro d'affari grazie ad agile ti consentirà di calcolare il valore fornito:

50% Turnover reduction = (Turnover Cost / 2) = Value

Il valore può tutto ciò che conta per te , il ragazzo che definisce qual è il valore.

Ecco perché il valore viene valutato in punti in agile. I punti vengono confrontati con i punti della storia per aiutarti a dare priorità al valore. Perché devi confrontare il valore (aziendale) (arbitrario) con il valore dei punti storia (costo).

In molti casi, il valore del software viene misurato calcolando "guadagni aggiunti" o "risparmi sui costi ottenuti".

In altri casi, dove il software è integrato in un sistema più grande (ad esempio il software che controlla un'auto), è più difficile. O si misura la spesa per farla (valore = costo), o si calcola il valore dell'intero sistema (guadagni aggiunti / risparmi sui costi accumulati) e si assegna una parte di se al software (ad esempio proporzionale ai costi del software vs costi totali)

Semplicemente, devi capire qual è la differenza finanziaria tra averlo e non averlo.

Se un po 'di software automatizza un processo che significa che due persone che lavorano a tempo pieno non devono più svolgere tale compito, questo è un risparmio dei loro stipendi annuali (più i relativi costi) per l'azienda. Se i venditori vendono in media il 10% in più di quelli che non utilizzano il nuovo sistema, il vantaggio è pari al 10% delle vendite totali per tutti i venditori che potrebbero utilizzare il software.

Le cifre potrebbero essere solo approssimative e pronte, ma la maggior parte delle cose può essere quantificata abbastanza da darti una sorta di impressione utile su cosa aspettarti.

Questa è una domanda complicata. Non sono sicuro che mi piaccia la metrica "caratteristiche / sviluppatore", perché non tutte le funzionalità sono uguali. Alcune funzionalità sono "Must-have" e ruberanno i clienti al tuo concorrente. Alcune funzionalità sono oscure e potrebbero essere utilizzate dallo 0.1% dei tuoi clienti, e potrebbero essere in grado di fare bene anche senza.

I miglioramenti delle entrate sono buoni se si può facilmente correlarlo a un improvviso aumento delle vendite / rinnovi del software alla tempistica di una nuova versione. Inoltre, se si fosse in qualche modo in grado di tracciare la conversione degli utenti dai prodotti concorrenti a una nuova versione. La soddisfazione del cliente potrebbe essere misurata in termini di numero di chiamate felici (o mancanza di chiamate arrabbiate) normalizzate al numero di clienti o vendite. Per collegarli direttamente al tuo dipartimento, la cosa fondamentale potrebbe essere la tempistica di questi cambiamenti e il timing del software che stai rilasciando.

Il software è la misura. Ascolta apertamente i tuoi utenti e coinvolgerli nel processo di sviluppo. Fornisci regolarmente le funzionalità che ti dicono che sono necessarie quando ne hanno bisogno. Consegna in piccoli blocchi in modo che gli utenti si sentano in corso.

Se stai appena iniziando uno sviluppo agile o anche un nuovo progetto ... allora le parti interessate devono avere un po 'di fede. Ciò richiede al proprietario del prodotto di articolare il motivo per cui l'agile è migliore di altri processi (presumo che pensi che sia nella tua situazione specifica).

Se il proprietario del prodotto non è sicuro su quali caratteristiche (storie) offrano il valore più relativo, è necessario sedersi con le parti interessate e capirlo. Pianificare il poker è un buon strumento per questo. Assegnare il valore di business relativo a ciascuna storia aiuta anche con la definizione delle priorità, ma fai attenzione a non parlare ai contatori di bean di "Agile Business Value", non è la stessa cosa del ROI!

C'è spesso una linea di fondo "dura" che può essere misurata facilmente per mantenere contenti i bean, "La caratteristica X ha aumentato le nostre entrate del 150%". Ma il più delle volte è una combinazione di valori "duri" e "morbidi" "Le nostre entrate sono aumentate del 160% e noi pensiamo possiamo attribuirle al cambiamento del software dato che i clienti in media ci hanno dato l'11% punteggi più alti con la nuova funzione dell'interfaccia utente ".

È davvero difficile misurare con precisione queste cose - prova a guardarle nel modo più olistico possibile.