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

Il motivo principale per il 20% di tempo è 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 modellarne il comportamento usando la teoria delle code .

TEORIA

Se le richieste arrivano più velocemente di quanto il sistema possa servirle, si accodano. Quando gli arrivi sono più lenti, la dimensione della coda diminuisce. Poiché i processi di arrivo e di servizio sono casuali, le dimensioni della coda cambiano casualmente con il tempo.

L'inclinazione matematica può chiedere di questa "casualità": deve esserci una 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 uguale al rapporto tra tassi di servizio e di arrivo.Se i processi non sono Markov, la matematica è più complicata, ma non cambia le conclusioni.)

Se tracciate questa funzione, potete vedere che la lunghezza media della coda rimane bassa mentre l'utilizzo è fino a 0,8 , quindi aumenta bruscamente e passa all'infinito. Puoi capirlo in modo intuitivo pensando alla CPU del tuo computer: quando il suo utilizzo si avvicina al 100%, il computer non risponde.

PRACTICE

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

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

Seguono immediatamente alcune conclusioni pratiche:

• se stai considerando il 20% di tempo e esegui la contabilità dei costi (il tempo degli sviluppatori costa X, ma / e l'azienda non 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% di tempo, stai sbagliando
• se stai compilando i timesheet, stai sbagliando
• se utilizzi l'innovazione come motivazione per il 20% del tempo, stai sbagliando. Mentre i nuovi prodotti sono usciti dal 20% dei progetti, non erano il punto. Se la tua azienda non può innovare durante le sue ore principali, questo è un problema!
• Il 20% di tempo non riguarda la creatività. Non dire che scateni la tua creatività con il 20% di tempo, chiedi perché non sei già abbastanza creativo durante il tuo core hours.

RISPOSTE ALLE DOMANDE NEI COMMENTI

Dan , hai capito bene e hai descritto con precisione 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 corrispondenza è uno dei problemi difficili affrontati dal corpus di conoscenza del software di sviluppo snello. L'utilizzo è uno degli indicatori di quanto questo problema sia stato risolto in un'organizzazione. Il lasco emerge man mano che la tua iniziativa snella progredisce e rimuovi gli sprechi dal flusso di valore. Ma se imposti il 20% di tempo, finisci nella stessa trappola di utilizzo con meno capacità disponibile.

Kim , è ancora parzialmente una cosa culturale. Il riferimento culturale più vicino a cui riesco a pensare è il livello sinergico del cosiddetto modello Marshall del cambiamento organizzativo. Emerge alla fine delle trasformazioni magre di successo o è presente nelle organizzazioni costruite a partire 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 in il loro libro del 2006 Implementazione dello sviluppo software snello . Donald Reinertsen in il suo libro 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, ho trovato molto meglio .

Non ho lavorato in un posto in cui tali opere sono state ufficialmente riconosciute. Ma dalle mie conversazioni e tentativi di conoscere questa pratica, ho trovato questo - beh, per lo più 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% di tempo è come hai detto tu - tempo in cui lo sviluppatore sceglie da solo su cosa lavorare. Skunkworks è completamente diverso. Un progetto skunkworks è un progetto ad alto valore e ad alto costo elaborato da un team (spesso un gruppo di esperti di guru) che non viene segnalato al management superiore e il team decide autonomamente come procedere senza la direzione del management . Questi progetti sono spesso motivati da una necessità tattica o aziendale di fare qualcosa, ma non c'è spazio per il budget. 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 ci ho provato, comunque. Ho avuto 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 richiedevano un intervento immediato, il tempo del 20% era stato superato. Questo ha finito per accadere 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 ciò che vuoi, purché sia legato alla programmazione", hanno comunque avuto difficoltà ad accettare la parte "nulla". 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 espandessero e crescessero, ma invece hanno approfondito la loro esperienza principale.

Lo farei di nuovo, ma proibirei espressamente di lavorare sul prodotto principale e potrei iniziarlo 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 l'ha presentato al colloquio di lavoro, sono rimasto davvero sorpreso, poiché la maggior parte degli altri datori di lavoro cercava di non "sprecare" una sola ora.

Mi sono unito allo start-up quando è stato formato e per quasi un anno sono stato l'unico sviluppatore. Ho speso il mio 20% con fondamentalmente un paio di cose:

• Segnalazione / correzione di bug in progetti open source casuali : può essere piccolo come un biforcarsi su un progetto interessante su Github & correggendo alcuni refusi nei documenti.
• Scrivere contenuti "open source" - cose come sfide di programmazione, solo per divertimento.
• Andando a conferenze e sprint - ogni poche falene andrei a uno sprint in cui posso lavorare su progetti (alcuni dei quali potrebbero essere usati dall'app principale, altri no) e fare esperienza. Ci sono alcune librerie che vengono utilizzate dalla nostra app e dalle app sviluppate da altre aziende che inviano gli sviluppatori alle conferenze, quindi possono essere viste come un beneficio diretto per la nostra azienda.
• Nuove tecnologie di apprendimento : ecco come ho imparato Vai , 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, non sono sicuramente 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 libero.

Sto lavorando in remoto, e usiamo la chat Campfire di 37signal per comunicare e tracciare liberamente la reciproca presenza, e queste ore sono tracciate come "ore di lavoro", sono connesso alla chat e disponibile per i colleghi , anche se chiarendo che al momento non sto lavorando al nostro progetto.

Dalla mia piccola esperienza, molti dei nostri progetti sono iniziati in questo modo. Abbiamo avuto tempo libero e larghezza di banda per intraprendere nuovi progetti, ci siamo messi insieme e abbiamo escogitato idee potenzialmente interessanti per il nostro dipartimento. Nel nostro tempo libero abbiamo sviluppato un prototipo e una volta che era abbastanza lucido, presentato al livello superiore e di solito ne vedono il beneficio.

Mi sembra che il livello superiore sappia ciò che vogliono se lo vedono, ma non sanno di aver bisogno / lo vogliono finché non lo vedono. La prototipazione ci ha permesso di creare i nostri progetti, proporli e poi, una volta approvati, dedicare loro più tempo per completarli.