Archivio tag: Edgeryders

Etnografia accresciuta: elaborare dati qualitativi da conversazioni massive

Sto lavorando su un progetto chiamato Edgeryders, un esercizio di collaborazione su larga scala per ridisegnare le politiche pubbliche sui giovani. L’idea è di fare in modo che i partecipanti condividano le loro esperienze su temi rilevanti: per esempio, come guadagnarsi da vivere in un mercato del lavoro precario, o come influenzare le decisioni politiche. Man mano che il progetto issa le vele, fa quello che fanno i progetti di crowdsourcing: aggrega un torrente di dati esperienziali. Nel mio libro e altrove ho sostenuto che le conversazioni rispettose convergono: si raggiunge un consenso e si passa oltre. Il problema è come trasmettere questa convergenza in modo verificable a osservatori esterni – nel caso di Edgeryders, ai governi europei e alla Commissione. Pretendere che essi si leggano i dati grezzi, anche in piccola parte, non è realistico. Cosa possiamo fare?

Io punto sull’etnografia. I metodi etnografici sono paticolarmente adatti a questo tipo di indagine, perché sono progettati per incorporare il punto di vista delle persone che studiano. I aggiungerei che sono anche adatti all’etica della rete: non siamo le cavie, siamo il laboratorio – così come non siamo i consumatori ma i protagonisti dei nostri luoghi di ritrovo online. L’etnografia moderna usa software come Atlas.ti la sua controparte open source Weft QDA per annotare le trascrizioni delle interviste.

I vantaggi di raccogliere i dati via social network online come Edgeryders sono due.

I dati sono già in forma scritta. Un costo molto significativo dell’analisi etnografica, la trascrizione delle interviste, viene quindi evitato (nel 2006 costava 100 euro per ogni ora di registrazione).
Decisivo: i dati sono connessi in una conversazione. I participanti commentano, contraddicono, lodano gli uni gli altri. Ciò che appare come “interviste” diverse (guardate questo esempio grandioso) sono in realtà collegate tra loro da una ragnatela di legami sociali, che sono codificati in un database e si prestano all’analisi quantitativa.

Per sfruttare queste caratteristiche, stiamo provando a sviluppare una metodologia che chiamo etnografia accresciuta. Dovrebbe funzionare più o meno così:

per prima cosa, organizza il materiale per partecipante. In Edgeryders, questo significa raccogliere tutti i mission reports (una specie di blog post), i commenti e le informazioni del profilo utente associati a ciascun utente. Questo produce una specie di super-intervista per ciascun partecipante attivo. Annota il materiale, da bravo etnografo.
poi, specifica una rete per rappresentare la conversazione. In prima approssimazione, io comincerei considerando l’intero social network online come un’unica grande conversazione, di cui i partecipanti sono i nodi. Un link viene creato tra due partecipanti, Alice e Bob, a seconda di una qualche interazione scritta nel database. La più intuitiva è che Alice e Bob sono connessi tra loro se almeno uno di loro ha commentato un mission report dell’altro, o se entrambi hanno commentato un mission report di una terza persona. Edgeryders è progettato con una ridondanza nel tipo di relazioni che i partecipanti possono intrattenere, per dare modo alla comunità di evolvere (per exaptation) diversi significati per diversi tipi di relazioni.
computa le metriche della rete e cerca di interpretarle, cercando informazioni di struttura utili. Una delle prima cose che proverei è calcolare le misure di centralità per ciascun partecipante. Questo potrebbe aiutare a risolvere un classico problema dell’etnografia: il ricercatore arriva in un’isola remota per studiare una comunità che non conosce. Intervista una persona, e raccoglie molta informazione. Come interpretarla? Molto dipende da se questa persona è un membro rispettato della comunità o lo scemo del villaggio – e il ricercatore può non avere un modo semplice di capirlo, perché non conosce (ancora) la cultura che sta studiando. Ma in una conversazione rispettosa e orientata ai fatti, lo scemo del villaggio difficilmente è centrale.
Certo, questo è solo un abbozzo. Non ho dubbi che si possano fare molti trucchi intelligenti con l'”etnografia su database”. Il problema è trovare ricercatori che possano avvantaggiarsi di questo tipo di analisi: etnografi competenti che possano assorbire anche i risultati dell’analisi di rete. Lettori: ne conoscete? C’è qualcuno interessato a continuare questa conversazione, e magari dare una mano a me e alla mia squadra?

