Domanda:
Come può un'azienda implementare un programma "20% time" come quello di Google?
Reinstate Monica - Goodbye SE
2012-04-13 02:03:46 UTC
view on stackexchange narkive permalink

Ho letto che la regola del 20% di Google riguarda l'incoraggiamento al divertimento e all'innovazione.

Come può la mia azienda implementare e gestire un programma come questo?

Una buona risposta a questa domanda dovrebbe coprire anche queste domande secondarie:

  • Quali sono i limiti per quel 20% del tempo?
  • Cosa succede se devo lavorare 40 ore per completare il mio progetto in tempo?
    Mi sarei aspettato di dedicare altre 10 ore di lavoro "divertente"?
    Posso solo trascorrere 16 ore normali la prossima settimana? Se perdo una settimana perdo solo il 20% delle ore?
Molto correlato: [Today is Goof off at work day] (http://www.codinghorror.com/blog/2012/08/today-is-goof-off-at-work-day.html), un articolo del blog su Tempo del 20% da Jeff Atwood.
In realtà Google si sta allontanando dal 20%. Se leggi le loro presentazioni ufficiali non ne parlano più, e non è incoraggiato come lo era.
Forse è per questo che non appaiono innovativi come una volta?
Sette risposte:
#1
+38
Hrafn
2012-04-21 03:28:37 UTC
view on stackexchange narkive permalink

Posso fornire alcune informazioni su questo in base a come la mia azienda lo ha implementato e come abbiamo lottato.

Nella mia azienda lo abbiamo implementato come strumento di reclutamento e come un modo per mantenere le competenze degli ingegneri acuto. Ci sono anche alcuni motivi potenzialmente interessanti per evitare che l'utilizzo diventi troppo alto per facilitare meglio il cambio di contesto. Questa risposta ha anche diverse buone linee guida circa il 20% del tempo e alcuni riferimenti aggiuntivi che supportano ulteriormente il suo punto.

Non stiamo basando quello che facciamo sui punti menzionati, ma penso che valga la pena riflettere se stai cercando di implementare il tuo 20% di tempo in un'azienda.

Abbiamo alcune linee guida di base su ciò per cui può essere utilizzato il 20% del tempo delle persone. Dovrebbe essere qualcosa che generalmente contribuisce all'azienda (inclusa la cultura che stiamo cercando di costruire) o al tuo sviluppo professionale. Quindi passare il tempo ad imparare un nuovo linguaggio di programmazione è fantastico, usare il tempo per imparare la chitarra non lo è.

Teniamo anche presentazioni regolari e, se ti prendi del tempo, devi anche fare una presentazione su cosa stavi lavorando. Ciò mantiene il 20% di tempo produttivo. Alcune cose per le quali abbiamo trovato il 20% di tempo particolarmente utili:

  • Prototipare idee o giocare con tecnologie che non siamo ancora pronti a mettere in produzione.
  • Mantenere le competenze affilate.
  • Reclutare persone fantastiche.
  • Offri un'opportunità per l'ingegneria per costruire prove di concetto efficaci che possono ottenere supporto a livello di prodotto.

Per quanto riguarda l'allocazione, abbiamo provato diverse cose.

Tempo alla settimana

L'idea qui è che 1 giorno alla settimana è dedicato ai progetti collaterali. Essenzialmente l'approccio "se stai assegnando il 20% a un venerdì ogni settimana" al problema. Abbiamo provato prima questa implementazione e abbiamo riscontrato diversi problemi immediati:

  • Molte sfide interessanti non consentono di lavorare per un giorno. Ci vuole così tanto tempo solo per familiarizzare con quello che stai facendo.
  • Se stavi correndo anche leggermente indietro in un determinato compito, non lo facevi ... il che spesso significava che non hai mai impiegato il 20% del tempo . Il ribaltamento era problematico, perché francamente, se lo stai monitorando con un foglio presenze a quel livello qualcosa è andato storto.
  • Non molto prevedibile dal punto di vista della pianificazione, perché mentre i venerdì erano comuni non erano universali e non sapevi chi lo avrebbe preso o se lo avrebbero effettivamente preso.
  • Ha aiutato di più con la pianificazione, perché ha aiutato a impedire alle persone di mettere la loro velocità personale troppo alta se inserivano un buffer automatico del 20%.
  • Per la maggior parte, non è mai stato utilizzato.

Un'iterazione su cinque

Abbiamo lavorato a lungo senza iterazioni di due settimane. Quindi l'implementazione successiva dell'idea era di spendere un'iterazione su cinque lavorando su qualsiasi progetto secondario. Funzionava ragionevolmente bene, sostanzialmente meglio della versione precedente. Alcune considerazioni:

  • Ciò ha reso le cose molto prevedibili dal punto di vista del prodotto. Sapevi esattamente quali settimane avresti perso e potevi pianificare di conseguenza.
  • D'altra parte, i conflitti di pianificazione erano comuni perché un team sarebbe stato programmato per un rilascio la settimana successiva e avrebbe bisogno di ottenere distribuzioni fittizie o test dell'ultimo minuto effettuati. Quindi trovavano spesso la loro pianificazione in movimento e potevano facilmente interrompere il 20% del tempo di qualcun altro a causa della necessità della loro esperienza sulla distribuzione o sul codice.
  • Non aiutava con l'utilizzo problema.
  • I team che non avevano iterazioni perfettamente sincronizzate (nessuno di noi lo faceva) non potevano lavorare insieme in modo efficace su progetti più grandi o più interessanti.

Uno Settimana su cinque

Quindi abbiamo iniziato a passare a un sistema kanban e abbiamo iniziato a pensare in settimane anziché in iterazioni, quindi siamo passati da 1 iterazione su cinque a una settimana su cinque.

  • I conflitti con le distribuzioni erano più comuni (frequenza), ma generalmente generavano un impatto inferiore poiché era più facile bloccare una settimana che bloccarne due.
  • Poiché tutti lavoravano settimana per settimana, è stato più facile sincronizzarsi con altri team.

A parte questo, era molto simile a un'iterazione su cinque.

Blocchi temporali per trimestre

Questo è il sistema attuale che stiamo provando. L'idea qui è che tu imposti le attività per te sulle bacheche kanban con la quantità di tempo assegnata a loro che ottieni per il trimestre. Il tempo non scorre tra i quarti, ma puoi prenderlo tutto in anticipo o tutto alla fine, o in blocchi più piccoli come ritieni opportuno. Ciò consente alle persone e ai team di capire cosa funzionerebbe meglio per loro in base al loro programma di rilascio e anche di prendere tempo in più o meno di un incremento di una settimana a seconda del loro programma, cosa stanno cercando di fare, ecc.

Questo risolve molti dei problemi che abbiamo incontrato in precedenza, ma ha lo svantaggio che il tempo deve essere gestito più da vicino ed è più difficile prevedere con precisione. D'altra parte, può essere avuto a un livello di interruzione inferiore.

#2
+21
jcmeloni
2012-04-21 20:28:06 UTC
view on stackexchange narkive permalink

Ho esperienza di lavoro in organizzazioni che hanno implementato qualcosa come "20% di tempo" (anche se era solo "10% di tempo") ed è qualcosa che implementerò nell'azienda in cui sono appena entrato.

La risposta alla domanda su come è "con attenzione". Non vuole essere una risposta irriverente, ma piuttosto vera a una domanda ampia in cui non conosciamo i dettagli della tua azienda. Con "attentamente" intendo:

  • con il supporto dei superiori, o almeno una tacita comprensione di quello che sta succedendo
  • con coerenza (non implementare il programma e poi portalo via immediatamente)
  • dando supporto a coloro che lo tentano (non denigrare il prodotto di lavoro e celebrare l'output)
  • con la consapevolezza che all'inizio potresti vedere benefici (o risultati) meno diretti per i progetti a cui le persone sono ufficialmente assegnate

Questo porta alla domanda che non hai effettivamente posto, che è perché farlo nella prima luogo ? Capire il "perché" dietro a questo renderà le seguenti risposte alle tue domande secondarie più sensate.

Quali sono i limiti per quel 20% del tempo?

Qualunque cosa tu voglia, in qualche modo potenzia i prodotti dell'azienda o le sue risorse (es. tu).

Cosa succede se devo lavorare 40 ore per completare il mio progetto in tempo? (ecc.)

Se non hai tempo da spendere per qualcosa in più, non farlo.

Se guardi la prima riga del L'articolo del NY Times a cui hai collegato un link dice "Gli ingegneri sono incoraggiati a dedicare il 20% del loro tempo a lavorare su qualcosa di correlato all'azienda che li interessa personalmente". Enfasi mia.

Incoraggiato. Non forzato. "20% di tempo" non riguarda "divertimento obbligatorio" o "lavoro extra oltre il tuo compito effettivo". È volontario e si tratta di scoprire e incoraggiare la motivazione sul posto di lavoro.

Vale la pena notare che non è qualcosa che Google ha inventato: la nota adesiva è nata all'inizio degli anni '70 perché un dipendente 3M ha utilizzato il suo "15% di tempo" per inventarla.

Daniel Pink, autore di Drive: The Surprising Truth About What Motivates Us concentra la discussione sulla motivazione dei dipendenti su tre fattori: il bisogno di autonomia (desiderio di dirigere il nostro proprie vite), padronanza (il desiderio di migliorare in qualcosa che conta) e molti esempi di "20% di tempo" o Atlassian's FedEx Days, che sono eventi di 1,5 giorni pensati per promuovere la creatività, graffiare i pruriti , ottenere trazione per idee radicali e (alla fine) divertirsi, avere al centro il desiderio di rendere i dipendenti più felici, più motivati ​​e coinvolti con la consapevolezza che l'investimento ripagherà in un lavoro migliore durante il restante 80% del tempo, se queste sono le cose che funzionano per te .

Tornando alla domanda iniziale di "come fa un'azienda a farlo"? Torno alla mia risposta "con attenzione", ma aggiungo anche "con gusto!"

Questa è un'ottima risposta!
#3
+8
Jim In Texas
2012-04-16 21:09:05 UTC
view on stackexchange narkive permalink

Lavoro in un'azienda che si considera un "ambiente di lavoro orientato ai risultati", a volte chiamato " ambiente orientato ai risultati."

Un team di ROW rifiuta il modello aziendale di occupazione in quali dirigenti e capisquadra sono pagati per cavalcare un gregge in una fabbrica di pecore come bambini di cui non ci si può fidare.

[A parte: negli Stati Uniti gli appaltatori della difesa sono praticamente costretti al taylorismo dai requisiti dei contratti governativi. Questo può spiegare i comuni enormi sforamenti dei costi e frequenti mancate date di consegna.]

L'ambiente di lavoro del modello di fabbrica è talvolta chiamato "Taylorismo", dopo Fredrick W Taylor.

Un team di software che lavora in una struttura di tipo Taylor non potrebbe implementare il concetto del 20% di Google, il solo monitoraggio del tempo sarebbe molto costoso e distrae. Poiché molti, probabilmente la maggior parte, dei progetti del 20% non si traducono mai in profitti a breve termine, un'azienda in stile Taylor non continuerebbe l'esperimento a lungo.

Non ho mai lavorato per Google, ma sospetto che siano una Organizzazione di tipo RIGA. Sospetto che gli sviluppatori di Google lavorino con i loro team leader per definire un programma di risultati attesi, che tenga conto dei progetti del 20% degli sviluppatori. Sospetto che fintanto che uno sviluppatore fornisce risultati più o meno secondo il piano concordato (non imposto) non ci sia alcuna preoccupazione per quanto tempo qualcuno ha impiegato per il pranzo o se ha trascorso 9 ore la scorsa settimana sul loro progetto del 20% .

Ciad - Ho modificato la domanda originale per consentire speculazioni, altrimenti solo la direzione di Google potrebbe rispondere. Spero che sembri una speculazione informata, dal momento che la mia organizzazione, pur non avendo una politica formale del 20%, consente ai dipendenti una grande libertà personale di sperimentare e apprendere nei tempi aziendali.
Va bene, Ciad, ma come scritto la domanda è senza risposta da nessuno che non sia un manager di Google. La domanda dovrebbe essere formulata in modo tale da consentire ai dipendenti non Google di rispondere in qualche modo. Ciò significa che le risposte implicheranno "speculazioni", che ci piaccia o meno quella parola.
"Come può essere implementato efficacemente", quando un tale piano * chiaramente è stato * non dovrebbe rispondere con "No, non puoi farlo".
Sono contento che tu abbia menzionato il taylorismo. C'è un ottimo documentario su YouTube a riguardo, cercherò di trovarlo questa sera.
#4
+3
HLGEM
2012-04-16 23:54:40 UTC
view on stackexchange narkive permalink

Cercherò di rispondere a quanto segue:

O come potrebbe un'organizzazione di sviluppo software implementare un concetto simile di "progetto 20%" che sarebbe accettabile per la direzione, i clienti e dipendenti.

Per come la vedo io, implementare una cosa del genere in un luogo di lavoro richiederebbe il superamento di diversi ostacoli. Devi capire che si tratta di una decisione aziendale e quindi deve essere qualcosa vendibile al senior management in termini di business.

In primo luogo, come viene pagato lo stipendio dello sviluppatore attualmente? Se, come nel posto in cui lavoro, la maggior parte del tempo dello sviluppatore viene addebitato a progetti specifici del cliente, il 20% del tempo speso per lavori non fatturabili sarà una vendita difficile. I soldi per pagare quegli stipendi devono venire da qualche parte e qualsiasi proposta in tal senso dovrà specificare da dove. Vedo tre scelte fondamentali: l'azienda prende dai profitti correnti, l'azienda aumenta la tariffa oraria addebitata ai clienti per poterla pagare o l'azienda tampona le ore modificate al cliente del 20% (che può o non può essere legale). Se non svolgi un lavoro fatturabile dal cliente, la prima scelta è la tua unica scelta. Se lo fai, il secondo potrebbe essere fattibile se (ed è un grande se) è improbabile che perderai clienti quando aumenterai le tariffe. La terza opzione mi sembra non essere realmente praticabile e non la suggerirei a meno che non sapessi che era legale.

Tuttavia, per vendere la proposta, devi mostrare cosa otterranno per i soldi. È simile a R&D in un'azienda farmaceutica. È un grosso rischio e un grande costo con un potenziale enorme guadagno. Ma come determinare se ha avuto un guadagno? Bene, è lì che devi tenere traccia dei progetti personali. Quindi, se proponi una cosa del genere, assicurati di ideare un sistema per i progetti personali che vengono implementati per essere monitorati e i risparmi sui costi oi nuovi profitti da essi tracciati.

Dovrai quantificare i potenziali vantaggi in termini di business. Parla in termini di capacità di attrarre i migliori talenti, costi inferiori grazie a una maggiore fidelizzazione dei dipendenti e, naturalmente, i potenziali profitti discussi sopra.

Successivamente devi mostrare come verranno utilizzate le ore e come la pianificazione del progetto dovrà essere adattata per tenere conto del tempo. Ciò significa che le scadenze verranno spostate, il che di nuovo non è una vendita facile. Suggerirei che fino al 20% delle ore addebitate in un mese viceversa alla settimana avrebbe più senso. E sì, se non lo facessi quel mese lo perderesti se non in circostanze straordinarie che sarebbero decise una alla volta dalla direzione. Potresti anche considerare di inserire parte o tutto il tempo come un periodo di riposo tra i progetti principali. È un po 'più facile dire ai clienti esterni che nessuno sarà disponibile a lavorare fino al 1 giugno e che il progetto richiederà 40 giorni lavorativi piuttosto che dire loro che inizierà il 15 maggio e richiederà 48 giorni lavorativi. Alcuni di questi dovrebbero considerare come fai attualmente affari. I team per lo più in modalità di manutenzione non avrebbero quel tipo di tempo di inattività facile da definire, ma con progetti più brevi è probabilmente più facile trovare le ore su base settimanale.

Devi anche affrontare, acquistare più persone o spostare le scadenze per tenere conto del 20% in più.

#5
+2
mhoran_psprep
2012-04-16 17:11:41 UTC
view on stackexchange narkive permalink

La domanda può essere risolta meglio da un'azienda che ha questa politica, ma ho lavorato con alcune organizzazioni che hanno provato, ma non sono riusciti a utilizzarla.

  • In 40 ore settimana lavorativa, 8 ore verranno utilizzate non per scherzare ma per fare in modo produttivo. In un'organizzazione, la quantità di documentazione richiesta per questo 20% ha significato che 4 ore sono state perse per scartoffie.

  • Un gruppo si aspettava che i dipendenti lavorassero 60 ore a settimana, quindi nessuno sapeva se si supponeva che fossero 48 ore di lavoro e 12 ore di sperimentazione; oppure 60 ore di lavoro e poi sperimentazione attaccata alla fine della settimana.

L'idea che l'azienda o il dipendente tenga traccia delle ore in modo che possa essere utilizzato per livellare il carico di lavoro lo fa sembrare un incubo amministrativo. Significa anche che il dipendente sa che la direzione tiene traccia del tempo e che la direzione decide con quali progetti vale la pena giocare.

Se non sembrava divertente, o almeno meno stressante rispetto agli altri progetti, non mi interesserebbe.

In qualche modo dubito che Google uccida effettivamente la metà del 20% del tempo con i documenti. Quale azienda ha richiesto un tale livello di documentazione e perché dovrebbe essere richiesto?
Era richiesto da un gruppo che leggeva un articolo sulla policy di Google, ma in realtà erano micro-gestori.
Micromanage! = Google. Non lo prenderei come un segno contro la regola del 20%, solo per l'azienda incompetente.
Se l'obiettivo di un'azienda è quello di massimizzare i profitti trimestrali riducendo al minimo i costi del lavoro, allora ovviamente un `` goof off '' del 20% sarebbe incomprensibile per la direzione o i dipendenti. D'altra parte, se un'azienda avesse una politica di progettazione di un i migliori dipendenti del mondo in modo da implementare il dominio mondiale a lungo termine del loro settore, quindi il 20% di "goof off" sembrerebbe un piccolo prezzo da pagare.
@JimInTexas Direi che è più complesso di così, il 100% dell'orario di lavoro non significa il 100% del tempo di produttività. Anche i progetti "Goof off" di Google a volte si trasformano in prodotti reali (il design attuale di Google Play è il momento "Goof Off"). Penso che molte persone qui non riescano a capire la politica di Google e cosa succede effettivamente.
-1 perché stai spiegando come farebbe un'azienda incompetente, non come implementarlo correttamente.
Devo fare -1 per gli stessi motivi per cui ha fatto Rarity.
#6
+1
Thaddeus Howze
2012-04-20 03:29:53 UTC
view on stackexchange narkive permalink

Tutte le idee prima di questa rendono la messa da parte del tempo molto più complicata di quanto dovrebbe essere. Il 20% corrisponde a un giorno di una settimana. In questo modo si impiegano quattro giorni a lavorare su progetti "normali". Un giorno alla settimana per quattro settimane vengono spesi in "altri" lavori più stimolanti. Prova questo processo per le dimensioni.

  1. Sembra che l'idea sia stata venduta ai vertici. Se è così, non c'è lavoro da fare lì.
  2. Se vuoi implementare il progetto, fallo su una base del 20% di un giorno alla settimana.
  3. Il quinto giorno del periodo (4 venerdì di fila, il 5 ° venerdì) Presenta il lavoro.
  4. Sesto venerdì, seleziona il progetto più bello. Aggiungilo a una coda di perfezionamento.
  5. I prossimi quattro venerdì risolvono lo sviluppo del progetto, decidono se il progetto ha un vero merito.
  6. In tal caso, aggiungilo al programma di lavoro principale come progettare e lavorare verso una versione alpha.
  7. Dimostrare l'alfa e decidere se si vuole andare oltre. Tieni a disposizione un elenco di altri progetti meno meritevoli. È probabile che il secondo classificato al progetto scelto possa ricevere la stessa attenzione.
  8. Se il progetto viene scelto per un ulteriore sviluppo, aggiungilo alla coda di sviluppo. Attendi un mese affinché il progetto si stabilizzi, risciacqui e ripeta
  9. Dovresti essere in grado di farlo almeno quattro volte all'anno.
  10. "Fallimenti" significa progetti a parte i primi 8 scelti possono sempre essere rivisti e rivisti in seguito.
#7
+1
Scott Stevens
2013-01-11 05:47:31 UTC
view on stackexchange narkive permalink

Sono d'accordo con gli altri commenti sul fatto che si dovrebbe farlo con molta attenzione. Penso che dovresti forse adoperarti per quanto segue:

1) obiettivi equilibrati . Vuoi che i tuoi dipendenti lavorino su progetti che possono potenzialmente avvantaggiare la tua azienda, tuttavia, non vuoi necessariamente avere troppo controllo su ciò che decidono di fare con questo tempo. Se dici loro su cosa possono lavorare, vedranno che non è diverso dall'avere un altro progetto aggiunto nel loro piatto.

2) Orari normali . Se le tue regole del 20% sono implementate correttamente, è probabile che i tuoi dipendenti lavorino su di esse fuori orario. Tuttavia, non lo richiederei. Questo in qualche modo coincide con l'avere "obiettivi equilibrati". Se dici ai tuoi dipendenti su cosa vuoi che lavorino nel loro 20% di tempo in aggiunta al loro tempo attuale, vedranno passato il gergo di fantasia e lo vedranno come straordinario forzato . Dovrebbe essere fatto chiaro, tuttavia, che le loro normali responsabilità lavorative hanno la priorità. Dovrai lavorare sodo per assicurarti che il loro normale lavoro sia limitato in modo tale da non invadere il loro tempo del 20% quanto è realistico. Aggiungerei inoltre, se hai problemi con i dipendenti che inseriscono solo il loro sindacato 40 quando c'è ancora molto lavoro da fare, c'è una forte possibilità che tu abbia un problema di morale. I dipendenti felici si prenderanno il tempo per portare a termine il lavoro.

