Inkas
Ferramentas de marketing
O Scrum, o princípio de Pareto, a produtividade e outras teorias relacionadas

Geralmente, de tudo o que fizemos durante o dia, apenas uma parte realmente importava  ou era o suficiente para produzir grande parte dos resultados ou impressionar.

Eu conheci muitos supervisores ou alta gerência que pouco faziam na prática. O comentário geral é que não eram bons exemplos de “colocar a mão na massa”. Mas sabe o que acontecia com eles? Eles sabiam aplicar uma estratégia de focar apenas que realmente importava, delegavam o restante e alcançavam resultados emocionantes para mostrar, tendo feito muito pouco para tal.

Esta estratégia está relacionada com o princípio de Pareto, conhecido como a regra 80/20 determina que, para a maior parte dos fenômenos, 80% das consequências advêm de 20% das causas. A partir dai supõe-se que a maioria dos resultados em qualquer situação é determinada por essa regra. Um exemplo é que “20% dos clientes podem ser responsáveis por 80% do volume de vendas” ou “usamos 20% das nossas roupas favoritas por volta de 80% do tempo”.

A regra 80/20, pode ser usada para melhorar a produtividade, pois ao nos concentrarmos nos 20% do que importa certamente teremos mais foco e terminaremos mais rápido do que quando nos focamos no todo. No Scrum (fiz um post sobre ele!) isso já acontece de alguma forma, pois as sprints de desenvolvimento do software vão sendo definidas conforme o desenvolvimento ocorre, a partir de uma lista de funcionalidades geral e bem completa, que só será esmiuçada no momento certo, o que permite concentrar no que realmente importa no início do projeto: definição dos objetivos, metas e comunicação clara com todo o time.

No gerenciamento de projetos em que existe alguém fazendo papel de gerentão  centralizador, é comum observar que existe uma grande carga em suas costas, pois ele é o responsável por tudo e precisa definir o projeto todo desde o começo, para só depois começar a desenvolver. Baseado no princípio de Pareto, o ideal seria gerenciar o projeto concentrando todos os esforços em seu início sim, mas apenas para definir objetivos e etapas corretamente e trabalhar em sua comunicação com a equipe. Essas questões estão relacionadas com duas máximas, uma que diz que “um mal começo faz um mal final” e outra que diz que “projetos não falham no final, falham no início”, afinal, as diretrizes e orientações definidas neste primeiro momento nortearão todo o projeto.

Ao analisar a teoria do caos compreendemos que software está, de fato, bem próximo do caos. Esta teoria trata de sistemas complexos e dinâmicos, rigorosamente deterministas, mas que apresentam um fenômeno fundamental de instabilidade chamado de sensibilidade às condições iniciais, que os torna-os não previsíveis na prática a longo prazo. Quando o conhecimento sobre tecnologia e sobre negócios é baixo, a gestão dos projetos torna-se complexa, algumas vezes gerando anarquia. Apesar de complexo, não se pode permitir chegar ao nível anárquico.

teoria-caos

Esta imagem mostra que quanto mais requisitos instáveis, clientes pouco conhecidos e tecnologias novas ou desconhecidas, mais perto se está do caos.

O software costuma estar no meio do caminho, pois são considerados complexos (63% de seu desenvolvimento está na área complexa).

Requisitos muito conhecidos e próximos da segurança possuem um valor muito baixo, muito inicial e que praticamente não se modifica no desenvolvimento, por serem simples, são facilmente dominados pela equipe. Estão geralmente na fase inicial do desenvolvimento de software.

Quando estudamos Engenharia de Software queremos fugir do caos. A teoria do caos e o SCRUM tem em comum o fato de admitirem que há uma imprevisibilidade inerente ao desenvolvimento de software, que é algo complexo. Aceita que os requisitos mudam e por isso foca no desenvolvimento iterativo e incremental, já que na maioria dos projetos as alterações são inevitáveis e devem ser gerenciadas, sempre buscando compreender o que será melhor para o cliente e para o projeto. Quanto mais tarde uma mudança for aprovada, mais ela vai impactar nos custos do projeto. Por isso não é interessante prender-se ao todo logo no início, mas entender prioridades e focar-se naqueles 20% que importam. Mesmo assim, a essência geral do projeto deve ser trabalhada com foco e desde o início ser claramente comunicada, para que o time possa trabalhar com segurança e pleno entendimento dos objetivos de negócio.

Uma teoria bem conhecida que foi desenvolvida por Barry Boehm no início dos anos 1980 é a do Cone da Incerteza. Este conceito foi introduzido no livro intitulado Software Engineering Economics.  O Cone de Incerteza diz respeito aos aspectos de incerteza na gestão de projetos e como eles evoluem ao longo do processo. Muitas vezes, quando um projeto está em seu início, é impossível prever com precisão como o trabalho vai progredir, as estimativas não podem ser precisamente previstas e, então, o projeto está sujeito às incertezas.

cone-incerteza

À medida em que o projeto se desenvolve, o conhecimento aumenta em várias áreas e mais detalhes podem ser obtidos permitindo que os envolvidos obtenham mais informações, portanto, diminuindo o nível geral de incerteza. Ele chega a 0% quando o risco contínuo foi contabilizado ou eliminado com estratégias de gestão de risco.

Adotar uma metodologia ágil como o Scrum pode reduzir a extensão do escopo de alterações, já que esta metodologia reconhece que os clientes podem mudar de opinião durante o projeto sobre o que querem ou precisam e que essas imprevisibilidades poderão ser facilmente tratadas, readequadas e atingidas, pois a equipe enfoca em entregar rapidamente e responder às necessidades emergenciais. É uma forma de focar-se apenas nos 20% que realmente importam naquele momento.

Um paper publicado na Harward Business Review 1986 escrito por Takeuchi e Nonaka, demonstrou os resultados de um estudo sobre o por que as empresas japonesas obtinham tanto sucesso e o que tinham em comum: Fuji, Toyota, 3M, Epson. O estudo concluiu que no desenvolvimento tradicional, modelo cascata, ocorre uma corrida de revezamento, enquanto o bastão não é entregue a outra não começa a correr referindo-se ao modelo extremamente processual desta metodologia, que faz com que o desenvolvimento fique enorme. Já no Scrum, estamos falando de jogadas Rugby, e temos um cenário chamado de aproximação em conjunto, no qual as fases são um pouco sobrepostas ou muito sobrepostas. Assim, antes de finalizar uma fase uma nova é iniciada e essa aproximação leva ao ganho de prazo. Aqui o “como será feito” não importa, essa questão será resolvida pelos desenvolvedores, que tem conhecimento para decidir a melhor forma de fazê-lo e de se auto-organizarem em torno dessas metas. E assim temos um ciclo iterativo e incremental.

paper-takeuchi-nonaka

É por isso que eu amo tanto as metodologias ágeis de desenvolvimento de software. Atuando no marketing e sem lidar diretamente com desenvolvimento de software adaptei o Scrum trabalhar com minha equipe e focar apenas no que importa em cada dia. Assim, temos de modo claro para toda a equipe as tarefas nas quais devemos nos focar naquele dia e que nos trarão grandes resultados, mas sem grandes instruções sobre como fazê-las, já que cada um do time possui competência para fazê-lo. Consolidamos todas essas teorias pra chegar a esta metodologia própria e os resultados tem sido maravilhosos.

Flávia Gamonar
posts 76
words/post 1510
media 180
comments 1
visits 125762

Leave a Comment

Name*
Email*
Website