Presentazione del "20% di tempo" sul luogo di lavoro [chiuso]

Il 20% del tempo è la cultura di un datore di lavoro che consente ai suoi dipendenti di trascorrere il 20% del loro tempo a lavorare su progetti che trovano interessanti - potrebbe essere inventare una nuova app o migliorare un processo esistente, ecc. Alcune persone potrebbero conoscerlo come skunk funziona, tuttavia quel termine potrebbe non significare nulla (o qualcosa di completamente diverso) per te.

Ci sono molti casi documentati di grandi prodotti nati dal 20% / lavoro skunk in un'azienda. Sembra una situazione win / win; la società potenzialmente ottiene un nuovo fantastico prodotto o applicazione e lo sviluppatore ha l'opportunità di flettere i suoi muscoli creativi e innovare.

In numerose occasioni ho provato a introdurre senza successo una qualche forma di 20% / Skunk nel mio precedente datore di lavoro.

Come posso giustificarlo meglio alla direzione? Qual è il modo "giusto" di affrontare questo tipo di organizzazione del lavoro?

Il motivo principale del 20% di tempo è di mantenere l'utilizzo della capacità all'80% anziché al 100%.

Puoi pensare a un'organizzazione di sviluppo software come a un sistema che trasforma le richieste di funzionalità in funzionalità sviluppate. Puoi modellare il suo comportamento usando la teoria delle code .

TEORIA

Se le richieste arrivano più velocemente di quanto il sistema possa fornirle, si mettono in coda. Quando gli arrivi sono più lenti, la dimensione della coda diminuisce. Poiché i processi di arrivo e di servizio sono casuali, la dimensione della coda cambia in modo casuale nel tempo.

I matematicamente inclini possono chiedere questa "casualità": ci deve essere una certa distribuzione di probabilità, quindi quale sarà la dimensione della coda in media? La matematica (teoria delle code) ha una risposta a questo: se entrambi i processi di arrivo e di servizio sono Markov, allora N = rho ^ 2 / (1-rho).

(Dove rho è il coefficiente di utilizzo pari al rapporto tra servizio e tariffe di arrivo. Se i processi non sono Markov, la matematica è più complicata, ma non cambia le conclusioni.)

Se traccia questa funzione, puoi vedere che la lunghezza media della coda rimane bassa mentre l'utilizzo è fino a 0,8 , quindi aumenta bruscamente e va all'infinito. Puoi comprenderlo intuitivamente pensando alla CPU del tuo computer: quando il suo utilizzo si avvicina al 100%, il computer non risponde.

PRATICA

L'economia dello sviluppo del software è tale che le società di software sostengono grossi costi quando le loro code si trovano in stati di alta coda. Ciò include opportunità di mercato mancate, prodotti obsoleti, progetti in ritardo e sprechi causati dalle funzionalità di costruzione in previsione della domanda.

Il tempo del 20% è quindi la risposta scientifica al problema dell'ottimizzazione dei risultati economici: evitare gli stati di coda elevata evitando i rapporti di utilizzo che li causano. È essenzialmente il gioco che mantiene il sistema reattivo.

Diverse conclusioni pratiche seguono immediatamente:

• se stai considerando il 20% di tempo e stai facendo la contabilità dei costi (il tempo degli sviluppatori costa X, ma / e la società può / non può permetterselo), stai sbagliando.
• se stai assegnando il 20% a un venerdì ogni settimana, stai sbagliando
• se stai impostando un sistema di invio / revisione / approvazione della proposta di progetto del 20%, stai sbagliando
• se stai compilando schede attività, stai sbagliando
• se stai usando l'innovazione come motivatore per il 20% del tempo, stai sbagliando. Mentre i nuovi prodotti sono usciti dal 20% dei progetti, non erano questo il punto. Se la tua azienda non può innovare durante le sue ore principali, questo è un problema!
• Il 20% del tempo non riguarda la creatività. Non dire che libererai la tua creatività con il 20% di tempo, chiedi perché non sei già abbastanza creativo durante le tue ore principali.

RISPOSTA ALLE DOMANDE NEI COMMENTI

Dan , hai capito bene e hai accuratamente descritto l'errore fatto da molti. Non puoi scegliere la percentuale di utilizzo, perché è una variabile di output. È un rapporto tra le caratteristiche di due processi, quindi è quello che è perché i processi sono come sono. Un'organizzazione ha influenza su entrambi i processi; la capacità e la domanda di abbinamento è uno dei problemi più difficili affrontati dal corpo snello di conoscenza dello sviluppo software. L'utilizzo è uno degli indicatori della risoluzione del problema in un'organizzazione. Il rallentamento emerge mentre la tua iniziativa snella avanza e rimuovi gli sprechi dal flusso di valore. Ma se si impone il 20% di tempo, si finisce nella stessa trappola di utilizzo con una capacità disponibile inferiore.

Kim , è ancora parzialmente una cosa culturale. Il riferimento culturale più vicino a cui riesco a pensare è il livello sinergico del cosiddetto modello Marshall di cambiamento organizzativo. Emerge alla fine di trasformazioni lean di successo o è presente nelle organizzazioni costruite lean fin dall'inizio. ( Ecco un link al white paper di Bob Marshall (PDF) .)

RIFERIMENTI

