Kanban Split Column

Finalmente in Visual Studio Online sono stati introdotti alcuni miglioramenti alla Kanban Board, che per lungo tempo era stata lasciata senza sensibili miglioramenti. In questo ultimo update di VSO è stato introdotto una funzionalità realmente fondamentale, che aumenta di molto la possibilità di usare realmente la Kanban Board in TFS/VSO.

Il cambiamento di cui sto parlando è l’introduzione delle Split Columns, ovvero la possibilità di suddividere ogni colonna in due sotto-colonne, rispettivamente Doing and Done. Vediamo il perché questa funzionalità è cosi importante.

Si parte da un presupposto: Kanban è un processo PULL, in cui ogni stadio decide di prendere in carico una card dallo stato precedente, se e solo se non ha raggiunto il suo limite e se tutte le regole sono soddisfatte (regole aggiuntive e Definition of Done). Questo è il segreto e la base su cui poggia Kanban, ogni stadio inizia a lavorare su un task solamente se ha modo di farlo. Questo viene fatto per evitare ingorghi nel processo e per massimizzare il flusso. Lo strumento principale di Kanban è la Board, che deve permettere immediatamente di individuare i problemi affinché il team possa affrontarli.

Ora analizziamo la situazione seguente:

image

La situazione rappresentata ci dice che: le colonne di Analysis e Committed sono attualmente piene (3/3), quindi non è possibile aggiungere del Work In Progress a nessuna delle due colonne. La domanda che ci si pone è: lo stadio di Analysis non può prendere in carico nessun nuovo item, ma i tre item che sono attualmente nella colonna sono stati terminati o no?

La risposta alla domanda precedente è di fondamentale importanza. Supponiamo i due casi estremi. Caso A: i tre item nella colonna Analysis sono tutti “in progress” questo significa che la colonna Analysis è in stato di pieno regime. Caso B: i tre item nella colonna Analysis sono completati e pronti per lo stadio successivo, questo significa che la colonna Analysis è paralizzata, dato che non può prendere in carico nuovo lavoro fino a che la colonna successiva (Committed) non prende in carico ancora del lavoro. Purtroppo dalla Kanban Board precedente è impossibile discernere i due casi.

Senza entrare nei dettagli, stiamo toccando quella che è chiamata teoria delle code che stabilisce modelli matematici per predire l’avanzamento in una catena di processi. L’identificazione delle code è fondamentale in Kanban, ed è una delle ragioni principali per l’adozione stessa del metodo.

Il metodo Kanban ha come scopo la massimizzazione del flusso ed in questa ottica l’individuazione delle code è un’operazione di massima importanza.

D’altra parte, Eliyahu Goldratt nel suo libro “The Goal” ci dice che uno degli scopi di una organizzazione è: Maximize Throughput while Minimizing Inventory and Operating Expense. La declinazione nello sviluppo software non appare sempre semplice, se da una parte è chiara la parte di minimizzare le Spese (Operating Expenses), si può anche intuire la massimizzazione del flusso (Maximize Throughput, concetto su cui tornerò in un post successivo), è difficile capire come minimizzare lo stoccaggio (Minimizing Inventory), dato che alla fine il codice non occupa spazio :).

Kanban ci aiuta a rispondere a questo problema adottando la tecnica dello split column. Nel nostro account VSO, se premiamo il Customize column troviamo una nuova opzione per le colonne.

image

Quello che accade è che ogni colonna viene ora suddivisa in due sotto-colonne, Doing e Done; questo ci permette di iniziare ad individuare le code nel nostro sistema. Vediamo allora come sarebbero rappresentati i due casi precedenti adottando questa nuova funzionalità. Il CasoA: sarebbe cosi rappresentato

image

è chiaro che il sistema sta larvando bene, tutte le colonne sono impegnate e a pieno regime. Il CasoB avrebbe invece una rappresentazione molto differente.

image

