Sviluppare un prodotto digitale con un fornitore

Il 9 gennaio 2007 Steve Jobs presentava l’iPhone. Da quel giorno si sono moltiplicati come mai accaduto prima prodotti tecnologici di stile e design.

L’arte di Apple fu quella di far sembrare tutto estremamente semplice. Ma c’è un episodio che descrive bene l’abilità che Steve Jobs ha avuto nell’incantare il mondo con prodotti in realtà realizzati con processi e tecnologie di grandissima complessità.

«Consiglio di Amministrazione Apple. Il prototipo era chiaramente un disastro. Non era semplicemente un “bug”, era tutto da buttare. La trasmissione delle telefonate era costante sì, ma solo perché si interrompeva costantemente. La batteria si caricava solo a metà e non parliamo delle applicazioni. La lista dei problemi sembrava infinita: alla fine della demo Jobs sospirò concludendo “We don’t have a product yet”.»
 — Wired «The Untold Story: How the iPhone Blew Up the Wireless Industry»

Oggi, dieci anni più tardi, solamente l’App Store di Apple conta più di 2,7 milioni di app. I numeri sono simili per il Play Store di Google.

App. Sono dappertutto. Le amiamo e poi le odiamo. Ma tutti, prima o poi, sogniamo di realizzarne una, se solo avessimo tempo ed energie.

In Moze aiutiamo imprenditori e manager d’impresa nel trasformare idee di business in prodotti digitali. Progettiamo e sviluppiamo servizi digitali come piattaforme web, siti e app.

Non tutti i nostri clienti hanno competenze tecniche di tipo informatico o di design del prodotto digitale. Spesso hanno un ruolo o una grande esperienza nel marketing o nello sviluppo business. Quando li incontriamo stanno solitamente cercando un fornitore di “servizi IT” o una software house a cui affidare la realizzazione del loro progetto.

Parte del nostro lavoro come partner tecnico è informare i nostri clienti di cosa ci sia “dietro” ad un’app e una piattaforma tecnologica apparentemente semplice, in modo da consentirgli di prendere decisioni informate.

Non serve un fornitore. Serve un partner tecnico che condivida gli obiettivi di business. Creare un nuovo prodotto digitale è una cosa ben diversa dal “semplice” sviluppo software. Significa progettare un nuovo business e l’esperienza che faranno gli utenti-clienti a cui il prodotto è destinato.

Per questo non si può ricorrere semplicemente ad un fornitore che sviluppi il prodotto che hai in mente. Un partner tecnico che abbia le competenze di strategia, product management, design e tecnologia capace di portare un prodotto al mercato con il giusto passo sin dal primo incontro.

Sono cinque i concetti fondamentali che condividiamo con i nostri clienti per dare la giusta impronta ad ogni nuovo progetto.

1. Pianifica su cicli brevi.
2. Un prodotto non è mai finito.
3. Software is Hard.
4. Tempo VS perimetro di progetto.
5. Costruisci il tuo team.

1. Pianifica su cicli brevi

Partiamo dall’inizio. Tutto nasce solitamente da una richiesta di preventivo (o RFP, Request For Proposal), che spesso contiene una lunga lista di funzionalità e la data di consegna desiderata.

Lunghi elenchi di funzionalità richiedono lunghi tempi di realizzazione: è facile quindi aspettarsi che il “go-live” (il momento in cui la piattaforma sarà disponibile al pubblico) sarà raggiunto non prima di 8 o 12 mesi.

Cody Simms di Techstars, un acceleratore d’impresa, sottolinea come i piani a dodici mesi abbiamo origine nell’era pre-Internet, quando lo sviluppo di un prodotto doveva necessariamente sottostare ai lunghi cicli (non comprimibili) della distribuzione del prodotto fisico. Tutta un’altra storia il software fruibile su Internet dei nostri giorni:

“Costruiamo prodotti iterativamente, adeguiamo scopi e funzionalità nel giro di pochi minuti, ore o giorni in base all’interpretazione dei dati raccolti in tempo reale.”
— Cody Simms a proposito delle Roadmap di Prodotto.

Condividere la visione d’impresa e una roadmap di alto livello del prodotto da costruire è un requisito necessario per poter collaborare in maniera efficace. Ma quando si passa all’implementazione (come costruire il prodotto) non troviamo opportuno blindare requisiti di funzionamento a monte. Il motivo è semplice: non si conosce ancora abbastanza del problema che si vuole risolvere.

Molte aziende che operano attraverso Internet pianificano per questa ragione cicli di lavorazione a breve termine. Intercom, un’azienda SaaS (Software as a service) spiega i vantaggi di questo approccio correlando l’accuratezza e il costo della pianificazione.

“Ci siamo accorti che il ciclo di sviluppo di sei settimane è semplicemente giusto. Il nostro team è in grado di lavorare su obiettivi concreti ma al tempo stesso ha la flessibilità necessaria ad adattarsi all’inevitabile incertezza tipica del settore del software Internet”.
— Inside Intercom «6 weeks: why it’s the Goldilocks of product timeframes»

Costruire meno. Costruire meglio. Passo dopo passo.

Team di lavoro che seguono la metodologia Agile, una modalità di sviluppo software particolarmente adatta a reagire rapidamente ai cambiamenti interni ed esterni ad un’organizzazione, lavorano solitamente in Sprint: periodi di tempo prestabiliti per durata e costo (E.g., Sprint bisettimanale).

Lo scopo principale di uno Sprint di lavoro non dovrebbe essere sempre e solamente quello di scrivere il codice sorgente del software. Jeff Patton, Product Manager veterano ed esperto di pratiche Lean e User Experience, sostiene che i team che fanno la differenza sono quelli che sanno bilanciare sapientemente il bisogno di scrivere software con la necessità di imparare dalle funzionalità già rilasciate, validando continuamente le nuove ipotesi progettuali attraverso prototipi e interviste con i potenziali utilizzatori.

Per questo è buona pratica alternare Sprint di “Discovery” e Sprint di “Delivery”:

• Discovery: l’attenzione principale è rivolta agli utenti, al mercato, ad effettuare test attraverso prototipi, a svolgere test di usabilità.
• Delivery: l’attenzione principale è rivolta a progettare e scrivere software.

Ciò permette di costruire un prodotto aderente alle aspettative e ai bisogni degli utilizzatori finali, accorciando sensibilmente i tempi che separano lo sviluppo di un software dal test del mercato.

2. Un prodotto non è mai finito

Ci è capitato molte volte, nella nostra esperienza come studio, di conoscere fondatori e manager convinti di poter realizzare il loro prodotto digitale attraverso un iter a compartimenti stagni: costruisci il prodotto, lo lanci quando è tutto pronto, aspetti che arrivino i clienti.

Dopo molti progetti siamo arrivati a considerare un prodotto digitale in modo completamente diverso: un’entità “viva” e in continua evoluzione.

Quando, da utilizzatori, guardiamo ad app come Instagram o Facebook—che rappresentano alcuni tra i prodotti più popolari—riusciamo a intuire solo la punta dell’iceberg.

Studiando questi servizi e queste aziende più a fondo è sorprendente osservare quanto queste semplici App siano invece entità ben più complesse: ci sono centinaia di progettisti e ingegneri per ognuna di queste aziende, al lavoro per migliorare le funzionalità di oggi e a creare quelle di domani.

Arrivare al go-live di un prodotto è il primo, grande passo. Ma non è il punto di arrivo. L’energia deve essere ripartita tra molti fronti: far crescere la startup rispetto alle sue metriche ritenute più importanti per il suo successo, occuparsi del reclutamento e della formazione dei nuovi membri del team, creare una cultura aziendale che possa attirare talenti e un’organizzazione del lavoro efficace, attivare il servizio di supporto ai clienti e molto altro.

3. Software is Hard

Affidarsi ad un’azienda per sviluppare un prodotto digitale non è come chiedere un preventivo per acquistare un’auto. Ci è capitato in passato che un nostro cliente chiedesse un contratto “chiavi in mano”. Per costruire una tech company non si può fare nulla del genere: c’è da rimboccarsi le maniche e comprendere a fondo le opportunità e i limiti di un software basato su Internet.

Anche nel caso di una “semplice App”, chi la vuole realizzare dovrebbe essere disposto a comprendere ciò che si trova sotto al cofano allo stesso modo in cui un pilota di Formula 1 conosce le leggi e le dinamiche dell’ingegneria, della meccanica e della fisica.

Rapido, sì. Ma la perfezione è un’altra cosa.

Le piattaforme tecnologiche come App o siti web sono per la maggior parte costruiti su diversi strati di software (spesso open source, cioè pubblicamente utilizzabile) e script, che si interfacciano e sfruttano componenti e servizi di terze parti gratuiti e a pagamento.

È per questo che oggi anche un piccolo team di sviluppo è in grado di creare un’App in soli due mesi. Ma è anche la ragione per cui non bisogna aspettarsi che quel prodotto sia perfetto.

Il software ha bug e difetti. È un fenomeno così naturale che aspettarsi un software senza bug sarebbe come dichiarare con perfetta sicurezza che una determinata area geografica sia completamente esente da rischio di terremoto o calamità naturale.

“L’unico modo affermato e affidabile per garantire software dalla qualità impeccabile è produrre meno codice per offrire meno funzionalità, tenendo comunque in conto di spendere non poco tempo per ultimare le rifiniture.”

—Articolo di DHH, Creatore di Ruby on Rails, uno dei più diffusi framework di sviluppo per applicazioni Internet, e CTO di Basecamp, azienda SaaS di successo.

4. Tempo VS perimetro di progetto

Un prodotto digitale si evolve giorno dopo giorno in base alle informazioni e le reazioni raccolte dai suoi utilizzatori: è quindi naturale pensare che la forma contrattuale che coinvolge un fornitore debba tenere conto di questa flessibilità.

Per questo motivo sono nati i contratti per lo sviluppo Agile di software, adatti al processo di costruzione di un prodotto in continuo cambiamento. Questi contratti prevedono solitamente un costo per ogni Sprint (periodi di tempo fissi, con costo identificato a monte); il cliente è coinvolto direttamente nella revisione del lavoro svolto in ogni Sprint e nella pianificazione dello Sprint successivo.

