Forse qualcuno si aspetta che io parli della festa del primo maggio, sfortunatamente ero a visitare un castello a Wupperthal/Solingen, e onestamente non l’ho seguita. Del resto, fare la festa del lavoro quando manca il lavoro e’ come fare una festa dell’acqua quando manca l’acqua: una festa per pochi fortunati che si sono accaparrati le ultime riserve. Vorrei invece parlare dei numeri di Grillo, perche’ si parla e si parla, ma nessuno propone un approccio un minimo sistematico al problema.
Supponete di offrire un prodotto od un servizio, per prima cosa vi chiederete quanti siano potenzialmente interessati al prodotto, ovvero chi siano coloro che potrebbero usarlo. Se fate una macchina che raccoglie pesche dai campi, ovviamente saranno le aziende che coltivano pesche, eccetera.
Rimaniamo in un campo a me congeniale, e diciamo che stiamo scrivendo una app per un cellulare, e diciamo che il numero di cellulari su cui questa app potrebbe girare sia di circa 9 milioni.
Cosi’, abbiamo questa app, diciamo “LiquidDM!” , che va sul nostro market (in questo caso, fa da enabler, cioe’ e’ il meccanismo che permette ai clienti di essere in grado di usare un servizio. Attenzione, non sempre l’utente e’ il cliente: posso vendere un servizio ad un supermercato (il mio cliente), che poi lo offre agli utenti veri – i SUOI clienti, che non hanno un contratto con me) .
Allora, la nostra app LiquidDM! dopo essere stata pubblicizzata in qualche modo, viene scaricata da 48.000 persone. In questo caso si parla di “indicatori di successo”, perche’ il cliente non usa nemmeno l’enabler, ovvero non fa parte di un processo. In questo senso, non e’ un pessimo indicatore di processo, ma un pessimo indicatore di successo.
Quel numero e’ ovviamente un numero catastrofico, ma onestamente nella vita non mi occupo di indicatori di successo, per cui l’analisi e lo splitting in CSF (un elenco dei fattori piu’ importanti nella produzione del successo) di solito la fa chi si occupa del mercato. Lanciano customer surveys, licenziano gli ideatori, cercano feedback, fanno piu’ pubblicita’, cambiano canale pubblicitario, eccetera. Non e’ il mio lavoro, quindi diciamo: l’indicatore di successo e’ catastrofico, ma non saprei dirvi la rava e la fava su questo.
Andiamo agli indicatori di processo, perche’ qui ne ricevo una paccata ogni mattina, da controllare con il mio bello splunk. Insomma, e’ il mio lavoro.
Abbiamo detto che il nostro UCD(1) in questo servizio contiene almeno:
- Il cliente scarica la app.
- Il cliente installa la app.
- Il cliente avvia la app e decide di usarla.
- Il cliente usa la app.
- Se il cliente usa la app e gli piace, ritorna ad usarla.
- Se non ritiene non la usa piu’.
- Se gli fa scaghissimo la disinstalla pure.
- Se ritiene, si deprovisiona dal sistema.
Dal punto 2 al punto 8 il cliente e’ gia’ abilitato al sistema. Significa che da questo momento e’ parte di un processo, e il fallimento di uno di questi punti e’ (o dovrebbe) essere misurato da un apposito KPI. In che modo prendere il KPI , cioe’ in che modo entrare in possesso del dato, e’ tutto da discutere coi tecnici, ovvero la APP potrebbe per esempio confermare la propria installazione, il market lo scaricamento, la applet dovrebbe loggare l’avvio (tipo, esegue il login al sistema producendo un evento loggato), e poi ci saranno dei cookie o qualche altro token che , leggendo sul backend, mi dice se il cliente ritorna. E cosi’ via.
Ognuna di queste fasi deve essere tracciata, altrimenti vi sognate quello che ITIL v3 definisce “miglioramento perpetuo”:
Detto questo, se il cliente si provisiona ma non usa il sistema, siamo parlando di KPI. Che cosa pubblica Casaleggio?
Pubblica che alle parlamentarie circa il 30% degli abilitati abbia scelto di non votare, e i voti siano stati circa 25K, mentre alle quirinarie i voti sono stati circa 28K, su un totale di 48K.
Questo e’ un KPI evidentemente ORRIBILE.
Sicuramente il tale utente puo’ scegliere di NON partecipare, o di non partecipare piu’, o di non partecipare quella volta. Aha. Ma questo innanzitutto non lo potete dire voi. Una volta stabilito che C’E’ un PROBLEMA, allora il punto e’ che si va ad investigare.
Non si puo’ dire che “e’ normale” senza investigare. Il ciclo e’:
- Una fase di reporting, ove viene evidenziato tutto questo.
- Visto che c’e’ un problema, il problema viene diviso in “incidenti”. (un problema causa uno o piu’ incidenti)
- Gli incidenti vengono inviati a chi gestisce le singole funzioni, per analisi.
Ora, stabilito che NON VOLEVAMO la rinuncia del 40% degli iscritti, e preferiremmo che tutti partecipassero , ci sono diversi “stakeholders”:
- Gli utenti si sono iscritti ad una lista, inviando i documenti. Qualcuno si sara’ occupato di riceverli, abilitar gli utenti ed inviare le lettere di risposta con le istruzioni per usare il servizio. Primo incidente: gli utenti hanno ricevuto in tempo ogni cosa? Investigare e fornire numeri.
- Secondo punto: gli utenti avranno ricevuto istruzioni su come accedere al servizio. Incidente: quanti hanno ricevuto le istruzioni in tempo? Investigare e fornire numeri.
- Terzo punto: ricevute le istruzioni, alcuni le avranno trovate sufficienti, altri no. Ci sara’ un customer care, che avra’ delle chiamate , che sono registrate, e una certa qualita’ (campionando un certo numero di telefonate da registrare). Terzo incidente: fornire numeri su questa funzione.
- Quarto punto: l’utente e’ entrato nel sistema? Un dipartimento che si occupa di frontend potra’ fornire i dati di accesso. Quanti hanno acceduto almeno alla login page quanti login sono riusciti e quanti falliti? Investigare e fornire numeri.
- Quinto: quanti hanno acceduto alla pagina regolarmente in passato ma non per le quirinarie o per le parlamentarie? Frontend, fornire numeri.
- Sesto: all’utente piace questa cosa? Ci sara’ un posto ove mettere un feedback , e qualcuno li raccogliera’. Un dipartimento se ne occupera’. Investigare e fornire numeri.
Una volta splittato il problema in incidenti, si assegnano gli incidenti e si analizzano i numeri. Se nessuno di questi punti mostra un fallimento, allora il problema non e’ di processo, ma viene prima, ed e’ un problema di successo.
Qui entrano in campo persone che avevano definito i CSF http://en.wikipedia.org/wiki/Critical_Success_Factor e via dicendo. Come ho gia’ spiegato, non e’ il mio lavoro. Io mi fermo alla gestione “informatica” del prodotto.
A quel punto, poi chi gestisce il prodotto in se’ dovra’ capire quale “Quality gate” ha mancato. Questo e’ il campo che mi e’ piu congeniale dei CSF ma e’ piu’ distante da me, perche’ gli unici quality Gate di cui mi occupo nella costruzione di un servizio sono quelli legati all’infrastruttura, quindi mi limitero’ ad un modello di Quality Gate per la messa live di un servizio IT. (che di solito ha un software alle spalle).(2)
Supponiamo che non ci siano problemi di processo , ovvero che tutti i punti del processo funzionino, semplicemente il cliente non usa il prodotto. In quel caso, sembra che il problema sia in G0, che normalmente contiene la fase di “ideazione” del prodotto stesso. Esso e’ pensato per fare una cosa che gli utenti non vogliono davvero fare. E questo e’ il fallimento che porta da 9 milioni di elettori a 48 mila iscritti.
Puo’ succedere che e’ un problema , sempre in G0, legato al fatto che l’utente non si fida del media, la raccomandata coi documenti, o non vuole usarlo, o non si fida di chi poi terra’ i documenti. Siamo sempre in fase di ideazione.
Se invece si iscrivono in 48.000 e poi usano il servizio solo in 28.000, possono esserci diversi gates mancati, dall’implementazione alla scarsita’ di portfolio, nel senso che magari si vota poco, o su poche cose , insomma l’idea in se’ piace, ma poi mancano use cases interessanti. Qui il fallimento sta , e bisogna stabilire dove , nei quality gates successivi:
Adesso, so che cosa avrete in mente: ma tutti quei disegni non sono altro che buon senso!
Ora, tutto questo non appare altro che essere una formalizzazione del buon senso. Perche’ il buon senso viene formalizzato in schemi e tabelle piu’ o meno colorate/i , e in terminologie piu’ o meno esotiche?
Nessuno pensa che questi concetti siano alieni o troppo difficili, quello che si vuole fare e’ molto semplice:
- Terminologia. Fornire a tutti una terminologia snella , per la quale se io dico “CAB” intendo Change Advisory Board, e tutti capiscono la stessa funzione. Allo stesso modo deve essere chiaro a tutti che se dico “processo” non intendo la stessa cosa di “funzione”, in quanto la funzione e’ contenuta in se’ stessa. Cosi’ si identifica con chiarezza ogni cosa.
- Sistematicita’: tutti seguiamo gli stessi metodi, significa che tutti svolgeremo ALMENO un certo numero di passi considerati indispensabili.
- Sequenzialita’: tutti seguiremo le stesse procedure, col risultato che potremo dire in che punto siamo nel lavoro, e tutti capiranno la stessa cosa.
- Metriche: se tutto e’ diviso in pezzetti uguali, posso capire chi lavora piu’ velocemente e chi meno velocemente.
Insomma, il punto e’ che magari voi COME SINGOLI non avete bisogno di tutto questo, ma ne ha bisogno l’azienda come sistema complesso pieno di persone. E ne ha bisogno perche’ vuole che le persone si capiscano tra loro in fretta, che usino metodi analoghi cosi’ da potersi aiutare meglio, che svolgano ALMENO un certo numero di “pezzetti di buon senso”, numero e tipo chiari sin dall’inizio, e che lavorando tutti allo stesso modo possano anche essere confrontati. I framework non servono a voi, servono alle aziende ove volete lavorare. Se non ne conoscete nessuno, sarete bravi quanto volete, e vi troverete a venire “misteriosamente” sorpassati dagli altri, oppure finirete a fare “i lavori che nessuno vuole fare”. Vi consiglio vastamente di conoscere uno o due di questi framework.
Sicuramente, FUORI da questi framework possono esserci degli autodidatti molto bravi a parlare, a “ggestire”, a “spegare” a “comunicare”, normalmente si tratta di persone che sanno parlarvi otto ore di qualcosa senza dire niente, e “senza dire niente” significa che, non usando framework riconoscibili (ITIL, MOF, 6sigma, e-tom, PMP, etc) quel che dicono risulta letteralmente incomprensibile agli altri.
Per dirne una, il comunicato stampa di DNV puo’ essere anche stato interessante per i politici, magari per i giornalisti, ma per gli addetti ai lavori non c’era scritto niente.
Quando ho letto il comunicato di DNV dopo l’ “attacco hacker”, per dire, la mia sensazione e’ stata questa:
Sicuramente, un venditore troppo bravo riuscira’ a prendere questo ed infilarlo in una galleria d’arte , e magari a venderlo bene, come hanno fatto quelli di DNV, ma dal punto di vista degli addetti ai lavori, quello non puo’ essere un documento tecnico. Certo, Santi Licheri sembra un giudice (lo era) e Forum sembra un processo, ma un esperto di procedura civile lo trova piu’ o meno come uno scarabocchio. Questo perche’, anche se ai profani sembrera’ che Licheri faccia le cose giuste, agli esperti apparira’ per cio’ che e’. Lo stesso dicasi per la disamina pubblica della questione degli “attacchi hacker” di Grillo (3)
Questo e’ il motivo per il quale i parlatori possono anche tacere: parlando non faranno altro che manifestare la propria incompetenza, e parlando di piu’ manifesteranno ancora piu’ incompetenza.
Chi ha fatto lo scarabocchio sopra, se vuole venderlo come progetto di un circuito elettrico, potra’ anche aggiungere altri scarabocchi, ma anziche’ migliorare la situazione aggiungendo scarabocchi, non fara’ altro che mostrare che non sa cosa sia lo schema di un circuito elettrico, e piu’ scarabocchi aggiunge, piu’ la situazione peggiora.
Uriel
(1) https://it.wikipedia.org/wiki/Use_Case_Diagram
(2) Un sistema di Quality Gates cambia a seconda del prodotto e delle tecniche in gioco. Per esempio, nel mondo dell’ auto avete invece questo:
(3)Anche in Italia si usano molto i quality gates per la qualita’ . Per esempio, ecco il framework che ho visto usare piu’ spesso per i processi di qualita’ nel mondo IT della penisola, quando vi lavoravo:
questo framework ha un nome, ed e’ “Riunione”.
