Ah! The new kid on the block!
Nas últimas semanas tenho ouvido o mesmo termo em inúmeras discussões que acompanho e participo online (já viu o Slack de Agilidade? você deveria entrar!). Umas das primeiras pessoas que ouvi falar os termos foi o Rodrigo Yoshima, conhecido da comunidade kanban/agile e treteiro de primeira linha. Depois disso vieram várias outras pessoas falando sobre uma forma de encarar projetos software, e de que forma avaliar a forma de conduzir um projeto: Côncavos e Convexos.
Fui atrás de ler algumas coisas a respeito, e no meio de um livro sobre economia comportamental (Blink, de Malcon Gladwell), o termo aparece novamente, sobre a visão da Lei de Retornos Decrescentes , sobre a forma que tratamos risco e recompensa. E então vi a serie de vídeos do Kent Beck a respeito do tema, descrevendo de forma simples o modelo. É interessante que não temos muito conteúdo online sobre essa visão em projetos de software, apesar de ser a coisa mais comum em Biologia(estabilização da população de espécies em ecossistemas), Economia (microeconomics) e Agronomia(fertilização de solo).
Este post é uma versão em ptBR de parte desse conteúdo, e espero que sirva como um trampolim para mais estudos.
O conceito é simples: Lei de Incrementos Decrescentes define que, em qualquer processo produtivo, incrementar um dos fatores enquanto mantém os demais constantes tende a diminuir o retorno por unidade produzida. Exemplo lindinho: Imagine-se numa noite fria de inverno, e você está estreando seu cobertor que liga na tomada e aquece, uma maravilha da tecnologia moderna. Você liga o cobertor e ele aquece até 20 graus, e está super empolgado com o quentinho e o conforto que isso lhe trás. Obviamente, aumentar a temperatura, não necessariamente aumentará o seu conforto, e num determinado momento, o calor pode causar mais mal do que bem.
Em projetos de software existem relações claras entre Risco e Recompensa. Projetos podem ser no estilo da sua startup hipster, em que o esforço é grande, não necessariamente você ganhará dinheiro no início, mas as expectativas de ganhos são gigantescas, assim como o Risco e as incertezas no caminho – aqui, previsibilidade é um mito. Em relação ao ganho, o investimento e esforço é considerado pequeno. Chamamos tais projetos de Convexos.
Projetos Côncavos são o oposto. Aqui, economias de escala são um objetivo a ser alcançado. Isso significa que o resultado desses projetos é mais previsível e normalmente cria-se uma aversão ao risco devido à Redução Marginal de Resultados, comum nesse cenário. Não necessariamente mais esforço e mais sucesso trazem grandes incrementos em ganhos.
Kent Beck apresenta um quadro de relacionando Sucesso x Ganhos, e a forma como ambos tipos de projeto, Convexo e Côncavo, se relacionam:
Naturalmente, por serem estilos completamente diferentes de projetos, eles demandam abordagens diferentes de gestão. Projetos de Alto Risco-Alto Ganho demandam alta experimentação e diversidade para avançarem, enquanto projeto de Baixo Risco-Baixo Ganho demandam menos diversificação/duplicação e redução de custos para seguirem.
Kent beck inclusive descreve sua frustração em não conseguir entender porque pessoas gerenciariam projetos usando deadlines, estimativas, prazos e cronogramas (e eu também). A verdade é que esse modelo serve para resolver problemas diferentes dos quais ele estaria mais envolvido. Projetos côncavos são bichos completamente diferentes de projetos convexos.
O pulo do gato está em entender que todos os projetos passam por momentos de Convexidade e Concavidade, e nunca um projeto estará somente em um ou outro cenário. Entender isso nos ajuda a colocar uma visão mais pragmática sobre a gestão de projetos. Em última instância, projetos de software podem iniciar muito bem com grandes riscos e expectativa de grandes ganhos, que quando alcançados, acabam cascateando para situações de previsibilidade e são sucetíveis à Lei de Redução Marginal de Resultados. Isso demanda uma mudança no estilo de gestão e a forma como encaramos o projeto. Entender em que momento o projeto se encontra é importante.
Pense na sua grande startup de sucesso ou o seu produto de software maravilhoso. Muito provavelmente, ele passou por uma curva S de resultado. Isso significa: inicialmente o projeto era incerto quanto ao seu resultado até alcançar algum sucesso, depois de inúmeras tentativas e experimentos, ganhar tração e começar a crescer. Depois de algum sucesso, naturalmente o produto tende a perder a incerteza – o retorno financeiro dá alguma previsibilidade, o pipeline de clientes se estabelece, os compromissos com clientes crescem. O risco diminui até o momento que esse produto alcança um estágio de crescimento que o retorno não extrapola muito mais do custo, ou o investimento necessário para rodar experimentos fica muito alto, ou seu tempo já passou. Aqui todos os projetos morrem – alguns se tornam fontes de renda recorrente sem que muito esforço seja colocado nele até que terminam, outros perdem seu momento e morrem de uma vez.
Assim, teríamos o seguinte diagrama:
Descobrir o momento ideal para iniciar uma nova onda é o grande desafio para empresas que vivem no desenvolvimento de software. Aproveitar o crescimento de ganhos para impulsionar uma nova onde convexa é um ponto importante. Avançar muito na fase de Ganhos Marginais decrescentes para somente então buscar alternativas é muito arriscado para a empresa.
Encontrar a forma como conduzir esse ciclo de vida exige uma série de conhecimentos, e a sensibilidade de entender quais modelos mentais utilizar em cada situação e o formato de gestão para cada um. Inconscientemente já fazemos isso – projetos de sustentação já são conduzidos de forma diferente de projetos greenfield.
Como um bom consultor, Kent Beck apresenta uma matrix 2×2 sobre Estilo de Gestão e Realidade do Projeto, traçando um paralelo sobre consequências de misturar erroneamente os modelos.
Realidade Convexa / Gestão Convexa: aqui temos um processo de gestão focado em Aprendizado, regado a experimentos, diversidade, hipóteses e baixa preocupação com resultados.
Realidade Côncava / Gestão Côncava: aqui o foco é eficiência, redução de custos através de eliminação de duplicidade, gestão de dependências e execução
O real problema está em misturar os estilos de gestão diferentes da fase em que os problemas se encontram.
Realidade Convexa / Gestão Côncava: Caótico. Expectativa de estimativas e metas nunca alcançadas, previsibilidade é uma piada e muito overhead de gestão desperdiçando tempo de experimentação. É a terra do microgerenciamento.
Realidade Côncava / Gestão Convexa: somente foco em visão, sem uma preocupação com coordenação objetivos. Nenhuma previsibilidade de resultados, e custos possivelmente elevados.
Na minha visão, isso se encaixa totalmente com o que viemos falando há muito tempo. Contexto é tudo, e entender qual a situação atual de seu projeto vai determinar qual o estilo de gestão você utilizará. Isso significa que Agile não serve para qualquer cenário de software? Absolutamente não! Existem inúmeras práticas e mindsets ágeis que podem ser usados em diferentes contextos de gestão de projetos, basta você estudar para descobrir, na sua realidade, qual se aplica melhor.
Gostou dessa história? Quer saber como conduzimos nossos projetos de software? Leia um dos meus artigos: Começando e entregando projetos na Lambda3.
Que tal nos chamar para entregar seus projetos?! Bora! entre em contato!
