Alberto Mucignat

Ne ho scritto già due volte. Oggi segnalo un bel contributo di Sett Gottlieb, che è forse indirizzato a clienti molto enterprise.

Ultimamente avrete capito che mi piace parlare più di content management framework, che un amico ha ribattezzato publishing framework. Però il mercato dei cms non è per niente morto.

Comunque, trovo molto interessanti i punti 6, 7 e 8 di Seth.

Per prima cosa, quando avete fatto una lista di fornitori, ingaggiate una relazione con le aziende, in modo da capire non solo quali feature differenziano i prodotti dagli altri, ma anche come funziona il loro approccio. Non accontentatevi di documenti descrittivi, insomma, parlate con le aziende e cercate di capire come lavorano, come sviluppano, ecc. Soprattutto, cercate di capire se la metodologia va bene per voi.

Inoltre, fatevi fare dei prototipi e testateli, perchè non è detto che una soluzione ultra-professionale si adatti a quello che serve a voi. Questa cosa è molto intelligente, specie se pensiamo che molti prodotti vengono comparati solo in base a funzionalità e prezzo, ma poi vengono presi un po' a scatola chiusa.

Infine, provate a progettare un'implementazione. Serve per molte ottime ragioni, tra cui aggiungo il fatto di capire qual'è la portata dei cambiamenti, cosa comportano, come affrontarli, ecc.

Lettura utile per tutti, anche se credo che questi consigli vadano bene per progetti la cui scelta di un cms sia strategica per l'impegno economico e gestionale che richiede. Penso probabilmente a grossi progetti come mega-portali istituzionali, grosse intranet o portali di turismo con budget milionario...

Mi ero quasi perso questa perla di Keith Robertson, che vale la pena leggere anche perchè è applicabile a qualunque progetto.

Tra le altre, trovo infinitamente giusta la frase:

The “problems” with almost any process start and end with people.

Ogni volta che mi sono trovato davanti ad un problema, spesso si trattava di un problema relativo alle persone. Una delle seguenti:
- alcuni non si parlavano
- altri si parlavano, ma non si capivano
- molte volte non avevano chiari in mente gli obiettivi
- non erano abbastanza invogliati a prendere iniziative
- non si sentivano responsabilizzati
- ecc

Morale: quando ti trovi di fronte a un problema, non chiederti cosa hai sbagliato. Chiediti chi non sta facendo la cosa giusta e perchè.

Certo, potresti anche scoprire che il problema sei tu. Cosa fare in questi casi? Ne avevo già parlato "anni fa" in un post molto zen. Credo si debba cercare di "spersonalizzarsi" e fare un passo indietro. Ci vuole umiltà, insomma. Eggià.

Grazie al link del post precedente, scopro anche questo Collaborative game manifesto for software development:

Lo sviluppo software è una serie di giochi cooperativi di invenzione e comunicazione, con risorse limitate e finalizzati ad un obiettivo. L'obiettivo primario di ogni gioco è la produzione e la consegna di un sistema software; ciò che rimane alla fine del gioco è un insieme di note, utilizzabili per assistere i giocatori del gioco successivo. Le persone utilizzano note e appunti per ricordare, trarre indicazioni e comunicare tra loro, allo scopo di passare alla mossa successiva del gioco. Il gioco successivo è la variazione del sistema, oppure la creazione di un sistema contiguo. Ogni gioco ha quindi come obiettivo secondario quello di conseguire una posizione vantaggiosa per il gioco successivo. Poiché ogni gioco si svolge a risorse limitate, l'obiettivo primario e quello secondario competono tra loro per le risorse disponibili.

Utile, in generale, anche per altri tipi di progetti. Deliverables è la parola chiave del gioco. Come strumenti, vedo bene il wiki. Prima o poi dovrei provare a impostarlo in questo modo.

Questa cosa del gioco, poi, viene fuori spesso ultimamente. Ne parlano continuamente gli anglofoni quando si tratta di fare focus group o altre ammucchiate lavorative.

Se ci penso, durante un recente card sorting estenuante mi sono ritrovato a dire ai partecipanti che dovevano pensare che era un gioco, cercare di pensarlo come uno svago dal loro solito tran-tran quotidiano. E ha funzionato, nonstante lo stress.

Lavorare giocando, lavorare divertendosi. Proviamoci tutti un pochino, dai.

