Boss-less business lesson by Valve

[Zaider]

http://www.ilsole24ore.com/art/impre...nl_14+economia

Semplicemente dei grandi

[Necker]

semplicemente secondo me implodono dopo 3 mesi oppure stan contando una marea di cazzate.

Per quel che ho potuto vedere da due anni e rotti senza una struttura gerarchica si lavora semplicemente di merda e si fatica il triplo.

[Zaider]

Mah, non lo so.

io ho seguito 2 corsi di strategia, di cui uno focalizzato nella strategia delle PMI (categoria teorica in cui potremmo considerare valve) e devo dire di aver letto diversi paper sul micro management senza imprenditori di punta o cose del genere, c'è stato anche qualche caso ita, che poi si è chiuso con exit molto fortunate (un'azienda acquistata dalla campari negli anni '90. ma davvero non ricordo il nome)

[Hador]

è roba vecchia mica lo stanno provando ora, solo che (come sempre) le cose arrivano sui quotidiani italiani con mesi di ritardo (anche se è da elogiare che una notizia simile sia arrivata).
in ambiente software scuole di pensiero piuttosto di moda (e in alcuni ambiti particolarmente efficaci) tendono a smontare, chi più chi meno, le gerarchie all'interno dei team (processi agili, xp programming etc). Uno dei principali problemi è far combaciare questo azzeramento di gerarchie all'interno di un team di sviluppo con un azzeramento dello stesso all'interno della struttura aziendale - nel senso, tu puoi finire a programmare in un team "di pari" col capo dell'azienda, ma in quanto tale probabilmente non lo contraddirai perchè è appunto il capo. Estendere quindi tale modello a tutta la gerarchia aziendale è molto interessante. Anche il sistema delle retribuzioni, è dimostrato che la produttività dipende anche dai meccanismi di scatto di carriera e stipendi (alla fine è come il levelling dei giochi di ruolo ) e questo è sempre stato un tallone di achille per questi processi agili, introdurre un sistema di peer review per gli scatti di stipendi è anch'esso molto interessante.

[Glorifindel]

bhe adesso abbiamo capito perchè gli ci vogliono millenni per far uscire HL3

[marchese]

se il sublime assoluto della perfezione che è stato giocare Portal 2 è il risultato di questa strategia, scusami eh ma preferisco aspettare che giocare ogni anno la copia dello stesso gioco dell'anno precedente solo con grafica un po rivista e un +1 sul titolo della scatola

io sono un disfattista cronico che si aspetta sempre il peggio e raramente si esalta....ma quando si tratta di Valve, mi metto in ginocchio e bacio per terra

[Alkabar]

semplicemente secondo me implodono dopo 3 mesi oppure stan contando una marea di cazzate.

Per quel che ho potuto vedere da due anni e rotti senza una struttura gerarchica si lavora semplicemente di merda e si fatica il triplo.

Concordo. Tutti parlano su tutti, e tutti impediscono il lavoro di tutti per stupide questioni personali.

[Alkabar]

è roba vecchia mica lo stanno provando ora, solo che (come sempre) le cose arrivano sui quotidiani italiani con mesi di ritardo (anche se è da elogiare che una notizia simile sia arrivata).
in ambiente software scuole di pensiero piuttosto di moda (e in alcuni ambiti particolarmente efficaci) tendono a smontare, chi più chi meno, le gerarchie all'interno dei team (processi agili, xp programming etc). Uno dei principali problemi è far combaciare questo azzeramento di gerarchie all'interno di un team di sviluppo con un azzeramento dello stesso all'interno della struttura aziendale - nel senso, tu puoi finire a programmare in un team "di pari" col capo dell'azienda, ma in quanto tale probabilmente non lo contraddirai perchè è appunto il capo. Estendere quindi tale modello a tutta la gerarchia aziendale è molto interessante. Anche il sistema delle retribuzioni, è dimostrato che la produttività dipende anche dai meccanismi di scatto di carriera e stipendi (alla fine è come il levelling dei giochi di ruolo ) e questo è sempre stato un tallone di achille per questi processi agili, introdurre un sistema di peer review per gli scatti di stipendi è anch'esso molto interessante.

