Rinominare un Team Project in VSO

Una delle funzionalità più richieste è ora disponibile in Visual Studio Online, la possibilità di rinominare un Team Project, vediamo come.

Il primo passo è andare nell’area di amministrazione tramite il link diretto  https://nomedelvostroaccount.visualstudio.com/DefaultCollection/_admin oppure semplicemente premendo il simbolo dell’ingranaggio in alto a destra. a questo punto a lato del Team Project appare la freccia del menù contestuale, da cui potete scegliere il Rename.

image

Una volta scelto il rename basta semplicemente specificare il nuovo nome.

image

A questo punto è il caso di leggere attentamente il disclaimer, l’operazione di rename project è una operazoine che porta molti cambiamenti.

image

L’aspetto più noioso è che, se utilizzate i workspace locali con TFVC, se non avete Update5RC o VS 2015RC o superiori, siete costretti a ricreare il workspace. Questo significa che se avete modifiche pendenti, dovete fare shelve, cancellare il vecchio workspace, rifarlo e rifare unshelve. Se usate git è tutto molto più semplice, perché basta cambiare il remote ed il gioco è fatto. Se vi scordate comunque il messaggio di errore che ricevete è particolarmente chiaro

image

Trovate comunque nel link http://vsalmdocs.azurewebsites.net/Library/vs/alm/admin/project-rename tutte le informazioni necessarie per svolgere queste operazioni in dettaglio, per cui non è il caso di preoccuparsi troppo. Una volta premuto il bottone Rename Project, il sistema inizia le operazioni, al termine delle quali, il vostro progetto è rinominato.

Tra le cose interessanti vi è il redirect automatico, ovvero se qualche membro del team ha memorizzato qualche url come

https://gianmariaricci.visualstudio.com/DefaultCollection/Experiments/_versionControl#path=%24%2FExperiments%2Ftrunk%2FElasticsearch%2FMusicDb&_a=contents

Andandola a mettere nel vostro browser preferito potrete notare che è ancora valida, sebbene parte della url contenga il vecchio nome del Team Project. Chiaramente se andrete a creare un nuovo Team Project con il nome del vecchio, il redirect non funzionerà più, dato che in quel caso vi starete riferendo al nuovo Team Project.

Attualmente l’unico reale drawback del rename è la necessità di andare a modificare le build di TFVC, specificando il nuovo path dei progetti, operazione che deve essere fatta ancora manualmente, ma confidiamo che in futuro anche l’aggiornamento delle build sarà fatto automaticamente.

Kudo al Team di VSO per avere finalmente soddisfatto una delle richieste più votate di tutti i tempi.

Gian Maria.

0  

Team Project Rename in VSO

Con l’update di Aprile 24, in VSO è ora disponibile il Rename per il Team Project, potete leggere tutti i dettagli in questo post. Questa funzionalità è stata per lungo tempo la piu votata di User Voice, penso quindi che questo update faccia felici molte persone.

Gian Maria.

Agile Planning… are you sure?

“Pianificare” è un termine che difficilmente si è portati ad associare alle metodologie Agili, implicando aspetti di gestione e management che, erroneamente, fanno pensare a vecchi retaggi del passato in chiave BigUP Front.

Ma è davvero così? La risposta è semplice ed immediata: assolutamente no!
Anche nel mondo Agile l’attività di pianificazione ha un ruolo decisamente forte: in fondo quale manager autorizzerebbe un progetto senza avere neanche minimamente idea dell’effort richiesto?

Quello che differenzia il planning in chiave Agile da quello BigUP Front è la consapevolezza di non poter definire tutto prima dell’inizio di un nuovo progetto, riconoscendo la necessità di rivedere costantemente e, in più fasi, le ipotesi inziali. Volutamente ho usato il termine ipotesi e non pianificazione, proprio perché nella fase di Inception (rif. DAD) possiamo solo ipotizzare quella che sarà la caratterizzazione del nostro progetto in termini di tempo, costi e funzionalità.

Chiaramente, posso trovarmi nelle condizione di dover affrontare progetti time-fixed, cost-fixed e time/cost-fixed, nel qual caso l’unica variabile su cui poter intervenire sono le funzionalità. Inutile dire che se sono in condizione di time/cost/features-fixed, probabilmente, il prodotto sarà di qualità opinabile, soprattutto se tale vincolo viene posto in fase di Inception.

