Assim como uma refatoração grande, reescrever um software não é algo simples. Após vários anos, adquirimos experiência suficiente para indicar o que você deve considerar ao planejar e executar um processo para reescrever software.

1. As duas plataformas existirão juntas por um determinado período ou não?

Você planeja manter a versão de legado e a nova versão em produção? Caso positivo, por quanto tempo? Você deve evitar manter duas versões em produção por muito tempo devido aos custos operacionais e de oportunidade.

2. Quem trabalhará na reescrita do código e quem trabalhará na versão do legado?

Geralmente, os desenvolvedores preferem trabalhar em projetos greenfield. Você deve considerar isto ao planejar quem trabalhará na versão do legado e quem trabalhará na nova.

3. É inviável reescrever todas as funcionalidades ao mesmo tempo

Mapear cada funcionalidade entre a versão do legado e a nova é inviável. Dito isto, que funcionalidades devem ser as primeiras a serem reescritas?

Leve em consideração como os clientes atuais serão afetados por um produto com menos funcionalidades.

4. Reescrever o software diminuirá ou interromperá o lançamento de novas funcionalidades na versão do legado

É provável que você não lance novos recursos na versão legada durante o processo de reescrita do código. Assim como os usuários finais, os clientes internos (comercial, produtos, financeiro) não terão novas funcionalidades. Seus clientes internos e outras partes interessadas vão pressioná-lo para entregar novas funcionalidades.

Certifique-se que a comunicação antes e durante o processo de reescrita do software seja clara e que cada stakeholder esteja alinhado com as metas.

5. O processo deve ser secreto ou público?

Imagine que você é um cliente potencial de um produto de software. Você planeja comprá-lo, mas descobriu que uma versão completamente nova será lançada em três meses. Você compraria a versão do legado ou esperaria por três meses? Multiplique isso por dezenas ou centenas de potenciais compradores. O fornecedor pode perder muito dinheiro.

Por isso, se você é o fornecedor, deve pensar cuidadosamente sobre como e quando divulgar o lançamento da nova versão.

6. Migração de dados

O processo de reescrever um software não envolve apenas o desenvolvimento de funcionalidades. Você também precisa planejar a migração de dados. As pessoas costumam subestimar a complexidade e o esforço necessários para migrar dados da versão do legado para a nova versão. Essa atividade não deve ser apenas mais uma tarefa em seu quadro, chamado “migração de dados”. É muito maior que isso.

Por exemplo, imagine que você precisa migrar as contas de seus usuários. Se a sua versão de legado é gerenciada por um terceiro, é provável que você não tenha acesso às senhas criptografadas dos usuários, portanto, não será possível migrá-las. Você terá de solicitar a cada usuário para redefinir a senha na nova versão. Isso também faz parte do processo de migração de dados.

7. Prepare-se para uma possível redução nas taxas de conversão

Você lançará uma nova versão com menos recursos. Quem garante que as taxas de conversão permanecerão as mesmas? As taxas de conversão são essenciais em algumas indústrias, como no e-commerce.

Preferencialmente, você deve manter o suporte à versão legada e à nova por um tempo para que, no caso de redução drástica nas taxas de conversão, você tenha um plano de backup.

8. Planeje treinamento para os usuários internos

Este é outro ponto negligenciado. O plano de reescrever o software precisa ter uma fase de treinamento de usuários internos antes de disponibilizar seu novo produto em produção. Não subestime a importância deste item. Pode demorar algum tempo, pois seus usuários internos darão feedback sobre pontos que talvez precisem ser alterados.

Usuários internos podem ser encontrados em várias áreas, como help desk e vendas.

Leia os outros posts da série Baixa Qualidade Interna de Software

1. Sintomas da Baixa Qualidade Interna de Software
2. 9 Pontos-chaves ao se fazer uma refatoração grande de software
3. 8 pontos-chaves para reescrever um software você está lendo

The post 8 pontos-chave para reescrever um software first appeared on Plataformatec Blog.

Realizar uma refatoração grande¹ de software não é algo simples. Há muitos pontos que você deve considerar, desde o planejamento e priorização até a motivação e execução da equipe. Entender esses pontos de forma estruturada e clara faz parte do processo. A boa notícia é que já passamos por essa situação antes e aprendemos quais os pontos principais com os quais você deve se preocupar.

Aqui estão os pontos principais que você deve considerar ao planejar e executar uma refatoração grande do seu sistema.

1. Defina metas de negócios

Uma refatoração grande de software não deve ser iniciada sem metas de negócios claras, caso contrário, você pode sofrer com a falta de comprometimento das partes interessadas. Aqui estão alguns exemplos de metas:

• O objetivo da refatoração é possibilitar a conexão de vários gateways de pagamento.
• O objetivo da refatoração é melhorar a velocidade de entrega.
• O objetivo da refatoração é viabilizar uma arquitetura multi-tenant para simplificar operações de infraestrutura.

2. Faça a medição do progresso

Em sua essência, o processo de refatoração de software é um esforço técnico, razão pela qual é comum não medir o progresso de forma estruturada, como é medido o progresso do desenvolvimento de novas features. Não caia nessa armadilha.

Assim como cada tarefa em um projeto, uma refatoração deve sempre ser planejada e medida.

3. Preste atenção à motivação da sua equipe

Trabalhar em base de código legado pode desmotivar os desenvolvedores, especialmente se não conseguem visualizar o progresso de suas atividades, ou se não sabem quando vão acabar. Ao passar por um processo de refatoração, você deve ter isso em mente.

Mostre à sua equipe que estão avançando. Planeje pequenas entregas, para viabilizar liberações contínuas e celebrar o bom trabalho feito. Além disso, pense em rotacionar os desenvolvedores para essa tarefa de refatoração, pois pode ajudar a manter a motivação.

4. Defina sua abordagem: puxada ou empurrada?

Você vai melhorar a base de código apenas quando encontrar um problema, ou escolherá de forma proativa as partes a melhorar?

Clique aqui para assistir o webinar Migração de Plataforma Tecnológica. É grátis!

5. Priorização

Se você tem uma meta de negócios clara, é mais fácil escolher proativamente as partes que precisam ser melhoradas para alcançar a meta. Com as partes listadas, você pode priorizar, como de costume.

Por outro lado, se você imagina que a base de código inteira deve ser refatorada, priorizar torna-se complicado, porque não há uma ou duas partes principais que precisam de melhorias, há muitas. É difícil saber por onde começar.

Uma solução é pedir ao time para avaliar a complexidade e churn do código para apontar as partes a refatorar. Para chegar numa conclusão se o código deve ou não ser refatorado, eles tem de se perguntar:

• A complexidade dessa classe é muito alta comparada às outras?
• Precisamos fazer mudanças constantes nesse arquivo?

Se ambas as respostas forem sim, essa parte do código parece um bom candidato para refatoração. Trace um gráfico de “complexidade de classe X churn”, priorize as partes que são mais complexas e que passam por alterações com frequência.

As partes do código que tem complexidade alta e que sofrem poucas modificações não são boas candidatas para serem refatoradas. Isso porque apesar de feias, funcionam. E também tem pouco impacto no desenvolvimento, já que a os desenvolvedores precisam modificá-las pouco no seu dia a dia.

6. Defina o “pronto”

O processo de refatoração de software pode se transformar em esforço infinito se você não planejar, priorizar e medir o progresso. Você deve tratá-lo como um projeto. Deve ter começo, meio e fim.

7. Cobertura da suíte de testes

A refatoração deve melhorar o que já está funcionando, sem quebrar nada. Certifique-se que a cobertura de testes está adequada, caso contrário, o processo pode gerar mais bugs do que melhorias de qualidade.

8. Desempenho da suíte de testes

Se a suíte de testes é lenta, refatorar também se tornará um processo lento, visto que a refatoração de software é fortemente baseada na execução contínua dos testes. Assegure que o desempenho da suíte de testes não seja um gargalo.

9. Compromisso dos patrocinadores

O processo de refatoração pode levar muito tempo: semanas, meses. Durante esse período, a velocidade das entregas de novas features será comprometida.

Certifique-se que stakeholders das áreas de negócio entendam os objetivos e a natureza desse tipo de trabalho para evitar que eles desistam no meio do caminho.

