Per questo, per quel che dice Dax, io non ritengo che tentare di fare esperienza in un team di sbandati sia necessariamente male, ne una perdita di tempo.
Il Rhaxen (il progettooooone del forum di RpgShrine, antenato di Rpg2s) è stato fondamentale per me, dapprima come grafico marginale, poi come persona chiave e poi come capo del Team. Ho vissuto i vari ruoli in una scalata involontaria (il ruolo di capo me l'han praticamente appioppato XD), con la fortuna che una fetta dei collaboratori ci credevano davvero (quindi averne persi il 90% per strada era relativamente non importante).
E poi si arriva ad un limite che non si conosce (Nel mio caso, non ero in grado di sostituire il grafico che se ne era andato, ma non ero capace di abbassare le aspettative del progetto ne avevo capito che quello era il problema, facendolo arenare per troppo tempo)
In quel periodo non dubito che la mia direzione sia stata ottima, sul livello del tenere le persone ancorate al progetto, e terribile sul riuscire ad avere un'idea realistica delle problematiche del progetto. La convinzione e la parlantina non me mancavano manco allora. XD
Quell'esperienza mi ha fatto vivere con persone creative e, tra di loro, ho legato di più con alcune che con altre. E' li che conobbi Pro e che fui costretto a collaborarci in maniera stretta, imparando a conoscere le sue capacità, i suoi limiti ed il suo metodo per superarli. Io facevo il ruolo di quello che chiede nuove feature e lui che mi malediva perché gli chiedevo i salti mortali.
Il fatto che io stia creando dei progetti con ProGM è dovuto alla fiducia che ho nella sua tenacia e razionalità, molto utili ad affrontare progetti più ambiziosi di RpgMaker ed ottimi nell'apprendere come migliorarsi.
Tuttavia ci siamo conosciuti in un progettone. Non demonizzerei, dunque, i progettoni. Sono destinati a fallire ( XD ) ma sono, quelli come qualsiasi altra occasione di lavorare in team, un modo per scoprire nuove persone e mettersi tutti alla prova.
Può succedere che da un team immenso, ci si riduca a 4 individui affiatati e che alcuni di loro sopravviveranno all'esperienza del progettone, finendo col diventare un vero team.
Per quanto riguarda la divisione dei ruoli... qui le regole sono labili. Dipende. Quante persone si è nel team? Più si è, più la divisione dei ruoli è di aiuto al riuscire ad ottenere qualcosa dal team in tempi utili. Meno si è, più è tollerabile che le divisioni di ruoli non siano così nette, anche per compensare il fatto che si è troppo pochi per ricoprire tutti i ruoli.
Sempre con l'esempio di io e ProGM, che siamo appena in due (e con il nuovo progetto, in 4), io sono assolutamente specializzato in grafica e lui assolutamente specializzato in programmazione. Ma poi?
Tra la programmazione e la grafica c'è il game design, l'user interface, delle mansioni che perdono la loro specializzazione e finiscono col mescolarsi.
Lì abbiamo banalmente imparato "Cosa siamo in grado di fare? A chi dei due esce meglio questa cosa?"
Non è raro che ProGM pensi ad alcuni aspetti grafici del gioco (Ad esempio, l'idea di fare un gioco a vetrate è sua) o pensi a come fare un menù decente. Io faccio schifo nei menù, ma proprio tanto. E quindi lui è grafico, in quel frangente.
Più il Team è piccolo, meno ha senso limitare il lavoro delle persone a delle specializzazioni stringenti. Specializzarsi serve solo a diminuire la mole di lavoro alla persona E ad evitare che troppe teste arenino una scelta.
Se però la scelta è di trama o è sul decidere la morale/visione del gioco, per me ha senso parlarne con il resto del Team. Con quella parte del team che desidera essere partecipe aldilà della mansioncina.
Una gerarchia chiara, però, è utile. Se in un team di 4 persone, esiste una fetta di queste che possono "decretare quando si chiude il discorso", come fosse un direttivo, allora non ci si può arenare. Se l'idea esiste, è stata detta, e tutto ciò che si fa è solo avere ripensamenti casuali, quelle persone o persona a cui si è data più autorità, è di aiuto a bloccare l'idea così com'è ed andare avanti.
Una cosa che ha senso usare solo in casi di emergenza, quando serve. E... come si fa a capire quando serve e quando invece sarebbe un'inutile prepotenza?
Ecco perché è bene conoscere le persone con cui si lavora. Devono essere lucide ed avere in mente il bene del progetto, non il bene delle proprie turbe. Inoltre aiuta avere una linea guida, tipo una parola chiave che il progetto deve rispettare. Aiuta a capire quando la strada sta deragliando e quindi quando usare il pugno duro.
Sempre nel rispetto di chi collabora con te, però, perché avere autorità non significa comandare, significa aiutare il team a, mentalmente, lasciarsi alle spalle una questione che non ha una sola risposta ma alla quale si deve decidere arbitrariamente una risposta unica.
Probabilmente non amplierei mai il mio team con persone che non hanno avuto un'esperienza amatoriale in un team. Non avrebbero il desiderio di seguire delle regole, perché dovrebbero ancora vivere la frustrazione di non averle. XD
1
5