Lo zen e l’arte della committenza dei siti web nella pubblica amministrazione: perché i burocrati dovrebbero sporcarsi le mani con la tecnologia

16 Repliche

Negli ultimi anni ho lavorato per diverse amministrazioni pubbliche. Gran parte del mio lavoro consiste nel concepire e dirigere progetti che si svolgono prevalentemente attraverso canali Internet. Mi sembra venuto il momento di fare qualche riflessione sulle cose che ho imparato. Come sempre, le lezioni più importanti mi vengono dagli errori commessi – e quando si è trattato di fare errori non mi sono mai tirato indietro.

Usare software-as-service non è una buona idea, anche se ci sono eccezioni. Il mio gruppo e io abbiamo commesso questo errore con Kublai, decidendo di aprire la nostra piattaforma su Ning. Questo ci ha permesso di essere online in mezz’ora, e non è un vantaggio da poco; ma, in compenso, ha sequestrato il nostro database – costruito a spese e per iniziativa di un Ministero italiano – e lo ha messo in mano a un’azienda privata americana, per sempre. Un anno dopo Ning ha cambiato CEO e modello di business: ha sostituito la licenza aperta della sua piattaforma con una full copyright, sganciato le API e ritirato i tools di migrazione. Per potere fare un’analisi di rete Ruggero Rossi ha dovuto scrivere un web crawler – è un po’ come dovere scassinare la porta di casa propria. Ci è andata ancora bene: il servizio era gratuito (a quel tempo non esisteva il servizio a pagamento su Ning). Se l’azienda avesse chiuso i battenti e formattato l’hard disk con il database di Kublai non avremmo potuto dire niente. Non rispondevano nemmeno alle mail. Non intendo mai più prendere in considerazione soluzioni che non contemplino un database su un server a cui la mia amministrazione ha accesso root.
Usare software proprietario non è una buona idea, di nuovo con alcune eccezioni. È costoso ed equivale a una delega perpetua al proprio fornitore, o quasi. Se una grande software house ti scrive un software su misura di cui poi ti vende la licenza nessuno, tranne quella stessa software house, potrà mai farti la minima modifica al codice. Rischi di trovarti in una situazione di totale impotenza, in cui cambiare il colore dello sfondo o il font ti costa molto in termini di denaro (le famose “billable hours” americane, in cui tu chiami e quelli attaccano il tassametro) e attrito amministrativo. Inoltre, è politicamente discutibile: il software proprietario non è riutilizzabile da altre amministrazioni se non pagando per altre licenze, e questo non è bene, soprattutto in tempi di tagli e di (sacrosanta) diffidenza dei cittadini verso la saggezza delle amministrazioni nello spendere.
Questo lascia solo il software libero o open source. Dal 2007 uso WordPress in progetti pubblici; per la piattaforma di Edgeryders, più o meno terminata in questi giorni, il mio gruppo di lavoro si è avventurato in Drupal. Lavorare sul software libero può essere faticoso e frustrante. Funzionalità che sulla carta dovrebbero essere disponibili semplicemente installando un modulo o un plug-in risultano non esserlo; i tempi si allungano; la gran parte del lavoro viene assorbita dal debugging. Nel frattempo, il resto delle attività rischia di inchiodarsi. Credo che l’esperienza possa mitigare il problema, ma mai veramente risolverlo. Il software libero è per definizione organico, “sporco”, vive di hacks e non solo di soluzioni eleganti e razionali.

