Archivio mensile:Aprile 2007

Redigere la relazione di una riunione

Pubblicato il da

Cosa fare terminata una riunione di progetto con un cliente? La cosa migliore è quella di scrivere la relazione della riunione da inviare in copia conoscenza e per conferma.

Senza aspettare una settimana: la relazione va scritta in giornata o al più tardi il giorno dopo, perché più tempo passa e più facile sarà che vi dimentichiate qualche punto importante, anche se avete preso note e siete convinti di avere segnato tutto cioè che è fondamentale.

Utilizzate una forma sintattica semplice, meglio se informale, e preferite termini che descrivono precisamente, con frasi brevi, i concetti che sono stati affrontanti nel corso della riunione.

Poiché nel corso della riunione gli argomenti possono essere stati i più vari, numerose le parentesi aperte e altrettanti i punti in cui si è tornato a discutere di cose già viste, cercate anche di riorganizzare il materiale dandogli un filo logico di progressione, per quanto possibile. Nel farlo cercate anche di dividere in capitoli i diversi aspetti affrontati nel corso della riunione.

Non lasciate punti aperti o liberi di interpretazione, magari deliberatamente a causa di una richiesta che volete mascherare o su cui non siete d’accordo. La relazione di riunione è anzi il luogo candidato ad anticipare problemi o incomprensione che in fase di sviluppo manifestano importanti influenze sui tempi e sui costi. Cercate quindi di far emergere dubbi, perplessità e problematiche già espresse nel corso della riunione.

Evitate invece di proporre delle soluzioni alle problematiche affrontate, almeno che di questo non abbiate già discusso. Il documento preposto a questo è quello di analisi, non questa relazione.

La relazione di una riunione è invece un modo per richiedere, dove esistano delle lacune, degli approfondimenti che il cliente è tenuto a fornire, possibilmente per iscritto. Approfondimenti che dovranno poi entrare a far parte di una nuova versione della relazione.

Se già esiste un’idea di come possa essere sviluppata l’applicazione, per esempio se la riunione riguarda un progetto già esistente, potrebbe essere una buona idea quella di corredare il documento con uno o più diagrammi o wireframe che partecipano a dissipare l’ambiguità che il testo comunque porta con sè.

La relazione andrebbe poi inviata al cliente per accettazione, in modo informale (via email), o formale (firmata) in base agli accordi contrattuali e alle dimensioni del progetto in esame.

Google e la sicurezza

Pubblicato il da

Google ha recentemente pubblicato un documento [Pdf, 70Kbyte] in cui evidenzia le strategie che adotta nell’ambito della sicurezza e della protezione alle vulnerabilità. Lo scopo è di garantire la riservatezza e integrità dei dati che ogni giorno transitano nella propria rete.

Di tutto il documento un punto di discussione lo merita senza dubbio la sezione Logical Security. Traduco in libertà:

Gran parte della tecnologia di Google è scritta per risolvere problemi ed esigenze specifiche piuttosto che generali. Lo strato di web server, per esempio, è stato progettato e sviluppato da Google in modo che esponga solo le operazioni necessarie alle nostre applicazioni. Per questo motivo non è vulnerabile agli attacchi così come lo sono solitamente i software commerciali.

Il discorso non fa una grinza ed è condivisibile. Mi chiedo però se da qualche parte sia possibile scaricare liberamente i sorgenti di questo web server oppure si tratti di una versione riservata, come temo. Perché se è così questa storia sa tanto da Microsoft e dall’idea che, creando un software proprietario senza liberalizzare i sorgenti, diminuisca la possibilità che qualche malintenzionato ne scopra le vulnerabilità. La storia ha più volte smentito questa convinzione.

Interfacce che si adattano

Pubblicato il da

Cominciano a comparire nei blog dei relatori alcune delle presentazioni al recente Information Architecture Summit di Las Vegas. E ce ne sono da leggere con attenzione.

Come per esempio quella di Stephen Anderson, “Creating the Adaptive Inferface” che affronta il problema della progettazione di interfacce che non si manifestino allo stesso modo a tutti gli utenti, ma siano in grado di adattarsi alle diverse esigenze, ai diversi usi, e anche al grado di padronanza che con l’uso l’utente è in grado di dimostrare.

L’idea – non nuova – di Anderson è quella di sfruttare le informazioni “involontariamente” lasciate dall’utente nel sito web, come per esempio l’indirizzo di ip (e quindi, con buona approssimazione, la località) e, nel caso di servizi sotto login o che sfruttino i cookie, le variazione nelle attività dell’utente e la frequenza di utilizzo.

Questo permette al software che produce l’interfaccia di evidenziare le sezioni più richieste a scapito di quelle meno utilizzate, di precompilare alcuni campi in base alle preferenze dell’utente e di personalizzare alcune etichette dell’interfaccia.

Il concetto è sicuramente interessante, come lo sono i diversi esempi presentati. Esistono comunque alcuni fattori da tenere in grande considerazione nel progettare questo tipo di interfacce. Il primo, riconosciuto dallo stesso autore, è che l’utente non va spaventato dandogli a vedere che sappiamo molto di lui: l’aiuto dell’interfaccia dev’essere discreto e non superare mai i limiti della cortesia.

A questo aggiungo che esiste un rischio nel modificare il comportamento dell’interfaccia verso un utente col il progredire della sua esperienza, ed è quello di generare dubbi e confusione perché eravamo convinti “che quel pulsante fosse lì” e che “quella funzionalità si attivasse in quel modo”. Anche queste variazioni vanno studiate con molta cautela.