Revolução ou Evolução?

Revolução ou Evolução?

Você já passou por uma implantação de um processo de desenvolvimento de sistemas? Talvez você foi o cara que tentou implantar um novo processo… Ou da equipe de desenvolvimento… Vamos ver o que revolução e evolução tem haver com isso?

Eu já vi isto acontecendo algumas vezes. Vem aquele gerente novo, aquele cara que acabou de ser contratado e tem aquela ideia genial de um novo processo de desenvolvimento (RUP, SCRUM, etc.) que vai acabar com todos os problemas da empresa… (Só que não)

No melhor caso, depois de muita resistência, muita luta, muita dor de cabeça aquele processo pode até acabar sendo implantado… Ou a energia pode acabar e agora está tudo pior do que antes. Nenhum processo e ainda desenvolvedores desmotivados e alguns: “Não falei que não ia dar em nada…”

O problema é que mesmo que aquele processo tenha sido implantando, daqui a pouco começa tudo de novo… As condições começam a mudar, as ineficiências começam a aparecer,  e aquele processo “salvador” não funciona mais como antes. Pronto: agora precisamos de um novo salvador e um novo processo.

Será que precisa ser sempre assim?

Existe alternativa?

Um novo ponto de vista

Bom, você não pode deixar tudo como está! Também não dá para depender de processos salvadores que de vez em quando vão solucionar todos os problemas.

Como fazer, então?

O contrário disso é fazer pequenas evoluções. Pequenas Melhorias. Constantemente. Todos os dias. Em toda a organização.

Curva J
Curva J

Você já deve ter visto uma curva J como estas do gráfico. Quando você faz uma mudança grande, a “barriga” do J é grande (gráfico à esquerda). O caos se instala para depois você conseguir uma melhora de produtividade (quando você não larga a mudança no fundo do poço!). Quando você faz várias mudanças pequenas, as “barrigas” dos J são pequenas (gráfico à direita).

Isso quer dizer que:

  1. Os caos provocado pela mudança é menor;
  2. Você chega mais rápido em um novo patamar de desempenho;
  3. Se tiver que desistir da mudança, o prejuízo é menor para voltar ao processo anterior.

Este é um dos motivos para eu gostar das ideias do Kanban e Lean. Neles, não existe um processo de desenvolvimento pronto. Não existe “o processo” que vai solucionar os problemas de todas as equipes e todas as empresas. Mas existem diretrizes e um processo de mudança de como melhorar o seu processo de desenvolvimento.

Além disso, testando uma mudança de cada vez, você aprende o que funciona para você e o que não funciona. O seu processo acaba ficando mais enxuto e perfeitamente customizado para o seus time. Para a sua empresa.

Será que seu time chegaria no Scrum depois de várias pequenas melhorias?

Se você gostou ou tem alguma dúvida sobre desenvolvimento ágil, pode mandar na área de comentários aí em baixo.

Obrigado e um abraço!

Seu comentário aqui

%d blogueiros gostam disto: