Processo chiaro.
Risultato migliore.
Capire. Pianificare. Costruire. Crescere. Quattro fasi che trasformano un’idea in qualcosa che resta – e una conversazione onesta all’inizio, in cui si decide se costruire o no.
Nessuna magia.
Solo lavoro fatto bene.
Ogni progetto attraversa le stesse quattro fasi, che sia un piccolo strumento interno o un sistema da cui dipende un’azienda. Quanto dura ciascuna dipende dal progetto – che abbia luogo, no.
Capire
Partiamo dal problema, non dalla soluzione. Per chi è, cosa ostacola, e cosa sarebbe davvero meglio?
Pianificare
Portata, architettura, budget. Tracciamo il percorso prima che qualcuno scriva codice – così le sorprese restano piccole.
Costruire
Iterazioni brevi, software funzionante, nessuna scatola nera. La cosa cresce sotto gli occhi di tutti invece di essere svelata alla fine.
Crescere
Il lancio è l’inizio. Misuriamo, perfezioniamo e teniamo in vita il prodotto a lungo dopo la prima release.
Prima il problema,
poi l’idea.
Nel primo colloquio ci conosciamo a vicenda. Di cosa si tratta, e siamo le persone giuste per realizzarlo? Se no, dirlo presto costa meno a tutti che accorgersene tardi.
E vogliamo più dell’idea – vogliamo i processi che ci stanno dietro. Solo dopo aver fatto i proverbiali cento passi nelle scarpe altrui si può dire cosa va costruito e cosa è meglio lasciar perdere.
Diciamo la nostra
In questa fase siamo sparring partner, non esecutori. Pensiamo con te e diciamo di no quando abbiamo una proposta migliore – e giriamo e rigiriamo l’approccio finché tutti sono convinti di aver trovato quello giusto.
Un prezzo indicativo prima di partire
Appena è chiaro di cosa si tratta, facciamo una prima stima per un prezzo indicativo. Se l’ordine di grandezza va bene, si prosegue. Se no, la conversazione è servita comunque a qualcosa.
Tracciare il percorso
prima di mettersi in strada.
Nel workshop di kick-off chiariamo la portata, elaboriamo insieme i dettagli, fissiamo le milestone e definiamo una pianificazione. Quello che ne esce non è un documento da archiviare, ma la base per un’offerta vincolante.
La stima diventa un’offerta
Con il capitolato d’oneri elaborato insieme, la prima stima di prezzo viene precisata, ciò che manca viene aggiunto e si calcola l’offerta definitiva. Due passi invece di una cifra a occhio – e il secondo regge.
Anche l’architettura è pianificazione
Quanto deve crescere? Che forma hanno i dati? Cosa va collegato? Queste domande vanno poste qui e non nella terza settimana di sviluppo, quando la risposta diventa cara.
Crescere alla luce del sole,
non dietro il sipario.
Prima i wireframe, poi mockup e prototipi, sempre in stretta collaborazione. Poi si sviluppa e si testa di continuo, le nuove idee vengono discusse e integrate invece di essere rimandate a una seconda fase che non arriva mai.
Non c’è un momento in cui si svela qualcosa di finito. Ci sono tanti momenti in cui si discute qualcosa di mezzo finito. È più scomodo e porta a risultati migliori.
Verificato, non presunto
Quando crediamo di essere nel giusto, lo verifichiamo con utenti veri. Osserviamo ogni passo e vediamo dove si inceppa – quasi sempre in un punto che nessuno avrebbe immaginato, ed è proprio per questo che osservare vale la pena.
Chi costruisce parla anche
Nessuno strato di consulenza in mezzo, nessun telefono senza fili tra briefing e sviluppo. Le domande vanno direttamente alla persona che scrive il codice – il motivo principale per cui i team piccoli possono essere più veloci di quelli grandi.
Il lancio è
l’inizio.
Dopo il testing il prodotto va online. Poi lo teniamo in funzione e lo sviluppiamo ulteriormente – non un’offerta aggiuntiva, ma la parte in cui si decide se l’investimento è valso la pena.
L’esercizio fa parte del lavoro
Aggiornamenti, monitoraggio, backup e un numero a cui qualcuno risponde. Gran parte di ciò che costruiamo gira sulla nostra infrastruttura nella regione di Berna – per questo la risposta a «chi può controllare adesso» è raramente complicata.
Le estensioni migliori nascono dall’uso
Non da un workshop sulla roadmap, ma da una frase detta di passaggio durante il lavoro. Sono le aggiunte che vengono usate, perché qualcuno ne ha sentito la mancanza prima.
Meglio mostrare una volta in più
che descrivere.
Prima di costruire qualcosa, lo rendiamo visibile: schizzi, un mockup cliccabile, un prototipo che si comporta già più o meno come il prodotto finito. È un lavoro in più all’inizio, e lo facciamo volentieri – una decisione davanti a qualcosa che si vede davvero è diversa da una decisione davanti a una descrizione.
Una modifica nel prototipo costa un’ora. La stessa modifica nel software finito costa una settimana. Questo è tutto l’argomento.
Cosa ne risulta
La stessa strada,
qualunque cosa si costruisca.
Un sito web, un’app, un sistema da cui dipende un’azienda, un pezzo di AI in un processo esistente – alle quattro fasi non cambia nulla. Solo alla durata di ciascuna.
Cosa costruiamoDi cos’altro
ci occupiamo.
Tutto inizia con
una conversazione.
Nessuna preparazione necessaria, nessun capitolato richiesto. Descrivi cosa ti ostacola – il resto è compito nostro.