Um guia do programador para quebrar o código 'Duas vezes o trabalho, metade do tempo'

A gestão teórica está cheia de avós. Li obras de Deming, Goldratt, Ohno e Drucker. Já ouvi falar de Ackoff e Juran. Gostei da atitude humana e cuidadosa em todos os livros que li. Nunca foi: "Explorar as pessoas até a exaustão". Peter Drucker, em seu "Management Rev Ed", chegou a nos orientar, gestores do século XXI, no que devemos fazer:

A contribuição mais importante e verdadeiramente única da administração no século XX foi o aumento de cinquenta vezes na produtividade do trabalhador braçal na manufatura. A contribuição mais importante que a administração precisa fazer no século XXI é, da mesma forma, aumentar a produtividade do trabalho do conhecimento e do trabalhador do conhecimento.

Vinte anos no século 21, quão perto estamos de cumprir essa meta ambiciosa no mundo do desenvolvimento de software? Vejo que estamos longe disso. Vamos explorar onde estamos, quais problemas temos e o que podemos fazer a respeito deles.

Explorando a Abordagem Ampla para a Eficiência no Desenvolvimento de Software

“The Art of Doing Twice the Work in Half the Time” é o subtítulo do livro “ Scrum ” de Jeff Sutherland, co-autor deste framework. Eu gosto desse subtítulo, pois ele reflete fortemente o quanto podemos nos tornar mais eficientes em nossos esforços de programação. Nem tudo é sem nuvens, no entanto. O primeiro problema que encontramos aqui é que é difícil entender o que é eficiência em nosso trabalho. O seguinte problema complexo é entender se nos tornamos mais eficientes ao longo do tempo.

Mas por que queremos eficiência no final? Bem, trata-se de fazer a mesma coisa com menos esforço e, em muitas esferas da nossa vida, é ótimo ter os mesmos ou melhores resultados mais rapidamente ou por um preço menor.

Voltemos à nossa questão. Os praticantes do Scrum propõem pontos da história como uma medida de uma tarefa. Existe uma definição no site scrum.org :

Um Story Point é uma unidade de medida relativa, decidida e usada por equipes Scrum individuais, para fornecer estimativas relativas de esforço para concluir os requisitos.

Um ponto de história é uma magnitude de complexidade relacionada à tarefa de referência. Você e eu temos a sensação de quanto esforço nos custou para implementar essa tarefa não muito difícil. Se eu disser que o novo trabalho custará três pontos de história, digo que será três vezes mais difícil que o anterior. É o meu palpite, e quem sabe o quão difícil seria.

Vamos nos concentrar novamente na eficiência. Se entregarmos tarefas estimadas em 25 pontos de história neste sprint, estamos melhores do que no sprint anterior quando tínhamos apenas 15? Ou talvez tenhamos sido mais cuidadosos e demos estimativas mais altas para o mesmo esforço? Mas como podemos comparar? Não fazemos trabalho repetitivo em engenharia de software em escala de fábrica. Desenhamos e implementamos fábricas de informação que prestam serviços. Existe lugar para conversas sobre eficiência em nosso setor?

Há um lugar para essas conversas. Pelo menos, podemos desacelerar as coisas intencionalmente. Por exemplo, podemos procrastinar ou pular de uma tarefa para outra. Se podemos fazer algo menos eficiente, há esperança para o contrário. No entanto, não vejo os pontos da história como um instrumento de medição útil aqui. Eles podem facilmente se tornar abusados intencionalmente ou não. Precisamos buscar algo melhor.

Definindo o Objeto de Medição

Antes de definir a forma de aumentar a velocidade do nosso esforço de programação, precisamos determinar qual é esse esforço que queremos medir. Não vejo nada que possamos usar em toda a indústria, mas o lado positivo é que não precisamos dessa amplitude para melhorar a eficiência. A necessidade é de algo que descreva uma etapa de trabalho significativa no desenvolvimento de seu produto de programação. Podemos usar épicos, tarefas, recursos ou qualquer outra coisa que represente o ajuste positivo do sistema em desenvolvimento.

