A jornada de trabalho e os desperdícios da produção de software

Considerando que a Constituição da República Federativa do Brasil prevê em seu artigo 7º, inciso XIII, que a duração de uma jornada normal de trabalho não deve ser superior a 8 horas diárias, começo a me questionar o que nossas atividades de desenvolvimento de software possuem de tão anormal para acharmos que essa carga horária seja insatisfatória para atender todas as necessidades de nossos clientes. Pode ser o excesso de demanda, a falta de profissionais, o excesso de falhas, ou qualquer outra justificativa resultante da ineficiência ou ineficácia de nossas equipes. O fato é que, considerando que a Constituição limita nossa jornada semanal em 44 horas (por incluir a manhã de sábado no horário comercial), por que precisamos ser inconstitucionais para conseguirmos atender os níveis de produtividade exigidos por nossos clientes (trabalhando até 60 horas por semana)? Talvez porque não temos a mínima idéia de onde investimos nossos esforços ou acontecem os desperdícios da nossa jornada semanal de atividades de desenvolvimento de software. Vamos analisar a natureza de nossos esforços e pensar se o que realmente precisamos é de mais gente em nossas equipes de desenvolvimento ...

Disponibilidade Semanal

Tipicamente, vejo muitos gerentes de projeto adotando uma jornada diária de 8 horas para cada profissional alocado em seus projetos de software, limitando a participação dos mesmos em 40 horas semanais (segunda à sexta). Para fins de cálculo, vou fazer o mesmo e considerar essas 40 horas como sendo 100% da disponibilidade de um membro da equipe de software para a realização do trabalho desejado. Não vou julgar se isso é bom ou ruim como premissa de planejamento, o que vou fazer é seguir as orientações de nossa Constituição e limitar o trabalho de segunda à sexta-feira.

Desperdícios das Atividades Extraordinárias

Se você é um profissional contratado para atuar no desenvolvimento e manutenção de software, qual é o principal resultado que se espera do seu trabalho? Talvez um produto de software em perfeito funcionamento, mais alguns artefatos técnicos e administrativos necessários para a manutenção do desempenho e qualidade do processo. Correto? Pois bem, agora pare e pense no percentual de horas que você gasta semanalmente em atividades que não possuem qualquer relação com os processos de desenvolvimento e manutenção de software. Para ajudá-lo, vou dar alguns exemplos:

• Necessidades sociais ou fisiológicas (descanso, ginástica laboral, reuniões privadas, telefonemas, café, banheiro, cigarro, chats, etc.);
• Qualquer tipo de atividade profissional não relacionada diretamente com os processos de software (reuniões administrativas, atendimento a usuários, suporte técnico, leitura de e-mail ou documentos, telefonemas, etc.).

É claro que muitas dessas atividades não são desperdícios, mas ações necessárias para a manutenção do bem estar do ser humano. No entanto, é comum exagerarmos no tempo dedicado a algumas delas, tornando parte das mesmas um total desperdício de tempo produtivo. Para dar mais uma ajuda na sua estimativa, considere que os alemães, os mais produtivos do planeta, apresentam um desperdício semanal da ordem de 11%, enquanto que os ingleses desperdiçam 22% do seu tempo. Nos EUA, algumas pesquisas indicam desperdícios da ordem dos 30% da jornada diária de trabalho.

Quanto você apostaria ser o desperdício semanal de sua equipe em atividades extraordinárias? Para fins de cálculo, vou considerar o valor dos americanos ... 30%. Logo, das 40 horas de trabalho semanal que você alocou em seu plano de projeto, restaram apenas 28 horas para você fazer realmente o que agrega valor a um produto de software! Mas isso não é tudo ...

Desperdícios da Burocracia e do Retrabalho (Muda Tipo II)

Este é um tema que, muitas vezes, me deixa chocado quando converso com alguns profissionais de empresas de software que desconhecem os desperdícios (muda, em japonês) ensinados no pensamento enxuto da Toyota. Ele está diretamente relacionado ao percentual de trabalho semanal que gastamos em atividades burocráticas e correções de falhas, pois não agregam qualquer tipo de valor ao produto final de nosso trabalho. É aquele tipo de trabalho pelo qual deveríamos desenvolver alguma alergia ou vergonha caso o praticássemos de forma sistemática em nossas empresas. Para mim, um trabalho mais nocivo que a atividade extraordinária, pois demonstra a falta de comprometimento da empresa com a qualidade do produto, do processo e satisfação do cliente. Para o modelo de gestão enxuta, ele deve ser totalmente eliminado!

Quanto você apostaria ser o desperdício semanal de sua equipe em atividades burocráticas e de retrabalho? Aqui podemos encontrar uma grande variação devido a natureza das equipes de desenvolvimento de software, mas você poderia pensar em exemplos relacionados a seis dos sete desperdícios identificados no modelo de gestão da Toyota: 1) percentual de não conformidades existentes em seu backlog de trabalho, 2) tempo gasto com excessos de produção (fazer além do necessário), 3) tempo gasto com o gerenciamento da informação (estoques dos excessos de produção), 4) tempo gasto com movimentações desnecessárias (layouts indevidos ou mudança de tarefas), 5) tempo gasto com o transporte de informações (atividades burocráticas) e 6) tempo gasto com esperas diversas (falta de sincronização dos membros da equipe). Você pode responder um valor em torno de 20%, 50% ou até mesmo 100% (já vi equipes totalmente dedicadas a correção de falhas, comprovando o total desperdício de seus profissionais devido a ineficácia de seu processo de desenvolvimento). Para você não desistir do resto da análise, pense na organização como um todo e faça uma estimativa ...

Para fins de cálculo, vou considerar os mesmos 30% das atividades extraordinárias, que é um valor otimista porém aceitável para os níveis de eficiência (excesso de atividades burocráticas) e eficácia (número de falhas a corrigir) de nossas empresas. Logo, das 28 horas de trabalho restantes do item anterior, subtrairemos 12 horas do desperdício da burocracia e do retrabalho, resultando em 16 horas disponíveis para você realmente agregar valor ao produto de software!

Será que é por isso que planejamos uma "margem de segurança" no final do cronograma de projeto? Até agora, você já pode multiplicar a duração estimada para seu projeto por um fator de 2,5 e ainda assim pode ser pouco para a realidade de sua equipe ...

Quer saber por que eu escrevi que esse tema me deixa chocado quando converso com alguns profissionais de outras empresas? Porque diversas vezes ouço afirmações do tipo:

• "Não existe software sem falhas ..."
• "Não tem problema se a equipe de desenvolvimento produzir falhas, nossa equipe de testes poderá detectá-las antes mesmo de entregarmos o produto para o cliente ..."
• "Temos uma equipe de manutenção dedicada somente à correção de falhas ..."
• "Todas as falhas detectadas na fase de testes são registradas e gerenciadas num sistema de controle de não conformidades, cujas correções serão planejadas a fim de serem incorporadas em releases futuros ..."
• "Toda essa burocracia é necessária devido ao nível de complexidade de nossa empresa ... "

Desperdícios das Ineficiências Operacionais (Muda Tipo I)

Este é outro assunto controverso, pois trata de todas as atividades que não agregam diretamente valor sobre o produto de software (funcionalidades percebidas pelo cliente), mas que não podem ser eliminadas do processo pois estão relacionadas a práticas de engenharia de produto, engenharia de sistemas, engenharia de software e gerência de projetos. Ele está diretamente relacionado a um dos sete desperdícios do pensamento enxuto que fala da necessidade de um processamento adicional devido às ineficiências operacionais de nossa organização. A família Poppendieck faz referência a este desperdício como sendo resultante de um déficit tecnológico, que também pode ser entendido como limitações na capacidade de processamento da equipe.

