UN CALL CENTER UN ANALISTA E UN TESTER

Una delle aziende di consulenza software per cui ho lavorato aveva ottenuto una nuova commessa: realizzare un sistema informatico per il call center di una nota compagnia telefonica.

Tutto era pronto, prima di consegnare un progetto il cliente fa dei test: ma l'analista assegnato sul progetto probabilmente non sapeva cos'erano...

IL CALL CENTER

Il mio capo, felice dei soldoni che il cliente avrebbe scucito, assegnò me ed altri sul progetto.

Ognuno di noi avrebbe sviluppato una parte del sistema. Avete presente quando telefonate al call center della vostra compagnia telefonica e l'operatore riconosce chi siete dal numero e senza che apriate bocca vi racconta la storia della vostra vita (telefonica)? E poi inserisce i dati della vostra segnalazione nel terminale per farla lavorare?

Ecco, proprio quello.

L'ANALISTA

Naturalmente ci vuole un'analista, cioè una persona che d'accordo col cliente (la compagnia telefonica) decide quali funzioni svolgerà il sistema e in che modo.

Costui in genere realizza adeguata documentazione, non sempre in qualche linguaggio umano, che poi distribuisce ai programmatori, i quali dovranno "tradurre" e scrivere il "codice" dei vari programmi, o, in altri casi, configurare all'uopo un CRM (avete presente Siebel?)

All'epoca ero Analista Programmatore, una figura spesso incompresa. Nella mia azienda, ma anche in altre, la figura dell'Analista Programmatore si trova spesso a metà tra il "Puro Pensiero", l'Analista, e "l'Operaio del Software", il programmatore. In pratica fa due lavori con uno stipendio. Nel nostro ufficio era noto come "il Programmatore che sa anche ragionare".Il Jolly, insomma.

Essendoci già un Analista, persona laureata, in gamba, rinomata bla bla bla, mi fu subito spiegato che non c'era bisogno del mio cervello perché avrebbe pensato costui, quindi io dovevo solo lavorare in modalità "Operaio del Software": l'analista ordina, tu esegui.

Contenta di essere stipendiata come Analista Programmatore per fare solo il Programmatore, proposi un largo sorriso al tizio in giacca e cravatta che mi consegnò la famosa Analisi Funzionale e Tecnica della mia parte di sistema: decine di pagine...piene di bachi (bugs alla english).

Mi bastò una scorsa per capire che quell'analisi faceva acqua da tutte le parti e che disegnini, schemi e "flow chart" non sarebbero bastati a nascondere i grossi bachi che si celavano in quelle pagine prodotte con Word e PowerPoint. Sarebbero esplosi in faccia al cliente, e al mio analista, al primo test ufficiale.

Ma come? Bisogna sempre prevedere le cazzate che potrà fare l'utente dummy (il famoso utente scemo) e impedirgliele inserendo opportuni controlli, che qui mancavano.

Con un sorriso ancora più largo mi confidai con lui, l'analista, il quale era troppo occupato a magnificare la qualità della stampa della documentazione prodotta per capire cosa dicevo.

La conversazione andò pressapoco così:
IO: Dobbiamo parlare
LUI: Dimmi
IO: C'è un problema. Se ti sviluppo la funzionalità in questo modo (indicando con la mano la documentazione rilegata) basta che l'utente clicchi questo pulsante (e gli indico il disegnino del pulsante) per fare un casino (gli specifico quale casino).
Dovremmo inserire dei controlli nel software per evitare che possa far danni.
LUI: No, macché, sono superflui.
IO: Superflui? Perché?
LUI: Perché queste azioni che tu mi descrivi l'utente non le eseguirà MAI, quindi quei controlli non servono, è inutile metterli.
IO: Come fai a sapere che l'utente non farà mai quelle "cose"?
LUI: Semplice. Consegneremo al cliente il Manuale Utente, là ci sono scritte le operazioni consentite. L'utente eseguirà solo quelle azioni e quindi non c'è rischio di casini. Ti preoccupi per nulla.

Mentre l'assurdità dell'ultima frase mi rendeva paonazza, iniziai a pregare il Santo protettore dei programmatori. Non sapevo se esisteva ma doveva esserci: possibile che nel ventunesimo secolo nessuno avesse pensato a dare un Santo protettore pure a noi?

Dopo aver vanificato tutte le mie obiezioni col solito ritornello del "Manuale Utente che vede e provvede", e avermi dato della "allarmista" sottolineando che non dovevo ASSOLUTAMENTE modificare NULLA perché il sistema era perfetto così com'è, l'analista contento tornò alle sue slide PowerPoint.

Rimasta sola col mio complesso di Cassandra, avevo due prospettive

1. Dimenticare la conversazione e obbedire


2. Fregarmene dell'analista e fare ciò che era giusto

