In questo post, datato febbraio 2021 voglio condividere una trasformazione interna del team Learnn che stiamo vivendo proprio nelle ultime settimane e che riguarda il modo in cui sviluppiamo gli asset tecnologici.
Non preoccuparti, niente termini astrusi o linee di codice: ti racconterò come siamo partiti da una riflessione per arrivare ad un cambiamento.
In questo contenuto vedremo:
- Come abbiamo lavorato fino ad oggi a livello tech
- L’evoluzione da team tech a team prodotto
- Il perché è necessaria questa evoluzione
- In che cosa consiste praticamente tutto questo
Learnn vista da fuori e da dentro
Vista da fuori Learnn è un’isola popolata da persone serie che lavorano in armonia. Sei sicuro sia proprio così?
È solo facciata. In realtà consumiamo le giornate su Slack tra una cospirazione e una lotta intestina 🙂
La verità però è un’altra. Tutti vogliono entrare a far parte del Team Tech e ci stanno provando in tutti i modi.
Ma questo Team Tech in cui tutti del team vogliono entrare in realtà non esiste più.
La scorsa settimana ho scritto al Team un post su Basecamp, facendo alcune riflessioni su come abbiamo lavorato in questi mesi dal punto di vista tecnologico.
Niente buoni propositi, anzi ti dico di più, dal punto di vista tecnologico in Learnn smetteremo di fare pianificazioni annuali. Ecco spiegato perché.
Premessa
Per noi, la tecnologia è un pilastro strategico.
Ad esempio, siamo partiti sviluppando l’app mobile che permette agli utenti di sfruttare qualsiasi momento libero della giornata per apprendere: una pausa caffè, uno spostamento in metro, la coda alle poste…
Abbiamo sviluppato un ecosistema proprietario proprio per poter offrire l‘esperienza più coerente possibile per ottenere lo scopo degli utenti: apprendere.
Ma non ci siamo fermati qui.
Come abbiamo lavorato fino ad oggi
Oltre all’app mobile, in sei mesi abbiamo sviluppato una Web App (piattaforma Web) e molta altra tecnologia che magari non è visibile ma è essenziale: un sistema di pagamento, uno di analisi dei dati, integrazioni con sistemi esterni come quello di email marketing o gestione delle subscription.
Insomma, tanta tanta roba.
Voglio concentrarmi però su ciò che è stato sicuramente più sfidante per Learnn: App mobile e web.
Ti dico qualcosa di sorprendente: fino ad ora è stato facile. Mi spiego (prima di essere preso ad insulti 😜).
In questi mesi abbiamo sviluppato un prodotto basandoci su una solida roadmap nata dall’esperienza di Luca e sulla sua conoscenza degli utenti. Grazie a questo siamo stati in grado di definire il subset minimo di feature necessarie nell’MVP.
Per chi sviluppa codice è la situazione migliore: puoi basarti su una pianificazione di medio periodo e “controllarla” settimana dopo settimana (o sprint dopo sprint) con una pianificazione di dettaglio.
Non dovevamo inventarci nulla, dovevamo solo correre.
Ecco, Omar e Mirko, con il supporto di Luca in questo sono stati fenomenali. Abbiamo fatto in 6 mesi quello che le altre aziende — con team collaudati — fanno in almeno il doppio del tempo.
Oggi però non abbiamo più una roadmap a medio periodo; certo c’è ancora qualche feature da sviluppare, qualche bug da fissare e qualche debito tecnico da colmare. Insomma, l’App e la piattaforma Web contengono tutto ciò che un utente si aspetta.
Adesso arriva il difficile (ed il bello): dobbiamo innovare.
Quindi, fine del Team Tech?
In un certo senso sì.
Dobbiamo sempre di più “adattarci” ed evolvere noi e il nostro prodotto in base a 3 aspetti:
- La nostra visione;
- I nostri valori;
- Ciò che chiedono gli utenti.
Ad oggi stiamo facendo (molto bene) i primi due punti, ma dobbiamo migliorare sul terzo.
Attenzione. Non sto dicendo che non ascoltiamo i nostri utenti. Lo facciamo in continuazione. Ciò su cui dobbiamo migliorare è pianificare ciò che ci chiedono gli utenti.
Tante volte condividiamo su slack, per mail, per messaggio, riflessioni, richieste e proposte degli utenti. A volte rimangono lì e non ci prendiamo il tempo giusto di valutare quante volte la stessa richiesta è emersa, quanto valore ogni proposta porta a tutta la nostra community.
Per farla breve: ascoltiamo tanto, analizziamo poco.
Non voglio parlare di soluzioni, ci sono mille modi per migliorare questo aspetto, ma voglio fare un passo indietro a ciò che secondo me è il cuore del discorso: dobbiamo cambiare il mindset con cui sviluppiamo il nostro prodotto.
(Ri)Partiamo dal perché
Credimi, per chi sviluppa con passione tecnologia da vent’anni, non è facile ammettere ciò che ti sto per dire. Non siamo una azienda tecnologica e (secondo me) non dovremmo mai diventarla. Sai perché?
La tecnologia può essere acquistata, i migliori talenti possono essere acquisiti. Chiunque può arrivare sul mercato con più soldi o più talenti e costruire tecnologia migliore di quanto possiamo fare noi. In poche parole, se giochiamo su questo piano siamo sostituibili.
Dobbiamo sempre più focalizzarci sul costruire un prodotto. Anzi, costruire il nostro prodotto.
In questo nessuno potrà essere come noi. Mai. Nessuno potrà essere in grado di sviluppare il miglior prodotto possibile per noi.
“Gianluca, parli di sviluppare tecnologia e di sviluppare un prodotto, ma qual è la differenza?”
Il prodotto è lo strumento con cui veicoliamo maggiore valore possibile ai nostri utenti.
Chi conosce meglio i nostri clienti? Noi.
Chi può sviluppare il miglior prodotto per i nostri clienti? Noi.
Ecco, questa è secondo me la chiave.
Dobbiamo migliorare il nostro processo incrementale.
Ogni settimana, – anzi ogni sprint – dobbiamo essere più bravi ad ascoltare intorno a noi cosa succede nel customer care, negli analytics, sui social, estrarne il valore e – soprattutto – accorciare il tempo in cui questo valore si riflette nel nostro prodotto.
Perché nessuno più di noi conosce e vede ciò che potrebbe portare il maggiore impatto sul proprio lavoro giornaliero.
La tecnologia deve essere uno strumento per ottenere un fine, non deve essere il fine stesso.
Detto in altre parole: la tecnologia è dei tecnici, il prodotto è di tutti.
Dobbiamo quindi trasformarci da “Team Tech” a “Team di Prodotto” e dove ognuno di noi (compreso noi componenti del team tech) è uno Stakeholder del prodotto, dove ognuno di noi ha il compito di analizzare di continuo ciò che gli succede durante la settimana e pensare a come prendere spunto per aggiungere il più alto valore possibile per il nostro prodotto.
Serve un cambio radicale di mentalità. Essere “agili” non significa seguire una metodologia con un nome figo, ma sapersi adattare e capire quando è il momento di cambiare approccio.
Si, ma in soldoni cosa cambia?
Ecco cosa faremo
Sin dal primo giorno, ad inizio settimana (o sprint) abbiamo fatto un planning ponendoci un obbiettivo concreto da portare a termine entro la fine della settimana (goal dello sprint).
Fino ad oggi abbiamo riempito il nostro sprint backlog (lista di cose da fare durante la settimana) in base alle priorità della roadmap definite i primi di agosto.
Quest’anno niente più roadmap, niente pianificazione a lungo termine. Manterremo la pianificazione dello sprint, ma ogni settimana azzereremo tutto.
Hai presente il film di Bill Murray “Ricomincio da capo” dove il protagonista rivive sempre il giorno della Marmotta?
Ogni nuovo sprint ripartiremo da un backlog vuoto. Il lavoro dello sprint sarà pianificato ponendoci una unica domanda:
Guardando la settimana scorsa, in base a ciò che abbiamo fatto e ciò che è successo in Learnn, cos’è quella singola cosa da portare a termine entro la fine dello sprint per poter massimizzare il valore del nostro prodotto?
It’s alway day one, o per meglio dire: it’s always sprint one.
Questo chiaramente non significa che non abbiamo dei macro-obiettivi per questo primo Q (trimestre), ma che siamo pronti a modificare il nostro percorso per arrivarci.
In questa ottica è riduttivo parlare ancora di Team Tech. Ogni componente del Team di Learnn è fondamentale per trasferire ciò che succede al di fuori di Learnn e cosa chiedono gli utenti che utilizzano giornalmente il prodotto.
Certo, questo non vuol dire che Luca, Susanna, Clara e il resto del team svilupperanno codice (almeno per ora, vero Luca?), significa che senza il loro contributo strutturale e continuo ci ridurremmo a sviluppare “solo” tecnologia e non un prodotto.
Abbiamo cambiato tutto per non cambiare niente. Perché ciò che non deve cambiare è il nostro scopo: creare un impatto nelle persone democratizzando l’apprendimento digitale.
Com’è possibile che però delle persone che prima scrivevano codice siano ora in grado di prendere decisioni che prima spettavano solo alla sfera business/management di un’azienda?
Questo lo vedremo in un prossimo case study.
Conclusione
A Learnn siamo estremamente attenti all’aspetto tecnologico e a chiederci come questo possa diventare un volano per migliorare sempre di più l’esperienza dell’utente all’interno della piattaforma.
Il focus però deve essere sempre il prodotto — quello che gli utenti toccano con mano — e per questo motivo chi scrive codice è prima di tutto un utente di Learnn.
Questo cambio di mentalità obbliga ogni membro del team a ragionare in ottica sia in ottica utente che in ottica tecnologica, unificato l’intero team attorno al valore comune che vogliamo dare ai nostri utenti.
Per poterlo fare però è necessario ascoltare (messaggi), leggere (dati), comprendere (feedback), immaginare (visione), realizzare (esecuzione) qualcosa che gli utenti stessi vogliono e per farlo tutti i membri del team devono avere pieno potere decisionale nella loro sfera.
Se ti è piaciuto questo articolo e vuoi approfondire gli aspetti di cui abbiamo discusso in questo articolo, allora inizia a seguire gratuitamente i corsi che trovi nel box qui sotto! 😜