iron triangle planning

Iron Triangle Planning

In chiave Agile la pianificazione è un’attività intensiva che accompagna l’intero processo di Application Lifecycle Management e che si spalma addirittura ben sei livelli di pianificazione, noti sotto il cappello di Planning Onion, coniato da Mike Cohn. In realtà si sta diffondendo l’idea che esiste un livello trasversale che è quello “Culturale”, ma per ora, essendo oggetto di dibattito, non sarà oggetto della nostra trattazione.

agile planning onion

Agile Planning Onion

L’idea di fondo è che il planning coinvolge una serie di livelli interconnessi, che vanno dalla prospettiva più ampia (Strategia) a quella più di dettaglio specifico (Daily).

Lo Strategy Planning e il Portfolio Planning avvengono al Portfolio Level (rif. SAFe) e condizionano le scelte aziendali a medio-lungo termine, 3-5 anni. Non si tratta di decidere cosa fare nello specifico, bensì di capire come l’azienda vuole porsi rispetto al mercato e quali opportunità cogliere/perseguire per soddisfare la propria Vision. Nel Portfolio Planning, la strategia si concretizza in “famiglie di prodotti”, differenziate per aree e per obiettivi e vengono individuate le risorse di area necessarie. Questi livelli di planning sono chiaramente quelli che vengono rivisti meno frequentemente, evidenziando che nella “Onion” i livelli esterni sono quelli più stabili. Attenzione, però: anche qui esiste una differenza rispetto all’approccio tradizionale dove, tipicamente, si guarda alla strategia in occasione dei bilanci e dei meeting annuali. In linea di principio sarebbe opportuno dare una rispolverata al piano almeno ogni trimestre/quadrimestre.

Il Product Planning è un po’ il “collante” tra gli aspetti strategici a la loro applicazione nel concreto. In quest’ambito viene definito l’insieme dei prodotti che si intende realizzare e si procede all’approvvigionamento delle risorse necessarie. Tipicamente la pianificazione di prodotto, afferente il Program Level, interessa un intervallo temporale medio-breve che possiamo individuare in 12-24 mesi. Qui viene individuato anche il Product Owner per lo specifico progetto, viene creata una road-map di sviluppo e viene effettuato un Grooming preliminare del Product Backlog.

Una volta identificati i prodotti da realizzare, arriviamo ai tre livelli che interessano direttamente le attività di realizzazione del software: Release Planning, Iteration Planning e Daily Planning, posizionandoci nel Program/Team Level ne caso della prima tipologia e nel Team Level per la seconda e la terza. Nel caso del Release Planning, il tipico Team Agile comincia ad essere coinvolto in modo forte, andando a definire e rivedere il set di features da inserire nella specifica release. L’Iteration Plannig ed il Daily Planning sono il pane quotidiano dell’Agile Team che incide direttamente sulla decisione di cosa realizzare nella successiva iterazione (1-4 settimane) e si confronta giornalmente su come stanno procedendo le attività. Tali livelli sono anche i più flessibili e quelli che permettono di abbracciare repentinamente il cambiamento.

Si intuisce quindi, come accennato, che i livelli esterni sono quelli più stabili, o, se si vuole leggere la cosa con una diversa chiave di lettura, quelli a forte rischio perché determinano, a cascata, tutte le attività (e le pianificazioni) dei livelli interni: un errore nello Strategy Planning può essere fatale, mentre uno a livello di Daily Planning, probabilmente, è sempre tollerabile.

La pianificazione viene supportata in modo diretto dalle piattaforme di gestione ALM, sia con funzionalità interne, sia consentendo di esportare i dati necessari per l’elaborazione con strumenti dedicati. In particolare, è possibile sfruttare le capacità di Visual Studio Online di esporre i dati delle attività (tramite RESTServices OData) e utilizzarli all’interno di strumenti di BI come PowerBI e lo stesso Excel, al fine di supportare le attività di analisi e pianificazione.

A questo argomento dedicheremo una serie di post in seguito.

Ancora novità nella Kanban Board di VSO/TFS

Nei precedenti post abbiamo parlato delle novità che sono state introdotte nella Kanban Board di VSO:

Kanban Split Column

Novità di VSO Sprint 79

Definition of Done

Nell’ultimo deploy del 10 Aprile troviamo ancora ulteriori novità. In alto a Destra, potrete trovare un nuovo link, chiamato Settings, che vi permetterà di personalizzare le colonne (opzione già esistente) e le card (la nuova opzione introdotta con questo deploy).

image

La personalizzazione delle Cards permette di scegliere quali campi del Work Item saranno visibili nelle card della board. Ecco qui il pannello delle opzioni.

image

Come potete vedere, finalmente si ha la possibilità di mostrare l’ID del work item in alto a sinistra nella card. Si può poi scegliere se visualizzare avatar e FullName o solo l’avatar o solamente il nome per la persona a cui è assegnata la card. Infine si può scegliere se mostrare l’Effort e i Tag.

La possibilità di visualizzare i Tag è particolarmente importante, soprattutto in VSO, che ammanca ancora della funzionalità di personalizzazione dei Work Item. In Kanban infatti, non si tende a fare stime esatte dell’effort per ogni card, ma spesso basta il T-Shirt sizing: Small, Medium, Large, eXtra Large. Si può pertanto utilizzare i tag per categorizzare le proprie Card, ed avere una migliore visualizzazione:

image

In questo caso è immediatamente visibile la “dimensione” della card, in maniera molto chiara ed esplicita. Ricordo inoltre, che negli sprint precedenti è stata data la possibilità di fare editing in place del titolo della card, basta cliccare nella icona della matitina in alto a destra.

image

Sebbene questa serie di post sia focalizzata sulla Kanban Board, le personalizzazioni di cui vi ho parlato sono presenti anche per la TaskBoard. Ora anche per chi usa SCRUM e vuole scomporre lo Sprint Backlog in Task, è possibile decidere quali informazioni visualizzare nelle card.

image

In questo caso potete personalizzare l’aspetto dei Product Backlog Item e dei task separatamente. La possibilità di creare elementi direttamente nella board rende molto semplice e veloce creare la propria task board, partendo dai PBI dello sprint corrente.

image

Infine, è stata data anche la possibilità di utilizzare sintassi MarkDown nella Definition of Done delle varie colonne, permettendo quindi di avere una maggiore chiarezza, specialmente potendo usare elenchi puntati.

Gian Maria.

0  

Definition of Done nella Kanban Board di VSO

Negli ultimi aggiornamenti di VSO abbiamo potuto notare alcune importanti migliorie nella Kanban Board, che onestamente era stata un po’ trascurata negli ultimi tempi.

Kanban Split Column

Novità di VSO Sprint 79

Nel secondo post avevo promesso di approfondire il concetto di Definition Of Done in Kanban, perché è di fondamentale importanza per gestire al meglio il processo. Per prima cosa, fin dagli albori del template SCRUM, in TFS/VSO si può trovare il campo Acceptance Criteria per i Product Backlog Item e le Feature.

image

Dal punto di vista prettamente agile, l’acceptance criteria rappresenta l’insieme dei criteri da soddisfare affinché la singola Card/PBI sia considerata completa a tutti gli effetti quindi, essa rappresenta la Definition of Done della singola card/PBI. Il problema è come declinare questa informazione dal punto di vista di una Kanban Board.

Sicuramente tutti i criteri che si trovano nella card/PBI debbono essere necessariamente soddisfatti prima che la card finisca nell’ultima colonna. Questa condizione è sicuramente intuitiva, ma visto che non vorremmo lasciare nulla al caso, possiamo utilizzare la nuova funzionalità di supporto alla Definition Of Done nella Kanban Board di VSO per rendere questa politica esplicita.

SNAGHTML12b0967

Come si può vedere, ogni colonna, tranne la prima e l’ultima, hanno la possibilità di editare la Definition Of Done. In realtà la posizione logica migliore per questa informazione sarebbe tra due colonne, in modo da rappresentare la barriera che determina le condizioni affinché una card possa essere mossa alla colonna successiva. In questo caso invece, essendo la DoD sulla singola colonna, essa rappresenta le condizioni da soddisfare affinché una card in quella colonna possa essere considerata come Done e quindi promuovibile alla colonna successiva.

Andando ad editare la Definition of Done della colonna Testing, possiamo esplicitare la condizione precedente, ovvero che per essere considerata DONE una card deve avere tutti gli Acceptance Criteria soddisfatti.

image

Ora sulla colonna si può una nuova icona con un piccolo punto esclamativo. Cliccandoci sopra si può vedere le DoD di quella specifica colonna.

image

Di base quindi l’acceptance criteria rappresenta la DoD della singola card, ma in Kanban esiste una DoD per ogni colonna, che vale comunque per tutte le card indipendentemente dalla acceptance criteria.

Questa funzionalità è molto utile per esplicitare in maniera chiara il livello di qualità che ci si attende prima di considerare completa una card. Nulla infatti rallenta il flusso come il dover riportare una card allo stato precedente perché si è dimenticati qualcosa. Un esempio tipico potrebbe essere quello di avere il codice pronto per andare in produzione, ma accorgerci che lo schema del nostro DB SQL è cambiato e gli sviluppatori hanno dimenticato di creare gli script di migrazione. In questo caso è evidente che è necessario aggiungere una condizione nella DoD della colonna Developing.

Per chi usa la Kanban Board su VSO, non dimenticate quindi di esplicitare tutte le condizioni di transizione, ricordate infatti che uno dei principi di Kanban è: Make Process Policies Explicit e la Definition Of Done è sicuramente una delle Policy più importanti dei processi agili.

Gian Maria.

Introduzione a Kanban su MVA ora online

Per chi fosse interessato è oggi online il corso su Microsoft Virtual Academy sul metodo Kanban, fatto da me dal caro amico Felice.

Trovate tutto qui.

http://www.microsoftvirtualacademy.com/training-courses/introduzione-a-kanban

Buona visione Smile.

Dove finisce la Kanban Board ed inizia il Feedback

,Nel precedente post ho continuato la dissertazione sul massimizzare il flusso, ed ho spiegato come sia fondamentale estendere la Kanban Board a più stadi del processo possibili. Lo scopo finale è visualizzare tutti i passi che portano *dall’idea ai guadagno*. In un sistema software quindi dovremmo avere come ultima colonna un qualche cosa simile a: Usabile in produzione dal cliente finale. 

La domanda principale è: Usabile dal cliente finale significa guadagno?

In parole povere, il fatto che una determinata feature/card sia in produzione, è condizione spesso necessaria, ma non assolutamente sufficiente affinché inizi a generare guadagno. In questo caso quindi, anche se abbiamo massimizzato il flusso grazie alla nostra Kanban Board, non ci stiamo necessariamente avvicinando al Goal. Quello che viene spesso trascurato nell’implementazione del metodo Kanban è il considerare la metrica probabilmente più importante dei processi agili: IL FEEDBACK!!!!

L’aspetto interessante è che, si è tentato per anni di mutuare tecniche di progettazione da altre branche dell’ingegneria all’informatica (vedi il waterfall) ed il successivo fallimento di molti di questi tentativi ha generato un assioma di questo tipo:

Essendo il sistema waterfall mutuato da un altra branca dell’ingegneria, è possibile che mal si adatti all’informatica. Ergo è piuttosto inutile cercare di adattare metodologie di progetto da altre branche dell’ingegneria, perché l’informatica è troppo differente.

Questa affermazione è sempre vera? Venendo da studi di Elettronica, per me è naturale che un sistema di controllo per essere stabile debba necessariamente usare il principio del feedback.

Ora consideriamo che: il metodo Kanban è un sistema di controllo, il cui scopo è monitorare l’avanzamento dall’idea al prodotto finito grazie alla Board. A questo punto io sono fermamente convinto che:

Uno degli errori maggiori in Kanban applicato ad un progetto software è credere che il flusso finisca una volta raggiunta l’ultima colonna, ignorando per questo il feedback!!!!

Se grazie a Kanban abbiamo aumentato di molto il flusso di produzione (software o manifatturiero, …), ma nel contempo abbiamo una qualità scadente, siamo ben lontani dal Goal, a meno che il Goal non sia avere orde di clienti insoddisfatti (o di vendere contratti di assistenza).

In questo particolare caso l’ingegneria dei controlli e dell’automazione ci viene in aiuto, perché il modo migliore per capire se il prodotto del nostro processo è valido e di qualità, è acquisire FEEDBACK!.

Nei prossimi post vedremo quindi che tipologia di feedback utilizzare e come integrare questo processo in Kanban.

Gian Maria.

0  

Dove finisce la Kanban Board ed inizia il Feedback