3) riconoscimento . Devi riconoscere il lavoro svolto dai tuoi dipendenti. Assicurati di riconoscere il successo, il duro lavoro e l'innovazione. Non tutte le loro idee saranno un fuoricampo. Ma devi incoraggiare la partecipazione. Hanno bisogno di vedere che apprezzi le loro idee e contributi.

4) Divertimento . Vuoi che i tuoi dipendenti si divertano con questo. Questo è un modo per sfogarsi intellettualmente, parlare con altri dipartimenti e gruppi con cui normalmente non interagiscono e scoprire problemi o idee di cui non sapevano l'esistenza. Questo non è solo un esercizio per gli ingegneri del software, è anche un esercizio per gli uomini d'affari. Spesso c'è una mancanza di comunicazione tra il lato software e il lato aziendale. Gli addetti al software stanno creando soluzioni di cui l'azienda non ha bisogno e le esigenze aziendali non hanno idea che ci siano soluzioni software ai problemi che devono affrontare ogni giorno. Dai una possibilità a entrambe le parti di comunicare tra loro e gli ingranaggi nella loro testa inizieranno a macinare.

5) feedback . Come regola generale, il tuo chilometraggio può variare. Penso che in definitiva la risorsa più importante per te siano i tuoi stessi dipendenti. Non limitarti a sollecitare feedback online dallo stack. Invita i tuoi dipendenti a esprimere le loro opinioni. Apprezzeranno che tu chieda loro e apprezzeranno la possibilità di trovare un modo per fare le cose che funzioneranno con loro. In definitiva, la regola del 20% secondo me è una macchina per migliorare il morale, generare idee e appiattire la tua organizzazione. Penso che aiuti ad eliminare la burocrazia con cui lottano molte culture aziendali. Se ci sono sfide che la tua azienda deve affrontare, è probabile che ci sia qualcuno che potrebbe avere un modo per risolverle. Potrebbe non essere la persona che ti aspetti. Ascolta i tuoi dipendenti e trova ciò che funziona per te.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...