Come ho già detto in passato il lavoro di assistenza tecnica è interessante perché costringe a trovare un modo sempre diverso di fare-configurare-risolvere un determinato problema. Oggi aggiungo che dà anche l’opportunità di vedere approcci diversi alla ricerca della soluzione, e questo per me è una ricchezza.
Nel vedere questi approcci ho notato che in molti casi la soluzione al problema non è stata trovata perché il malfunzionamento non è stato analizzato con un metodo preciso. Così facendo serve più tempo per risolverlo, oppure l’aiuto di qualcun altro per venirne a capo.
Voglio raccontarvi il mio metodo. La mia personale scaletta è composta di tre fasi: replicare, isolare, congelare.
Prima di tutto è necessario essere in grado di replicare il problema, perché finché capita in modo imprevedibile è difficile comprenderlo, figurarsi risolverlo. L’ideale è conoscere la sequenza esatta di operazioni da compiere per manifestare l’anomalia, ma può andar bene anche un problema che si ripresenta molto spesso. Nella maggior parte dei casi già in questa fase si trova la soluzione.
Se il problema non è risolto bisogna isolarlo, cioè separare il più possibile l’anomalia dai normali comportamenti applicativi. L’analisi di un solo ingranaggio è sicuramente più semplice rispetto a quella dell’intero meccanismo, ed è così che si possono risolvere i casi complessi. Trovare l’ingranaggio giusto, poi, aiuta la comprensione di quello che sta veramente accadendo.
Se ancora la soluzione non è stata trovata, è arrivato il momento di chiedere aiuto per non perdere troppo tempo. In questo caso occorre congelare il progetto, cioè crearne una copia in cui il problema sia isolato e replicabile. Questo passaggio è di fondamentale importanza perché altrimenti ogni successiva variazione dell’applicazione può impedire l’analisi del problema, richiedere altro tempo per replicarlo, o peggio risolverlo casualmente, senza che sia stato possibile capirne la causa e quindi avere la certezza che non si presenti più.
In molte delle richieste di assistenza che abbiamo gestito, l’uso di questo approccio ha permesso al cliente di individuare la soluzione da solo. Usandolo prima sarebbe stato possibile risparmiare tempo, trovando la soluzione anche senza il nostro intervento.
Se non avete un metodo prestabilito di approccio alla soluzione di un bug, vi suggerisco di provare questo. Se invece avete qualcosa da aggiungere sarei molto contento di parlarne insieme.
Picture: farnea
Faccio riferimento al recente post di Giovanni sulla tecnologia semplice, in cui si citava la non necessità di leggere il manuale utente come requisito di qualunque applicazione software gestionale moderna, per raccontare una vicenda personale, un po’ surreale ma realmente accaduta, in cui ho capito definitivamente che deve essere così.
Qualche mese fa sono stato sottoposto ad un piccolo intervento chirurgico in anestesia locale. In pratica mi sono trovato in una sala operatoria proprio come quella del dottor House, pieno di elettrodi e legato come un salame, ma sveglio e cosciente. Non vi nego una certa apprensione.
Mentre il chirurgo si apprestava ad iniziare l’intervento è arrivato il temuto contrattempo (ma perché proprio a me?). Questo è un resoconto fedele dei dialoghi fra chirurgo ed infermiera.
Chirurgo: “Ma questo non è il nostro bisturi elettrico, che fine ha fatto?”
Infermiera: “Dottore si è rotto e abbiamo preso in prestito quello di un altro reparto”
Chirurgo: “Ma il nostro aveva due pedali, questo solo uno. Come funzionerà?”
Infermiera: “Dottore basta girare la manopola F sul valore 3 e usare il pedale come nel nostro bisturi”
Chirurgo: “Ma lei come fa a saperlo?”
Infermiera: “Sa dottore, sono gli appunti che ci passiamo fra noi infermiere”
Dopo questo fatto ho giurato che non avrei più scritto una sola riga di codice che non servisse per semplificare e rendere più naturale il funzionamento delle applicazioni di cui mi occupo. E ce n’è bisogno anche nel caso di un “semplice” bisturi elettrico.
Picture: SarahMcD
I miei genitori hanno acquistato una nuova televisione LCD e per attivarla sono stati costretti a chiamarmi. Non che io sia particolarmente esperto, ma studi scientifici e lavorare in un’azienda ad alto contenuto “tecnologico” dovrebbero essere condizioni sufficienti per affrontare la configurazione di una tv. Invece non è stato semplice muoversi tra mille opzioni, sigle sconosciute e comandi di cui non si capiva il significato e l’effetto, in poche parole mi sono sentito abbastanza “impedito” in barba a tutte le mie conoscenze…
Questo mi ha fatto chiedere perchè debba essere sempre così complicato utilizzare nuovi prodotti e se questo dipenda dal fatto che forse chi li ha realizzati abbia dedicato un’attenzione eccessiva alle novità tecnologiche, piuttosto che ai futuri utilizzatori.
Purtroppo credo che spesso questo capiti anche a noi quando sviluppiamo i nostri prodotti software: ad esempio a chi è rivolta la nostra attenzione quando progettiamo una videata con centinaia di campi di cui un certo utente all’atto pratico dovrà gestirne solo una decina? Possibile che non ci siano altre soluzioni?
Ho visto qualcosa di nuovo quando mia moglie ha attivato il suo iPhone: è riuscita a metterlo in funzione con una facilità e un’immediatezza che mi hanno colpito, così come anche mio figlio dodicenne, appena lo ha visto, lo ha subito preso, si è collegato all’AppStore e ha iniziato a scaricare le applicazioni di suo interesse, tutto con molta naturalezza.
Penso che sia giunta l’ora di cambiare il modo con cui si progettano le interfacce dei software gestionali.
I fattori che hanno contribuito all’esperienza di soddisfazione raccontata prima e che mi piacerebbe trovare nelle prossime applicazioni sono:
- Si deve capire subito come usarle, il manuale utente non deve servire.
- Devono essere belle esteticamente, anche l’occhio vuole la sua parte!
- Devono essere sempre disponibili: in ufficio, dal cliente, sul treno, a casa…
- Devono essere fruibili da qualsiasi dispositivo e da qualsiasi browser.
- Devono essere utilizzabili da touch screen o magari in futuro anche solo con la voce.
Sentite anche voi questa esigenza?
Da una pagina del supporto tecnico di google:
Support stops on March 13th. Stopped support essentially means that some future features on YouTube will be rolled out that won’t work in older browsers.
Trovate questa frase nella sezione FAQ alla voce When does older browser support end for YouTube and what does this mean?, mentre alla voce Which browsers will this impact? trovate l’elenco delle versioni considerate obsolete.
Google fa un passo deciso per togliersi di torno i browser meno recenti, interrompendo il supporto e quindi eliminando molti vincoli nella realizzazione delle nuove feature.
E’ interessante notare due cose:
- la scomparsa del supporto non influenza solo IE 6.0, che come abbiamo già detto ormai è da pensione, ma anche Firefox 2.x, Chrome 3.x e Safari 2.0.
- la comparsa di Opera 10 tra i browser scelti per la compatibilità di youtube.
In particolare la presenza di Opera tra i browser scelti da Google ci ha spinto a pensare di estendere la compatibilità delle applicazioni create con In.de anche a questo browser, cosa che molto probabilmente avverrà entro fine anno.
Decisamente una bella notizia, perché dai primi test che abbiamo fatto l’ultima versione di Opera risulta essere il più veloce tra i browser in circolazione, ottenendo il 50% di velocità in più rispetto a Chrome nell’applicazione di esempio fps.
Picture: gianΩmerz – 