Costumo dizer que se não podemos nos livrar dessas práticas, pois elas são intrínsecas da natureza do nosso trabalho, devemos realizá-las no menor tempo possível, pois não resultam em produto de software potencialmente entregável ao cliente. Ou seja, quanto mais tempo eu me dedicar a estas atividades (perceba que os outros seis desperdícios ainda assombrarão este tipo de atividade), menos tempo eu terei para produzir o software desejado. Estas atividades podem ser tanto de apoio e gestão quanto de preparação de ambientes e investigação de novas tecnologias.

Por que este assunto é controverso? Vou dar alguns exemplos de atividades que geram desperdícios por ineficiência operacional e você tira suas conclusões:

• Captação e Análise de Requisitos - existem técnicas de comunicação humana que podem diminuir consideravelmente o tempo de realização dessas atividades;
• Especificação e Validação de Requisitos - existem padrões de documentação, baseados em arranjos logísticos da produção Just in Time (JIT), que podem triplicar a capacidade produtiva de uma equipe de software;
• Planejamento de Projeto - existem técnicas extremamente simples, baseadas no balanceamento da produção e na capacidade produtiva da equipe, que permitem estimar o tempo e o esforço necessários para a execução do projeto;
• Controle de Projeto - é possível desenvolver equipes autogerenciadas;
• Inspeção da Qualidade de Código - existem ferramentas de software que inspecionam de forma automatizada a qualidade do código fonte gerado por todos os membros da equipe;
• Testes de Unidade e de Sistema - existem ferramentas que automatizam a realização dos mais diferentes tipos de testes para comprovar tanto a eficácia quanto a eficiência de sua aplicação;
• Integração e Deployment - existem ferramentas que podem automatizar o "empacotamento e entrega" do produto de software em ambientes de produção complexos;
• Setups de Ambientes de Trabalho - existem ferramentas de análise, design, codificação, testes e implantação que permitem realizar de forma rápida e efetiva as atividades de desenvolvimento, manutenção e operação de software;
• E muitos outros exemplos!

Veja bem como é delicado definirmos um nível ótimo de esforço para esse tipo de atividade, pois a ausência ou o excesso das mesmas pode aumentar consideravelmente os riscos e a duração do projeto de software. Quanto você apostaria ser o desperdício semanal de sua equipe em atividades de apoio, gestão, preparação de ambientes e investigação de problemas e novas tecnologias? Aqui também podemos encontrar uma grande variação devido a natureza das equipes de desenvolvimento. Como nos restam dois dias de trabalho, segundo o saldo do item anterior, vou considerar 50% da disponibilidade produtiva remanescente (8 horas), representando 20% do tempo total gasto numa jornada semanal de trabalho.

Agregação de Valor

Por fim, concluimos a análise dos desperdícios com um percentual de nossa alocação semanal disponível para a produção e entrega do produto de software: 20% de nosso tempo (ou um dia de trabalho)! Mas que tipo de atividade realmente agrega valor ao produto de software? Aquela que, quanto mais fizermos com total qualidade, mais funcionalidades serão entregues na saída de nosso processo (sem a necessidade de retrabalho). Ou seja, a codificação do software em si e a produção dos testes automatizados necessários para a garantia da qualidade do que será agregado ao sistema.

Mas a criação dos testes agrega valor ao produto? Sim, pois dependendo da forma como você assume a elaboração dos testes, você estará fazendo simultaneamente a análise e o design daquilo que deve ser codificado (Test Driven Development, TDD), diminuindo consideravelmente tempo e esforço necessários na saída do processo (testes). Afinal, qual "gabarito" devo utilizar como referência para inspecionar e aprovar os componentes que pretendo integrar no produto de software? Se nossa equipe produzir continuamente componentes com falha zero, qual o valor agregado dos testes no final do processo?