Si è creata una coda tra gli stati di Analysis e Committed, dato che abbiamo la colonna Analysis bloccata dal fatto che il lavoro nella colonna Committed non sta proseguendo, per questo non vengono prese in carico (pull) le card terminate in Analysis e questo fa si che la colonna Doing di Analysis sia vuota e bloccata. Tutte le card che sono nella colonna Dona rappresentano infatti card in Coda per lo stadio successivo e possono essere paragonate a quello che Eliyahu Goldratt chiama Inventory in “The Goal”.

Se siamo d’accordo che è necessario minimizzare le code ed evitare che il lavoro si accumuli nelle colonne “done”, senza questa funzionalità, è impossibile capire dalla nostra Kanban Board se siamo nel CasoA oppure nel CasoB e si perde una informazione di vitale importanza.

Un altro valore secondario dello split column è permettere in maniera semplice allo stadio successivo, di capire quali card dello stadio precedente possono essere prese in carico. Senza la colonna Done infatti, quando si libera uno spazio nella colonna Committed, non è ben chiaro dalla Board quali card dello stadio precedente (Analysis) possono essere prese in carico, perché non si ha la distinzione tra ciò che è in corso d’opera e ciò che invece lo stadio precedente ha completato.

Gian Maria.

0  

Lean Startup in a Nutshell, parte 6 – Tools & Platforms

startup toolsCon questo post andiamo a chiudere la serie “Lean Startup in a Nutshell”, dando uno sguardo a tool e piattaforme utili soprattutto al mondo delle startup IT. La premessa è d’obbligo: le startup non sono legate esclusivamente al mondo dell’Information Technologies, così come non lo è Lean Startup.

E’ possibile affermare che, con rare eccezioni, lo strumento principe è una piattaforma Cloud (come accennato nel primo post della serie) che consente di creare una infrastruttura IT in modo rapido e dinamico, estendendola progressivamente e pagando solo per il suo reale utilizzo. I principali vantaggi dell’utilizzo del Cloud sono:

  • Pay-per-use & Continuous Innovation: si paga solo ciò che realmente si consuma, contenendo al minimo le spese e accedendo da subito a tecnologie all’avanguardia;
  • Mobilizzazione del Capitale, passaggio dalle spese in conto capitale (CapEx) alle spese operative (OpEx);
  • Riduzione del Time-to-Market, ovvero del tempo che intercorre dall’ideazione di un prodotto alla sua effettiva commercializzazione/disponibilità;
  • Scalabilità, Affidabilità e Sicurezza, garantite in modo costante;
  • Riduzione della Complessità Operativa, semplificando il modello di costo e abbattendo drasticamente i relativi costi operativi di gestione.

Ma gli strumenti a disposizione delle startup sono molteplici, e i campi a cui afferiscono vanno da quelli del coding al marketing: Building/Coding, Domain and Website Management, eCommerce, Design, Mobile, All Things Content, Social Media, Marketing Resources, Business/Legal Tools and Resources, ecc.

Volendo dare delle indicazioni, senza la pretesa di creare una lista delle soluzioni migliori (cosa umanamente impossibile visto anche che le alternative aumentano ad un ritmo giornaliero), possiamo individuare i seguenti tool da combinare alle varie esigenze di Lean Startup:

  • Validate Learning
    • MVP (prototipizzazione rapida): MockFlow, Balsamiq, PowerPoint, Visual Studio LightSwitch (BizSpark program)
  • Innovation Accounting:
    • Brand Value: Mention, Microsoft Power BI;
    • Social Media Presence Management: Buffer;
    • Social Media Influencers: Followerwonk;
    • Customer Satisfaction and Collaboration: Intercom, Freak, Streak
  • Build-Measure-Learn:
    • Team and Stockholders communication: Slack e VisualStudioOnline Team Room;
    • Application Lifecycle Management: Asana, VisualStudioOnline, Jira (GreenHopper);
    • Application Coding: Heroku, Visual Studio (BizSpark program)
    • IT Infrastructure: Microsoft Azure (BizSpark program), Google Cloud Platform for Startups, Aruba Cloud Startup

La maggior parte delle soluzioni proposte offrono piani gratuiti, spesso particolarmente generosi, che consentono di accompagnare la propria startup nella crescita e nella trasformazione in un’azienda con un business sostenibile.

 

