Pensiero laterale
Condividi
L’altro giorno stavo parlando di social tech, wiki e ambienti collaborativi con un’amica e questo pensiero mi ha colpito la tempia, così, all’improvviso:
L’approccio alla tecnologia secondo il quale prima concepisci gli strumenti e poi eroghi formazione ed addestramento agli utenti, è sorpassato. Siccome si tratta di contesti, prima viene il disegno della community e poi quello degli ambienti.
Davvero una banalità sconcertante. Ma me la segno lo stesso perché mi sembra anche un principio assurdamente forte, nella prospettiva di una Metodologia per il Social Web.
Amico mio questa regola non è nuova, ma è la buona regola per scrivere qualsiasi software (e qualsiasi tool in generale): prima il problema/esigenza e poi il codice!
Molti programmatori spesso se la dimenticano…
dadda
PS il tuo controllo antispam ha un comportamento assurdo dal punto di vista della usabilità: se dimentichi di mettere la somma cancella tutto e devi ricominciare da capo.
Concordo con il buon Roberto (che saluto).
Suggerisco una variazione sul tema per la metodologia per il Social Web ovvero: prima sperimenti con una piccola community, poi sviluppi e allarghi
Temo che non funzioni così, italoc.
Esistono dinamiche, comportamenti e fenomeni che emergono solo alle grandi scale. Questo è uno dei grandi temi delle scienze del web per esempio, quello di trovare leggi e metodologie in grado di fornire informazioni e previsioni sul comportamento delle applicazioni nel passaggio dal micro al macro.
ciao a tutti, scusate il ritardo (e saluti e auguri, poffare :)
bob, italo: sì, certo, ma intendevo una prospettiva più ampia. nel momento in cui disegni scenari collaborativi, le stesse esigenze non possono essere definite che… dalla community. un po’ come il concetto di “perpetual beta”, ma in questo caso lo contestualizzavo in ambiente, diciamo così, corporate – per la precisione, si stava parlando di pubblica amministrazione locale
pensiamo proprio agli uffici PAL: ok, sono dipendenti pubblici e le procedure – in linea di massima – sono centralizzate, no way. ma non tutte sono statali, e non tutte sono portabili così, ex abrupto, da una PAL all’altra. ci possono comunque essere logiche, abitudini etc, specifiche di un determinato “contesto”
altro esempio preso da uno scenario reale: un mini-social network per un CRAL aziendale (esempio tratto da un corso che ho tenuto). magari non serve il commento pubblico di documenti ma puoi avere la creazione di gruppi/eventi facebook-style. ma la funzione è quasi la stessa, con un diverso “wrap”
il ragionamento può essere esteso ancora: quali analisi di marketing (interno) si possono fare sulla community potenziale dei dipendenti che useranno una certa funzione? per esempio: si sentiranno esautorati o “empowered”? quale può essere il loro “rewarding”?
credo siano anche un po’ questi i temi del “design motivazionale” di cui parlano Gianandrea e Davide nel post che ho linkato, e che mi è capitato più volte di trattare pensando alla “content strategy” (o, in altro ambito, al media design) da affrontare nel momento in cui si disegna, appunto, un contesto. che secondo me viene prima delle funzioni / esigenze
il che mi porta al contributo di federico: sì, è vero – anzi: non lo so, e mi fido di te al 100%, per cui per me buona la prima :D ma nello stesso tempo l’impronta che dai a un certo ambiente determina le evoluzioni future, e quindi è molto sensata la sperimentazione di cui diceva italo. sperimenti, sviluppi, deploy, e in questo modo indirizzi. finché a un certo punto – sperabilmente – il motore entra in coppia e ti sfugge di mano. ma allora happy problem :D
Federico: concordo con il tuo commento se l’assunto è che l’applicazione vada poi messa in opera su larga scala ma, nel caso assai più frequente di applicazioni aziendali che lavorano in contesti limitati a centinaia o al massimo migliaia di persone l’assunto non vale. Sempre in contesto aziendale: le risorse/budget le ottieni molto più facilmente con una approccio “tried and tested” che buttandola sulle “scienze del web”.
@italoc
In quel caso è un progetto che nasce piccolo e rimane tale. Considera che un numero che sento spesso (anche se starei cercando la fonte affidabile) è che “sotto le 1000 persone” non si innescano le dinamiche proprie di un social network, ma sono solo dinamiche sociali e interrelazionali. Differenza sostanziale.
Se il sito nasce piccolo ed è targettizzato per rimanerlo, un test su poche persone ha una certa efficacia. Altrimenti è molto pericoloso estendere i risultati su un campione alle dinamiche molto differenti di portata sociale.
Il discorso costi poi, da un mio punto di vista, è delicato. Come dici tu è “più facile”, ma è anche quello che si schianta sempre più facilmente. I costi e i rischi di fare fallire il progetto sono a mio avviso sempre superiori all’avere almeno un minimo di consulenza e/o supporto da una o più esperti nel campo. Si tratta “solo” di fare emergere questo “piccolo” vantaggio. :)
Lascia un commento
Benvenuti
Starting up
Categorie
Discussioni e Commenti
Interviste e Incontri
Si parla di
E di
Altri Luoghi
Blogrock
Interviste e Incontri
Nuovi Amici
Patron Saints
Licenza
Archive
Ultimi Articoli Pubblicati
Most Commented
Most Viewed