⚡ Unpeeragogy · Friction · Observation
Cooperation — Il dominio dove regge
Questo articolo fa parte della serie “Where the pattern works” — una documentazione esplicita delle condizioni in cui i pattern di Peeragogy funzionano. Non è una concessione alla teoria. È un test necessario: se vediamo solo i fallimenti, il progetto conferma la sua tesi. Se documentiamo anche i successi, la critica diventa ricerca.
Il pattern: Cooperation — la capacità di un gruppo di lavorare insieme senza gerarchia formale, basandosi su impegno condiviso e fiducia reciproca.
La domanda: In quali condizioni questo pattern funziona davvero — non come eccezione, ma come dinamica sostenibile?
Precondizioni osservate
Dall’analisi dei casi in cui la cooperazione emerge naturalmente (e non deve essere imposta), emergono tre precondizioni ricorrenti:
1. Modularità del lavoro
Ogni persona può produrre valore indipendentemente, senza bisogno di coordinamento continuo. Il lavoro è parallelizzabile. I membri del gruppo non dipendono l’uno dall’altro per avanzare — dipendono l’uno dall’altro solo per integrare.
Esempio: Un handbook open-source dove ognuno scrive capitoli indipendenti. Ogni autore avanza da solo, il coordinamento serve solo per evitare sovrapposizioni. La cooperazione è reale perché il costo del coordinamento è basso.
2. Visione condivisa ma non consenso totalizzante
Il gruppo sa dove vuole arrivare, ma non ha bisogno di concordare su come arrivarci. L’accordo è sul perché, non sul cosa e quando. Questo riduce l’attrito: le persone possono muoversi in autonomia sapendo di non andare in direzione opposta.
Esempio: Una comunità di ricerca dove i membri fanno esperimenti in parallelo. Ognuno sceglie il proprio metodo. La cooperazione è nell’allineamento epistemico, non nella sincronizzazione operativa.
3. Asimmetria accettata
Alcuni contribuiscono più di altri, e questo non genera risentimento — perché la modularità permette a ognuno di contribuire esattamente quanto vuole, nel momento in cui vuole. L’asimmetria è trasparente e volontaria.
Esempio: Un progetto dove i ruoli sono autodeterminati e la distribuzione del carico è visibile a tutti. Chi dà di più lo fa perché può e vuole, non perché qualcun altro ha delegato in silenzio.
Dove il pattern funziona
Projects che soddisfano almeno due delle tre precondizioni:
| Precondizione | Essenziale? |
|---|---|
| Modularità del lavoro | Sì — senza, la cooperazione diventa coordinamento |
| Visione condivisa | Sì — senza, le traiettorie divergono |
| Asimmetria accettata | No — ma senza, si genera risentimento nel tempo |
In pratica: la cooperazione funziona quando il costo di non coordinarsi è basso e il costo di coordinarsi è trasparente e volontario.
Dove il pattern cede
Progetti che richiedono:
- Coordinamento stretto — il problema di ognuno è il problema di tutti. Il lavoro non è parallelizzabile. Ogni decisione richiede allineamento collettivo.
- Scadenze esterne — la cooperazione diventa compliance. Le persone non cooperano perché vogliono, ma perché devono consegnare.
- Contributi disuguali su lavoro identico — alcuni fanno di più, ma il lavoro è lo stesso per tutti. Questo genera risentimento anche in assenza di gerarchia.
Interpretazione
Il pattern Cooperation funziona quando le condizioni strutturali riducono il costo della cooperazione a un livello che i membri del gruppo sono disposti a sostenere. Non funziona quando il progetto richiede cooperazione come prerequisito invece che come risultato di un design organizzativo che la rende economica.
Perturbator: “La cooperazione non è un valore. È un output. Se il lavoro è modularizzato, se la visione è chiara, se l’asimmetria è trasparente — la cooperazione emerge da sola. Se manca una di queste, puoi predicare cooperazione quanto vuoi. Non succederà.”
La teoria ha ragione a descrivere la cooperazione come desiderabile. Ma potrebbe aver bisogno di esplicitare meglio le precondizioni strutturali senza le quali il pattern resta un ideale — vero, ma inapplicabile.
💬 Discussione: Cooperation — Il dominio dove regge
La discussione vive su GitHub, non in un widget. Niente magia, niente bug silenziosi. Apri un thread, condividi la tua esperienza, e la settimana successiva il progetto può evolvere a partire da ciò che è emerso.
Cosa succede dopo che apro una discussione?
1. La discussione appare in GitHub Discussions col tag discussione.
2. Una volta a settimana, il progetto analizza i thread attivi.
3. Se emergono nuovi Failure Vector, tension_index da rivedere, o Agenti Perturbatori da affilare, la entry viene aggiornata.
4. Un log settimanale in /log registra cosa è cambiato.