Zaider
26th June 2012, 18:35
http://www.ilsole24ore.com/art/impresa-e-territori/2012-06-25/fare-business-senza-capi-154013.shtml?uuid=Abk0l0xF&cmpid=nl_14+economia
Semplicemente dei grandi
Semplicemente dei grandi
View Full Version : Boss-less business lesson by Valve
Necker
26th June 2012, 20:08
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.
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
26th June 2012, 20:23
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)
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
26th June 2012, 20:26
è 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 :sneer: ) 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.
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 :sneer: ) 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
1st July 2012, 09:19
bhe adesso abbiamo capito perchè gli ci vogliono millenni per far uscire HL3 :sneer:
marchese
1st July 2012, 12:07
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
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
1st July 2012, 12:14
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.
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
1st July 2012, 12:17
è 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 :sneer: ) 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.
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 :sneer: ) 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
1st July 2012, 16:06
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 :D) 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.
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
1st July 2012, 16:41
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 :D) 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.
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
1st July 2012, 17:15
buono a sapersi :)
Hador
1st July 2012, 22:13
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 :sneer:
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 :sneer:
Alkabar
1st July 2012, 23:58
alka, se non riuscite ad applicare un processo agile in 4, non è il vostro mestiere :sneer:
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 (:sneer:).
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.
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 (:sneer:).
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.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.