Sviluppo software a settimane
SVILUPPO DI PRODOTTO A SETTIMANE
TEMPO DI SVILUPPO CONCENTRATO. PRIORITÀ FLESSIBILI. DECISIONE DI SETTIMANA IN SETTIMANA.
Da questa logica deriva il modello a settimane. La collaborazione non comincia con il tentativo di fissare per intero un insieme di funzionalità a lungo termine. Comincia con un’idea di prodotto concreta o una questione tecnica e con un periodo di sviluppo chiaramente delimitato.
Prima della settimana di sviluppo
Chiariamo quale domanda, allo stato attuale, promette il maggior valore in termini di conoscenza o di prodotto. Decisiva non è la lista di funzionalità più lunga, ma la domanda il cui chiarimento tecnico migliora la prossima decisione imprenditoriale.
Può trattarsi di una sezione verticale coerente di un’applicazione, del nucleo di una nuova architettura software, di un concetto d’interazione esigente, di una simulazione, di un ambiente di lavoro visivo o di un primo nucleo di prodotto completo.
Durante la settimana di sviluppo
Lo sviluppo è concentrato. Nuove conoscenze possono modificare le priorità. Se un approccio si rivela debole o diventa visibile una direzione migliore, si può reagire immediatamente.
Questa flessibilità non è mancanza di pianificazione. È una conseguenza consapevole del fatto che le informazioni rilevanti sul prodotto possono emergere solo durante lo sviluppo reale.
Alla fine della settimana di sviluppo
È disponibile lo stato di sviluppo raggiunto. Su questa base si decide se proseguire lo sviluppo, approfondire, modificare o concludere.
Ciò che si prenota è tempo di sviluppo. Non un insieme di funzionalità definito in anticipo, né un determinato risultato d’opera.
UNA SETTIMANA · 4.900 € NETTI
Ogni settimana successiva viene concordata separatamente. Non è prevista alcuna prosecuzione automatica.
Un prezzo fisso per un prodotto nuovo è una scommessa: sapere prima ciò che si impara solo costruendo.
Una settimana di sviluppo non è un’unità di misura per un numero fisso di funzionalità. I prodotti software differiscono troppo per complessità, situazione di partenza e dipendenze tecniche perché ciò sia possibile.
Con compiti adatti, tuttavia, già in brevi cicli di sviluppo può nascere un sistema applicativo coerente: con un’interfaccia utente reale, una logica di dominio centrale, un modello dati, la visualizzazione e una struttura tecnica solida.
Nei sistemi desktop, in tempo reale o di visualizzazione complessi, una settimana può produrre uno spaccato verticale che non contiene ogni funzionalità futura, ma possiede abbastanza architettura e funzionalità reali per prendere decisioni di prodotto centrali.
Se le basi tecniche sono già ben comprese, la portata può spingersi molto più in là.
In presenza di rischi legati alla ricerca, all’integrazione o alle prestazioni, invece, il chiarimento di un singolo problema tecnico critico può avere il maggior valore economico.
La portata non è standardizzata. L’ambizione sì: quanta più realtà di prodotto affidabile possibile nel più breve tempo di sviluppo.
Chi alla fine di un progetto software non possiede il codice sorgente, ha preso il software in affitto.
CODICE SORGENTE. CONTINUITÀ. RISERVATEZZA.
La collaborazione è pensata per garantire l’indipendenza tecnica.
A pagamento integrale avvenuto, il committente riceve il codice sorgente relativo al progetto per lo stato di sviluppo raggiunto, nonché i file di progetto rilevanti per l’ulteriore lavorazione, nella misura in cui questi siano parte dello sviluppo e possano essere trasferiti giuridicamente.
Lo stato di sviluppo deve poter essere portato avanti dal committente stesso o da terzi.
Le informazioni commerciali e tecniche riservate vengono trattate con riservatezza.
Non esiste alcun vincolo strategico a una piattaforma di sviluppo proprietaria di CUBE4DEV.
Lei acquista tempo di sviluppo e riceve lo stato di progetto che ne risulta.
Se servono solo più ore di sviluppo, sono la scelta sbagliata.
L’approccio è particolarmente adatto alle aziende in cui esistono idee di prodotto sostanziali il cui potenziale non è ancora stato chiarito a sufficienza.
Può trattarsi di una nuova applicazione autonoma, di un prodotto digitale, di un sistema specialistico, di una simulazione, di un ambiente di visualizzazione, di uno strumento interattivo complesso o di un’estensione software sostanziale di un prodotto esistente.
Il modello ha senso soprattutto quando uno stato di sviluppo tecnico reale promette più conoscenze di un’ulteriore pianificazione astratta e quando l’idea di prodotto è ancora abbastanza aperta da poter reagire a nuove acquisizioni.
È meno adatto quando si vuole acquistare un insieme di funzionalità completamente specificato a un prezzo fisso, quando serve un grande team di sviluppo o quando si intende soltanto integrare risorse di sviluppo aggiuntive in un’organizzazione esistente.
L’approccio non punta alla realizzazione più economica possibile di attività IT già esistenti. Punta a idee di prodotto per le quali lo sviluppo tecnico può rendere visibili nuove opzioni imprenditoriali.
QUALE IDEA DOVREMMO PROVARE PER PRIMA?
La lista di funzionalità più lunga è il peggior inizio per un nuovo prodotto.
Non tutte le idee di prodotto rilevanti richiedono subito un grande progetto.
Spesso, per cominciare, basta una domanda precisa: quale idea di prodotto andrebbe portata a un livello tecnico reale prima di decidere un investimento maggiore? Quale applicazione esiste finora solo come concetto? Quale possibilità tecnica è abbastanza interessante da non doverne più discutere solo in teoria?
Una settimana di sviluppo può essere l’inizio di un prodotto più grande. Può però anche creare la base per decidere consapevolmente di non proseguire con un’idea o di svilupparla in un’altra direzione.
Il primo passo non deve definire l’intero prodotto. Deve rendere migliore la decisione successiva.
UNA SETTIMANA · 4.900 € NETTI
Progetti di esempio
3
Chiedere informazioni
SVILUPPO DI PRODOTTO A SETTIMANE