No meu local atual, usamos três níveis diferentes:

 User-valuable feature: ⎿ Its slice for the engineering team's convenience: ⎿ The specific task inside a slice (eg, back-end task).

Precisamos que o ajuste tenha as seguintes características:

1. Tem a hora de início e a hora de conclusão;
2. Ocorre regularmente.

Então, o que definimos aqui é "essa grande obra". Vamos nomeá-la a ação na parte conseqüente do artigo. Nem todas as ações são iguais. Demonstrei três tipos no exemplo acima.

Precisamos que a ação ocorra regularmente.

Esse requisito vem do fato de que você não pode ser eficiente desde o início, mas pode se tornar mais eficiente com o tempo. Não é a desvantagem da abordagem descrita. O Scrum funciona assim, o Toyota Production System funciona assim e a ciência funciona assim. Exigimos repetibilidade para descobrir o estado atual e melhorá-lo consistentemente.

Você pode fazer qualquer coisa nova com eficiência otimizada apenas por acaso. E quanto mais complexa a ação, menos possível ela seria. A preparação antecipada pode ajudar. No entanto, a capacidade de se preparar com antecedência significa que a ação ou suas subações ocorreram no passado e há conhecimento sobre elas. Não há nada para se preparar para algo completamente novo. Por outro lado, dificilmente encontramos uma novidade completa em nossa vida. Uma fração da experiência anterior é sempre relevante para as situações nunca vividas.

Em suma, temos uma espécie de ação como essência a medir.

Como medir uma ação de um tipo?

À primeira vista, a seção anterior não acrescenta nada. Nós fazemos algumas ações de um tipo. Como é melhor do que tarefas medidas com pontos de história, tamanhos de camisetas ou animais? Um nome não é um ganho único. A ação de um tipo tem dois timestamps e podemos medir sua duração subtraindo o início da conclusão. A duração é um excelente ganho aqui, pois é nossa chave para a linguagem da realidade cotidiana.

• Quanto tempo leva para completar um épico?
• Levamos 39 dias desde o início até a conclusão.

Maravilhoso.

Existe algo mais que ganhamos?

O segundo requisito para nossa ação, a ocorrência regular, nos dá tanto que é difícil acreditar. Em primeiro lugar, ganhamos um tipo de fluxo de ações. Aqui está uma definição de fluxo do livro "Actionable Agile Metrics for Predictability " de Daniel Vacanti:

Simplificando, o fluxo é o movimento e a entrega de valor ao cliente por meio de um processo.

Nosso requisito para dois timestamps, o início e o término de uma ação, nos dá um bom conjunto de novas métricas. Aqui estão eles do mesmo livro:

Work In Progress (o número de itens nos quais estamos trabalhando em um determinado momento), Cycle Time (quanto tempo leva para cada um desses itens passar pelo nosso processo) e Throughput (quantos desses itens são concluídos por unidade de tempo ).

Posso intrigá-lo se achar que é tudo o que temos aqui. Estamos bem no começo. Outro tesouro que o fluxo nos dá é o rastro que ele deixa com o passar do tempo. Este traço nos permite entender melhor o sistema. Podemos capturá-lo usando vários diagramas. Um deles é o gráfico de dispersão do tempo de ciclo.

O deleite vem do fato de captar "como fazemos as coisas aqui". Não requer nada do seu processo, nenhuma metodologia particular. Você deseja capturar o fluxo de escovação dos dentes usando o gráfico de dispersão do tempo de ciclo? Apenas faça. Você quer o mesmo para as casas construídas em sua área? Absolutamente bem. Deseja acompanhar o ciclo de vida do desenvolvimento, incluindo os experimentos A/B feitos após o desenvolvimento de novos recursos? Por favor, comece e faça.

Na imagem, você também pode ver as linhas de percentis assinadas com 50%, 70%, 85% e 95% à direita. O que eles querem dizer? No lado esquerdo, há dias. Você pode ler os 85% e 16 dias da seguinte maneira:

Para 85% dos itens que entraram em nosso sistema no período analisado, demorou 16 dias ou menos para sair.

É a segunda vez que uso a palavra "sistema" nesta seção. O que isso significa? Vamos defini-lo da seguinte forma para esta história:

Sistema é algo fazendo ações de um tipo.

Uma ação desse tipo no exemplo do sistema de construção de casas acima é construir uma casa. Fazer um quilômetro de estrada não conta como uma ação aqui. É um tipo diferente de ação e outro sistema. No entanto, não há divisão concreta, mas queremos que nossas casas sejam iguais, assim como a escovação dos dentes e o desenvolvimento de software com testes A/B. Para algo diferente o suficiente, podemos criar outro sistema.

Mais um ganho importante

É hora de discutir mais um efeito que nos ajudaria a garantir a precisão de nossos esforços de aprimoramento. Imagine que você tem uma equipe e precisa criar um novo software. Você considera as histórias do usuário como uma medida de progresso, como uma ação. Depois de completar sua primeira história, é hora de fazer a retrospectiva para ver onde poderíamos melhorar na próxima vez.

Existe algo nessa lógica que nos leva a uma armadilha? Vamos dar uma olhada mais de perto.

Durante a implementação da primeira história do usuário, o principal obstáculo foi concordar com as bibliotecas necessárias e instalar o software necessário. Demorou algum tempo, e foi uma verdadeira dor. Durante a retrospectiva, a equipe discutiu como foi doloroso e como podemos ser melhores da próxima vez. A falha bastante óbvia é que, da próxima vez, dificilmente você precisará concordar com as bibliotecas e instalar o software. As bibliotecas costumam permanecer por muito tempo. A instalação do software faria parte da integração de novos membros, mas não incomodaria a equipe já estabelecida em sua segunda história de usuário. É diferente o suficiente e agora pode se tornar parte do sistema de integração.

Vamos dar uma olhada na seguinte sabedoria de programação de Donald Knuth ( ou Tony Hoare ):

Otimização prematura é a raiz de todo o mal.

Acho que você já conhece este, que diz para você não pensar no desempenho nos estágios iniciais do desenvolvimento de software. Você pode ter visto essa sabedoria na seguinte forma:

Faça funcionar, faça certo, faça rápido.

O exemplo sobre a instalação de bibliotecas mostra que o ditado é relevante para o código e também para a equipe de codificação! Que mistério encontramos aqui! Não é um mistério, mas o atributo de um sistema. Há pelo menos duas razões pelas quais devemos evitar pular direto para os aprimoramentos após a primeira tentativa.

Razão estatística para não pular imediatamente para o aprimoramento

Cada ação completa de um tipo tem sua duração. A duração consiste em duas partes: uma causada por motivos comuns e outra causada por motivos especiais.

Vamos nos referir ao exemplo da escovação dos dentes mais uma vez. Normalmente, revestir a escova de dentes com pasta de dente leva alguns segundos. Em casos especiais, é preciso tirar a pasta de dente do armário, abri-la e utilizá-la. Aqui toda a ação leva vários minutos. Se, por qualquer motivo, precisarmos pensar na eficiência da subação do revestimento da escova de dentes na escovação dos dentes, fazê-lo após a inicial seria enganoso. A ação inicial contém uma parte extra e difere da ação típica que queremos acelerar.

A natureza de ser especial leva ao aparecimento inconsistente das razões especiais de duração. O que sempre se mostra é o cerne da nossa ação, o alvo frutífero de nossas melhorias.

Razão da teoria das restrições para não pular imediatamente para o aprimoramento

O que a teoria das restrições nos diz? Ela nos diz que o todo produzindo algo será tão produtivo quanto sua parte menos produtiva. Imagine que temos uma empresa construindo pequenas casas de um andar. Nossas capacidades anuais são as seguintes:

• 6 porões,
• 24 conjuntos de paredes,
• 52 telhados.

Quantas casas podemos construir por ano? Você pode responder seis, mas sugiro dizer não mais que seis. Nosso processo construtivo é um processo consequente: porão → paredes → telhado. Terminar a última e sexta casa pode ficar para trás no final do ano.

