lunedì, marzo 05, 2012

Analisi dei requisiti? Parte seconda

Per sviluppare un software mi hanno spiegato che in teoria:

- Ricevi le richieste del cliente
- Ne analizzi la fattibilità e l'eventuale modularità
- Imposti uno schema di risoluzione
- Fai eventuali disegnini per far capire la tua idea al cliente
- Correggi il tiro in base alle modifiche richieste
- Imposti le priorità ed una timeline
- Generi il database ed i moduli in ordine di priorità
- Correggi i bachi e le imprecisioni
- Implementi le funzionalità aggiuntive

Tutto questo in teoria. Purtroppo.

La condizione in cui mi sono trovato è stata:

Four years ago

Gama - Sono qui per sapere cosa vi serve nel programma per la gestione dell'imposta sugli immobili.

$dirigente - Un programma per la gestione dell'imposta sugli immobili.

Gama - Ok, un po' più di dettaglio?

$dirigente - Sonasegaio, senti $moglie.

Vado quindi da sua moglie che lavora nell'ufficio accanto.

$moglie - Usiamo il programma di $exGestoreTributiImmobili.

Gama - Vabbè, ma per fare pagare la gente come fate? Le cose mi hanno insegnato non si generano dal nulla.

$moglie - Ah, per quello senti $exGestoreTributi: il loro programma che funziona benissimo!

Ed inizia a cliccare come una forsennata in un applicativo che apre un fottigliardo di sottofinestre.

Gama - O_O'


Mesto me ne ritornai nel loculo con un foglio di carta bianco ed un numero di telefono da contattare, avviluppatto nella certezza che "Sicuramente mi diranno tutto quello che voglio appena sapranno che il loro contratto sta per essere reciso come un ramo secco!"

Nessuna risposta per giorni.

Nel mentre, durante un intervento di routine per pc spappolato ho incrociato $exCollegaTributi che, a quanto ho scoperto con il tempo, è una delle due persone che REALMENTE lavoravano sul programma di $exGestoreTributi.

$exCollegaTributi - Tranquillo, va sempre a finire così: io e $collegaTributi carichiamo le dichiarazioni dei contribuenti nel programma ed il resto lo fa tutto l'ufficio di $exGestoreTributi. Il tributo è tutto basato sull'auto-dichiarazione del contribuente, se poi non dichiarano il vero vengono prese sanzioni tramite gli accertamenti.

Gama - Ah.

$exCollegaTributi - Hai presente quella maschera di stampa delle ricevute delle dichiarazioni? Ecco, quel numero progressivo che generi è il numero di protocollo che diamo alla dichiarazione nel programma.

Gama - Ho già scritto un pezzo di programma e non lo sapevo?

$exCollegaTributi - A quanto pare si, sono davvero felice che ci lavori su! Quando vuoi ti faccio vedere come funziona la parte di inserimento ma se riesci cerca di farla meglio perché non ci si capisce nulla ed è scomoda e macchinosa.

Gama - Hai mica uno di quei moduli che consegnano i contribuenti in bianco, mi sembra ci siano sopra tutte le informazioni che vi interessano.

A quanto pare da un colloquio casuale ho ottenuto più informazioni di un incontro ufficiale.

Alcuni giorni dopo riuscii a contattare $exGestoreTributi che, ovviamente, si limitò a mandarmi un dump della banca dati in formato testuale. Record con campi a dimensione fissa e '\0' come riempimento degli spazi inutilizzati. Per i non tecnici '\0' è la trascodifica del carattere che termina una stringa di testo.
Ovviamente dato in pasto a qualsiasi programma di importazione o script scritto ad hoc il risultato era un sonoro sfanculamento.

Non ebbi nemmeno il tempo di iniziare a ripulire il tutto che il progetto venne fermato a causa della decisione del governo di modificare il tutto, cosa che si è risolta nell'abolizione del pagamento per la prima casa.

Tutto rimase congelato fino ad ottobre dello stesso anno.

Continua.

Gama

3 commenti:

Daniele C. ha detto...

Quando si dice, chiedi alla persona giusta le informanzioni che ti servono...

So cos'hai passato: per il progetto di cui ti parlavo prima io avevo 3 contatti:

1. SUSL della ditta (che aveva pensato al progetto, ma non aveva conoscenze tecniche o commerciali)
2. SL commerciale (per le funzionalità da implementare, ovviamente senza conoscenze tecniche)
3. CL tecnico (per le questioni tecniche, che ovviamente non sapeva spiegare).

Il problema era che SUSL diceva che voleva una cosa. Io la facevo. Un mese dopo mi chiamava SL dicendo che così non andava bene, che era contro la legge (e via dicendo). Io correggevo. Un mese dopo mi chiamava CL dicendo che così non riuscivano ad usarlo, che i valori non avevano senso (e così via). Io riricorregevo. Un mese dopo mi richiamava SUSL, incazzatissimo, chiedendo che era successo alla sua funzionalità che era perfetta come me l'aveva detta (ovviamente).

Alla fine (dopo una serie di modifiche che 3 tre mi avevano chiesto, ma, incidentalmente, quello che mi chiedeva uno non piaceva agli altri due) io, con i cogl###i stracciati, ho chiesto al mio boss che dovevo fare quando ricevevo una richiesta. Lui fa "ora chiedo, tu per ora non fare più nulla".

6 mesi (SEI MESI) dopo, mi è stato detto che avrei ripreso a fare le modifiche solo dopo che uno dei tre me la richiedeva ed io ricevevo l'assenso degli altri due.

Valeren ha detto...

@ Gama
QUANTO HAI RAGIONE!
Ci sono più possibilità di avere le info alla macchinetta del caffé che in riunione.
E non servono inutili memo riepilogativi.

@ Daniele C
Er... Le tre scimmiette.
In condizioni simili ho imparato che i backup cambiano / salvano la vita.
Utente A rivuole la " sua " versione: ripristini e via.
C si lamenta? Versione 3
Non risolvi il problema finale, perché richiede almeno due proiettili, ma intanto eviti di farti saltare il fegato.

Daniele C. ha detto...

@Valeren:
Quanto è bello il backup... senonché, tra la versione A e la versione B, il database che ci sta in mezzo non c'entra una cippa!

Vabbé forse è un po' esagerato, ma quando cambi il tipo di dato delle colonne anche poche modifiche diveantano pesanti da riportare indietro... A meno che non passi tutto sul Varchar5000 e te ne sbatti altamente di performance e simili.

La cosa triste è che, ad oggi, l'app in questione ha un DB che gli manca assai poco di diventare così.