Quali misurazioni utilizzi per migliorare i tuoi processi?[Chiuso]

Question

Inizialmente la domanda era "Quali KPI utilizzi in un'organizzazione di sviluppo software".Purtroppo sembra così KPI è una parola di quattro lettere e il presupposto immediato è che i KPI vengono sempre utilizzati in modo improprio (forse lo sono?).

Quindi, spero di aver migliorato la domanda per raggiungere gli obiettivi sottostanti per i quali inizialmente pensavo che i KPI fossero utili.Supponendo che tu abbia un processo su come tu (o la tua organizzazione) sviluppate il software.In secondo luogo, presupponi che tu (o il tuo team) vogliate migliorare nello sviluppo e nella distribuzione di software.Infine, presumi che uno dei modi per migliorare sia perfezionare il processo.

Considerato tutto ciò, come fai a sapere se i perfezionamenti dei tuoi processi stanno avendo un impatto positivo?Se questi lo sono KPI, o [Obiettivi SMART](http://en.wikipedia.org/wiki/SMART_(gestione_progetto) fornisci singoli o gruppi di KPI/obiettivi SMART che ritieni siano efficaci.Se si tratta di qualche altro meccanismo, spiega di cosa si tratta.Infine, immagino che, se non pensi che migliorare i processi sia una cosa utile, immagino che tu possa spiegarlo anche tu.

Le aree di miglioramento che penso possano essere utili sono:qualità, tempestività dei rilasci, produttività, flessibilità.Se ci sono altri aspetti di un individuo o di un team di sviluppatori, sarebbe interessante saperlo.

Note chiarificatrici:

La domanda non riguarda come adattare o modificare al meglio un processo, o quale sia un buon processo di miglioramento del processo (che si tratti di Kaizen, retrospettive, ecc.).Né si tratta di analisi delle cause profonde o di altri approcci utilizzati per determinare quali aspetti specifici di un processo dovrebbero essere migliorati.

L'uso di misure per determinare se il miglioramento del processo è stato raggiunto, non deve essere confuso con il miglioramento continuo del processo.(Questa è una buona cosa, ma non è questo l'oggetto della domanda!)

IL processi potrebbe essere qualsiasi cosa;mischia, agile, estremo, cascata, ad hoc.La domanda non riguarda quale sia il processo migliore per determinati tipi di sviluppo software, ma piuttosto come migliorarlo nel tempo.

Ovviamente la metrica specifica dipenderà dal processo coinvolto e dal problema percepito che si sta cercando di migliorare.Questa domanda è progettata semplicemente per ottenere esempi di metriche utilizzate, che ovviamente abbracciano una serie di processi e aree di miglioramento diversi.

Non è necessario che la metrica sia qualcosa che viene utilizzato tutto il tempo, ad esempio, potrebbe essere utilizzato semplicemente durante il test se una modifica al processo funziona.(Ad esempio, potrebbe essere troppo costoso, in termini di tempo o denaro, misurarlo e monitorarlo in ogni momento, quindi monitorarlo modificherà il processo).

È dato per scontato che, se implementato in modo inadeguato, l'uso delle metriche può avere un effetto dannoso poiché gli sviluppatori manipolano il sistema o meno.Si presuppone che la persona che implementa il cambiamento del processo sia consapevole di questo problema e abbia adottato misure efficaci per mitigarlo.

Tutte le organizzazioni software sono diverse e differiscono nel modo in cui si inseriscono nella propria azienda, quindi si aspettano cose specifiche diverse da loro all'interno dell'azienda, tuttavia penso che la qualità del prodotto, la produttività, la flessibilità e la tempestività dei rilasci siano applicabili alla maggior parte se non a tutte le organizzazioni.(Con enfasi ovviamente diversa a seconda della specifica organizzazione.)