Nel precedente post ho continuato la dissertazione sul massimizzare il flusso, ed ho spiegato come sia fondamentale estendere la Kanban Board a più stadi del processo possibili. Lo scopo finale è visualizzare tutti i passi che portano *dall’idea ai guadagno*. In un sistema software quindi dovremmo avere come ultima colonna un qualche cosa simile a: Usabile in produzione dal cliente finale. 

La domanda principale è: Usabile dal cliente finale significa guadagno?

In parole povere, il fatto che una determinata feature/card sia in produzione, è condizione spesso necessaria, ma non assolutamente sufficiente affinché inizi a generare guadagno. In questo caso quindi, anche se abbiamo massimizzato il flusso grazie alla nostra Kanban Board, non ci stiamo necessariamente avvicinando al Goal. Quello che viene spesso trascurato nell’implementazione del metodo Kanban è il considerare la metrica probabilmente più importante dei processi agili: IL FEEDBACK!!!!

L’aspetto interessante è che, si è tentato per anni di mutuare tecniche di progettazione da altre branche dell’ingegneria all’informatica (vedi il waterfall) ed il successivo fallimento di molti di questi tentativi ha generato un assioma di questo tipo:

Essendo il sistema waterfall mutuato da un altra branca dell’ingegneria, è possibile che mal si adatti all’informatica. Ergo è piuttosto inutile cercare di adattare metodologie di progetto da altre branche dell’ingegneria, perché l’informatica è troppo differente.

Questa affermazione è sempre vera? Venendo da studi di Elettronica, per me è naturale che un sistema di controllo per essere stabile debba necessariamente usare il principio del feedback.

Ora consideriamo che: il metodo Kanban è un sistema di controllo, il cui scopo è monitorare l’avanzamento dall’idea al prodotto finito grazie alla Board. A questo punto io sono fermamente convinto che:

Uno degli errori maggiori in Kanban applicato ad un progetto software è credere che il flusso finisca una volta raggiunta l’ultima colonna, ignorando per questo il feedback!!!!

Se grazie a Kanban abbiamo aumentato di molto il flusso di produzione (software o manifatturiero, …), ma nel contempo abbiamo una qualità scadente, siamo ben lontani dal Goal, a meno che il Goal non sia avere orde di clienti insoddisfatti (o di vendere contratti di assistenza).

In questo particolare caso l’ingegneria dei controlli e dell’automazione ci viene in aiuto, perché il modo migliore per capire se il prodotto del nostro processo è valido e di qualità, è acquisire FEEDBACK!.

Nei prossimi post vedremo quindi che tipologia di feedback utilizzare e come integrare questo processo in Kanban.

Gian Maria.

Fail-Fail-Win pattern and Win-or-Fail anti-pattern

Investire su una nuova idea è costoso e rischioso, questi sono dati di fatto difficilmente contestabili. Ma in un mercato in continuo fermento in cui le idee ed i prodotti nascono e muoiono come funghi, come è possibile mitigare il rischio del fallimento?

Ebbene, non possiamo eliminare tale rischio, quello che possiamo fare è accelerare il ritmo del fallimento al fine di ridurne gli effetti. Tale necessità è tanto più evidente quanto più si vanno a leggere i dati percentuali relativi al tasso di fallimento: oltre il 90% delle nuove idee/prodotti/servizi sono destinate a fallire, soprattutto se a perseguirle sono startup.

new product failure rates

New Product Failure Rates

In realtà, bisogna inquadrare il concetto di “fallimento” nel contesto giusto che non è quello tipicamente italiano, in cui il “fallimento” è definitivo ed è una macchia indelebile, bensì quello anglosassone in cui il “fallimento” è un’opportunità per rivedere le proprie ipotesi e le proprie assunzioni. Certo, ciò non vuol dire che possiamo fallire sempre e in numero così elevato da diventare intollerabile per la nostra startup o azienda che sia, ma che comunque è un elemento importante per raggiungere il successo.

Il pattern da considerare è, quindi, quello che possiamo denominare fail-fail-win, che va chiaramente ad opporsi all’anti-pattern win-or-fail:

failure

Win-or-Fail vs Fail-Fail-Win

