Apresentando "20% de tempo" em um local de trabalho [fechado]

20% do tempo é a cultura de um empregador, permitindo que seus funcionários passem 20% de seu tempo trabalhando em projetos que acham interessantes - pode estar inventando um novo aplicativo ou melhorando um processo existente, etc. Algumas pessoas podem saber isso como skunk trabalho, no entanto, esse termo pode não significar nada (ou algo totalmente diferente) para você.

Existem muitos casos documentados de ótimos produtos nascendo do trabalho de 20% / skunk em uma empresa. Parece uma situação de vitória / vitória; a empresa potencialmente ganha um ótimo novo produto ou aplicativo e o desenvolvedor tem a oportunidade de flexionar seus músculos criativos e inovar.

Tentei em várias ocasiões introduzir alguma forma de 20% / Skunk trabalhando no meu empregador anterior sem sucesso.

Como justificá-lo melhor à gerência? Qual é a maneira "certa" de abordar esse tipo de organização do trabalho?

O principal motivo para 20% do tempo é manter a utilização da capacidade em 80%, e não em 100%.

Você pode pensar em uma organização de desenvolvimento de software como um sistema que transforma solicitações de recursos em recursos desenvolvidos. Você pode modelar seu comportamento usando a teoria de filas .

TEORIA

Se as solicitações chegarem mais rapidamente do que o sistema pode atendê-las, elas serão colocadas na fila. Quando as chegadas são mais lentas, o tamanho da fila diminui. Como os processos de chegada e serviço são aleatórios, o tamanho da fila muda aleatoriamente com o tempo.

Os inclinados matematicamente podem perguntar sobre essa "aleatoriedade": deve haver alguma distribuição de probabilidade; então, qual será o tamanho da fila, em média? A matemática (teoria das filas) tem uma resposta para isso: se os processos de chegada e de serviço são Markov, então N = rho ^ 2 / (1-rho).

(Onde rho é o coeficiente de utilização igual à taxa de serviço e taxas de chegada. Se os processos não são de Markov, a matemática é mais complicada, mas não altera as conclusões.)

Se você plotar esta função, poderá ver que o comprimento médio da fila permanece baixo enquanto a utilização é de 0,8 , depois aumenta acentuadamente e vai para o infinito. Você pode entender isso intuitivamente pensando na CPU do seu computador: quando sua utilização se aproxima de 100%, o computador deixa de responder.

PRÁTICA

A economia do desenvolvimento de software é tal que as empresas de software incorrem em grandes custos quando suas filas estão em estados de alta fila. Isso inclui oportunidades perdidas de mercado, produtos obsoletos, projetos atrasados ​​e desperdícios causados ​​pela construção de recursos em antecipação à demanda.

O tempo de 20% é, portanto, a resposta científica ao problema de otimizar os resultados econômicos: evite os estados de fila alta, evitando as taxas de utilização que os causam. É essencialmente a folga que mantém o sistema responsivo.

Várias conclusões práticas seguem imediatamente:

• se você está pensando em 20% do tempo e está fazendo contabilidade de custos (o tempo dos desenvolvedores custa X, mas / e a empresa pode / não pode pagar), está fazendo errado.
• se você está alocando 20% a uma sexta-feira toda semana, está fazendo errado
• se você estiver configurando um sistema de envio / revisão / aprovação de proposta de projeto em 20%, estará fazendo algo errado
• se você está preenchendo folhas de ponto, está fazendo errado
• se você estiver usando a inovação como motivador por 20% do tempo, estará fazendo errado. Embora os novos produtos tenham saído de 20% dos projetos, eles não eram o objetivo. Se sua empresa não pode inovar durante o horário comercial, isso é um problema!
• 20% do tempo não é sobre criatividade. Não diga que você liberará sua criatividade com 20% de tempo, pergunte por que você ainda não é criativo o suficiente durante o horário comercial.

RESPOSTAS ÀS PERGUNTAS NOS COMENTÁRIOS

Dan , você acertou e descreveu com precisão o erro cometido por muitos. Você não pode escolher sua porcentagem de utilização, porque é uma variável de saída. É uma proporção de características de dois processos, por isso é o que é porque os processos são do jeito que são. Uma organização tem influência sobre os dois processos; combinar capacidade e demanda é um dos problemas difíceis abordados pelo corpo de conhecimento de desenvolvimento de software lean. A utilização é um dos indicadores de quão bem esse problema foi resolvido em uma organização. O Slack surge à medida que sua iniciativa lean progride e você remove o desperdício do fluxo de valor. Mas se você exige 20% de tempo, acaba na mesma armadilha de utilização com menos capacidade disponível.

Kim , ainda é parcialmente uma coisa cultural. A referência cultural mais próxima que consigo pensar é o nível sinérgico do chamado modelo Marshall de mudança organizacional. Ele surge no final de transformações lean bem-sucedidas ou está presente em organizações criadas lean desde o início. ( Aqui está um link para o white paper de Bob Marshall (PDF) .)

REFERÊNCIAS