Il processo agile. Sono tanto fissati qua col processo agile che hanno provato a metterlo in pratica a tutti i costi. Io ovviamente mi adeguo, perchè a me frega un cazzo.

E loro sono a 4 mesi di ritardo. Io non sono in ritardo perchè su quel progetto lavoro da esterno.

L'unica cosa che applico io è il pairwise programming, quello funziona, tutto il resto, almeno in un gruppo di 4 persone, crea degli overhead mostruosi.

Oltre tutto, non consideri il problema derivante dagli interessi delle persone. I processi agili sono per gruppi di persone ideali e civili.

Sono sicuro che possa anche funzionare bene con un gruppo tra i 20 e i 40. Al di sopra/al di sotto di tale numero, il processo agile è talmente complesso che è meglio tornare al waterfall.

[Necker]

aggiungo una cosa: gli italiani hanno nel dna la spregievole volontà di tirarlo in culo con ogni furberia immaginabile a chiunque gli stia attorno pur di guadagnare quel tozzo di pane in più, pensare, in un ambiente di merda tale, che si possa ideare una struttura lavorativa priva di una corporate governance (spero d'aver azzeccato la terminologia ) mi pare oggettivamente un autogoal clamoroso per le sorti produttive del posto di lavoro.

A mio parere la presenza di un capo è un'aspetto fondamentale e ancor più importanti sono le qualità che tale figura deve assolutamente possedere. Capacità organizzative in primis, credibilità ed ovviamente capacità e conoscenze all'altezza.

[Alkabar]

aggiungo una cosa: gli italiani hanno nel dna la spregievole volontà di tirarlo in culo con ogni furberia immaginabile a chiunque gli stia attorno pur di guadagnare quel tozzo di pane in più, pensare, in un ambiente di merda tale, che si possa ideare una struttura lavorativa priva di una corporate governance (spero d'aver azzeccato la terminologia ) mi pare oggettivamente un autogoal clamoroso per le sorti produttive del posto di lavoro.

A mio parere la presenza di un capo è un'aspetto fondamentale e ancor più importanti sono le qualità che tale figura deve assolutamente possedere. Capacità organizzative in primis, credibilità ed ovviamente capacità e conoscenze all'altezza.

No scusa, dopo aver viaggiato cosi' tanto, ti posso dire che il buttarlo in culo ce l'hanno comune tutti. Dipende da se sei sfigato o no col gruppo di lavoro.

[Necker]

buono a sapersi

[Hador]

Il processo agile. Sono tanto fissati qua col processo agile che hanno provato a metterlo in pratica a tutti i costi. Io ovviamente mi adeguo, perchè a me frega un cazzo.

E loro sono a 4 mesi di ritardo. Io non sono in ritardo perchè su quel progetto lavoro da esterno.

L'unica cosa che applico io è il pairwise programming, quello funziona, tutto il resto, almeno in un gruppo di 4 persone, crea degli overhead mostruosi.

Oltre tutto, non consideri il problema derivante dagli interessi delle persone. I processi agili sono per gruppi di persone ideali e civili.

Sono sicuro che possa anche funzionare bene con un gruppo tra i 20 e i 40. Al di sopra/al di sotto di tale numero, il processo agile è talmente complesso che è meglio tornare al waterfall.

alka, se non riuscite ad applicare un processo agile in 4, non è il vostro mestiere

[Alkabar]

alka, se non riuscite ad applicare un processo agile in 4, non è il vostro mestiere

Io non applico niente, il mio codice è finito dal 16 Dicembre 2011 ahhahaha. Mi sto girando i pollici.

Sono i tedeschi di merda che si puntano su ogni dettaglio. Hanno accumulato 4 mesi di ritardo perchè si sono puntati su ogni stronzata che gli veniva in mente sulle interfacce. Sul database. Sul server di integration and testing. Cioè cazzo, io finito con 7 mesi di vantaggio il mio componente. E i tedeschi dovevano essere efficienti. Ma sto gran paio di cazzi ().

Pero' ti do ragione sul fatto che se il processo viene seguito bene, CON BUON SENSO, è un buon modo di organizzarsi. Tuttavia, c'hai giusto un tipo un attimo dogmatico davanti e ti assicuro che la pacchia è finita.

E' questione di sfiga.