La logica di cui sopra è ben supportata nella letteratura di ingegneria del software. Mary e Tom Poppendieck lo hanno accennato nel loro libro del 2006 Implementing Lean Software Development . Donald Reinertsen nel suo libro del 2009 Principles of Product Development Flow (capitolo 3) offre un trattamento approfondito di questo argomento, con formule e grafici.

Quattordici mesi dopo aver scritto questa risposta, ne ho trovato una molto migliore .

Non ho lavorato in un posto in cui tali lavori sono stati ufficialmente riconosciuti. Ma dalle mie conversazioni e dai tentativi di conoscere questa pratica, ho scoperto questo - beh, soprattutto ciò che il "20% di tempo" non è:

• è davvero una cultura e non una politica
• non può essere decretato dal senior management
• non può essere istituito da un comitato di sviluppatori
• non sono 32 ore su questo e 8 ore su quello

" Skunkworks " non equivale al 20% di tempo. Il 20% del tempo è come hai detto: il tempo in cui lo sviluppatore sceglie da solo su cosa lavorare. Skunkworks è totalmente diverso. Un progetto skunkworks è un progetto ad alto valore e ad alto costo elaborato da un team (spesso un gruppo di guru scheggiati) che non viene segnalato all'alta direzione, e il team decide da solo come il progetto dovrebbe procedere senza direzione del management . Questi progetti sono spesso motivati ​​da un'esigenza tattica o aziendale di fare qualcosa, ma non c'è spazio nel budget per questo. Se qualcosa deve essere fatto , viene fatto - i budget sono dannati.

Ho gestito un team di sviluppo in cui ho implementato il 20% di tempo. O comunque ci ho provato. Avevo l'approvazione dei miei superiori, quindi non era un problema. Il problema era che la squadra era troppo piccola e troppo specializzata. Ogni volta che si presentavano problemi che necessitavano di un intervento immediato, il tempo del 20% veniva bloccato. Questo finì per succedere molto spesso.

Ho anche scoperto che alcuni dei miei sviluppatori hanno trovato inquietante la mia mancanza di direzione. Anche se ho detto "lavora su tutto quello che vuoi, purché sia ​​legato alla programmazione", hanno avuto difficoltà ad accettare la parte "niente". Hanno pensato che alcuni progetti sarebbero stati migliori di altri, quindi hanno inevitabilmente lavorato su richieste di implementazione di basso livello nel prodotto principale, cose del genere. Volevo che si ramificassero e crescessero, ma invece hanno approfondito la loro esperienza principale.

Lo rifarei, ma proibirei espressamente di lavorare sul prodotto principale e potrei iniziare con alcune idee tra cui scegliere per iniziare.

Sto lavorando per una start-up che ha implementato la politica del 20%. Questo è il mio primo datore di lavoro a farlo, e quando lo ha sollevato durante il colloquio di lavoro, sono rimasto davvero sorpreso, poiché la maggior parte degli altri datori di lavoro stava cercando di non "perdere" un'ora.

Ho aderito alla start-up quando è stata costituita e per quasi un anno sono stato l'unico sviluppatore. Ho speso il mio 20% praticamente con un paio di cose:

• Segnalazione / correzione di bug in progetti casuali open source - questo può essere piccolo come la creazione di un progetto interessante su Github e la correzione di alcuni errori di battitura nei documenti.
• Scrivere "cose" open-source - cose come sfide di programmazione, solo per divertimento.
• Andando a conferenze e sprint - ogni poche tarme andrei a uno sprint dove potrei lavorare su progetti (alcuni dei quali potrebbero essere utilizzati dall'app principale, altri no) e acquisire esperienza. Esistono alcune librerie utilizzate dalla nostra app e dalle app sviluppate da altre società che inviano sviluppatori alle conferenze, quindi può essere visto come un vantaggio diretto per la nostra azienda.
• Apprendimento di nuove tecnologie : è così che ho imparato Go , anche se non lo usiamo in azienda. Questo è particolarmente incoraggiato dal mio datore di lavoro. Ultimamente ho seguito alcune delle lezioni online gratuite di Stanford.

I tempi non sono misurati con precisione, sicuramente non sono 32 + 8 ore, a volte ci sono cose urgenti da fare quando non c'è abbastanza tempo per tagliare quel 20%, altre volte ho più tempo da perdere.

Sto lavorando in remoto, e usiamo la chat di 37signal Campfire per comunicare e per rintracciare vagamente la presenza reciproca, e queste ore sono tracciate come ore "lavorative", sono collegato alla chat e disponibile per i colleghi, anche se sto facendo è chiaro che non sto lavorando al nostro progetto in questo momento.

Dalla mia piccola esperienza, molti dei nostri progetti sono effettivamente iniziati in questo modo. Avevamo tempo libero e larghezza di banda per intraprendere nuovi progetti, ci siamo riuniti e abbiamo trovato potenziali idee cool / lungimiranti per il nostro dipartimento. Nel nostro tempo libero abbiamo sviluppato un prototipo e una volta che è stato abbastanza lucido, presentato al livello superiore e di solito ne vedono il vantaggio.

Mi sembra che il livello superiore sappia cosa vogliono se lo vedono ma non sa di averne bisogno / volerlo finché non lo vedono. Il prototipo ci ha permesso di creare i nostri progetti, proporli e, una volta approvati, dedicare loro più tempo per completarli.