L’aspetto fondamentale di questo pattern è la necessità di accelerare quanto più possibile la verifica della propria idea, andando a validare se il prodotto o il servizio che si è immaginato ha un potenziale mercato e quindi merita di essere realizzato. Un modo per fare ciò è adottare Lean Startup e il ciclo build-measure-learn in abbinamento al pretotyping, di cui abbiamo discusso nel post introduttivo specifico (Lean Startup, the art of Customer Development: pretotype).

L’idea è quella di sfruttare un pretotype per fallire velocemente, aiutandoci a capire se stiamo puntato sul prodotto giusto prima di iniziare ad investire tempo e denaro per la sua realizzazione. Non si tratta, rimarchiamo la differenza, di un MVP che va a lavorare sul “prodotto” o su un suo prototipo comunque utilizzabile, ma di una sorta di mock-up che con pochi giorni di lavoro (o addirittura poche ore) ci permette di capire la risposta dei potenziali clienti.

Un esempio di pretotyping?

Probabilmente si resterà sorpresi nello scoprire che uno dei suoi primi utilizzi noti, anche senza la formalizzazione del termine specifico, risale a diversi decenni fa (più o meno agli albori dei personal computer) quando IBM pensa di realizzare una macchina da scrivere a riconoscimento vocale per la dettatura e scrittura di testi (speech-to-text). L’idea sembra buona, anche in funzione dei clienti intervistati, ma come può BigBlue essere sicura che poi il prodotto verrà realmente acquistato senza spendere milioni di dollari in un settore tecnicamente molto complesso? Ebbene, qualcuno ha la brillante idea di utilizzare un pretotype di tipo Mechanical Turk, andando a simulare il funzionamento del sistema con l’ausilio di un operatore umano all’insaputa dell’utilizzatore.

Così IBM allestisce una “sala prove” in cui una serie di possibili utilizzatori sono convinti di provare realmente il nuovo sistema, dettando a microfono il testo e vendendo comparire su uno schermo la relativa rappresentazione (perfetta, grazie a esperti dattilografi) testuale. Nel giro di poche ore viene però fuori che il prodotto, apparentemente brillante, soffre di alcuni gravi problemi, come l’affaticamento vocale dell’operatore e la creazione di un ambiente rumoroso, che spinge a ripiegare sulla vecchia e tradizionale tastiera.

In tal modo, BigBlue si accorge che la propria idea è affetta da gravi problemi e decide di soprassedere, anche se non abbandona del tutto la ricerca nel campo del riconoscimento vocale.

Immaginate i milioni di dollari buttati se IBM si fosse buttata a capofitto nella realizzazione del prodotto basandosi sul suo apprezzamento ipotetico dei clienti. Ecco, questa è l’essenza del pretotyping e di come attraverso esso è possibile far scorrere il pattern fail-fail-win per individuare il giusto prodotto su cui puntare prima di dedicarsi alla creazione del Minimum Viable Product.

Obiettivo clienti: Demand Creation

Indipendentemente dal settore di afferenza, che si tratti un’azienda manifatturiera o di una web company, tre sono gli obiettivi di sintesi perseguiti da ogni azienda:

  • realizzare prodotti di successo;
  • acquisire, mantenere e far crescere il numero dei propri clienti;
  • fare soldi, direttamente o indirettamente, con i clienti.

La chiave del successo nella gestione dei propri clienti è la Customer Relationship, uno degli elementi portanti del Business Model Canvas di Alexander Osterwalder.

bmc customer relationship n

Business Model Canvas, Customer Relationship

Entriamo così di petto nel mondo della Demand Creation, focalizzata nel trovare una risposta di contesto alla domanda fondamentale: come creiamo la domanda rispetto ai nostri prodotti e servizi? Nel nostro specifico contesto di riferimento, quello delle startup, possiamo affidarci al Get, Keep and Grow funneldi Steve Blank. In realtà esistono due versioni del GKG funnel, che si differenziano per lo più nella fase di “Get” in funzione del canale di distribuzione utilizzato per il prodotto: fisico o virtuale.

funnels

GKG Physical and Virtual Channel

Questo modellosi concentra sulla ricerca di nuovi clienti, la loro fidelizzazione e la crescita, in numero e in volume di affari, in un contesto incerto di innovazione, andando a comprovare il modello di business e proiettando l’esperimento (la startup secondo Eric Ries) verso la trasformazione in un’azienda basata su un business sostenibile.