Se aumentarmos o número de paredes que levantamos ou telhados que construímos, isso mudará a capacidade de toda a nossa empresa? Vamos produzir mais do que o mencionado "não mais que seis"? Não, o porão ainda nos limita.

Os números de capacidade acima vêm da experiência desta empresa superficial. Não temos essa experiência depois de implementar a primeira história do usuário. Ainda temos que determinar a restrição de nosso sistema de criação de histórias de usuários, pois não sabemos quanto tempo dura cada subação. Considere a garantia de qualidade como parte de nosso processo de desenvolvimento de histórias de usuários. O teste de uma história de usuário dura quatro horas. O desenvolvimento de uma história de usuário dura cinco dias úteis em geral. Digamos que haja 250 dias úteis em um ano. Você espera ter 50 histórias de usuário completas ou 730? Tal como acontece com as casas e caves, no máximo 50 por ano. Precisamos coletar estatísticas para entender a forma de nossa ação e sua parte menos produtiva.

Quantas ações completas são suficientes para iniciar as melhorias?

Para ter certeza, sugiro ter o número ∞ de ações completas neste ponto. Depois de obter esse número exato, você pode ter 100% de certeza do que aprimorar primeiro.🥁

Para aqueles que estão fora do mundo da matemática pura, vamos considerar os seguintes pensamentos. Aqui está uma referência do livro "Actionable Agile Metrics for Predictability " referente ao livro " How to Measure Anything ":

Por exemplo, Douglas Hubbard (cujo livro "How to Measure Anything" está listado na Bibliografia) aconselha seus clientes sobre sua " Regra dos Cinco ": Regra dos Cinco – Há 93,75% de chance de que a mediana de uma população esteja entre os valores menores e maiores em qualquer amostra aleatória de cinco dessa população.

Por favor, não veja isso como um tabu para mudar algo nas primeiras cinco ações. Considere também outros aspectos: segurança da saúde, coesão da equipe e muito mais.

Por onde começar o aprimoramento?

Se fizermos a ação elementar, por exemplo, ligar a TV pressionando um botão, podemos pensar nela como um todo. Para reduzir o número de movimentos e o tempo total, compre um clicker e mantenha-o em um lugar próximo ao seu sofá. Neste exemplo, a primeira ação pode levar cerca de 20 segundos e a segunda... um segundo. Meus parabéns! Você reduziu 95% do tempo exigido anteriormente e ainda recebe o mesmo valor. Que eliminação de resíduos fantástica!

Nem todas as ações são tão diretas. O já mencionado desenvolvimento de user stories é complexo. É um desafio lidar com a melhoria ali em um salto. Precisamos dividir as coisas em subações, como no exemplo da construção de casas. Podemos começar com o seguinte ciclo de vida:

1. Análise,
2. Desenvolvimento,
3. teste,
4. Feito.

Onde começar?

Na manufatura enxuta, o processo de criação, ou ação conforme nomeado neste artigo, consiste em subações de três tipos:

• Atividades de valor agregado;
• Atividades necessárias sem valor agregado;
• Desperdício.

Formular a história do usuário, projetar uma solução e codificá-la são atividades de valor agregado. O uso da ramificação do git durante o desenvolvimento pode ser considerado uma atividade necessária sem valor agregado. Não acrescenta nada a esta mudança mas organiza todo o processo. O desperdício impede a acumulação de valor por um tempo sem um bom motivo. Esperar pelo banco de dados que não funciona é um desperdício.

Na manufatura enxuta, os desperdícios (ou muda ) são conhecidos e definidos pelo criador do Sistema Toyota de Produção, Taiichi Ohno. Pelo menos eles são definidos para a empresa Toyota, fabricante de carros. Outras indústrias têm suas variantes. Aqui está o nosso, criado por Mary e Tom Poppendiecks no livro " Lean Software Development ":

1. Trabalho parcialmente feito,
2. processos extras,
3. Recursos extras,
4. Troca de tarefas,
5. Espera,
6. Movimento,
7. Defeitos.

Ou estes? Do livro " Implementing Lean Software Development " dos mesmos autores:

1. Trabalho parcialmente feito,
2. Recursos extras,
3. Reaprendendo,
4. Transferências desnecessárias,
5. Troca de tarefas,
6. atrasos,
7. Defeitos.

Pelo menos os engenheiros de software podem se mover agora!😅

Como esses pilares podem ter mudado tanto em apenas alguns anos em nossa indústria? Vejo a resposta na impossibilidade de ter uma lista suficiente de desperdícios para todos os tempos. Até a Toyota, em algum momento, surgiu com o oitavo desperdício.

É ótimo que a lista de nossa indústria tenha mudado tão radicalmente. Essa mudança abre nossas mentes para reconsiderar nossos pensamentos sobre o que é desperdício continuamente. Aqui está mais uma visão sobre o que pode ser uma parte inútil do desenvolvimento de software:

Um dos maiores mal-entendidos no mundo do software é o valor do código. Mas o código é uma responsabilidade, como diremos repetidamente neste livro. Quanto mais código escrevemos, mais complexidade e risco geramos para nós mesmos.

É uma citação de " The Value Flywheel Effect " de David Anderson com Mark McCann e Michael O'Reilly. Ufa, que passeio!

Então, como começamos? Olhando para a subação menos produtiva. O que buscamos? Subações que não agregam valor.

Reconsiderando o fluxo de trabalho de desenvolvimento de histórias de usuários

Deixe-me lembrá-lo do fluxo de trabalho que tínhamos:

1. Análise,
2. Desenvolvimento,
3. teste,
4. Feito.

Normalmente, são peças feitas por pessoas diferentes, e sempre há algum tempo para aguardar a entrega. Vamos documentar:

1. Análise ativa,
2. Análise feita,
3. Desenvolvimento Ativo,
4. Desenvolvimento feito,
5. teste,
6. Feito.

Eu não inventei essas etapas. Eu os tirei da demonstração do produto ActionableAgile Analytics . Podemos confiar neles? Direi que sim, pois vi diferentes exemplos de dados reais, e este parece próximo. Vamos investigar as estatísticas das etapas seguintes. Demonstra as médias.

O tempo de ciclo do sistema é de 9,37 dias. Essa afirmação significa que uma tarefa chega no estágio Analysis Active , passa por todos os próximos e sai do Testing for Done e, em média, esse caminho leva 9,37 dias. Etapas com "Ativo" em seu nome parecem trazer utilidade para o resultado, bem como para Testes . Etapas que terminam com "Concluído" são filas, espera e nada de útil. Se os marcarmos adequadamente usando o diagrama de Eficiência de Fluxo, veremos que, em média, apenas 40% do tempo gasto em uma única história de usuário é valioso.

Neste diagrama, também incluímos o tempo bloqueado rastreado e as tarefas estranhas, que passaram todo o seu tempo nos estágios "Concluído". Se os excluirmos, a eficiência de fluxo para este exemplo de demonstração seria de cerca de 50%.

Lidando com a perda de tempo descoberta

Como temos muito pouca informação sobre o conjunto de dados demonstrativo, não haverá recomendações específicas como: "Dê computadores melhores à Equipe E". No entanto, haveria pensamentos suficientes para inspirar os seus próprios no seu caso. A parte menos produtiva do nosso processo é a etapa de análise concluída . Não podemos nem chamá-lo assim, pois descreve a espera. No entanto, leva quase 29% de cada tarefa. Qual poderia ser a razão aqui?

A fase de desenvolvimento ativo não parece lenta, exigindo menos tempo para ser concluída do que a parte de análise ativa. Observando o WIP médio, destacaremos o problema: o departamento de análise pode lidar com mais histórias de usuários simultaneamente.