Questa domanda non ha nulla a che fare con righe di codice sorgente!In particolare, non sono interessato a misurare la produttività del programmatore, soprattutto in termini di SLOC o numero di bug risolti, o qualsiasi altra misurazione ingenua.Sono interessato al modo in cui un team o un individuo di livello superiore misura il proprio miglioramento.Non mi interessa utilizzare un singolo KPI per misurare le prestazioni di qualcuno.IO Sono interessato a utilizzare una serie di KPI per misurare e migliorare i processi di sviluppo software del mio team.

Conosco storie dell'orrore sull'uso improprio e sull'inefficacia dei KPI (non è necessario cercare molto per trovarli), ma non posso credere che nessuno là fuori cerchi di migliorare continuamente i propri processi, quindi devono esserci alcuni buoni esempi di KPI disponibili.

So tutto degli svantaggi delle metriche semplicistiche applicate ai singoli programmatori di software.Spero davvero di ottenere esempi di KPI o strategie alternative che le persone hanno trovato utili, piuttosto che tutti i motivi per cui non dovrei utilizzare i KPI.

Sono interessato principalmente ai processi e alle prestazioni relativi a un'organizzazione di sviluppo all'interno di un'azienda più grande, anziché a una società di sviluppo software nel suo insieme.Ad esempio, un'azienda di software dovrebbe garantire che i prodotti abbiano le caratteristiche giuste per il mercato, ma in genere questo è il ruolo della gestione del prodotto, piuttosto che dell'ingegneria.E sì, c'è tutta un'altra discussione sul perché e in che misura gli ingegneri dovrebbero essere coinvolti nella gestione del prodotto, ma questa è una discussione separata.

Answer 1

Di gran lunga il miglior indicatore singolo è "funzionalità testato consegnato e accettato". Nel mondo Agile, di solito misuriamo "funzionalità" in termini di "storie di utenti", ma può essere in qualsiasi forma conveniente finché si tratta di misurare la funzionalità effettiva consegnato e collaudato, accettabile per il cliente.

I soliti altre misure, come SLOC, SLOC / personale ore, ecc, non riescono a causa di Charlie Prima Legge della gestione, che è:

  

La gente consegnare tutto ciò che sono   essere ricompensati per consegnare.

Impostare le misure come SLOC, e si otterrà un sacco di SLOC. Utilizzare SLOC / h, si otterrà un sacco di SLOC / HT. Dare loro bonus per il lavoro straordinario, si otterrà un sacco di ore di lavoro straordinario.

Ah, e ricordare il correlary, troppo:

  

Quello che la gente stanno fornendo è quello che   che pensano sarà gratificante per   consegnare.

Se non sei ottenere quello che vuoi, chiedere perché è gratificante per fare le cose che ha sempre fatto.

Answer 2

Quando sento Key Performance Indicator ho un po 'preoccupato perché di solito la prossima cosa fatta è di collegare le prestazioni per premiare e quindi è possibile ottenere scollarsi molto rapidamente. Sono sempre in mente la società di software che hanno deciso su un sistema di ricompensa intorno bug fixing - i tester sarebbero ricompensati per la ricerca di bug e gli sviluppatori ricompensati per correggere i bug. terra di sviluppo una battuta d'arresto come un mercato nero istante formata attorno l'inserimento, il rilevamento e la correzione di bug.

I tuoi KPI organizzative dovrebbero essere concentrati cliente. A seconda del tipo di prodotto software si stanno facendo, si può misurare nei seguenti modi:

• Vendite - è la vostra esigenze dei clienti incontro di prodotti? Si può essere in grado di misurare questo in termini di rapporto tra presentazioni di software per vendite o visite alla pagina di acquisto del tuo sito web per gli acquisti effettivi
• Qualità - Il vostro software è comprensibile ed affidabile? Quante chiamate di supporto per cliente si ottiene al giorno? Sono le domande su come fare qualcosa o errori?
• La soddisfazione del cliente - Quanto sono soddisfatti i vostri clienti con il vostro prodotto? Indagine vostri clienti e scoprire che cosa si potrebbe fare per aumentare la loro soddisfazione per poi rilevare di nuovo più tardi per scoprire se hai migliorato. (Non infastidire i clienti, chiedendo un sacco di domande o di fare troppo frequentemente)