A lógica acima é bem suportada na literatura de engenharia de software. Mary e Tom Poppendieck sugeriram isso em seu livro de 2006 Implementing Lean Software Development . Donald Reinertsen, em seu livro de 2009, Princípios do fluxo de desenvolvimento de produtos (capítulo 3), oferece um tratamento completo desse assunto, com fórmulas e gráficos.

Quatorze meses depois de escrever essa resposta, criei uma muito melhor .

Eu não trabalhei em um lugar onde essas obras foram oficialmente reconhecidas. Mas com minhas conversas e tentativas de aprender sobre essa prática, eu descobri isso - bem, principalmente o que o "tempo de 20%" não é:

• é de fato uma cultura e não uma política
• não pode ser decretado pela gerência sênior
• não pode ser instituído por um comitê de desenvolvedores
• não são 32 horas nisso e 8 horas naquele

" Skunkworks " não é o mesmo que 20% do tempo. 20% do tempo é o que você disse - tempo que o desenvolvedor escolhe por conta própria no que trabalhar. Skunkworks é totalmente diferente. Um projeto skunkworks é um projeto de alto valor e alto custo, trabalhado por uma equipe (geralmente uma equipe fragmentada de gurus) que não é reportada à alta gerência e a equipe decide por si mesma como o projeto deve prosseguir sem a direção da gerência. . Esses projetos geralmente são motivados por uma necessidade tática ou comercial de realizar algo, mas não há espaço no orçamento para isso. Se algo tem que ser feito , é feito - os orçamentos sejam condenados.

Gerenciei uma equipe de desenvolvimento onde implementei 20% do tempo. Ou tentou, de qualquer maneira. Eu tive a aprovação dos meus superiores, então isso não foi um problema. O problema era que a equipe era muito pequena e muito especializada. Sempre que surgiam problemas que precisavam de intervenção imediata, o tempo de 20% era ultrapassado. Isso acabou acontecendo com muita frequência.

Também descobri que alguns dos meus desenvolvedores acharam minha falta de direção perturbadora. Embora eu tenha dito "trabalhe no que quiser, desde que relacionado à programação", eles ainda tiveram dificuldade em aceitar a parte "qualquer coisa". Eles achavam que alguns projetos seriam melhores que outros, então eles inevitavelmente trabalharam em solicitações de implementação de baixo nível no produto principal, coisas assim. Eu queria que eles se ramificassem e crescessem, mas, em vez disso, se aprofundaram em sua principal experiência.

Eu faria isso de novo, mas proibiria expressamente o trabalho no produto principal e posso começar com algumas idéias para escolher.

Estou trabalhando para uma start-up que implementou a política de 20%. Este é o meu primeiro empregador a fazer isso e, quando ele falou sobre a entrevista de emprego, fiquei realmente surpreso, pois a maioria dos outros empregadores estava tentando não "desperdiçar" uma única hora.

Entrei na start-up quando foi formada e por quase um ano fui o único desenvolvedor. Passei meus 20% com basicamente duas coisas:

• Relatar / corrigir bugs em projetos aleatórios de código-fonte aberto - isso pode ser tão pequeno quanto criar um projeto interessante no Github e corrigir alguns erros de digitação nos documentos.
• Escrever "coisas" de código aberto - coisas como desafios de programação, apenas por diversão.
• Indo para conferências e sprints - a cada poucas mariposas, eu participava de um sprint onde trabalhava em projetos (alguns dos quais podem ser usados ​​pelo aplicativo principal, outros não) e ganham alguma experiência. Existem algumas bibliotecas usadas por nosso aplicativo e por aplicativos desenvolvidos por outras empresas que enviam desenvolvedores para conferências, para que isso possa ser visto como um benefício direto para nossa empresa.
• Aprendendo novas tecnologias - foi assim que aprendi a Go , mesmo que não a usemos na empresa. Isso é especialmente incentivado pelo meu empregador. Ultimamente, tenho acompanhado algumas das aulas on-line gratuitas de Stanford.

Os tempos não são medidos com precisão, definitivamente não são 32 + 8 horas, às vezes há coisas urgentes a serem feitas quando não há tempo suficiente para cortar esses 20%, outras vezes tenho mais tempo de sobra.

Estou trabalhando remotamente e usamos o bate-papo da 37signal Campfire para se comunicar e rastrear vagamente a presença um do outro, e essas horas são rastreadas como horas de "trabalho", estou logado no chat e disponível para colegas de trabalho, embora fazendo fica claro que não estou trabalhando no nosso projeto agora.

Da minha pequena experiência, muitos dos nossos projetos começaram dessa maneira. Tínhamos tempo livre e largura de banda para assumir novos projetos, nos reunimos e criamos idéias interessantes para o nosso departamento. Em nosso tempo livre, desenvolvemos um protótipo e, uma vez que foi bastante polido, apresentado ao nível superior e geralmente eles vêem o benefício.

Parece-me que o nível superior sabe o que eles querem se o virem, mas não sabe que eles precisam / o querem até que o vejam. A criação de protótipos nos permitiu criar nossos próprios projetos, propô-los e, depois de aprovados, desviar mais tempo para eles concluírem.