Equilibrar isso, por exemplo, trazendo mais desenvolvedores para a equipe, pode ser uma solução possível. No entanto, não seja muito apressado aqui. A razão pode ser bem diferente. O estágio Análise Concluída pode conter o trabalho secreto. Pode ser que os desenvolvedores não estejam satisfeitos com a qualidade dos requisitos, mas não consigam resolver esse problema sistematicamente e gastem tempo durante esse estágio para aprimorá-los. Para descobrir as condições de limite, propor a manipulação da interface do usuário das solicitações assíncronas e muito mais.

Antes de propor a solução, aplique a análise de causa raiz: use cinco porquês , espinha de peixe ou qualquer outra coisa.

Verificando o Sucesso da Mudança Aplicada

Digamos que abordamos o problema da seção anterior. Como podemos ter certeza de que a mudança proposta funcionou? Precisamos acumular dados mais uma vez. Você se lembra da Regra dos Cinco acima? Podemos usar aqui também. Nosso sistema agora está ajustado. Vamos medir novamente.

Em meu trabalho, utilizo duas ferramentas para medir os resultados do experimento:

1. Diagrama de fluxo cumulativo,
2. A linha de tendência no diagrama de dispersão do tempo de ciclo.

Você vê a área ciano da análise concluída ? Espere que pelo menos fique mais fino com o passar do tempo e, no máximo, desapareça.

Observe a linha tracejada verde que aparece neste diagrama já familiar. Ele mostra a tendência de tempo de ciclo de 85% nos últimos N dias. Eu uso 30 em vez de N, pois é estável o suficiente para demonstrar as mudanças. Se a solução descoberta lidar com a causa raiz profunda o suficiente, espere que essa linha diminua ≈30% até 11 dias.

Se não houver alterações significativas nos dados, é hora de procurar outras soluções.

Os próximos passos

O próximo ponto óbvio para melhoria é o estágio de Desenvolvimento Concluído . Vamos imaginar que também lidamos com isso. Reduzimos 50% do tempo necessário inicialmente para concluir a história do usuário. No entanto, o título da história promete produtividade quadruplicada. Neste caso, podemos começar pensando na fase de Análise Ativa . Então tente paralelizar o Testing com ele e o Development Active .

No entanto, não tenho certeza de que seja necessário aqui. Imagine usar um software que recebe novos recursos a cada dois dias. O mercado pode não estar preparado para isso. O mercado torna-se uma restrição para o nosso sistema. Essa descoberta não significa que estamos sempre tão limitados em nossas melhorias. Normalmente, temos vários sistemas de desenvolvimento criando valor, e nossas funcionalidades levam mais de nove dias. Na minha experiência, a visão do pássaro sobre os itens com duração de seis meses descobriu apenas 30% do tempo de agregação de valor. A imagem mais detalhada das tarefas dentro dos 30% demonstrou novamente os exatos 30% do tempo de valor agregado. Descobriu-se que, durante os 180 dias, houve apenas 16 dias de atividade com valor agregado. Um potencial de melhoria de 11 vezes é visível.

A abordagem em resumo

Perguntas válidas

Eu sinto que a abordagem descrita tem um alto potencial em fazer a gestão da contribuição do século XX que passou por nós. Quando conto a alguém sobre o método, geralmente me deparo com várias perguntas:

1. Isso não destruirá a alegria de programar?

2. O desenvolvimento de software é tão imprevisível e tão criativo. Como podemos falar em trabalhar em sua eficiência?!

   
   

A proposta não vai destruir a alegria da programação. Você deve ter notado que trabalhamos para eliminar os buracos no processo em que nada acontecia. Poder assumir a tarefa recém-criada é tão prazeroso quanto fazê-la dois dias depois. Outra alegria vem de olhar para o seu código como o sistema em mudança e sua equipe como a mesma. Você tem uma nova terra de ferramentas de programação e abordagens abertas.

Por que você precisaria anteriormente de ferramentas de programação mob online? Para se tornar mais rápido? Mas o que era mais rápido naquela época? Por que você precisaria do estágio explícito de design de software? Ah! Nossa equipe de desenvolvimento está sobrecarregada com bugs, e é por isso que as histórias de usuários esperam até 30% de seu ciclo de vida para que os desenvolvedores corrijam os bugs. Por que não os prevenimos?