Nonostante i problemi, la mia esperienza di committente di Drupal si annuncia positiva, come lo è stata prima quella con WordPress. Il motivo è questo: queste piattaforme consentono, e anzi richiedono, l’emersione di una figura intermedia di “admin avanzato” tra quella dello sviluppatore e quella dell’utente. Ciò accade perché le interfacce di amministrazione di WordPress e Drupal sono intuitive e potentissime; soprattutto Drupal ti consente un controllo molto preciso sul sito. Puoi fare queries dal database, formattare il risultato e visualizzarlo su una pagina, un blocco o una mail; puoi impostare regole del tipo SE [condizione] ALLORA [azione]. Queste attività non sono programmazione, ma sono al confine. Inoltre – e qui faccio riferimento alla mia esperienza con WordPress – quando l’interfaccia di admin non ti basta più, in rete trovi facilmente tutorial e informazioni per mettere le mani in parti del codice non core: io dal punto di vista tecnico sono uno sprovveduto, ma fino a mettere le mani nel CSS del blog (e, per cose moolto semplici, tipo incollare del Javascript, nei files PHP) ci arrivo. Ci è voluto un piccolo investimento, testimoniato dalla presenza nella mia biblioteca di libri della serie “for Dummies”. Questo ti dà una libertà inestimabile: quella di sviluppare in modo anche grezzo, lanciare e poi continuare a fare piccoli cambiamenti al tuo sito man mano che il progetto evolve. Fidati: ne sentirai il bisogno, fin dal primo giorno.

Il trucco sta in questo: il ruolo di admin avanzato un po’ smanettone è perfetto per un amministratore pubblico che deve commissionare software. Arrivare a conoscere bene l’architettura di queste piattaforme e a personalizzarle in modo avanzato non significa essere sviluppatori, ma significa che puoi dialogare in modo costruttivo con i tuoi sviluppatori, avere un approccio realistico alle cose che si possono e che non si possono fare, quanto tempo ci vuole, quanto costano. Inoltre, l’admin avanzato può provare a concettualizzare i propri obiettivi in termini del software, e quindi esprimere una domanda molto sofisticata nei confronti degli sviluppatori. Per esempio, su Edgeryders è necessario ricoinvolgere continuamente gli utenti nella conversazione; questo si fa attraverso le notifiche email e il feed di attività recenti. In Drupal, queste funzioni vengono svolte da certi moduli non-core. Se l’amministratore pubblico sa questo, può chiedere non “un sito web che dia l’idea di un luogo vivo”, ma “activity stream deve loggare tipi di attività a cui normalmente non è agganciato”, che è tutt’altra cosa.

Quando ho iniziato a andare in moto, mi sono letto Lo zen e l’arte della manutenzione della motocicletta. La lezione di quel testo è questa: l’attività di guidare la moto non è veramente separabile da quella di farne la manutenzione. I motociclisti “romantici”, che non intendono sporcarsi le mani, non lo accettano, e delegano anche la più semplice delle operazioni di manutenzione a meccanici professionisti. Ma pagano il pegno dell’impotenza di quando le loro moto si fermano, e loro non sanno perché, né come fare a ripartire. Questa impotenza può essere disastrosa nella pubblica amministrazione: nei progetti che dirigo io tipicamente il costo della tecnologia incide per meno del 10% del budget, eppure se la tecnologia non funziona blocca l’intero progetto.

Conclusione. Fare committenza è impossibile se non capisci quello che stai comprando. La comunità del software libero, nella mia esperienza, è disposta a condividere la propria conoscenza, le aziende che fanno software proprietario molto meno. Se ti trovi, come me, a commissionare un semplice progetto tecnologico per il settore pubblico ti consiglio di rivolgersi a questa comunità, armarti di pazienza, e investire un po’ di tempo per sporcarti le mani con la tecnologia che poi gli sviluppatori useranno. Installa e configura siti di prova, aggiungi funzionalità, prova a cambiarne l’estetica. Passa un po’ di tempo con gli hackers. Mostrati desideroso di imparare e fai molte domande. Soprattutto, non cedere alla tentazione del “non è il mio lavoro, fallo funzionare e mandami la fattura”. Non è così che funziona. Ti richiederà molto tempo, ma sempre poco in confronto a quello che poi risparmierai una volta in produzione. Il sistema non è perfetto, ma è di gran lunga meglio delle alternative. In realtà, credo che sarebbe molto utile organizzare un corso per pubblici amministratori volto a formare committenti migliori di software libero. Qualcuno là fuori è interessato? Io parteciperei subito.

Thanks Freddy Mascheretti, Ivan Vaghi, Paolo Mainardi and Claudio Beatrice for their patience and suggestions

Crowdsorcery: come sto imparando a costruire comunità online

3 Repliche

Sto lavorando alla costruzione di una nuova comunità online, che si chiamerà Edgeryrders. È un’attività ancora relativamente nuova, affidata a un sapere ancora non del tutto codificato. Non c’è un manuale di istruzioni che, eseguite, ti garantiscono i risultati: alcune cose funzionano ma non sempre, altre funzionano più o meno sempre ma non capiamo perché.

Non è la prima volta che faccio cose del genere, e sto scoprendo che anche in un campo così complesso e meravigliosamente imprevedibile si può imparare dall’esperienza, e come. Alcune delle iniziative di Edgeryders sono riadattamenti dell’esperienza Kublai: il crowdsourcing del logo, e il reclutamento del team a partire dalla neonata comunità, ad esempio. Per altre decisioni mi sono ispirato a progetti non miei, come Evoke o CriticalCity Upload; e molto mi hanno insegnato gli errori, sia miei che altrui.

È un’esperienza strana, esaltante e umiliante al tempo stesso. Sei il crowdsorcerer, l’esperto, colui che può evocare ordine e senso dal magma della rete. Tu ci provi: pronunci le formule, agiti la tua bacchetta magica e… qualcosa emerge. Oppure no. A volte tutto funziona benissimo, ed è difficile resistere alla tentazione di attribuirsene il merito; altre non funziona niente, e per quanto ci provi non riesci a trovare l’errore. E l’errore – come il merito, del resto – potrebbe non esserci: le dinamiche sociali non sono deterministiche, e i nostri migliori sforzi non sono sempre sufficienti a garantire il risultato.

Per come la vedo io, la competenza che sto cercando di sviluppare – chiamiamola crowdsorcery – richiede:

pensare in probabilità (con varianza alta) anziché in modo deterministico. Un’azione efficace non è quella che, a colpo sicuro, mobilita dieci contributi di buon livello, ma quella che raggiunge mille sconosciuti, di cui novecento ti ignorano, novanta contribuiscono cose di bassissimo livello, nove ti danno cose di buon livello e uno ti scrive il contributo geniale, che ti rivolta il progetto come un guanto e influenza tutti gli altri novantanove (i novecento sono persi comunque). Il trucco è che nessuno sa chi sia quell’uno, neppure lui o lei, fino a che non cominci a sparare nel mucchio.
monitorare e reagire anziché pianificare e controllare (adaptive stance). Costa meno e funziona meglio: se una comunità ha un tropismo naturale, ha più senso incoraggiarlo e cercare di capire come valorizzarlo che non reprimerlo. Il monitoraggio online è tendenzialmente gratis, anche quello “profondo” alla Dragon Trainer, quindi meglio non risparmiare sulle web analytics.
costruirsi un arsenale teorico ridondante anziché appoggiarsi sulla linea del pragmatismo (“faccio così perché funziona”). La teoria pone domande interessanti, e trovo che cercare di leggere il proprio lavoro alla luce della teoria aiuti il crowdsorcerer a costruirsi attrezzi migliori. Io sto usando molto l’approccio complexity e la matematica delle reti. Per ora.