Trabalho Energizado e a Teoria das 2 horas produtivas

Quando eu trabalhava como funcionário, formulei uma teoria exótica e controversa que se uma empresa tiver em média duas horas produtivas por cada “recurso”, essa empresa teria um lucro exorbitante e seria sustentável.

Duas horas produtivas para mim é uma licença poética para “códigos testáveis de forma automatizada, bem escritos, entregues por dia independente de tempo e que não trarão retrabalho”. Um par evita muito retrabalho, lembrando que retrabalho não é refactoring, é prejuízo.

Claro que não há método científico algum, apenas inferência por observação simples. Dia desses um funcionário de um cliente me disse:

“- Milfont, essa sua teoria é mais um dos seus exageros”.  Respondi:

“- Olha do lado, observe o que todos estão fazendo”.

Para espanto desse funcionário, ao olhar para o time mais caxias da empresa, aquele time considerado certinho, que ninguém conversa com ninguém, ele tomou um susto e detectou que todos, eu disse T-O-D-O-S, estavam com o cliente de email aberto. Ninguem estava com sua IDE em primeiro plano.

Coincidência?

Trabalho Energizado

Como consultor eu enfrento problemas de coaching e mentoring [adoro buzzwords] em relação a dificuldade da alta gestão não compreender os benefícios de programação em par para o trabalho energizado. Não que programação em par seja o único responsável por um trabalho focado, mas sem essa prática não dá nem para começar a mudar o cenário.

Todos meus clientes dizem em uníssono: “Até entendo que programação em par é importante, mas não o tempo todo e não para aqueles trabalhos simples”. Investigaremos essa frase ao final.

Meu trabalho como consultor é transformar galinhas mortas em galos de briga, então não tenho pretensões nem esperança que em um mês meus clientes terão integração contínua, todos seguirão Test First como prática e serão felizes para sempre, no mundo real a coisa é só um pouquinho mais complicada. Enfrento muitos clientes saindo da década de 80 direto para o novo milenio, é uma leva de CVS, Delphi, até clipper, além de vícios provocados por essas plataformas/arquiteturas/whatever.

Agile Bibas

Hoje é muito comum meus clientes pedirem planilhas e técnicas para medir velocidade e desempenho de seus “recursos” porque leram sobre isso nas revistas da moda. Isso é perda de tempo, vou cair no clichê mas não posso deixar de falar, enquanto voce não tratar seu time como pessoas e que elas não são máquinas controladas, não espere retorno deles.

Leonardo Eloy cunhou o termo #Agilebibas para representar todos os defensores do PMBoK de Jeans que irão vender métricas e dirão que o time não produz conforme o esperado porque não se comprometem com as planilhas. Apenas comando-controle disfarçado de ágil.

Esqueça métrica de time, concentre-se na métrica do software. Não importa se o membro do time está nu, pulando corda, de cabeça para baixo, lendo emails ou enchendo a cara numa terça de manhã. O que importa é se as features foram entregues e com qualidade.

Parece simples mas não é, a soma “8 + 8 = 16” é difícil de ser anulada [imaginar que 8 horas de dois funcionários representam 16 horas de trabalho produzido com qualidade]. Medir tempo por funcionário é um dos maiores erros para tentar aumentar a produtividade do time.

Vou dizer mais uma vez: “Não meça pessoas, meça e entregue software”. Então não importa se seu funcionário não trabalha as 6 ou 8 horas que você espera que ele trabalhe, o que importa é se as duas features planejadas para hoje foram entregues com a qualidade esperada.

Evitar o trabalho chato

Algumas empresas ainda sonham com a esperança que basta impedir o acesso a redes sociais ou serviços na web, então o funcionário vai parar o “Goofing Off“. Existem inúmeros motivos para uma pessoa não estar energizada em seu trabalho, considero o principal como sendo “fazer trabalho chato”.

Vamos agora analisar aquela frase do início:

“Até entendo que programação em par é importante, mas não o tempo todo e não para aqueles trabalhos simples”

Observe que essa frase revela duas nuances onde o cliente acredita que trabalho em par não é importante, uma consequência da outra. Trabalho simples que provoca a necessidade de não trabalhar em par o tempo todo.

A primeira coisa como consultor quando sou contratado para mudar a cultura do time é tentar incluir programação em par como algo natural e prática necessária, para tanto preciso anular esse trabalho chato que considero ser basicamente trabalho repetitivo. Observe na frase anterior que meus clientes chamam esse trabalho de “simples”.

Não é simples, é chato.

Exemplo que me veio a cabeça agora mesmo, todos os cliente que não tem Test First como prática, então ficam testanto as coisas durante o desenvolvimento na mão, para tanto precisam gerar dados.  Para um desenvolvedor é frustrante ficar fazendo dump e passando para seus colegas de trabalho, porque não automatizar isso?

Todos meus clientes que não fazem Test First passam por isso. Ora, se mesmo os que tem essa prática nós enfrentamos desafios de um bom Setup para garantir a independência no INVEST, imagina os que não fazem.

Outro erro comum é achar que número de commits é sinal de proficiência ou estar trabalhando mais, em regra, para mim é sinal de muito trabalho repetitivo.

Não vou me prolongar, quero só concluir que evitar trabalho chato ajuda a demonstrar que Pair Programming é sim necessário o tempo todo e que se isso for alcançado a “morcegação” tende a diminuir e o reflexo na entrega de funcionalidades se torna positivo. Junte a isso o foco no software ao invés de medir pessoas e esqueça as toneladas de planilhas, na maioria das vezes nem um Burndown seja necessário, apenas trabalho energizado.