asana  mockflow

heroku bizspark

Startup tools & platforms

Si conclude così il nostro viaggio introduttivo nel mondo di Lean Startup, viaggio in cui abbiamo evidenziato la validità dell’approccio proposto da Ries per la creazione di un business sostenibile che coniughi l’intuizione (Vision) degli imprenditori con gli strumenti indispensabili al suo raggiungimento.

Some love to Kanban Board in TFS

Nell’ultimo update di VSO che è stato effettuato ieri (http://www.visualstudio.com/news/2015-feb-18-vso) sono finalmente state fatte importanti modifiche alla Kanban Board, che era rimasta un po ferma da troppo tempo a mio avviso.

La prima novità è che è possibile aggiungere gli item direttamente dalla board, ma sicuramente la funzionalità piu succosa è la divisione delle colonne in doing e done. Non starò qui a sottolineare l’importanza di questa funzionalità, dato che senza la possibilità di capire quali Item sono realmente fatti e sono pronti per essere presi (pull) dalla colonna successiva, la Kanban board ha poco valore.

Nell’upgrade vi sono anche altre novità, tra cui la possibilità di assegnare piu persone alle test suites, e l’annuncio che le funzionalità di Application Insights saranno migrate nel nuovo portale di azure. Il nuovo link di riferimento per Application Insights è quindi il seguente: http://azure.microsoft.com/en-us/services/application-insights/

Happy VSO e buon fine settimana. Smile

Lean Startup in a Nutshell, parte 5 – Growth Engine

engineL’approccio scientifico proposto da Lean Startup consente di validare le proprie ipotesi, accelerando quanto più possibile il loop build-measure-learn. Finora abbiamo posto l’enfasi sul creare il “giusto” prodotto/servizio in linea con la Vision, rispondendo alla seguente domanda:

  • A value hypothesis: What product or service will satisfy that demand?

Ma la strategia scelta deve, inoltre, confutare una ulteriore e fondamentale ipotesi:

  • A growth hypothesis: How can growth be made sustainable so that it happens without requiring new funding?

che ci proietta sulle questioni inerenti la crescita del proprio business, andando a trasformare rapidamente, anche se gradualmente, il nostro “esperimento” in un’azienda in grado di generare e sostenere profitto.

strategy 2 values

Strategy: 2 values

Si tratta di ricercare un modello di crescita dipendente dal contesto che, per forza di cose, può evolvere in qualcosa di decisamente complesso. Tale attività rientra nelle “cose noiose” che sono il succo dell’Innovation Accounting, fondamentali per il successo del nuovo business.

La crescita passa, banalmente, dall’acquisizioni di nuovi clienti. Tale processo è ben rappresentato da Steve Blank (“The Startup Owners Manual”) che definisce tre step fondamentali per attuarlo, andando a coniare l’acronimo: GKG: Get (Customer) Keep (Customer) Grow (Customer). In sintesi l’obiettivo primario è quello di acquisire (GET) un numero iniziale di clienti sufficienti a sostenere il proprio business, creando le condizioni per fidelizzarli (Keep) e quelle affinché si riesca ad ottenere una crescita sostenibile (Grow) che porti nuove risorse finanziare da investire in nuovi esperimenti.

Durante la fase di crescita bisogna fare particolare attenzione ai nuovi fattori, spesso in contrasto:

  • esigenze dei clienti attuali;
  • ricerca di nuovi clienti;
  • gestione (aggiustamento) dell’attuale modello di business;
  • esplorazione di nuovi business model.

Tali fattori (non esclusivi) vanno bilanciati attraverso pratiche di gestione (anche qui, Innovation Accounting docet), come:

  • gestione oculata delle risorse, finite ma garantite. Un budget eccessivo può portare a rilassarsi, mentre è fondamentale che quello allocato non venga tagliato al fine di garantire una tranquillità nelle attività;
  • concedere autonomia nello sviluppo. I Team impegnati nella sperimentazione devono essere relativamente liberi di organizzarsi e provare nuove soluzioni;
  • stimolare e premiare i dipendenti. Stock options e bonus sono un buono strumento per spronare i dipendenti a dare il meglio di se.

Blank propone di approcciare al GKG secondo lo schema seguente:

gkg

The Startup Owner’s Manual”: Get-Keep-Grow

in cui le varie fasi possono contare su una serie di tool e soluzioni, ben riassunte nella figura seguente:

gkg explined

GKG tools and solutions

La crescita, in particolare, garantisce la trasformazione della startup in un’azienda consolidata, grazie alle revenue annesse e alla possibilità di investire in nuovi progetti/iniziative/servizi. Non sorprende, quindi, la sua trattazione esplicita in Lean Startup, che si concentra sui cosiddetti motori di crescita (Growth Engines) da applicare al proprio “esperimento” ed inquadrabili in due modelli fondamentali:

  • Jump-start Engine, basati su azioni una tantum, come, ad esempio, l’acquisto di ADV slot sui più noti motori di ricerca;
  • Sustainable Engine, basati su azioni che generano un flusso continuativo di crescita.

Soprassedendo sul modello “Jump-start”, di facile comprensione, il modello “sostenibile” è suddivisibile in tre specifiche categorie:

  • Sticky: i clienti che provano il prodotto/soluzione decidono di utilizzarlo regolarmente (es. acquisti ripetuti o abbonamenti). Questo modello di crescita spinge la startup a concentrarsi sui clienti che ha già acquisito: un cliente felice vale più di 100 passaggi pubblicitari!
  • Viral: basato sul passaparola (word of mouth), diretto o indiretto. Nel primo caso l’utente fa da promotore esplicito del prodotto, nel secondo è l’utilizzo implicito che contagia gli altri (side effect: l’esempio più ricorrente è il colore delle cuffie bianche dell’ipod che ne hanno spinto le vendite). La “misura del contagio” può essere fatta attraverso un viral coefficient (VC), ovvero il numero dei nuovi utenti generati dai vecchi:
    • VC molto inferiore a 1, il trend di crescita è breve. Si immagini di avere VC=0.1, ciò significa che 100 utenti ne portano 10, quei 10 ne porteranno 1 e poi l’effetto virale termina;
    • VC uguale (o molto vicini) ad 1, il trend di crescita è costante;
    • VS maggiore di 1, crescita esponenziale.

L’ideale è che ogni cliente “contagi” almeno 1 nuovo utilizzatore (meglio più di uno, chiaramente) a provare il prodotto/servizio.

Tale motore è particolarmente difficile da attuare perché richiede che il prodotto superi le attese stesse dei clienti e che il target di riferimento sia perfettamente inquadrato: in caso contrario l’effetto virale termina rapidamente e il numero di clienti tende presto a stagnarsi;

  • Paid Growth: ottenimento di nuovi clienti tramite investimento diretto. La forma più comune di questo approccio è, banalmente, la pubblicità, ma possiamo anche citare l’impiego dei call center o l’apertura di sedi di rappresentanza in punti strategici particolarmente trafficati. Il fattore predominante è il profitto marginale, ovvero la differenza tra il valore totale del cliente (lifetime customer value , il profitto legato al cliente) e il costo marginale (costo di acquisizione del cliente).

Questo motore richiede che si verifichi costantemente la copertura dei costi: finché si ottiene un profitto su ogni cliente, è possibile investire i profitti stessi in ulteriore pubblicità per accelerare la crescita.

Ovviamente, i modelli di growth engine possono essere combinati, ma per ottenere delle metriche specifiche che ne convalidino i risultati (Actionable Metrics) è fondamentale che si riesca a misurare puntualmente il loro effetto. Bisogna, inoltre, tener presente che un growth engine va legato ad un breve/periodo di riferimento, dopodiché può perdere rapidamente efficacia rendendo necessario un rinnovamento di strategia o, in extremis, un PIVOT.

Prima di concludere è cruciale evidenziare che quando l’azienda passa da uno stato di startup ad uno stato “consolidato”, non è ovviamente più possibile fare esperimenti continui sul prodotto o sulla soluzione core, dovendo garantire un alto livello di qualità ai propri clienti. In tal caso è opportuno approcciare una (mini) divisione o un (mini) Team che ha il compito di continuare a sperimentare soluzioni innovative parallelamente al core business.

Con questo quinto appuntamento ci avviamo alla fine della serie, lasciano spazio nel prossimo ed ultimo post ad una rassegna di tool e piattaforme che facilitano l’applicazione dei concetti di Lean Startup.

Intervista su EssentialSQL.com

Quest’oggi ho avuto l’onore di vedere pubblicata l’intervista che Kris Wenzel (twitter | linkedin) mi ha fatto sul suo interessantissimo EssentialSQL.

Per chi non lo sapesse EssentialSQL è una risorsa molto utile per avvicinarsi e capire SQL Server, anche per chi vuole studiarlo e vuole imparare a conoscerlo. 
Come espresso nella homepage:
            “Now it is time to learn SQL in simple English.
L’obbiettivo di Kris è quello di:
- Fornire un approccio step-by-step ai lettori
- Ottimizzare il tempo di chi segue focalizzandosi sui topic utili per il lavoro del lettore
- Rispondere alle domande poste nei commenti
Insomma, un servizio di grande aiuto. Qui Kris spiega le motivazioni che lo hanno spinto ad offrire questo servizio.
Per me è stata una chiacchierata molto interessante, su un topic che ormai è sempre presente nelle mie giornate lavorative. Abbiamo parlato di Source Control su database, di tool disponibili, ed infine, anche di testing su database. E come poteva essere diversamente? 
Abbiamo anche rispolverato alcune delle worst practices che ho visto seguire nel tempo, ormai tanto tempo fa. Ed ancora, mi è stato chiesto un elenco di suggerimenti da dare a chi si avvicina a SQL Server.

Insomma, se avete un paio di minuti, date una letta all’intervista qui.

Stay tuned! 

Code search–In preview su VSO

Il blog di VS ALM ha appena pubblicato questo post in cui viene mostrata una nuova funzionalità, ancora in limited preview, presente su Visual Studio Online, il Code Search.

In un progetto è spesso di vitale importanza poter effettuare una ricerca nel source control, alla ricerca di una particolare porzione di codice, oppure di una classe con un particolare commento, etc. Le nuove funzionalità di ricerca introdotte in VSO permettono infatti di effettuare una ricerca semantica, in cui I risultati vengono suddivisi in base alla porzione di codice dove viene effettuato il match. Ad esempio I risultati ci permettono di dire se il testo cercato è presente in un commento, oppure in una dichiarazione di classe Etc.

E’ anche possibile andare a richiedere direttamente un filtro per restringere lo “scope” della ricerca, Es: class: per ricercare nelle dichiarazioni di classe, oppure comment: per cercare all’interno di un commento. La lista completa è presente nel post del blog sopracitato e la riporto per comodità.

image

Attualmente, data la natura di preview di questa funzionalità, esistono delle limitazioni. Il servizio è disponibile solamente per gli account del Nord America, e per progetti che utilizzano Git; la ricerca viene inoltre fatta solamente nella master branch ed il supporto ai linguaggi è per ora disponibile per C#, C e C++.

Gian Maria.

Code search–In preview su VSO

Il blog di VS ALM ha appena pubblicato questo post in cui viene mostrata una nuova funzionalità, ancora in limited preview, presente su Visual Studio Online, il Code Search.

In un progetto è spesso di vitale importanza poter effettuare una ricerca nel source control, alla ricerca di una particolare porzione di codice, oppure di una classe con un particolare commento, etc. Le nuove funzionalità di ricerca introdotte in VSO permettono infatti di effettuare una ricerca semantica, in cui I risultati vengono suddivisi in base alla porzione di codice dove viene effettuato il match. Ad esempio I risultati ci permettono di dire se il testo cercato è presente in un commento, oppure in una dichiarazione di classe Etc.

E’ anche possibile andare a richiedere direttamente un filtro per restringere lo “scope” della ricerca, Es: class: per ricercare nelle dichiarazioni di classe, oppure comment: per cercare all’interno di un commento. La lista completa è presente nel post del blog sopracitato e la riporto per comodità.

image

Attualmente, data la natura di preview di questa funzionalità, esistono delle limitazioni. Il servizio è disponibile solamente per gli account del Nord America, e per progetti che utilizzano Git; la ricerca viene inoltre fatta solamente nella master branch ed il supporto ai linguaggi è per ora disponibile per C#, C e C++.

Gian Maria.

0  

Lean Startup in a Nutshell, parte 4 – Learn

Realizzato l’MVP e Misurate le risposte degli utenti, early adopters o clienti che siano, è giunto il momento di “tirare le somme” ed eliminare gli sprechi: siamo nella fase di Learn. Prima di continuare è utile sottolineare che tutte le attività che sottendono Lean Startup si basano sul principio Genchi Gembutsu: «vai e verifica di persona», invitando l’imprenditore a non rilassarsi e ad essere sempre presente e vigile nelle azioni chiave finalizzare alla creazione del nuovo business.

Per la fase di Learn, ripartiamo dai risultati ottenuti tramite le Actionable Metrics (si veda il post precedente) che consentono di valutare in modo indiretto la risposta degli utenti, tracciandone i comportamenti e osservando le reazioni ai cambiamenti.

learn

A questi dati, però, è utile aggiungere anche un’analisi diretta, utilizzando strumenti ben noti al mondo del marketing come le Interviste/Questionari o i Focus Group. Bisogna fare attenzione a valutare con parsimonia i risultati che si ottengono dall’approccio diretto, perché vale sempre la massima che “spesso il cliente non sa quello che vuole o non sa come specificarlo”.

take notes

 

Quasi sempre l’analisi dei risultati è orientata alla ricerca del risultato negativo: si cerca di capire se si ha un riscontro negativo del prodotto/servizio in modo da confutare le proprie tesi.  Gli utenti, lo ricordiamo, non sono tutti uguali, e nel processo di crescita attraverso i vari loop build-measure-learn, è fondamentale sceglierli accuratamente tenendo ben ferma la propria Vision. Quello che bisogna essere pronti a cambiare è la Strategia, laddove, oggettivamente, la strada intrapresa non stia dando i risultati sperati. Lean Startup raccoglie questa sfida con il PIVOT tool, che reagisce ad una domanda fondamentale: I miei dati validano la mia ipotesi iniziale?

  • [no] Pivot, le ipotesi sono fondamentalmente sbagliate ed è necessario cambiarle;
  • [si] Preserve, si continua sulla strada intrapresa.

pivot

PIVOT

Fondamentalmente, “fare PIVOT” consiste nella formulazione di una nuova ipotesi e nella sua validazione attraverso un nuovo ciclo di Validate Learning Testing. Ricordiamo che in un terreno incerto come quello in cui operano le startup, l’apprendimento convalidato (validated learning) è il fattore di misura dei progressi raggiunti, esattamente come la qualità dei prodotti può esserlo per il settore manifatturiero.

Esistono diversi tipi di PIVOT:

  • Zoom In: una feature diventa l’intero prodotto;
  • Zoom Out: un prodotto diventa una feature di un nuovo prodotto più grande;
  • Customer Segment: il prodotto funziona, per un segmento diverso da quello a cui lo avevo destinato nei miei piani, faccio diventare questo segmento inaspettato il mio target principale;
  • Customer Need Pivot: il prodotto va bene in parte, l’ipotesi era parzialmente vera, l’utente stesso mi dice che vuole una cosa leggermente diversa;
  • Platform Pivot: trasformo il prodotto da un applicazione a una piattaforma o viceversa;
  • Business Architecture Pivot: passo da una struttura ad alto margine e basso volume (B2C) ad una a basso margine ed alto volume (B2B), o viceversa;
  • Value Capture Pivot: cambio il revenue model;
  • Engine of growth pivot: cambio l’engine della crescita (ne parleremo nei prossimi post), che di solito può essere viral, sticky o paid growth;
  • Channel pivot: cambio il canale di vendita;
  • Technology Pivot: cambio la tecnologia adottata, ma non il business.

Nella valutazione della risposta degli utenti è fondamentale capire quali sono le cause di insoddisfazione e dei problemi riscontrati. Per fare ciò Lean (Startup) propone la Five Whys Analysis, uno strumento di root analysis pensato per scalfire la superfice del problema ed arrivare al vero motivo del perché esso si è verificato grazie ad una drill down analysis.

Il tool è semplice da applicare e consta di due fasi: analisi e azioni risolutive bilanciate. La prima si attua ponendo ripetutamente (max per 5volte) la domanda “perché” ad ogni risposta inerente il problema:

fivewhys example

Five Whys Analysis Example

Scovata la radice del problema, nell’esempio: “L’azienda non ha investito in formazione” (cosa che non sarebbe venuta alla luce se non si fosse scavato in fondo alla questione), si passa alla seconda fase che consta nell’intervenire ad ognuno dei livelli evidenziati, proporzionalmente all’incidenza sul problema. Sempre nel caso di esempio, il maggior investimento sarà fatto, presumibilmente, nel formare un nuovo DBA.

Nel prossimo post della serie ci dedicheremo agli aspetti della crescita (growth) della startup e del concetto applicato di “engine”.

Lean Startup in a Nutshell, parte 3 – Measure

Creato l’MVP è ora di passare alla “misurazione” della reazione dei nostri clienti (early/potenziali/finali) al fine di poter applicare le pratiche annesse all’Innovation Accounting, che, come descritto nel post introduttivo, consentono di capire se si stanno facendo progressi o se la strategia adottata va modificata (PIVOT) perché non produce i risultati attesi.

measure                       

Per poter misurare correttamente i reali miglioramenti ottenuti è fondamentale affidarsi a Metriche Perseguibili (Actionable Metrics), che consentono di effettuare analisi su dati che fotografano lo stato reale del business, eliminando false valutazioni (Vanity Metrics). In generale, una metrica è perseguibile se è:

  • Impugnabile: chiara causa ed effetto;
  • Accessibile: facile da capire e maneggiare;
  • Controllabile: i dati devono essere attendibili.

Bisogna quindi avere una reale comprensione di ciò che si vuole misurare e del campione di utenza di riferimento, cosa che ci porta nell’ambito della Cohort Analysis, in cui le valutazioni sono basate su gruppi temporanei, omogenei ed indipendenti di utilizzatori con caratteristiche ed interessi affini. La Cohort Analysis, che si contrappone alla pratica di considerare gli utenti come “un unico gruppo”, è molto utile per analizzare la crescita andando a considerare i nuovi utenti in modo distinto da quelli precedenti. In tal modo, ad esempio, una startup può validare la capacità delle modifiche apportate di attrarre nuovi clienti, così come un’eventuale regressione. Per ogni Cohort (gruppo) deve essere possibile rispondere a domande come:

  • Quanti utenti del gruppo hanno utilizzato la nuova funzionalità?
  • Quanti utenti del gruppo hanno acquistato il prodotto?
  • Quanti utenti hanno lamentato un peggioramento della user experience?

E’ interessante evidenziare la possibilità di sfruttare la Cohort Analysis per la cosiddetta pratica del “killing features”: viene rimossa una funzionalità e si verifica cosa accade. Se le metriche di rilievo non subiscono cambiamenti significativi è possibile migliorare il prodotto nel complesso eliminando la funzionalità in modo da renderlo più snello e semplice da manutenere.

Nell’attività di analisi del nostro gruppo di clienti, è possibile sfruttare un’analisi Conversion Funnel. Nata nel mondo dell’e-commerce, tale analisi consente di tracciare il percorso (pagine) fatto da un cliente da quando clicca su un banner pubblicitario a quando finalizza l’acquisto, ottenendo Actionable Metrics legate, ad esempio, all’analisi delle pagine (o aree tematiche) su cui i clienti si soffermano maggiormente, piuttosto che conteggiare banalmente il numero di visitatori (Vanity Metrics).

conversion funnel

Conversion Funnels

A cosa ci serve la Conversion Funnel Analysis? Gli usi sono chiaramente molteplici, ma proviamo a fare un semplice esempio: dalla nostra analisi “misuriamo” che su 100 visitatori (potenziali clienti), 30 arrivano ad inserire un acquisto in catalogo, ma solo 3 completano l’acquisto stesso. Una delle ipotesi di tale riduzione è che il “carrello” abbia difficoltà intrinseche nel far completare la fase di acquisto, possiamo quindi scegliere di provare, ad esempio, a modificare la User Interface relativa per semplificare la fase finale di acquisto.

Un’ulteriore strumento di analisi, legato al comportamento del singolo cliente/utilizzatore, è il Net Promoter Score (NPS), che, in modo semplicistico, è possibile definire come il “tasso di passa parola”:

Qual è la probabilità che lei raccomandi il prodotto ad un amico o un collega?”

La domanda base può essere riformulata in diversi modi [Sean Ellis]:

“Sarebbe molto deluso se non potesse più utilizzare il prodotto?” oppure

“Ritiene il prodotto un must-have?”

In pratica si analizza la penetrazione virale della soluzione, consentendo alla startup di essere sempre focalizzata sul risultato finale che si vuole ottenere. Se si supera una percentuale del 40% di risposte affermative, la strategia intrapresa può essere ritenuta valida (stima empirica), altrimenti è ora di operare un PIVOT! (capiremo meglio cosa significa nei prossimi post della serie).

net promoter score

Net Promoter Score

Fin ora abbiamo ragionato in termini di variabilità degli utenti, ma se si utilizza un campione di riferimento costante, o se si stanno eseguendo i primissimi loop build-measure-learn in cui gli utenti sono gli early adopters, uno strumento particolarmente utile è lo Split Testing (o anche A/B testing), attraverso il quale è possibile verificare la reazione alle modifiche dividendo il campione in due macro-gruppi e consegnando loro due versioni leggermente differenti della soluzione.

split testing

Split Testing

Le differenze devono essere veramente minime (a livello atomico di modifica): una feature presente solo in una delle due alternative, il cambio di un bottone sulla UI, la modifica dei colori, ecc. In tal modo è possibile misurare in modo puntuale la reazione dei due gruppi alle alternative presentate e capire quali di esse risponde in maniera migliore alle esigenze degli utilizzatori.

Lo split testing è, inoltre, un ottimo approccio per misurare la reale utilità di una nuova feature: se si rilasciano due MVP in cui solo uno è dotato di una feature extra e questa viene praticamente ignorata dal gruppo di utilizzatori di riferimento, vuol dire che essa non è percepita come valore e non è utile investire su essa. In generale, uno split testing ben impostato segue due regole basilari:

  • Semplice da implementare da un punto di vista del codice (on-line development);
  • Facile da utilizzare per le metriche di analisi sui cui prendere specifiche decisioni.

Ad onor del vero lo split test può essere usato sempre, anche quando si è in fase di acquisizione di nuovi clienti, ma ciò rende più difficile valutare le reazioni perché i fattori da considerare si moltiplicano.


Si conclude qui il nostro terzo post dedicato a Lean Startup, nel prossimo appuntamento ci dedicheremo all’ultimo step del loop build-measure-learn.

Nuovo sondaggio su database e Source Control

Ormai sono completamente orientato alla parte di ALM su database (DLM – Database Lifecycle Management) e quindi sono proprio curioso di capire come vi muovete in questo ambito, sempre più presente e ricco di possibilità. 

Se pensiamo non troppi anni fa, le operazioni su database per la gestione del suo ciclo di vita erano proprio poche, e pochi erano i tool disponibili. Ora, oltre a Visual Studio (o SSDT o come vogliamo chiamarlo ) ci sono strumenti di terze parti che semplificano notevolmente il lavoro, soprattutto per quanto riguarda l’integrazione continua (Source Control – Test – Deploy).
Ho pubblicato un sondaggio per la parte di source control.. I vostri database sono sotto controllo del codice sorgente?
Fate la vostra selezione direttamente sul blog (in alto a sinistra).
Se la risposta non è tra quelle elencate, mandatemi un PM che ne discutiamo insieme.
Attendo le vostre risposte..
Stay tuned!