Da dove partire
Se il problema è vago o i requisiti non sono chiari, il modo migliore per iniziare non è mettersi a scrivere codice, ma fare chiarezza con uno studio preliminare.
Qui trovate proposti alcuni di quelli che ci vengono chiesti più spesso.
“Vorrei realizzare un nuovo software ma non so da dove partire.” · “Per questo progetto il budget è già stato fissato. Non so se basta.”
Stiamo costruendo la cosa giusta?
Prima di investire nello sviluppo mettiamo in fila il problema, il valore atteso e le priorità. Ne uscite con un backlog ordinato, una direzione che potete sostenere davanti a chi prende le decisioni e una stima di budget su cui ragionare.
“All'inizio i requisiti sembravano chiari. Dopo un po' non lo erano più.”
Riusciremo a finire quello che ci è stato chiesto?
Prima di passare alla scrittura del codice verifichiamo architettura, requisiti e integrazioni, e mettiamo per iscritto le decisioni tecniche ancora aperte, in modo che nessuno le scopra a metà progetto.
“Il progetto è partito ma non riesco a dire dove sia arrivato.”
Il progetto è sotto controllo?
Una fotografia chiara di tempi, costi, dipendenze e responsabilità, scritta in modo da poter aiutare sia il team che chi prende le decisioni.
“Questo software funziona solo che nessuno vuole metterci mano.”
Siamo ancora in grado di far evolvere questo sistema?
Stimiamo quanto vi costerà far evolvere il software che avete già, dove conviene intervenire e cosa è meglio lasciare com'è.
Come funziona l'analisi?
- Investimento
- Il costo è fisso e contenuto, concordato prima di iniziare.
- Consegna
- Dieci giorni di calendario dal kickoff, che avviene entro 5 giorni lavorativi dalla conferma.
- Il vostro tempo
- Circa 6 ore complessive, distribuite in tre incontri con le persone di riferimento.
- Cosa ricevete
- Un documento strutturato di circa venti pagine, scritto per essere letto anche da chi non ha seguito l'analisi, con diagnosi e indicazione del passo successivo.
- La decisione
- Alla fine avete gli elementi per decidere se procedere, cambiare direzione o fermarvi, prima di impegnare il budget di sviluppo.
Cosa non è
- Non è un audit formale e non è una verifica sul lavoro delle persone.
- Non è una proposta commerciale travestita da analisi per vendere giornate di sviluppo.
- Non produce codice ma le basi per scrivere il codice giusto.
- Non vi obbliga a proseguire lo sviluppo con noi.
Il documento resta vostro
Nessuna di queste analisi vi lega a noi per lo sviluppo: il documento è vostro e resta valido anche se poi lo affidate a un altro fornitore o al vostro team interno.
E nessuna analisi è obbligatoria: se il quadro è già chiaro, possiamo iniziare direttamente con lo sviluppo.
Non sapete quale vi serve?
Abbiamo preparato un breve questionario da tre minuti che mette a fuoco la vostra situazione e indica quale passo ha più senso adesso. Oppure, se preferite parlarne, scriveteci. Non risponderà un commerciale ma un ingegnere.