martedì 2 settembre 2008

Perché si può volere un leader


Dal  Leadership Game di Ignace Hanoulle Yves Hanoulle a cui ho partecipato.


Mi annoto in sintesi  le ragioni che possono rendere desiderabile essere guidati da un Leader con un approccio di tipo direttivo (che da indicazioni su cosa fare e come) nel realizzare un progetto :

  1. Perché assicura il coordinamento
    es. procura le risorse - assegna i task alle persone nel modo più appropriato - si assicura che i task più importanti non siano trascurati e quelli minori non siano seguiti più del necessario


  2. Perché allinea gli sforzi verso la stessa direzione
    es. indica la direzione appropriata - tiene un occhio su tutti i membri del team perché la seguano - solleva ogni membro del team dallo sforzo di vedere in che direzione statto andando gli altri


  3. Perché garantisce una buona comunicazione
    es. si assicura che i membri del team dialoghino tra loro superando eventuali attriti personali


  4. E'  il collegamento tra il team e il "mondo esterno" e gestisce i problemi di "contorno"
    es. gestisce la pianificazione, delega le responsabilità, risolve problemi, tiene i contatti con altri team coinvolti nel progetto


  5. Si assume responsabilità che altri nel team non si sentono di assumere


  6. Garantisce la sicurezza/tranquillità e la accettazione di ogniuno nel team


I primi 3 punti sono di tipo pratico e il peso di ogni punto magari varia a seconda del progetto, gli ultimi 2 punti sono più di tipo psicologico e il peso di uno di questi punti può variare dalle in base alle preferenze da persona a persona.

Riguardo al punto 5 sono interessanti i risultati del esperimento di  Milligram.



In un prox post le ragioni che possono far preferire ad alcuni di realizzare il progetto senza la guida di un Leader direttivo (senza leader o con altri tipi di leadership).




Tags :   |  |  |  | 
posted @ lunedì 1 gennaio 0001 00:00 | Feedback (3)

Letteratura & Informatica ??? Si


In quella trasmissione in bianco e nero  a ora tarda un gruppo di persone con l'aspetto di intellettuali e accademici erano sedute in modo sparso e informale in una stanza parlavano di letteratura in francese (la trasmissione tv era in b/n, i sottotitoli ... no).

Un quadro esistenzialista sembrava.

Quando il professorone (il + vecchietto del gruppo) mi comincia a parlare di grammatiche, sintassi, semanti, ricorsione e mischiarla a argomenti letterari e filosofici.

Ci mancava solo una canna!!!!



L'altra sera mi sono sorpreso quando ho scoperto che Noam Chomsky quello che ha sviluppato la teoria delle grammatiche generative (basate su un approccio per studiare la sintassi e metterla in relazione alla semantica in cui un programma in un certo linguaggio viene rappresentato come insiemi, relazioni e operazioni su insiemi cioè in un linguaggio puramente matematico)  e famoso per la Gerarchia di Chomsky che classifica i tipi di grammatiche  è ...



il padre della linguistica moderna

un filosofo

un attivista politico

un prolifico autore di libri di politica, linguistica e dai uno anche di informatica

è un attore, appare anche nel film documentario The Corporation e in molti altri

i suoi studi hanno contribuito alla rivoluzione cognitiva nella psicologia

e nel tempo libero ... ha contribuito pure all'informatica moderna :)


Anche questo arzillo vecchietto è vivo e vegeto - cioè non è ancora roba da libri di storia polverosi -  ma da vecchie trasmissioni in b/n di repertorio si

sorprendente questa informatica !!!!




Tags :   |  | 
posted @ lunedì 1 gennaio 0001 00:00 | Feedback (3)

Hoare sul disegno del software

Tony Hoare è conosciuto per aver inventato l'algoritmo QuickSort e per i suoi contributi alla programmazione concorrente, su molti  libri sono citati i Monitor di Hoare.
Sono rimasto sorpreso di scoprire che questo bel pezzo di antiquariato :D - cioè questo arzillo vecchietto - è ancora vivo e vegeto ed è Senior Researcher alla  Microsoft Research in Cambridge


Ecco una citazione di Hoare sul del disegno del software


There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult


Update: altre citazioni sulla semplicità in questo post: http://blogs.ugidotnet.org/adrian/archive/2006/03/03/36066.aspx

Tags :   |  |

posted @ lunedì 1 gennaio 0001 00:00 | Feedback (2)