E você tem alguma dica além dessas para grande refatoração de software? Compartilhe conosco!

Leia os outros posts da série Baixa Qualidade Interna de Software

1. Sintomas da Baixa Qualidade Interna de Software
2. 9 Pontos-chaves ao se fazer uma refatoração grande de software você está lendo
3. 8 pontos-chaves para reescrever um software

The post 9 Pontos-chaves ao se fazer uma refatoração grande de software first appeared on Plataformatec Blog.

Um dos desafios mais comuns que você vai encarar na sua carreira, ou até mesmo em sua vida, é escolher entre uma coisa e outra. Pode ser a decisão entre ir ao restaurante japonês ou pizzaria, um projeto de 2 meses que custe $1M ou um projeto de 10 dias que custe $10k. O fato é: nós gastamos muito tempo decidindo o melhor caminho a ser seguido.

source: [xkcd](http://xkcd.com/1445/)

O que é Custo de Atraso

Custo de Atraso (Cost of Delay ou CoD em inglês) é o impacto econômico do atraso de um projeto. Em outras palavras, é quanto você deixa de ganhar se o produto, ou feature, não estiver pronto em uma certa data. O benefício do cálculo é proporcionar mais informações para tomada de decisão, do ponto de vista econômico-financeiro.

Como calcular CoD?

Para calcular o CoD você pode simplesmente estimar quanto de lucro seria esperado do projeto depois de um certo período de tempo.

Digamos que você espera que o projeto que está desenvolvendo, quando terminado, dê de retorno à empresa algo em torno de $10.000 por semana. Nesse contexto, o CoD é $10.000 / semana. Isto é, cada semana que o projeto atrasa a empresa “perde” $10.000. Não parece bom, né?

Outra métrica relacionada ao CoD é o CD3 (Custo de Atraso dividido pela duração, do inglês Cost of Delay Divided by Duration). A diferença entre ambos é que o CD3 é o CoD dividido pela duração do projeto. Essa é uma boa métrica para priorização. Você pode calculá-la da seguinte maneira:

• Calcule o lucro semanal (ou mensal) esperado do projeto (CoD);
• Calcule, aproximadamente, quanto tempo demorará para implementá-lo;
• Divida o lucro pelo tempo estimado de duração do projeto.

Quanto maior o CD3, mais importante o projeto é, já que o retorno sobre o investimento seria mais rápido.

Planilha para calcular probabilidade de data de término de projetos
BAIXAR PLANILHA GRÁTIS

Tipos de CoD

Curva Padrão

Em curvas padrões, o CoD do projeto aumenta quase linearmente com o tempo. Este é o jeito mais simples de calcular o CoD, já que não muda com o tempo.

Curva Urgente

Em curvas urgentes, o projeto precisa ser entregue rápido para gerar valor para empresa, caso contrário perde-se muito. Isso acontece, por exemplo, quando um competidor lança um produto similar e não há tempo suficiente para reagir e competir no mercado. Provavelmente, o CoD será muito alto, começando na semana da entrega do projeto, aumentando pouco com o tempo.

Curva de Data Fixa

Curvas de data fixa são o clássico exemplo de projetos com deadlines imutáveis. Nesses casos, o CoD está altamente ligado à uma data específica. O exemplo mencionado na curva urgente também é válido aqui. Outro exemplo seria um comercial de TV marcado para uma certa data, ou uma nova lei que afetará o projeto. O CoD será um pouco mais complexo. Nas primeiras semanas o CoD cresceria em ritmo moderado. Após certa semana, o custo receberia um grande impulso, depois retornaria ao crescimento moderado.

Curva Intangível

A curva intangível cobre os projetos que têm baixo CoD. Geralmente, os projetos têm baixa prioridade dentro da empresa, pois causam pouco ou nenhum impacto nos resultados. O CoD é quase estático, já que não existe muito risco em atrasar o projeto.

Como usar?

Além do conhecimento de quanto a empresa perde semanalmente caso o projeto seja atrasado, é possível utilizar o CoD como ferramenta de tomada de decisão ao priorizar projetos.

Exemplo

Digamos que você tenha dois projetos: A e B. Ambos com CoD de curvas padrão.

Baseado nos detalhes do projeto, alguém poderia pensar que o projeto A é mais importante que o projeto B. No entanto, se você calcular o CD3, você verá que CD3_A = 138.8; enquanto o CD3_B = 200.

Mas o que isso significa? Significa que caso você trabalhe no projeto B primeiro, você vai antecipar a geração de renda quando comparado com começar o projeto A. Ainda não acredita? Aqui está uma simulação de 75 semanas:

Ponto de atenção

É importante notar que a curva de CoD de um projeto pode mudar com o tempo. Para ilustrar, digamos que um produto nunca antes visto no mercado está sendo desenvolvido. Como não há competidores, ele segue a curva padrão. Depois de um ano de desenvolvimento, chegam notícias de que um competidor está desenvolvendo algo similar, e vão lançar o produto no dia X. A curva do projeto provavelmente seguirá a curva de data fixa, com a reta íngreme começando no dia X.

Conclusão

Você pode, e deveria, calcular o CoD toda vez que houver dúvida de qual projeto priorizar. É uma método fácil de ser calculado e, pensar em todos esses detalhes, pode proporcionar intuições sobre os projetos.

E você? O que acha de usar Custo de Atraso na priorização de projetos? Deixe seus comentários abaixo!

The post Quanto a empresa perde financeiramente quando o projeto atrasa? first appeared on Plataformatec Blog.

Não só bens físicos se deterioram, isso também ocorre com software.

Todos sabem que bens físicos se deterioram. As pessoas aceitam este fato e sempre lidaram com isso. O que as pessoas não aceitam tão facilmente é que software “se deteriora” também. Ao contrário dos bens físicos, isso não acontece devido a algum fenômeno físico ou químico. Essa deterioração ocorre geralmente devido a mudanças de negócios ou de profissionais. Vou dar um exemplo.

Imagine que você é o líder de uma equipe de produto ou tecnologia em uma startup; você é o CTO. Você já lançou a primeira versão do seu produto e foi um sucesso. Seu modelo de negócio foi validado e agora você está em fase de crescimento. Isso é fantástico! Mas tem seus custos, além de novos desafios.

A primeira versão do seu produto está funcionando, mas a base de código não está como você precisa a partir de agora. Talvez sua equipe não seja tão veloz quanto antes. Sua equipe reclama continuamente da qualidade do código. O CEO e o diretor de produto querem novas features e suas estimativas atuais não atenderão às necessidades do negócio.

Não raro, baixa qualidade da base de código está entre as principais origens de todos problemas. Talvez você precise refatorar (refactor) ou reescrever (rewrite) o software.

Quando a base de código não está em boas condições, todos podem ficar frustrados.

Sua equipe inteira, incluindo os desenvolvedores, se sentirão frustrados porque gostariam de liberar features com maior velocidade, porém a qualidade do código e a arquitetura atual não ajudam.

Os departamentos de TI, produto e software sofrem por não atenderem às expectativas das outras áreas.

O cliente também sofre devido aos bugs frequentes, o tempo gasto para que sejam corrigidos, além da demora para lançar novas features.

Você conseguiu entender.

Identifique os sintomas

É papel do líder (por exemplo, o CTO) identificar quando é necessário refatorar ou reescrever o software. Para isso, ele(a) pode fazer uma análise em busca de alguns sintomas, como os listados abaixo:

• Tudo é difícil: Quase todas features novas ou correções de bugs que sua equipe precisa fazer são difíceis. Nem sempre foi assim. Você se lembra dos bons tempos em que sua equipe era rápida e a execução era perfeita.
• Velocidade lenta: a velocidade de sua equipe diminuiu ou está diminuindo. Quando vocês desenvolveram a primeira versão do produto, era rápido desenvolver uma nova feature. Sua equipe conseguia desenvolver um monte delas a cada iteração. Agora é diferente.
• Suíte de testes lenta: Sua suíte de testes apresenta tempo de execução 10x, 20x, 30x maior que antes.
• Bugs que não desaparecem: Sua equipe corrige um bug e em algumas semanas ele reaparece. É comum sua equipe corrigir bugs em testes de regressão.
• Sua equipe está desmotivada: Sua equipe reclama continuamente que trabalhar no projeto já não é tão produtivo como era no antes. Uma pessoa não consegue construir uma feature sozinha; há muitas partes em movimento.
• Conhecimento isolado: Existem algumas partes do software que apenas um desenvolvedor conhece bem o suficiente para mantê-las. O resto da equipe tem dificuldades em trabalhar com esse código específico.
• O período de adaptação de um novo desenvolvedor é muito longo: Quando novos desenvolvedores se juntam à equipe, demora demais para que eles se tornem totalmente produtivos.

A razão pela qual você está em uma dessas situações provavelmente não é técnica. Talvez você precisasse entregar muitas features muito rápido, enquanto ainda estava desenvolvendo a primeira versão de seu produto. Talvez sua equipe não tinha maturidade e experiência que possuem agora. Analisar a causa raiz também é importante, mas você precisa fazer mais. Você precisa resolver o seu problema.

Se você está enfrentando os sintomas acima, provavelmente você tem problema de baixa qualidade interna de software. Reconhecer os sintomas já é um grande passo. O próximo passo é pensar em soluções. Algumas soluções que você pode considerar incluem o processo de refatorar ou reescrever o software.

Refatorar ou reescrever?

Não existe um guia definitivo que aponte quando você deve refatorar ou reescrever o software, pois depende muito do seu contexto. Dito isto, existem algumas regras básicas que você deve considerar ao avaliar qual a melhor solução para sua situação:

Quando reescrever

• Se a tecnologia que você usa está desatualizada e não possui mais manutenção;
• Se seu software é muito lento e mudar a arquitetura não é suficiente ou viável;
• Se a disponibilidade de desenvolvedores de software que conhecem a tecnologia que você usa é baixa e está diminuindo;
• Se existem novas tecnologias que oferecem vantagem significativa em relação a que você utiliza.

Quando refatorar

• Se a tecnologia que você usa ainda possui manutenção e é relevante;
• Se é viável melhorar seu aplicativo gradualmente;
• Se o problema que você está resolvendo é apenas técnico, e não de negócio.

Não é fácil decidir qual opção escolher. Ao optar por uma delas, você enfrentará um monte de novas preocupações. Fique atento, em nossos próximos posts vamos discutir o que levar em consideração antes de optar por refatoração ou reescrita do software.

Agora eu gostaria de saber sobre suas experiências. Você já esteve nessa situação? Como você identificou que o problema era baixa qualidade interna de software? Compartilhe sua história conosco!

Leia os outros posts da série Baixa Qualidade Interna de Software

1. Sintomas da Baixa Qualidade Interna de Software você está lendo
2. 9 Pontos-chaves ao se fazer uma refatoração grande de software
3. 8 pontos-chaves para reescrever um software

The post Sintomas da Baixa Qualidade Interna de Software first appeared on Plataformatec Blog.

Before we explain in details why that is not true, we need to introduce a microeconomics law: The Law of Diminishing Returns. Don’t get discouraged by the “microeconomics” word… It will be fast and painless.

Law of Diminishing Returns

Increase in process productivity is not directly proportional to the increase of people in the team. That happens because there is a limited number of ways to increase work parallelism (sometimes there is not a way to divide the tasks that are being held in more tasks), and because each additional worker may actually harm the team’s organization.

When a new person enters the team, the following results may be noticed:

• The team may actually need more capacity and, therefore, the throughput will increase a lot and the return on the investment will be fast reached — increasing returns.

• The team can still absorb an extra person, but the throughput gained with the addition is low, resulting on long term returns — decreasing returns.

• The team is saturated and the new teammate makes everyone compete for tasks and invest extra time to coordinate the activities, which causes a decrease in the team’s throughput — negative returns.

What you are saying then is that I can’t do anything to improve my process throughput?

No! There is a workaround to that law, and we’ll show you how to do it.

Workaround

The diminishing returns curve has as a premise: you set the variables around your system, and you are only changing the amount of people. Therefore, if you change other variables, you may be able to stay longer in the increasing returns area.

These changes will not only make it more appropriate for people to join your team, but it may improve its throughput even if no one is hired as well.

First, you should see if you are following a healthy process. We have a great blog post that summarizes how to improve your workflow: 5 Strategies to improve software development workflow

Second, to make sure you’ll get 100% of efficiency from the new hire, your project may need these characteristics:

• High quality code – if the code quality is bad, the addition of a new member will not change anything. The learning curve to develop new functionalities will be steep and the lead time will only increase with time, due to the complexity generated by the low quality.

• Software architecture – the software architecture needs to enable the addition of a new member without harming the global throughput.

• Team organization – the team needs to be correctly organized in order to not destabilize the team’s functioning with the addition. This includes keeping an eye on process bottlenecks to make sure everyone is working on the task that helps the process flow the most.

• Software documentation – the team needs a good documentation of the existing code so new members can understand the context faster and start working more efficiently right away.

To illustrate this whole idea of diminishing returns and changes in the system, we present a simple, and maybe even a little dumb, example.

Example

To easily understand what people saturation means in a team, imagine that John works selling hotdogs, with a hotdog cart, at a very busy avenue.

He takes care of assembling the hot dogs as well as handling the cash. Since he has a huge line waiting in front of the cart, he often sees people leaving the line to eat elsewhere. Based on that fact, he decides to hire one more person to take care of the hotdog assembly, and he would only take care of the cash.

After the arrival of the new member, sales increase more than 100%, because no one is leaving the queue anymore (example of increasing returns).

However, John believes that one more member would still benefit the business, because the new person could clean the leftovers, so the assembler would be only focused in the assembly process. With that improvement, he is hoping to be fast enough to eliminate the line. Hence, John hires a new person and his revenue increases by 25%, instead of the 100% seen before (example of decreasing returns).

But John still feels that the assembler spends too much time customizing each hotdog according to the customer’s taste. Therefore, he brings one more person to the team to handle the customization. However, with the new person, he sees his productivity decrease in 30%, and notices that the new member started to dispute space with the assembler and the cleaner. He disturbed the process more than helped the flow (example of negative returns).

Nonetheless, John is a visionary and wants to grow his business. To accommodate 4 people and improve the flow even more, he decides to open a hotdog brick-and-mortar store. Now, he has enough space for everyone to work together, and even hires more people as waiters. With the new store, John’s revenue increases in 600% (example of changes in the system to maintain increasing returns).

Conclusion

It is necessary that, before making decisions about hiring or moving in someone new, you are aware of the team’s conditions so you know if the arrival of a new member will bring positive results or not.

What did you think about this post? Did you already know about diminishing returns? Leave your comment below!

The post The Law of Diminishing Returns and its impact on projects first appeared on Plataformatec Blog.

Antes de explicarmos em detalhes o por que disso não funcionar, precisamos introduzir uma lei da microeconomia: a Lei dos Rendimentos Decrescentes. Não se sinta desmotivado pela palavra “microeconomia”… Será rápido e indolor!

Lei dos Rendimentos Decrescentes

O aumento na produtividade de um processo não é diretamente proporcional ao aumento no número de pessoas do time em questão. Isso acontece pois existe um limite no número de maneiras de paralelizar um trabalho (algumas vezes é impossivel dividir ainda mais uma tarefa). Além disso, cada membro adicional do time pode prejudicar a organização do mesmo.

Quando um novo integrante se junta a um time, os seguintes resultados podem ser notados:

• O time pode realmente precisar de mais pessoas e, portanto, sua vazão de tarefas vai aumentar consideravelmente, fazendo com que seu investimento tenha retorno rapidamente — rendimentos crescentes.

• O time ainda consegue absorver uma nova pessoa, no entanto a produtividade gerada com essa entrada é baixa, resultando em um retorno lento de seu investimento — rendimentos decrescentes.

• O time está saturado e o novo membro do time faz com que as pessoas tenham que disputar espaço por tarefas e investir um tempo maior para coordenar o processo, o que causa diminuição na produtividade do time — rendimentos negativos.

O que você está dizendo então é que eu não posso fazer nada para melhorar a vazão do meu time?

Não! Existem métodos que te ajudam a contornar essa lei, e nós mostraremos como alcançar isso.

Ações de contorno

A curva de rendimento decrescente segue uma premissa: você fixa as variáveis do seu sistema e apenas varia a quantidade de pessoas. Portanto, caso mudemos as outras variáveis que outrora estavam fixas, podemos nos manter por mais tempo na área de rendimentos crescentes.

Tais mudanças não vão apenas tornar seu time mais preparado para receber novos integrantes, mas pode também melhorar sua vazão por si só, sem a necessidade de novas contratações.

Primeiramente, você deve observar se seu processo de desenvolvimento é saudável. Nós possuímos um ótimo blog post que sumariza como melhorar seu fluxo de trabalho: 5 Strategies to improve software development workflow.

Além disso, para que seu time seja o mais eficiente possível com a nova contratação, seu projeto precisa das seguintes características:

• Alta qualidade de código – caso a qualidade do código esteja ruim, a adição de um novo membro em nada mudará pois a curva de aprendizado para desenvolver novas funcionalidades será grande e o seu lead time só aumentará com o tempo devido à complexidade gerada pela baixa qualidade.

• Arquitetura de software – a arquitetura do software precisa possibilitar que a adição de um novo integrante melhore o throughput global.

• Organização do time – o time precisa estar corretamente organizado para que a adição de um novo membro não desestabilize o funcionamento do time.

• Documentação – O time precisa de uma boa documentação do software existente, para que novos membros consigam entender seu contexto mais rapidamente e, portanto, comecem a trabalhar mais eficientemente.

Para ilustrar toda essa ideia de retornos decrescentes e as possíveis mudanças em um sistema, nós apresentamos aqui um simples exemplo.

Exemplo

Para que seja possível ver mais facilmente o que significa a saturação de pessoas em um time, imagine que Carlos trabalha em um carrinho de cachorros-quentes em uma rua movimentada.

Ele cuida tanto da montagem do cachorro-quente quanto da venda do mesmo. Por ter uma fila muito grande de pessoas esperando pelo seu hot-dog, ele vê que algumas vezes as pessoas saem da fila. Com isso em mente, ele decidiu contratar mais uma pessoa para cuidar da parte de montagem enquanto ele cuida das vendas.

Após a entrada do novo integrante, a venda de cachorros-quentes aumentou em 100% pois ninguém mais saia da fila (exemplo de rendimento crescente).

Carlos, no entanto, acredita que mais um integrante ainda traria benefícios ao negócio, pois a nova pessoa poderia recolher o resto de comida que fica em torno do carrinho e organizar os ingredientes, para que o montador ficasse focado apenas na montagem. Assim ele poderia eliminar a fila. Carlos então contratou mais uma pessoa e sua venda de hot-dogs aumenta em 25%, ao invés dos 100% conseguidos com o primeiro novo integrante (exemplo de rendimento decrescente).

Carlos ainda vê que o montador de hot-dogs gasta muito tempo customizando o final da montagem, pois algumas pessoas gostam de mostarda e ketchup e outras não. Pensou então em trazer ainda mais uma pessoa para o time, para cuidar apenas da customização dos produtos. No entanto, quando a pessoa chegou ele viu sua produtividade diminuir em 30%, e notou que o que acontecia era que o novo integrante tinha que dividir espaço com o montador e, portanto, atrapalhava mais do que ajudava no fluxo (exemplo de rendimento negativo).

No entanto, Carlos era um homem de visão, queria crescer seu negócio. Para acomodar as 4 pessoas e aumentar ainda mais o fluxo, ele decidiu abrir uma loja de cachorro-quente. Nessa loja agora, ele tem espaço para todos e ainda conseguiu colocar mais duas pessoas como atendentes. Carlos fatura agora 600% mais do que anteriormente (exemplo de mudanças no sistema para manter um rendimento crescente).

Conclusão

É necessário que, antes de tomarmos decisões sobre contratação ou deslocamento interno de pessoas, tenhamos consciência das condições do time em questão para que a chegada de um novo membro tenha a maior eficiência possível.

O que achou desse post? Você já conhecia a Lei de Retornos Decrescentes? Deixe seus comentários abaixo!

The post A Lei dos Rendimentos Decrescentes e seu impacto em projetos first appeared on Plataformatec Blog.