10 thoughts on “Trabalho Energizado e a Teoria das 2 horas produtivas

  1. Rafael Ponte

    Excelente post, Milfont.

    É fácil observar que o maior problema na aceitação do agile é a mudança de cultura na empresa. Já é dificil tirar um desenvolvedor da zona de conforto então imagine toda uma equipe ou mesmo empresa!

    Eu, particurlarmente, já acho exagero considerar 6h de trabalho produtivo por “recurso” numa equipe, imagina mais que isso, no qual normalmente é o que ocorre.

    Procrastinar, enrolar, whatever é normal em qualquer área, e eu acredito que a melhor maneira de resolver isso é motivando a equipe.

    Não existe uma maneira simples de motivar todos da equipe uniformemente, mas para começar se já for possível tratar os “recursos” como pessoas e acreditar que eles são o maior capital da empresa então as coisas certamente melhorarão!

    Enfim, parabéns pelo post.

  2. Pingback: Tweets that mention Milfont.org Ultrapassando os limites da WEB -- Topsy.com

  3. Daniel Chaves

    Exelente post cara! Só tenho um comentário a fazer.
    Este post está totalmente direcionado ao ponto de vista daqueles que estão próximos e ‘meio-próximos’ ao processo de produção do software (desenvolvedor, gerente). Imagina agora um gestor em conversa com um gerente que precisa mostrar as entregas do produto, mas também saber a real necessidade de manter todos aqueles profissionais. Imagina uma situação de corte de pessoal que essa empresa possa vir a ter. As métricas em relação à produtividade pessoal e o quanto cada pessoa contribui para o acontecimento de cada entrega deve ser mensurado sim.
    É evidente que alguns gerentes/gestores tornam a frequente análise de resultado dessa métrica uma desculpa para justificar algum atraso, até para ‘tirar o deles da reta’ e passar o abacaxi para os ‘subordinados’. Mas devemos também ter em mente que o dinheiro gasto em uma folha de pagamento deve ser mensalmente justificado.

  4. cmilfont Post author

    Daniel Chaves
    Vou começar pelo fim do seu comentário.

    “Mas devemos também ter em mente que o dinheiro gasto em uma folha de pagamento deve ser mensalmente justificado.”

    Isso é a consequência de código [substitua pelo resultado de qualquer trabalho] sem prejuízo. Se os funcionários produzem o esperado o dinheiro é justificado.

    “As métricas em relação à produtividade pessoal e o quanto cada pessoa contribui para o acontecimento de cada entrega deve ser mensurado sim.”

    Primeiro que isso é quase impossível e a energia desprendida não vale a pena. Mesmo que conseguissemos medir o que cada um contribui individualmente, o esforço seria tanto que a entrega do que é mais importante seria comprometida e o preço não se paga.
    Como mediríamos a minha contribuição? se eu ajudar meu colega [que é a cerne de Pair Programming] dividiríamos meio a meio a realização de uma tarefa ou a entrega de uma feature?

    Note que o importante é entregar o software, para planejar entregas aí já temos outros assuntos que são ligados a esse post mas que seria muito difícil cobrir tudo.

    “Imagina agora um gestor em conversa com um gerente que precisa mostrar as entregas do produto, mas também saber a real necessidade de manter todos aqueles profissionais.”

    Se você medir o software ao inves de gente, você tem a noção clara de quantas e quais pessoas precisa para construir/manter/evoluir, como gestor saberá resolver, ou então não está capacitado a ser gestor.

  5. Daniel Chaves

    “Se você medir o software ao invés de gente, você tem a noção clara de quantas e quais pessoas precisa…”
    Cara, acho q não é bem assim. Contratar/demitir pessoas é algo q não é trivial. Muitas vezes o currículo ou as referências recebidas de uma pessoa não condiz com as suas reais capacidades.

    Falando de negócios sabemos que a meta é produzir mais rápido e com o menor custo. É assim e não se pode mudar. Se vc entrega tudo ok, ótimo, sua empresa está no caminho certo. Mas do ponto de vista do gestor ele sempre vai buscar uma forma de reduzir custos. Claro q um bom gestor deve saber q se isso for feito sem controle, resulta numa queda na qualidade dos produtos. Daí vem a necessidade de medir também as pessoas, além de outras alternativas como adotar novas metodologias, ferramentas, tecnologias, etc…
    A medição do software, como vc esplanou no post, é importantíssima sim. Mas retrata a qualidade do software e da equipe somente. Não acho q isso seja suficiente para levar uma empresa a um sucesso duradouro.

  6. Pingback: Palestra Agilidade no Mundo Real - Milfont Consulting

  7. Rodrigo Galba

    Muito bom esse post.

    Quando voce falou sobre a chatisse de fazer um setup de testes, me identifiquei imediatamente.
    Hoje quase não faço pareamento, mesmo com uma equipe de consultoria vindo semanalmente aqui não conseguimos disseminar essa cultura.
    Sem contar na forma de medição das metricas. Ainda uso planilha e validamos o software com o cliente não tanto quanto deveriamos.
    E te digo mais, se voce adivinhar que a cada sprint, mesmo com todo esforço e commits sendo gerados, as planilhas preenchidas e enviadas diariamente a equipe nunca consegue bater as metas.
    Seria por falta de que?
    Pois falta de trabalho não é.

  8. Pingback: Trabalho Energizado 2 - Milfont Consulting

  9. Rômulo Augusto

    Eu to procurando uma forma de chegar na “alta cúpula” de uma empresa, que segue o xGH, com algumas idéias novas. Tá difícil…. por acaso não tem nenhuma dica não aí? (sem querer pedir já pedindo…)

Comments are closed.