O que mata a alegria de programar é a necessidade regular de cortar sua carne para completar as tarefas. Ser capacitado com melhores métodos, ferramentas e conhecimento não mata a alegria.

Sim, a criação de desenvolvimento de software é realmente imprevisível e não rotineira. No entanto, é infinitamente imprevisível? Um ano seria suficiente para concluir qualquer uma das tarefas que estão olhando para você em sua lista de pendências? Que tal dez anos? A natureza de sua variação é tão elusiva que não podemos fazer nada a respeito? A existência do diagrama de dispersão de tempo de ciclo nos mostra que há um limite para a variação do desenvolvimento de software. Você pode apontar que algumas tarefas requerem uma correção rápida da constante textual, enquanto outras requerem vários dias de investigação. Eu concordo com isso, mas também pergunto: "A existência dessas tarefas é resultado da natureza inevitável do software ou é resultado da arquitetura de software que você usa? A grande bola de lama nos processos não é a razão para tanta confusão?"

A necessidade de um fluxo de desenvolvimento mais suave não é, finalmente, um motivo infalível para lidar com suas dívidas técnicas, arquitetônicas e processuais?

Sim, mesmo na arquitetura mais amigável à mudança, apareceriam perguntas difíceis que exigiriam mais tempo do que gostaríamos que precisassem. E já temos o local no diagrama de dispersão do tempo de ciclo acima da linha do percentil 95 para lidar com eles. Mas são exceções, e não queremos que tudo se torne exceção.

Nós, gerentes, não devemos fazer o combate a incêndios, mas sim trabalhar no design de nossos sistemas e suas variações.

Evitando as etapas óbvias e erradas

Não sou a primeira pessoa a buscar eficiência em nosso setor. Alguns dos buscadores acham que já estão familiarizados com o assunto. A abordagem deles é instalar o software de rastreamento nos computadores de seus empregadores e punir aqueles que fazem algo tratado como não trabalho. Este método mostra o completo desconhecimento das fontes de eficiência do desenvolvimento de software. A ideia de grande sucesso resultante de grande tensão não é apenas pobre. É mortal. Limita nosso olhar para nossos sistemas em apenas uma dimensão: trabalhando duro o suficiente ou não o suficiente. Sua experiência pessoal fornece exemplos suficientes de pessoas esgotadas. A história nos mostra que os países caíram nessa armadilha com muitas baixas. Não, trabalhar duro não é o caminho para a melhoria contínua. Mas o que é isso?

Descobrindo um lugar para começar

Mais de um século atrás, Frederick Taylor iniciou seu trabalho no que hoje conhecemos como administração científica. Ele olhou para seus colegas e procurou os métodos mais eficientes para eles fazerem seu trabalho:

Taylor decidiu descobrir, por métodos científicos, quanto tempo levaria os homens para realizar cada trabalho; e foi no outono de 1882 que ele começou a colocar em operação os primeiros recursos da administração científica.

Não conheço a estrutura do negócio em que Taylor estava trabalhando naquela época. Pode ser que sua etapa de produção esteja entre outras, o que também pode significar que Taylor foi pego na armadilha da subotimização local. É sobre aumentar o número de telhados que nossa empresa imaginária de construção de casas pode manusear. A influência da descoberta de Taylor não diminui, mesmo que fosse esse o caso. Agora sabemos o perigo dessa armadilha e podemos agir de forma mais inteligente.

Você se lembra do meu exemplo com itens que duram seis meses ou 180 dias? Se eu eliminar com sucesso a perda de tempo nos itens internos onde os engenheiros trabalham, economizarei 38 dias e sobrarei 142 dias para um item grande. Se eu fizer o mesmo para o exterior onde toda a equipe trabalha, vou economizar 126 dias e ter 54 dias para o mesmo item grande. Torturar desenvolvedores com horas extras e camas no escritório não faz sentido se você quiser ganhar muito. Veja o processo de entrega de valor do ponto de vista do pássaro e só vá mais fundo quando estiver fora do espaço para melhorias neste nível.