L’analogia dell’imbuto è fortemente rappresentativa, poiché è dimostrato come al lancio di un nuovo prodotto (o meglio di una nuova idea di prodotto tramite un MVP) l’attenzione può essere decisamente alta, soprattutto se si adottano forti strategie pubblicitarie come, ad esempio, gli ADV sui motori di ricerca.

Quando si è in presenza di un canale fisico di distribuzione, nella fase di “Get” è necessario creare la domanda e accompagnare il potenziale cliente nell’acquisto del prodotto stimolandolo attraverso una serie di fasi di riflessione:

  • Consapevolezza (Awareness), il potenziale cliente viene a conoscenza del prodotto e si informa su di esso;
  • Interesse (Interest), il potenziale cliente approfondisce la conoscenza del prodotto, mostrandosi così interessati ad esso;
  • Considerazione (Consideration), il potenziale cliente comincia ad apprezzare la soluzione, valutandone l’efficacia e la possibilità di acquistarlo. Uno stimolo (es: nuova release o un’offerta promozionale di acquisto) può essere sufficiente per adottarlo definitivamente;
  • Acquisto (Purchase), il potenziale cliente si trasforma in “cliente”.

physical channel

GKG Physical Channel

Quando si è in presenza di un canale virtuale, la fase di “Get” apparentemente si semplifica in due azioni: Acquiring, ovvero acquisire nuovi clienti portandoli sul proprio sito o sullo store, e Activate, ovvero trarre valore dal fatto che l’utente utilizzi il prodotto (pagamento, registrazione, ecc.). Anche se le azioni sono minori di quelle associate al canale fisico, le complessità e le frizioni sono quelle tipiche del mondo virtuale, dove la complessità si moltiplica velocemente ed esponenzialmente. Quello che è fondamentale è il Customer Acquisition Cost (CAC), dato dal rapporto di tutti i costi annessi all’acquisizione (ADV, campagne stampa, ecc..) e i clienti che realmente hanno acquistato o attivato il prodotto.

virtual channel

GKG Virtual Channel

Conoscere tali informazioni permette, inoltre, alla startup di sfruttare un Sustainable Engine di tipo Virale e valutare il ROI per validare la strategia scelta.

Una volta che i clienti cominciano ad utilizzare costantemente la soluzione, si pone la questione di come fidelizzarli, “Keep”, per non rendere vano il duro lavoro fatto per ottenerli. Il primo elemento è quello di “mantenere le promesse” fatte in fase di acquisizione del cliente stesso: ad esempio, se ci si è impegnati su una certa funzionalità, il prodotto dovrà averla, non ci sono scusanti che reggono. I clienti devono amare il prodotto e l’azienda deve accompagnarli nel suo utilizzo mettendo a disposizione tutti i servizi di cui hanno bisogno (customer-facing, dal supporto tecnico a quello di fatturazione e consegna, solo per citarne alcuni) e attivando i cosiddetti “programmi fedeltà” che consentono al cliente di guadagnare punti e sfruttarli per ottenere benefit e vari tipi di vantaggi.

Non bisogna comunque dimenticare che il fulcro di tutto è il prodotto in sé, che va costantemente aggiornato e che deve rimanere quanto meno al passo con la concorrenza, ascoltando sempre la “voce” del cliente, realizzando nuovi MVP e interviste dirette.

Per ogni azienda è, infine, indispensabile, pensare costantemente a come accrescere il numero di clienti ed incrementare gli affari con loro: si passa nella fase di “Grow”.

Grazie alla strategia dei “Referrals” è possibile sfruttare un sustainable growth engine di tipo Virale per aumentare il numero di clienti, mentre per aumentare il volume di affari con i clienti, nuovi o già in essere, possiamo attivare diverse politiche incentivanti:

  • Cross-Sell, pensata per incoraggiare i clienti ad acquistare prodotti affini e potenzialmente rispondenti a loro esigenze latenti;
  • Next-Sell, concentrarsi sulle vendite successive puntando a diventare il fornitore di riferimento del client, valido soprattutto in un contesto B2B;
  • Up-Sell, spingere all’acquisto di prodotti di fascia alta;

Se l’intero core business è basato su un unico prodotto/servizio potrebbe essere opportuno adottare una strategia di Unbundling per aumentare i ricavi: in pratica lo si divide in componenti con funzionalità specifiche, in grado di interagire strettamente, e vendibili separatamente o in-bundle.