Porque o Waterfall não morreu?
Olá!
Recentemente me deparei com alguns conceitos que me fizeram refletir sobre a forma como estamos trabalhando hoje e o seguinte questionamento me veio a mente: será que agilidade é a resposta para tudo?
Como profissional de TI, seria leviano da minha parte negar a influência e a importância que ideias como Scrum, XP, Kanban, Lean, Less e Safe tiveram (e ainda tem) no meu dia-a-dia.
Exceto Less e Safe, que me parecem só buzzwords para vender cursos e certificações e que eu só ouvi falar mesmo.
E nesse mês de dezembro, tive uma aula sobre esses assuntos no MBA e me deparei com outras perspectivas muito interessantes, que preencheram muitas lacunas no meu conhecimento, por ex:
- A ideia de desenvolvimento ágil é fortemente inspirada no sistema Toyota de produção da indústria. Até aí, todo mundo sabe, certo? mas quem fez a ponte entre indústria e software? Foram o casal Mary e Tom Poppendieck, que coincidentemente, ele era de TI e ela era da indústria. O resultado? após muita troca de experiência entre eles, surgiu esse livro aqui. Eu acho muito importante essa multidisciplinaridade na tecnologia e já escrevi sobre isso aqui.
- O Scrum é mais antigo que o manifesto ágil e se originou em um paper de 1986! E porque ele ficou tão popular, comparado aos outros métodos? Bem, seus criadores (Jeff Sutherland e Dave Thomas) são signatários do manifesto ágil e já tinham um framework pronto quando a ideia começou a crescer e dar dinheiro. Quase bom demais para ser verdade. Mas acho que foi só sorte de estar no momento certo com a ideia certa mesmo.
Mas, curiosidades a parte, uma ideia que me soou incrível foi um framework para categorizar problemas que me fez ter alguns insights, como: quando e como gastar energia em alguns tipos de processos específicos, qual a melhor hora de perguntar para um especialista em um determinado assunto, o que agilidade tem a ver com ciência de foguetes (literalmente) e o porque tem tanta gente que ainda cai no golpe de “sucesso garantido” na bolsa de valores. Muita coisa? é, eu também achei, mas calma que vai fazer sentido. Vou compartilhar o que aprendi e tentar responder essas perguntas :)
Eu lhes apresento um dispositivo que faz sentido (foi o próprio criador que chamou assim) com nome gaulês chamado Cynefin (pronuncia-se cãnevin, de acordo com o robô do Google):
Criado por Dave Snowden (Ex-IBM, o outro Snowden se chama Edward, caso o nome tenha-lhe parecido familiar) em 1999, visa fornecer respostas e formas de agir para alguns tipos de problemas. A palavra Cynefin na língua original quer dizer habitat. Ou seja, é um modelo que visa categorizar os problemas em domínios específicos. Vamos passar por cada um dos quadrantes para entender melhor:
Óbvio: também chamado de Claro ou Simples em versões antigas do Cynefin. Aqui os problemas já tem múltiplas soluções conhecidas para praticamente qualquer pessoa (se tornando commodity). Nesse estágio, o desafio é somente decidir qual a melhor prática para atuação, através dos seguintes passos: Discernir (no sentido de entender qual o tipo de commodity que estamos falando), Categorizar (ou seja, classificar o problema em um categoria já conhecida) e Responder (agir).
Ficou abstrato? Vamos a um exemplo prático: Fazer um bolo. Você simplesmente pergunta qual é o bolo (discernir) e usa a receita de acordo com o tipo de bolo (categorizar) e depois é só fazer o bolo em si (responder).
Um exemplo corporativo: uma prática de RH corriqueira, como o trabalho operacional de contratação. O intuito é descobrir qual o perfil e suas particularidades (discernir), após isso, aplicar as boas práticas já conhecidas (categorizar) e executar (responder).
Nesse ponto, você não usa agilidade, design thinking e nem cascata, simplesmente porque não precisa. Porque esse domínio é muito simples e o grau de incerteza é baixo. Sendo assim, qualquer tipo de técnica de gestão de projetos é uma espécie de excesso de gestão — desnecessário nesse contexto, que fique claro — , por assim dizer.
No domínio do complicado, é a hora de perguntar para quem realmente sabe… ou seja, o especialista.
Com esse tipo de problema, não há a “melhor” resposta, já validada e aplicada inúmeras vezes a ponto de se tornar o padrão de resposta para uma determinada situação. Aqui, o especialista é a pessoa que vai conseguir fornecer uma boa solução, com base na experiência.
Portanto, o motto aqui é entender (Discernir) e procurar uma resposta adequada através de conhecimento especializado (Analisar), para enfim, agir (Responder).
Um exemplo prático seria um problema abrangente como: como criar o sistema inteiro de banco de forma segura e escalável?
Existem inúmeras formas de se fazer isso e nem todas necessariamente estão certas ou erradas, porém, caso você não seja uma pessoa desenvolvedora/arquiteta extremamente experiente seja no ramo bancário ou com uma determinada tecnologia, talvez seja a hora de perguntar para o especialista para obter uma boa (reforçando: não ótima!) resposta, porque o domínio é complicado demais para se obter respostas fáceis e prontas.
É aqui que o Waterfall entra como solução adequada. Somente relembrando: Waterfall (ou Cascata) é uma metodologia de gestão de projetos composta de fases sequenciais que tem como principal característica a dependência de uma tarefa para outra. Ou seja, para a próxima etapa começar, a atual precisa terminar. Logo, espera-se um ambiente previsível.
É aqui que eu tento responder o título desse artigo. Em um cenário previsível, com a execução apoiada por um especialista que já fez aquilo antes e sem necessidade de experimentação ou aprendizado validado (guarde essa parte, pois é importante), eu acredito que seja possível sim obter sucesso em um projeto trabalhando dessa forma.
Porém, quais projetos digitais que se encaixam nessa característica? Quase nenhum. E porque isso acontece? Porque produtos digitais são complexos, e não necessariamente complicados.
O domínio Complexo do Cynefin vem para ajudar a discernir quando usar um método de gestão por sua característica peculiar: nesse domínio, não se sabe muito bem onde se pode chegar.
Nesse tipo de problema, a solução é emergente (ou seja, não se sabe de antemão o que fazer, mesmo perguntando para um especialista). Portanto, a recomendação é aprender rápido e de forma barata, para ai sim decidir o que fazer.
Diferente do domínio Complicado — que já é possível saber o que é necessário fazer — no domínio complexo, eu ajo primeiro em um escopo controlado e previsível (sprints de poucos dias/semanas) para saber como agir melhor depois através do aprendizado validado obtido nessas sprints. Ou seja, ciclos iterativos de experimentação recorrentes que servem para validar produtos ou tecnologias.
Nesse domínio você encaixa Scrum e outros métodos ágeis. Pois o lema aqui é: delimitar um escopo específico de atuação (Investigar), começar a experimentar e com o aprendizado validado entender o que pode ser feito (Discernir) e por fim executar o desenvolvimento daquele produto/tecnologia (Responder).
E é aqui que entra a ciência de foguetes. A NASA possui um framework de verificação de maturidade de uma determinada tecnologia que é usado para avaliar o quanto maduro está uma tecnologia para uso em projetos espaciais.
Isso é chamado de TRL (Technology Readiness Level) e é expresso pela seguinte imagem:
Apesar dessa fonte aeroespacial, é possível aplicar a mesma ideia em outros lugares, como produtos digitais. Por exemplo: dos níveis 1 ao 3, temos a fase de experimentação através de uso de ciência básica (TRL 1) e ciência aplicada (TRL 2), bem como concepção de possíveis aplicações (TRL 3), ou seja, uma espécie de Product Solution Fit. Nesses 3 primeiros níveis, a pergunta é: O que está sendo desenvolvido se sustenta?
E qual a metodologia que passa por essa fase com eficiência?
Nada mais que: Design Thinking, que com suas sprints semanais em que no final do processo gera uma ideia validada (que pode ser qualquer coisa, mas geralmente relacionada a um produto físico ou digital) que se transforma em um protótipo real que será validado por um usuário real e pronto para ser escalado ou descartado, caso a ideia se prove ruim.
Faça uma conta simples: sprints semanais. Em um ano, são 52 ideias validadas de uma forma eficiente caso seja feito com disciplina. Isso é inovação constante e por mais contra intuitivo que pareça… gera previsibilidade na inovação. E não é isso que a maioria das empresas procurando se reinventar atualmente procuram?
Dos níveis 4 ao 6 do TRL, temos o Market Fit. Agora a ideia é desenvolver a ideia validada e “tentar ver se pega” com o público pretendido. Em termos de tecnologia, é fazer provas de conceitos (TRL 4), prototipação um pouco mais próxima do real (TRL 5) e ensaios ambientais (TRL 6).
Pode ser um teste de vôo em ambiente controlado de um novo drone, uma versão beta de um app ou site, uma release de uma nova feature para um público restrito… enfim, acredito que você tenha entendido a ideia dessas fases.
Ou seja, o domínio Complexo do Cynefin é igual ao TRL dos 4 ao 6.
Dos TRL 7 ao 9, é escalar o produto ou tecnologia no mundo real. Seja disponibilizar o produto para milhões de usuários ou colocar o foguete para literalmente, sair da Terra.🚀
Ou seja, o domínio Complicado do Cynefin é igual aos TRL 7 ao 9.
“Mas porque startup não usa cascata então? Dado que muitas estão na fase de escalar o produto?” Você pode se perguntar.
Eu chuto que: elas parecem que estão com o produto validado, mas não estão na verdade. Pense em Uber, Netflix e Nubank, todas tem milhões de usuários, mas de certa forma, não dão dinheiro. Elas ainda estão validando o Market Fit do produto se você parar pra pensar. Afinal, se eu sei o que é o meu produto, sei como fazer e pra quem é, eu deveria ganhar dinheiro com isso escalando o produto de forma previsível usando PMBOK/PMI e afins, porque não há imprevisibilidade e muito menos necessidade de experimentação.
No domínio Caótico, não há muito o que fazer, a não ser sobreviver simplesmente inventando uma prática inédita. Pois não é possível gerenciar o Caos, imagine tentar gerenciar um projeto nesse cenário! Seria como tentar tornar uma hidrelétrica viável dependendo de raios como fonte de energia.
Pelo meu entendimento, caos não é simplesmente desordem, é imprevisibilidade extrema, na verdade.
O que acontece quando você tenta atacar problemas de fora da classificação de óbvio do Cynefin com ações do domínio óbvio?
Como por exemplo: o comportamento de ações no mercado financeiro (que pode ser do domínio caótico ou complicado, depende do ponto de vista). Bolsa não é cassino, mas tampouco é imprevisível. Os efeitos desse descompasso entre complexidade do problema e ação que visa resolver geram: influencer de Day Trade e aquela propagando de “Olá, eu sou fulana, tenho 23 anos e tenho 1 milhão de reais de patrimônio, compre meu produto que você consegue também”.
Ou seja, tente resolver um problema complexo/complicado/caótico com ferramentas simplistas e tenha como resultados: familias falidas e propaganda enganosa.
Reinterpretando a frase de HL Mencken: para todo problema caótico, há uma solução simples, fácil e errada que vai acabar com suas finanças.
E o que eu quis dizer com todo esse texto? Dá uma olhada o que acontece quando se junta tudo:
Agora você já pode tenter aplicar agilidade na sua empresa com embasamento, ao invés de citar buzzwords, como mudança de mindset e afins. Basta entender o problema que você está tentando resolver e aplicar a técnica correta.
Esse foi o maior aprendizado do Cynefin para mim.
Até!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