Sembra la storia della mia vita. Ma Software projects as rock climbing non l'avevo mai pensato, a dire il vero. Per me, che l'arrampicata è una metafora che si può applicare a tutte le cose della vita. Solo un piccolo appunto:

Rock climbers are fond of saying that climbing, done properly, is less dangerous than driving a car.

Io dico invece che si rischia di più andare con lo scooter in tangenziale

Grazie a Ludo per il link.

Ieri sono arrivato al classico problema: come posso strutturare la navigazione conoscendo poco o niente i contenuti?

La risposta, manco a dirlo, viene dal solito polarbear: contenuti e architettura evolvono assieme, man mano che la fase di ricerca e analisi procedono a iterazioni.

Come dire che -in generale- quando vi trovate ad affrontare un problema di questo tipo, la risposta è: ricerca, analisi, iterazione. Piano piano ti trovi l'uovo e la gallina pronti sul piatto.

Certo, non è facile la visualizzazione di un percorso così poco lineare, ma questo è il punto: anche le "metodologie lineari" hanno delle fasi di iterazione (le cosiddette sovrapposizioni tra due diverse fasi sequenziali), altrimenti non funzionano.

Sto cercando un analista software per un programma windows, che faccia un'analisi di utilizzo con gli utenti, rediga specifiche funzionali, ecc ecc. Si lavora in Lombardia, a progetto, retribuito degnamente.

Se sei fortemente motivato perchè fare l'analista è la tua passione, contattatami via mail/skype oppure lascia un commento dopo il beep, sarai ricontattato. Se invece non ti interessa, spargi comunque la voce, grazie.

Tempo fa avevo dato le mie regolette base per la buona riuscita di una riunione.

Oggi Gigi Tagliapietra, di ritorno da un meeting in UK, riporta le sue impressioni, che mi confermano quanto siamo distanti dal modello anglosassone, aggiungendo anche molte indicazioni preziose.

Torno a parlar de schei, tema caro a noi del nordest, anche se trapiantati ovunque.

I ragazzi di Blue Flavor ci spiegano per benino come stimano i costi di un progetto (leggi bene anche i commenti perchè sono molto interessanti).

L'iniziativa chiarisce ai clienti come si lavora nel mondo 2.0, in quello vero intendo. Qui da noi, anche se spieghi in dettaglio ore e costi, ti chiedono lo sconto. Il principio invece è un altro: ti faccio vedere quanto mi costa, così non discutiamo di sconti, ma di cose da fare e di obiettivi. E questo credo sia un buon punto di partenza per una trattativa: si parla di cose da fare ad un costo ragionevole.

Nel paese dei sogni, forse. Nel paese delle banane senza alberi di banane, il problema è ancora a monte: capire che non si parla di fare solo del lavoro materiale, ma che ci sono persone e aziende che creano valore e per questo devono essere pagate.

Ad ogni modo, negli ultimi tempi ho lavorato stimando i task e le ore di lavoro. Trovo che sia un bel sistema, tranne per il fatto che quando il progetto si evolve è difficile modificare i costi. O meglio, qui in mezzo alle banane, i clienti si aspettano di modificare continuamente il progetto senza che cambi il costo. Non c'è soluzione, ci vuole la capacità di un buon manager e un contratto flessibile.

A tal proposito mi piacerebbe sentire anche la l'opinione di te che non hai un blog e mi leggi di nascosto. Dai amico lurker, lascia un commentino.

Segnalo ora un paio di post interessanti sui meeting, per aiutarvi a superare il terrore di questi appuntamenti insidiosi.

• 9 tips for running more productive meetings: più o meno quello che scrivevo qualche tempo fa


• Avoiding Vampire Meetings: per evitare che le riunioni ti succhino il sangue

Un gruppo di studenti indiani sta sviluppando un Learning CMS basato su eZ publish:

The eZ publish LCMS is a Learning Content Management System (LCMS) combining learner administration capabilities of a Learning Management System (LMS) with the content creation and storage capabilities of a Content Management System (CMS).

In pratica si tratta di un progetto per la realizzazione di un sistema di interazione studenti-professori.

A quel che vedo il progetto è ancora embrionale, ma è aperto ai contributi di studenti universitari e di esperti di e-learning e cms. Credo sia anche una buona idea per una tesi di laurea.

Per ulteriori info consiglio il forum di eZ LCMS.