IL TESTER

L'opzione 1 non era fattibile: L'azienda aveva in programma una dimostrazione del sistema proprio col tester fidato della compagnia telefonica.
Il tester ha il compito di cercare i bug, le imperfezioni, le dimenticanze, tutto ciò che avrebbe potuto dare al cliente un pretesto per chiedere una riduzione sul prezzo per la realizzazione del sistema: a seconda della complessità questi sistemi possono arrivare a costare decine anche centinaia di milioni di vecchie lire, e andranno a gestire i dati di milioni di persone che pagano i servizi della compagnia telefonica. Mica son bruscolini, devono essere in grado di fare pure il caffè.

La figura del tester è un gran disgraziato, alcuni (me compresa) provano un piacere perverso a trovare i bug, per giunta a pagamento (io sono così brava che li trovo pure se non li cerco :D). Il tester non segue mica il Manuale Utente per trovare i bachi, ma diciamo la verità: quale utente segue il Manuale Utente????

Per cui, anche se avessi fatto il mulo e seguito le direttive (errate) dell'Analista, al momento dei famosi test non ci sarebbe più stato scampo: e quando un software fa casini i papaveri aziendali possono far ricadere la colpa della figuraccia su chi sta alla base della piramide, in quel caso me medesima.

"Perché non mi hai segnalato i bachi?" sarebbe stato il primo rinfaccio e probabilmente l'analista neanche si sarebbe ricordato della mia profezia, ma anche qualora lo avesse fatto, il mio capo non avrebbe mai dato la colpa ad uno blasonato dallo stipendio di decine di migliaia di euro in più del mio.

IL PROGRAMMATORE PENELOPE

Così scelsi l'opzione 2, correggere il sistema di nascosto, alla Penelope: davanti all'analista sviluppavo il programma secondo le sue direttive (casinare), appena usciva o si voltava, riprogettavo al volo (a runtime nel nostro gergo) blindando ogni possibile bug, ogni potenziale azione nefasta potesse immaginare quello spauraccho del tester.

Più un sistema è complesso più bug potenziali ci sono, e nel mio caso ce n'erano davvero tanti: nemmeno un bambino di 5 anni avrebbe progettato un sistema con così tante falle.
Il mio lavoro "ufficiale" subì uno strano rallentamento. Considerando che ero nota come "Speedy Gonzales" per la mia velocità di programmazione, nessuno capiva il perché del rallentamento (e il mio analista ingenuo aveva già archiviato la nostra conversazione).

Rallentamento per modo di dire, è che di solito se mi davano 10 giorni per implementare una funzionalità, io la terminavo in 4. Stavolta invece stavo impiegando tutti i giorni previsti. Mai successo!!

Incassai i commenti sarcastici di capo e colleghi a corredo della mia "presunta" perdita di talento, sapendo che sopportavo tutto ciò per un fine superiore: il mio stipendio mensile.

IL TEST

Il giorno della dimostrazione con il tester, l'analista non si fece sentire. Un silenzio preoccupante per tutti, tranne per me, che, onestamente, sapevo il fatto mio.

Al ritorno l'analista entrò in stanza ed esordì così
"La dimostrazione è andata molto bene, la compagnia è stata contenta. Ringrazio tutti voi per il contributo... e un grazie speciale va a " e fece il mio nome " per tutti gli easter eggs (uova di pasqua) che ha inserito nel sistema".

"Easter eggs", carinamente definì così tutti i controlli anti bug che avevo disseminato a sua insaputa.

L'analista, tra il mortificato e il contento, mi svelò che avevo ragione io . Lo aveva capito nel momento in cui il tester aveva impugnato il mouse SENZA mai guardare quel benedetto manuale utente.
Tra un click e l'altro, l'analista aveva ricordato il mio avvertimento, sudando freddo dato che ricordava anche di avermi ordinato più volte di NON mettere quei benedetti controlli.

In quella giornata di sole, si era finalmente reso conto che il sistema che lui aveva progettato consentiva al tester di cavalcare libero nella prateria investendo e distruggendo qualunque cosa gli fosse capitato a tiro. Aveva quindi iniziato a prepararsi alla immane figuraccia che stava per procurare alla sua e alla mia azienda.

Ma proprio in quel momento Santa Valeria aveva fatto capolino con alcune message box (messaggi d'errore) e controlli vari che bloccavano qualunque tentativo di "fottere" il sistema (e la mia azienda), costringendo il tester a camminare sulla "retta via".

Alla fine, soddisfatto, il tester aveva pure stretto la mano al mio analista complimentandosi per la realizzazione del sistema.

La compagnia telefonica riconfermò la fiducia alla mia azienda e l'analista restò in debito con me.

Sembra fantascienza ma andò davvero così.

Condividi su Facebook, Twitter, Google Buzz o Friendfeed: