« Intro.01 « Intro.02 « Intro.03 « Intro.04 « Intro.05 « Intro.06 « Intro.07 « Intro.08 « Intro.09

A differenza della progettazione tradizionale, lineare, una progettazione Open Peer-to-Peer è, a causa del numero elevato di agenti e delle loro interazioni, non-lineare, aperta e caratterizzata da più processi in svolgimento parallelo. Un processo progettuale Open Peer-to-Peer fornisce quindi le basi affinché si sviluppino più progetti paralleli, un ecosistema di agenti progettisti con una evoluzione memetica dei progetti più “adatti” alla comunità, la cui selezione porterà ai risultati migliori.

Un processo progettuale Open Peer-to-Peer è caratterizzato dalla apertura e condivisione del progetto (il codice sorgente del software) della piattaforma e della attività che permette che, una volta fornito alla comunità dai designer, verrà da essa sperimentato e modificato più volte ed in più direzioni (nel software, la compilazione nel codice binario), sino al raggiungimento di una definizione soddisfacente (la versione stabile del software) per garantire l’auto-organizzazione.
Il codice sorgente del progetto (community source code) è costituito da strumenti provenienti dal design dei servizi, con l’introduzione di una descrizione dei livelli di reputazione presenti all’interno della comunità, delle licenze che regolano la collaborazione e la fruizione dei risultati, di una mappa della rete sociale in grado di mostrare punti deboli e forti della comunità. Il codice sorgente è accessibile a tutti i partecipanti, che lo sperimentano con crescenti livello di realtà (la piattaforma viene mano a mano migliorata durante questa fase) segnalando ai designer gli eventuali errori (bug, nel software) presenti. Maggiore il numero dei partecipanti, maggiori sono le probabilità che gli errori vengano rilevati e corretti.
La comunità, durante il processo progettuale e anche alla sua fine, si auto-organizzerà modificando se necessario il progetto, per quanto è possibile; è questa capacità di auto-organizzazione e di modifica del reale che rende le comunità vive ed interessanti.

La partecipazione è aperta e paritaria, ma è regolata da due principi: auto-selezione e reputazione, che danno luogo a differenti livelli di partecipazione nelle diverse fasi progettuali, in base al possesso delle conoscenze necessarie nelle diverse fasi progettuali. Le differenti fasi del processo progettuale, quindi, richiederanno differenti livelli di partecipazione e quindi di impegno e visibilità del partecipanti. Questi differenti livelli danno luogo a varie fasi di vita tipiche (simili in alcuni punti alle fasi delle comunità di pratica): potenziale, coalizzazione, maturazione, auto-organizzazione ed espansione, declino.

analisi

L’intervento progettuale inizia con una necessaria analisi dei partecipanti, al fine di comprendere le risorse esistenti e quindi utilizzabili, le limitazioni, i punti critici. Attraverso l’analisi i designer cominciano a conoscere i partecipanti, potendo così cominciare a prefigurare quali caratteristiche l’attività della comunità avrà. L’obiettivo della fase di analisi è quello di definire degli obiettivi e della strategia su cui costruire il concept di attività per la comunità. L’analisi, svolta attraverso indagine etnografica ed analisi delle reti sociali, riguarderà la piattaforma, le caratteristiche dei singoli partecipanti ove possibile, e le attività già esistenti.

concept

Una volta terminata l’analisi dei partecipanti, delle loro attività e della loro rete sociale, viene elaborato un primo concept della attività (e sua piattaforma) della comunità. I designer elaborano quindi una prima versione (si potrebbe dire la 0.0.1) del progetto della attività-piattaforma, formalizzato nel codice sorgente della comunità.

co-progettazione / sperimentazione / realizzazione parallele

Una volta elaborato, il concept viene mostrato ai partecipanti e discusso collettivamente. Da questo momento inizia una fase di co-progettazione dell’attività/piattaforma, caratterizzata da una crescita costante di impegno, quindi energia impiegata e visibilità. In questa fase il concept di attività viene sviluppato collaborativamente fino ad ottenere un progetto funzionante, una “versione stabile” del codice sorgente (la versione 1.0).
Il codice sorgente della comunità viene testato dai partecipanti che simulano l’attività, per capire quali siano i punti deboli, gli errori (i bug del codice sorgente della comunità) e quindi le modifiche da apportare. Il codice sorgente viene sottoposto cioè ad un processo di peer review, in cui sia i designer (che osservano la simulazione) che i partecipanti segnalano gli errori presenti e le necessarie modifiche. Non appena viene identificato un bug il codice sorgente viene modificato e la sperimentazione riparte dal nuovo codice.

Affinché si possa simulare l’attività, i partecipanti devono condividere le condizioni necessarie per svolgerla, rappresentate dalla piattaforma. Regole e ruoli dovranno essere adottati e sviluppati, e gli artefatti che non sono già presenti dovranno essere realizzati o acquisiti. Ciò significa che con il procedere del processo di progettazione/sperimentazione, la piattaforma viene mano a mano realizzata, e quando il progetto raggiungerà la versione stabile, i partecipanti potranno cominciare a svolgere l’attività, rafforzando così il senso di comunità.
Una volta terminata la fase di co-progettazione/sperimentazione, il progetto sarà già realizzato, non vi sono fasi di produzione o esecuzione. Come nel software, a quel punto il codice sorgente (il progetto) avrà dato luogo al codice binario (l’attività svolta dai partecipanti).

auto-organizzazione

Raggiunta la prima “versione stabile” del codice sorgente dell’attività, la 1.0.0, la comunità sarà quindi in gran parte formata: durante la simulazione/svolgimento dell’attività si saranno formate alcune relazioni sociali, che vanno a sommarsi a quelle preesistenti. Una versione stabile del codice sorgente significa che questo può essere “compilato” (ossia, svolto) e utilizzato da chiunque senza possibilità di errori critici. In questa fase quindi la comunità è in grado di svolgere l’attività ed auto-organizzarsi senza l’apporto dei designer: se il loro ruolo era quello di facilitatori (enabler), ora la comunità è in grado di agire con successo da sola.

In linea di principio, i designer hanno esaurito il proprio ruolo; tuttavia, la comunità potrà sempre necessitare il suo apporto in futuro, dato che i designer possiedono sempre conoscenze ed expertise utili per fornire un supporto all’evoluzione dell’attività e della comunità in risposta ai cambiamenti dell’ambiente esterno.
Inoltre, se l’attività è di progettazione, le loro capacità li rendono una figura importante all’interno della comunità, di cui continueranno a fare parte anche nella fase di auto-organizzazione.

Queste riflessioni rappresentano quindi una prima proposta (1.1) di linee guida progettuali, in un più ampio processo di studio di una metodologia completa Open Peer-to-Peer.

Concludendo, quali sono le prospettive di applicazione e di studio per queste linee guida progettuali?

(continua)