Sì, questi indicatori sembrano avere nulla a che fare con le metriche del software livello di base come i bug trovati e le linee di codice prodotte. Tuttavia, il problema con gli insetti trovato è allora dovete grado la gravità dei bug, e refactoring spesso ridurre le linee di codice. Tempestività conta solo se si è soddisfare le aspettative dei vostri clienti di consegna puntuale.

Concentratevi sugli obiettivi di business. Se si dispone di clienti che acquistano il software, non hanno bisogno di un sacco di sostegno da usare e sono felici, allora la vostra organizzazione software va a buon fine. Nessuna misura di bug rilevati, slittamenti di orario o qualsiasi altra cosa importa se non si dispone di queste tre cose a posto.

Se il progetto del software è come la maggior parte là fuori, sarà in ritardo, fuori budget, nave con caratteristiche meno rispetto bug previsti e avere. Non ti hanno picchiato su queste cose, trattare con loro e andare avanti. Sì, avete bisogno di database di bug, controllo del codice sorgente, test e un modo per misurare la velocità di progetto, ma alla fine se non si soddisfano i risultati di business, allora non si può avere successo, indipendentemente da come lucido e lucido il codice e come alcuni bug che ha.

Aggiorna per cercare di affrontare la questione rivisto

KPI come volete usarli sono difficili quando consegna un prodotto intangibile che è anche spesso un bersaglio in movimento. Il vostro KPI utilizzati quest'anno su un sistema di contabilità hanno lo stesso significato prossimo anno, quando si implementa un sistema di gestione dei documenti?

Prendiamo come esempio una professione in cui KPI vengono utilizzati ampiamente - avvocati. Misurare avvocati utilizza KPI quali: ore medie lavorate fatturati al giorno; ore fatturate al mese; All'età di registro dei debitori; età media di lavoro non ancora fatturate; per cento delle tasse fatturate stornato; e così via. Si dovrebbe notare una tendenza qui - tutti questi KPI relativi a volontà (o meno) dei clienti a pagare per i servizi resi. Questo è l'arbitro finale di successo ed è il motivo per cui ho suggerito (sopra) un certo senso si potrebbe usare questo tipo di misura come KPI per il vostro business software.

Quando si tenta di scendere ad avere KPI che non si riferiscono alla disponibilità del cliente a pagare per il valore che si sta fornendo, quindi ci mettiamo a problemi con quello che stiamo misurando, come si sta misurando e quali differenze ci sono nella misurazione o di ciò che viene misurato quest'anno rispetto allo scorso anno.

"dollari pagati dai clienti" ha un valore fisso di anno in anno - metriche arbitrarie come "bug nel software", "tempestività del rilascio"e "flessibilità" non hanno un valore fisso e un aumento della KPI non può avere un rapporto diretto al sottostante che è destinata ad essere misurata dal KPI, ad esempio "più insetti significa qualità inferiore".

Per esempio, dopo la Columbia disastro , ricordo la squadra investigativa si avvicinò con diversi centinaia di consigli e oggetti da indagare. Ha fatto queste scoperte di recente "bug" significare la navetta spaziale aveva improvvisamente molto meno qualità? In realtà, dopo l'inchiesta della navetta spaziale aveva più qualità. Quindi un KPI intorno bug può essere facilmente distorta da una ricca sessione di QA e altri bug segnalati può effettivamente significare il software ha una qualità più elevata.

La produttività in termini di tempestività delle uscite è facilmente distorto da fattori commerciali, come ad esempio un client buttare i soldi a voi per fare un po 'lo sviluppo personalizzato per loro. Il vostro programma di rilascio scivolerà ma il vostro business migliorerà.