Achou pouco tempo para desenvolver testes, componentes e funcionalidades? Se você fizer uma dinâmica com sua equipe de desenvolvimento e pedir para o grupo desenhar um mapa de fluxo de valor do cenário atual de sua organização, é bem possível que possa encontrar uma eficiência de processo (valor agregado) da ordem dos 10%. Organizações de alta maturidade relacionada ao pensamento enxuto costumam apresentar eficiências próximas a 50%.

Como sair deste cenário

Em sânscrito, a palavra "Samsara" é bem conhecida na maioria das tradições filosóficas da Índia (como o Hinduísmo, o Budismo e o Jainismo), e representa o fluxo incessante de renascimentos através dos mundos, mais especificamente, no mundo do sofrimento. No contexto de nosso ambiente de negócios, representaria o fluxo incessante de projetos de desenvolvimento e manutenção de software realizados com altos níveis de desperdício, principalmente de retrabalhos e burocracias que nada agregam ao produto desejado por nossos clientes.

O modelo de gestão enxuta (Lean) ensina métodos para a libertação desse tipo de sofrimento (desperdícios) e a conquista da felicidade mediante o desenvolvimento de equipes altamente eficientes e eficazes capazes de entregar um produto de software em pleno funcionamento, numa fração dos prazos convencionais de nossa indústria, e com uma qualidade inimaginável para nossos profissionais dos dias de hoje. A mágica está na busca contínua e incessante de melhores formas de fazer o trabalho diário, tendo sempre como foco a redução dos desperdícios. Só que, para isso, é necessário alocar um pouco do tempo escasso da jornada semanal de trabalho em atividades de desenvolvimento de competências e melhoria contínua, como a realização de grupos de Kaizen, por exemplo.

Assim como muitas filosofias orientais consideram ilusório procurar a felicidade em meio à ignorância, longe da prática da autodisciplina e do aperfeiçoamento pessoal, é ilusório acreditar que alcançaremos altos níveis de maturidade organizacional (não estou me referindo aqueles do CMMI ou MPS.BR) longe do desenvolvimento do ser humano, focando somente em ferramentas e processos. Decidir aumentar a produtividade com o aumento puro e simples do número de profissionais da equipe de desenvolvimento também é ilusório, pois acaba gerando retrabalho em diferentes aspectos e demandando ainda mais atividades de apoio e gestão, todas relacionadas a desperdícios no processo.

Aqui vão algumas dicas de por onde você pode começar o caminho da mudança e da conquista da verdadeira eficiência e eficácia do processo de software:

1. Negocie com os membros de sua equipe a alocação de, pelo menos, 1h de atividades semanais focadas em melhoria de produtos e processos, dentro do escopo das Atividades Extraordinárias (são somente 2% daquela fatia dos 30%);
2. Aprenda a enxergar os desperdícios de seu processo e a reconhecer as burocracias desnecessárias com a realização de workshops de Mapeamento de Fluxo de Valor (peça ajuda a algum profissional especializado);
3. Incentive a consolidação de uma cultura de qualidade total na equipe de desenvolvimento, começando pela redução periódica dos níveis de falhas detectados nos produtos entregues ao cliente;
4. Promova a análise periódica dos problemas, identificando suas causas raízes e os recursos que irão promover a conquista do cenário desejado (resolução dos problemas) - faça isso com a criação de grupos de Kaizen;
5. Adote novas tecnologias se as atuais dificultam a eliminação dos desperdícios e a melhoria do processo organizacional;
6. Acredite que sua equipe tem competência para trilhar este caminho caso conte com a ajuda de um orientador (coach ou sensei) capacitado.

Para concluir, apresento um diagrama que costumo incluir em meus cursos de capacitação profissional quando discuto os problemas que trato neste post. Ele mostra qual o foco dos ciclos de Kaizen na organização de software e como a redução dos desperdícios pode triplicar a capacidade de sua empresa.

Nota: Para quem tiver interesse, um excelente livro que trata da redução dos desperdícios segundo o modelo de gestão Toyota é Aprendendo a Enxergar, de Mike Rother e John Shook, 2000.