Coloro i quali hanno familiarità col mondo del software sanno che gli sviluppatori etichettano i loro software con un numero, il release number o version. Prima versione? 1.0. Un po’ di correzioni alla prima versione? 1.1. Nuova versione? 2.0
(Questo prima che un nero genio del marketing a orologeria sostituisse i numeri di release con l’anno di fabbricazione, cosa che porta la bomba obsolescenza a deflagrare quando l’utente realizza che sta “ancora usando Prodotto 2000! Siamo nel 2007!” Come se il software arrugginisse, poi.)
Alla PiccolaImpresa si sta lavorando con sempre crescente alacrità, e cominciano a restare indietro quelle cose che andrebbero fatte però il cliente mi ha chiamato e c’è un’urgenza. Ti accorgi di avere un problema quando sono sei mesi che c’è urgenza ogni santo giorno e ancora non hai fatto la policy per le trasferte.
un task visto da vicinoCosì abbiamo iniziato a scrivere la lista delle cose da fare dentro Gemini. Questo software è pensato per la to-do list di un software (bug, nuove funzioni) e permette di associare ad ogni elemento della lista, oltre alla priorità e cose del genere, la versione per la quale sarà pronto. Grafici in 3D? Nella versione 3.0 (ops, volevo dire 2008).
Di qui l’idea: e se concordassimo delle versioni anche per la nostra organizzazione? La policy trasferte è urgente, la facciamo per la PiccolaImpresa release 1.1, il controllo di gestione invece lo rilasciamo nella 2.0. Questo ci costringe a fare quello che pianificavamo entro ogni data di rilascio, oppure a spostarne la realizzazione nel rilascio successivo. Ma almeno non rischiamo di dimenticarcene.
Non ti è arrivato lo stipendio? E’ un bug.
(via Pondga’s starred items in Google Reader)
Iscriviti ai feed RSS [11.541 iscritti]