Per quanto riguarda la flessibilità, non riesco nemmeno a tentare di indovinare il modo in cui si misura qualcosa di così intangibile.

Circa l'unica misura che posso pensare che ha valore questo lato del portafoglio del cliente è - quanto ha stimiamo che avremmo fatto ultima iterazione / ciclo / release e quanto abbiamo effettivamente ottenere fatto? Quindi collegare questo dato nel tempo a disposizione per l'iterazione successiva / ciclo / rilascio di stimare quanto si sarà probabilmente in grado di ottenere fatto questa volta. È possibile visualizzare il tempo rimanente in un bruciare grafico o simile durante l'iterazione.

Il resto si riduce a processo che non credo che si può definire di KPI. Tutto quello che puoi fare è assicurarsi che gli sviluppatori sanno che cosa ognuno sta facendo (riunioni sviluppatori al giorno), il team esteso ottiene ingresso (riunioni di team settimanale o quindicinale), si capisce che cosa ha funzionato l'ultima volta e cosa no (retrospettive) e, soprattutto, si dispone di una comunicazione efficace trasparente.

Purtroppo, non credo che ci siano KPI magici come si sta dopo (ma non trascurare l'importanza di ottenere denaro da parte dei clienti come KPI).

Answer 3

Benno, sto rispondendo il tuo commento, ma non ha avuto abbastanza caratteri lì per la risposta.

Questo dipende il problema si sta risolvendo. Per esempio supponiamo che il problema è che il tempo da quando i controlli per gli sviluppatori nel codice fino a quando non è in realtà messi in produzione sembra troppo lunga. Poi si dovrebbe ottenere una misura di base di quanto tempo sta prendendo. allora si dovrebbe mettere nel vostro cambiamento e quindi misurare per un periodo di tempo per vedere se la società richiede meno tempo. Si potrebbe anche verificare qualcosa di simile al numero di volte che la soluzione è stata decisa a non lavorare e rispedito per la rilavorazione prima e dopo pure per fare in modo che la soluzione non è più veloce ma di qualità inferiore.

Ora il problema in IT con queste misure è che si può prendere un po 'di tempo per accumulare abbastanza dati in quanto alcuni problemi non si ripetano frequentemente. In questo caso potrebbe essere necessario avviare basandosi su dati soggettivi fino a quando si può accumulare abbastanza dati per sapere se il cambiamento è stato buono o no. Ma non chiedere se qualcosa è un miglioramento fino a quando gli utenti sono abituati ad esso. La prima settimana o due di un nuovo processo, si incontrerà la resistenza al cambiamento e, quindi, sarà possibile ottenere risultati soggettivi cattivi se chiedete troppo presto.

Un'altra cosa a diffidare di è che se la gente sa che si sta misurando qualcosa, avranno paura che le loro prestazioni personali viene misurata e quindi sarà ingannare il sistema per ottenere buoni risultati. Spesso è meglio se si può prendere le misure sulla base di un qualche sistema già in atto (abbiamo aa sistema che gestisce le richieste di modifiche del software, abbiamo potuto interrogare il database per scoprire storicamente quante richieste mancato la scadenza, quanti abbiamo riaperto dopo essere stato chiuso o sono legati a richieste passate ecc, quale la differenza di tempo tra finitura sviluppatore e il codice di essere spostato nella produzione ecc sono). Si può anche prendere in considerazione l'eliminazione gravi valori anomali, soprattutto se il tempo si estende il periodo di tempo sia il vecchio e il nuovo sistema. Per esempio abbiamo una richiesta che è stato in Qa per oltre 100 giorni non ragione fosse perché è male, ma perché ha un problema di QA avaliability e questo è la priorità più bassa in modo che mantiene sempre urtato per una maggiore lavoro prioroity. Questa volta non sarebbe utile a misurare il miglioramento del tempo, ragione fosse perché il fattore rendendo il tempo così a lungo non è il processo che si sta tentando di risolvere. Se si rappresentano i dati, potrete facilmente vedere i valori anomali che potrebbero aver bisogno esclusi.

Answer 4

Basando KPI intorno costo, qualità e pianificazione sarebbe un buon inizio. Considerare quali sono gli attributi per ognuno di coloro che si vuole misurare.

Essere in grado di dividere ciascuna di queste misure per mostrare il costo di bug sarebbe utile - un sacco di fatica bug fix in ritardo nel progetto significa costi / calendario scoppio. Essere in grado di profilare quali parti del codice di base sono buggy potrebbe aiutare in termini di orientamento ulteriori test e possibili code riscritture - in genere l'80% dei bug verrà dal 20% del codice. Sapere dove cioè permetterà al team di concentrarsi meglio.

Modifica : Guardate misure come costo della Qualità (CoQ) e il costo di scarsa qualità (COPQ).

Misure come la produttività sono sempre difficili da quantificare - ad esempio, utilizzando LOC / giorno porta ad un dibattito su ciò che è esattamente una riga di codice? Si può anche portare a sciocco formattazione del codice per la produttività "boost" se gli sviluppatori non capiscono il motivo per cui queste cose vengono monitorati o li percepiscono come misure personali. Anche se LOC / giorno non si misura a livello di sviluppatore, è ancora possibile ottenere squadra rivalità che porta allo stesso risultato.

EDIT: Ci sono alcune buone discussioni per essere trovati su Construx sito di Steve McConnell. [Sì, questo è lo Steve McConnell del codice fama Complete]

Answer 5

Nessun processo sta andando per aiutarti a migliorare ciò che si fa, tranne in realtà sempre tutti insieme e cercare di capire cosa funziona e cosa non funziona. Per la squadra che sto attualmente leader, lo facciamo attraverso una serie di retrospettive (di cui consiglio caldamente questo libro ). Le squadre in genere sanno quali parti vogliono migliorare - il trucco sta dando loro l'empowerment per misurare e migliorare le cose in realtà

.

Sì, è certamente ancora bisogno di qualcuno alla ricerca a livello macro. Se si guarda a un'organizzazione come la Toyota, hanno un ingegnere capo che si trova a cavallo quella linea tra affari e di produzione (per una buona spiegazione, vedere di Scott Bellware post sul blog ). Nella nostra organizzazione abbiamo qualcuno simile - il mio capo era uno degli sviluppatori iniziali del nostro prodotto quasi 20 anni fa, e rimane molto attiva nel lato tecnico, ma è pesantemente investito nel lato cliente pure. Il mio lavoro è anche quello di guardare ai team nel suo complesso a suggerire miglioramenti.

Per misurare, per prima cosa assicurarsi che qualsiasi miglioramenti ci sforziamo di cose sono le nostre squadre possono realmente cambiare, e quindi usare qualcosa di simile al obiettivi SMART in modo che eventuali miglioramenti sono misurabili. Abbiamo un Grande, visibile parete che abbiamo posto le note dalla retrospettiva su. Questo sembra essere anche il luogo dove teniamo le nostre quotidiane stand-up, in modo che dà concentriamoci su ciò che sta accadendo.

Per rimboccarsi le statistiche alle nostre riunioni dei dirigenti, ci concentriamo sulla distribuzione di codice - non le linee di codice consegnati. Ho volutamente preso a calci la squadra fuori misura in unità nebulose il che significa che non ci riferiamo up che abbiamo lavorato x numero di ore o giorni, o qualsiasi altra cosa. Quello che vedono è un grafico trend di quanto bene stiamo offrendo le nostre caratteristiche e di come stiamo migliorando. Includeremo anche interessanti curiosità quando la squadra si sente che vogliono condividerlo.

La parte migliore di tutto questo è che siamo in grado di provare le cose per un mese, e poi rivalutare è appena 4 settimane dopo. Questo crea una barriera molto più basso di voce per provare cose nuove, dal momento che la squadra sa che se li sta avendo effetto, ci sia annullarla immediatamente, o ti rivalutare e trovare il modo migliore in occasione della prossima retrospettiva.

La parte negativa è che non è esattamente quello che stai cercando. Non c'è una sola metrica o un insieme di metriche continuamente seguiamo. Noi guardiamo le tendenze in ogni momento, e misurare quelle che pensiamo siano interessanti - ma solo per un po ', e solo quando la squadra è di partire per raggiungere un obiettivo specifico a causa loro. Ma in generale, sono abbastanza contento di come funziona, e ho visto un netto miglioramento nel coinvolgimento delle squadre di miglioramento del processo. Non siamo abbastanza Kaizen , ma stiamo migliorando ogni giorno.

Answer 6

Ho fatto il miglioramento dei processi professionalmente per 14 anni. Ecco il mio consiglio, smettere di cercare di quantificare e iniziare a parlare con la gente. Misura funziona bene per un problema specifico (una volta che si conosce il problema, si ha una migliore idea di cosa misurare) e per i processi repeatble come la produzione. La tua gente sa esattamente dove le aree problematiche sono, così fanno i vostri clienti e utenti (da una prospettiva molto diversa). Diagramma di flusso (utilizzare i simboli ingegneria industriale non simboli di programmazione informatica) fuori il processo reale per le aree dove ci sono preoccupazioni (non quello che facciamo finta che il processo è, è necessario osservare e fare domande). Una volta si vede l'intero flusso del processo cercare ritardi, aree in cui è duplicato il lavoro, le aree in cui v'è processo non necessario (di solito a causa di aggiunta di ulteriori passi per il processo per tenere conto di un errore umano, creando così molte zone più potenziali per l'uomo errore). Mettere in discussione la necessità di ogni passo e se ci sia un modo migliore per fare ogni passo. Testare potenziali cambiamenti e vedere se in realtà sono un imporvement (modo troppe volte fanno peggiorare la situazione non migliore). Non in nessun caso solo parlare con i manager quando ottenere un tatto per problemi o quando grafici di flusso. Non sarà possibile ottenere una rappresentazione veritiera e sarà quindi risolvere il problema sbagliato.

Answer 7

I rifiuti comprensione e mappatura valore-stream vi mostrerà dove è necessario apportare miglioramenti, e da questa conoscenza, imparerete che cosa è necessario misurare. Principi di magra e Kanban applicano qui. La comprensione dei rifiuti ed è effetti sulla produzione di software si avvia lungo il sentiero specifico per il miglioramento che è inevitabilmente specifico per la tua organizzazione. Non si può adottare un approccio cookie-cutter. Leggi (o ascoltare) "L'obiettivo" e "Lean Thinking" per maggiori informazioni su questo veramente sorprendente e aprire gli occhi la prospettiva di ciò che è sbagliato e come rimediare.

Answer 8

L'uso migliore degli indicatori chiave di prestazione è per guida (o sterzo, se preferisci).Per correzioni di rotta in tempo reale.

(Vedere I cruscotti servono per la guida per ulteriori chiacchiere su questo sottoargomento.Avvertimento:Sono l'autore dell'articolo blaterante.)

Quindi la domanda che ti rispondo è:stai cercando di valutare le prestazioni dopo il fatto, quando è troppo tardi per fare qualcosa al riguardo, o stai cercando di trovare KPI che possano aiutarti rimanere sulla rotta?

Nel primo caso, qualsiasi parametro importante per la tua organizzazione (conteggio dei bug, slittamento della data di spedizione, righe di codice con commenti, percentuali di reso dei clienti, ecc.) andrà bene.Misura e buona fortuna per migliorare tra la spedizione dei prodotti e gli aggiornamenti ;-)

Se quest'ultimo, scegli velocità.Supponendo che tu stia utilizzando lo sviluppo basato sui test (TDD), ovviamente.

MODIFICARE:quindi è il primo.Bene, ecco perché probabilmente sei sfortunato:

Supponiamo di decidere che la "qualità" sia quantificata al meglio misurando il numero di bug segnalati dai clienti come KPI post-elaborazione.Supponiamo che tu stia utilizzando TDD e diciamo che il tuo team consegna il Prodotto n. 1 in 6 mesi e dopo 6 mesi sul campo scopri di avere 10 bug segnalati dai clienti.Allora cosa farai esattamente per migliorare il tuo processo?Testare di più?Testare specificamente più cose come le cause dei bug segnalati?Mi sembra che staresti già testando e quando vengono scoperti bug, da parte del cliente o meno, aggiungi un test di regressione per il bug specifico e test unitari aggiuntivi per assicurarti che non ci siano più bug simili.In altre parole, la risposta al miglioramento post-processo non sarà diversa dalla risposta al miglioramento in-process, quindi questo KPI non è di alcun aiuto significativo nel migliorare il processo.Il punto è che il modo in cui migliori il tuo processo rimane lo stesso indipendentemente dal fatto che i bug vengano scoperti 6 mesi dopo il rilascio o due giorni dopo l'inizio della codifica.Quindi, anche se questo potrebbe essere un KPI brillante da appendere alla bacheca di un manager o a una newsletter di dipartimento, in realtà non cambierà i meccanismi di miglioramento dei processi.(E fai attenzione a non dare troppa importanza a questo KPI perché può essere fortemente influenzato da fattori fuori dal tuo controllo!).In breve, conoscere il numero di bug non ti aiuta a migliorare.

(C'è un altro pericolo qui, che si riscontra comunemente non solo negli affari ma anche in campo militare, e cioè l'illusione che l'analisi post mortem abbia rivelato informazioni preziose, quindi le lezioni apprese post mortem vengono vigorosamente applicate al progetto successivo, che probabilmente non è lo stesso dell'ultimo progetto.Questo è noto come "combattere l'ultima guerra".)

Supponiamo che il numero di resi/rimborsi dei clienti sia il tuo KPI preferito per la "qualità": se questo numero è 5, cosa ti dice?I motivi specifici per cui i clienti hanno richiesto un rimborso potrebbero essere indicatori di problemi di qualità ("troppo lento", "non si interfaccia con il sistema XYZ", ecc.), ma il semplice numero di tali incidenti non ti dicono nulla.Una varianza rispetto alla percentuale di rendimento previsto potrebbe dirti se la qualità stava migliorando, ma ancora una volta il numero non ti aiuta a migliorare.Hai bisogno di più informazioni di quelle che il numero può darti.

Quindi, per quanto riguarda la "tempestività dei rilasci", quale misura sarebbe appropriata?Numero di giorni di slittamento della data di spedizione?Superamento percentuale in base alle stime originali? Non importa, perché ancora una volta i numeri non ti aiutano a migliorare.

Se puoi misurare la "produttività" dopo che il prodotto è stato realizzato, probabilmente puoi misurarla mentre il prodotto viene sviluppato (ad es.velocità), la differenza è che una produttività inferiore a quella prevista durante lo sviluppo può essere migliorata immediatamente, mentre un numero di produttività complessiva misurato dopo il completamento dello sviluppo è troppo grossolano, troppo mediato, per essere di qualche utilità.Si poteva solo immaginare il motivo per cui era inferiore al previsto 6 mesi dopo...

Non ho idea di come si possa misurare la "flessibilità", sembra un gergo di marketing ;-)

Spero di non aver piantato questo chiodo troppo forte o troppo lontano, ma non credo che ci sia qualcosa utile che puoi misurare a posteriori, ciò che non puoi misurare mentre è in corso.E ci sono molte misurazioni a posteriori che sono inutili senza conoscerne le cause.

Answer 9

È possibile ottenere molte idee circa KPIs e Esempi di cruscotti all'indirizzo http://www.dashboardzone.com

E 'KPI da parte dell'industria e aree funzionali.