Il tuo lavoro, prima del software.
Fogli di calcolo e strumenti si sono accumulati. Osserviamo come lavora il team per capire cosa un software interno deve semplificare, prima di decidere cosa sviluppare.
Un utilizzo preciso.
Attività disperse
Seguire una pratica tra file, conversazioni e approvazioni.
Ruoli diversi
Chiarire chi consulta, modifica e approva le informazioni.
Sistemi esistenti
Identificare dati e connessioni da conservare.
Cosa ottieni dalla definizione.
Una mappa del lavoro
Ruoli, dati e passaggi che creano duplicazioni o blocchi.
Un unico schema del processo dall’inizio alla fine, con le note dei colloqui da cui nasce, in una cartella che le resta.
Un prototipo operativo
Le schermate del processo prioritario, discusse con chi le utilizzerà.
Schermate cliccabili che seguono una pratica dall’arrivo all’approvazione, più la registrazione della sessione in cui il suo team le ha provate.
Specifiche utilizzabili
Primo ambito, regole di accesso, dipendenze e criteri di accettazione.
Una specifica numerata, un criterio di accettazione per riga, scritta perché qualsiasi team di sviluppo possa quotarla.
Quanto tempo serve.
Da tre a cinque settimane, secondo quanti ruoli toccano il processo e quanto in fretta si fissano i colloqui. Lo schema arriva a colloqui conclusi, di solito nella seconda settimana.
Cosa serve da Lei.
Tempo con chi fa il lavoro
Da quattro a sei colloqui di quarantacinque minuti, con le persone che eseguono il processo ogni giorno. Le loro scorciatoie sono i requisiti veri, e chi dirige spesso le ignora.
Una pratica da seguire dall’inizio alla fine
Un caso recente con le sue email, gli allegati e le approvazioni, così come è andato, anonimizzato se serve. Un esempio pulito nasconde le eccezioni che costano di più da sviluppare.
Una decisione sugli strumenti già in uso
Quali restano, e chi ne detiene le licenze. Il costo della migrazione si decide qui, molto prima della prima riga di codice.