Ma se un contratto Agile è per definizione dinamico, come è possibile per un cliente sapere quanto spenderà e di quali funzionalità disporrà il suo prodotto?

Mike Cohn, esperto di metodologia Agile e fondatore della Scrum Alliance, offre il suo punto di vista per rispondere in maniera ottimale al quesito. Suggerisce di fissare per ogni progetto una tra le due principali variabili: il perimetro delle sue funzionalità, espresso in quantità di lavoro da parte del fornitore, e il budget a disposizione da parte del cliente.

Caso A: accordo con perimetro di progetto fisso, budget variabile

In questo caso, avere un determinato insieme di funzionalità è più importante che avere una variazione nel costo finale di progetto, limitato tra gli estremi di uno scenario ottimistico e uno pessimistico inizialmente previsti.

Seppure in poche occasioni, abbiamo avuto modo di adottare questo approccio nella nostra esperienza diretta come studio. È accaduto nel caso di progetti tecnologicamente complessi, nei quali il set minimo di funzionalità era difficilmente “comprimibile”.

Caso B: accordo con budget fisso, perimetro di progetto variabile

È l’ideale se si vuole avere la certezza di non sforare il budget di riferimento. In progetti Internet complessi, soggetti a frequenti necessità di adattamenti, bisogna però essere disposti ad una certa flessibilità sul perimetro di progetto.

Se un certo budget determina un certo numero di Sprint di lavoro, si potranno tracciare due scenari che riguardano il perimetro di progetto che sarà realizzato: l’insieme delle funzionalità minime garantite e un altro insieme di funzionalità che potrebbero eventualmente rientrare nel budget a disposizione (Cohn le chiama funzionalità “will-have” e “might-have”).

In Moze adottiamo questo approccio, spesso più vicino alla realtà di imprese costruite attorno ai budget fissi, quando è ragionevolmente facile identificare un set minimo di funzionalità fondamentali per iniziare a portare il prodotto sul mercato, dando importanza secondaria ad ulteriori sviluppi.

5. Costruisci il tuo Team

Lavorare ad un prodotto tecnologico collaborando con una realtà specializzata ha i suoi vantaggi, tra cui poter contare dal giorno uno su un team rapido e con molta esperienza, invece di dover attendere cicli di reclutamento e formazione notoriamente lunghi quando si parla di professionisti nel settore tech.

Abbiamo avuto esperienza di ottime collaborazioni nella fase dello sviluppo di un nuovo prodotto o per aggiungere forza lavoro ad un team già esistente e saturo.

Tuttavia, proprio perché “un prodotto non è mai finito” e la corsa per migliorare il prodotto non prevede un “punto di arrivo”, non pensiamo che questa possa essere la soluzione definitiva.

Le migliori aziende tecnologiche che abbiamo conosciuto si preoccupano di pianificare l’ingresso dei futuri membri del team tecnico fin dai primi giorni, programmando con cura il passaggio di consegne da parte di una realtà esterna.

Marty Cagan, esperto di organizzazione di team di prodotto digitale e tra i fondatori del Silicon Valley Product Group, descrive in un suo libro i ruoli chiave per un team che lavora su un prodotto software:

Product Manager: è la persona responsabile di associare i bisogni e i problemi degli utenti ad un prodotto che offra una soluzione appropriata.

User Experience Designer: è la persona responsabile di sviluppare una profonda comprensione degli utilizzatori attuali o potenziali del prodotto e di progettare funzionalità che offrono una soluzione appropriata ai loro problemi.

Product Marketer: è la persona responsabile di far sapere al mondo che il prodotto esiste e di far crescere l’acquisizione di nuovi utilizzatori attraverso i canali esistenti.

Engineering: è l’insieme delle persone responsabili della realizzazione tecnologica del prodotto.

Operations: è l’insieme delle persone responsabili di mantenere il prodotto attivo e funzionante (come ad esempio il Customer Support).

Avere il proprio team non è solamente una buona pratica, ma qualcosa di essenziale quando è necessario far crescere ed evolvere il prodotto o quando si approccia un Venture Capital.

Queste sono le cose che abbiamo imparato realizzando prodotti digitali assieme ai nostri clienti. Siamo curiosi di confrontarci con persone che hanno avuto esperienze simili.

Crediamo che, per un “Non-tech founder” o Manager, conoscere questi cinque aspetti fondamentali legati alla realizzazione di un prodotto digitale sia cosa fondamentale. Non vogliamo scoraggiare le nuove iniziative imprenditoriali, ma al contrario incoraggiare a prendere decisioni consapevoli per creare il giusto prodotto.

Auguriamo che tutti possano alla fine avere successo nel mostrare agli utenti solo la punta dell’Iceberg:

Quell’incredibile semplicità e bellezza dei prodotti digitali che usiamo ogni giorno e che ci appassionano, senza farci percepire l’inevitabile complessità di ciò che si nasconde dietro di essi.