Alberto Mucignat - Projects

Scegliere un CMS /3

nospam@example.com (Alberto) — Thu, 31 May 2007 15:26:10 -0700

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...

Persone al centro del processo

nospam@example.com (Alberto) — Tue, 29 May 2007 11:12:19 -0700

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à.

Sviluppare progetti giocando

nospam@example.com (Alberto) — Mon, 02 Apr 2007 17:53:37 -0700

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.

Sviluppare software arrampicando

nospam@example.com (Alberto) — Mon, 02 Apr 2007 17:22:37 -0700

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.

L'uovo e la gallina

nospam@example.com (Alberto) — Tue, 21 Nov 2006 09:46:29 -0800

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.

Cercasi analista software

nospam@example.com (Alberto) — Sun, 12 Nov 2006 16:50:51 -0800

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.

Riunioni efficenti

nospam@example.com (Alberto) — Fri, 16 Jun 2006 14:08:40 -0700

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.

Stimare il costo dei progetti

nospam@example.com (Alberto) — Mon, 08 May 2006 13:37:55 -0700

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.

Paura dei meeting?

nospam@example.com (Alberto) — Thu, 23 Feb 2006 22:28:21 -0800

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

eZ publish LCMS

nospam@example.com (Alberto) — Mon, 20 Feb 2006 14:21:19 -0800

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.

Live from Dortmund

nospam@example.com (Alberto) — Wed, 25 Jan 2006 14:37:41 -0800

Sono a Dortmund, Germania del nord. E nevica appalla. Sono partito stamattina da Roma Ciampino e devo dire che sorvolare Roma è un'esperienza (da Fiumicino si passa invece per il mare). Il Colosseo è un'opera monumentale, davvero: è più imponente dello Stadio Olimpico. Va beh, si passa al lavoro, un saluto a tutti e scusate per i pochi post, ma negli ultimi giorni non ho avuto un attimo di tregua. Stanno cambiando un po' di cose... più avanti vi spiegherò.

I temi del talk su eZ publish e IA

nospam@example.com (Alberto) — Mon, 21 Nov 2005 11:46:09 -0800

Sabato sarò a Cesena per tenere un talk su IA e eZpublish. Durante il weekend ho fatto un brainstorming con me stesso e quindi vi segnalo i temi che andrò a trattare:

- IA e CMS: cosa sono
- eZ publish: enterprise key features
- scalabilità dei contenuti
- progettazione dell'architettura delle informazioni
- blueprints e struttura del sito
- creazioni di classi di oggetti in eZ
- il sistema di templating in eZ
- wireframes e template
- relazioni tra contenuti
- categorie
- link tra contenuti e relazioni tra oggetti in eZ
- keywords/tagging
- tags in eZ publish
- flussi di produzione e eZ workflow system
- sistemi di navigazione: menù e breadcrumbs
- personalizzazione (eZ users)

A seguito del mio intervento ce ne sarà un altro su eZ publish, tenuto da Francesco e dal taglio più tecnico.

ps: spero di riuscire a vedere anche qualcuno di quelle zone (Pesaro, Ancona, chennesò )

Partnership con eZ systems

nospam@example.com (Alberto) — Mon, 14 Nov 2005 15:31:14 -0800

Momento di gaudio personale: da oggi la mia azienda è ufficialmente partner di eZ systems, l'azienda che sviluppa eZ publish. Per arrivarci ho passato del tempo a contatto con i norvegesi: ho così imparato a conoscerli e ad apprezzare la loro filosofia di community, che condivido appieno e spero di aiutare a sviluppare con il nostro lavoro.
È anche disponibile il comunicato stampa ufficiale (pdf).

Consigli per risolvere i problemi

nospam@example.com (Alberto) — Tue, 08 Nov 2005 21:21:00 -0800

Negli ultimi giorni ho risolto (almeno credo) alcuni problemi di lavoro che tiravo avanti da un po' di tempo. A posteriori ho annotato sulla preziosa moleskine le cose che mi hanno aiutato a risolverli. Quello che segue è un piccolo corso alla risoluzione dei problemi. Enjoy!

Continue reading "Consigli per risolvere i problemi"

Analisi di un progetto web

nospam@example.com (Alberto) — Mon, 17 Oct 2005 19:47:00 -0700

Oggi ho passato la giornata ad analizzare un progetto web che consiste in qualche decina di categorie connesse tra loro in varia maniera. Diciamo che non si tratta di semplice tassonomia, ma di qualcosa che la mente umana ha tentato di complicare ulteriormente.

Ho passato ore a capire quali documenti ci siano dentro le varie categorie e quale senso ci sia dietro le varie scelte di presentazione (perchè un documento qui e non lì).
A un certo punto, mi sono detto, forse ci vuole un lavoro ad hoc sull'architettura delle informazioni.
Mentre pensavo a tutto ciò, scorrendo categorie e informazioni che si ripetono in sezioni apparentemente diverse, ho ribaltato il ragionamento e mi sono detto: se ci fossero solo 3 categorie cambierebbe qualcosa?

Morale: proporrò di semplificare notevolmente queste catalogazioni e suggerirò di utilizzare tags/keywords per creare associazioni tra contenuti.

A cosa serve parlarne se poi non applichiamo?