Como NÃO ser o Peru de Ação de Graças

Você já teve seu projeto cancelado por uma mudança repentina no mercado? Já foi demitido apesar de não ter nenhum indício de que isso pudesse acontecer? Já ganhou na loteria? Você nasceu? 😀 Se alguma destas coisas já te aconteceu, você vivenciou um Cisne Negro: um evento totalmente imprevisível para você, que traz um grande impacto negativo ou positivo.

No livro The Black Swan (A Lógica do Cisne Negro, em português), Nassim Taleb apresenta um fato, cada vez mais comum, segundo ele, de que as pessoas se apoiam demais naquilo que sabem, desconsiderando os possíveis impactos daquilo que não sabem. O autor vai dizer que deveríamos estar mais preocupados com o que não sabemos, pois aquilo que já é de nosso conhecimento acaba nos cegando ou nos dando falsas sensações de segurança, tornando-nos frágeis. Difícil de entender? 🙂

Mas peraí!! Você não ia falar do peru? O que esse cisne aí tem haver? 😀

Para falar sobre esse assunto e tentar esclarecer algumas das minhas dúvidas também, entrevistei Celso Martins, Agile Coach e desenvolvedor, atualmente atuando na Taller – Ateliê de Desenvolvimento de Software e na Crafters Innovation Studio, e que em breve lançará um livro tratando dos “cisnes negros”, complexidade e sistemas, aplicados ao desenvolvimento de software. Agradeço enormemente o Celso por separar um tempo e trazer mais luz aos nossos estudos.

Para melhor aproveitar esta entrevista, caso não tenha lido os livros The Black Swan ou Antifragile, veja este vídeo (13 min) que traz comentários sobre o livro e que pode lhe dar uma base para assimilar melhor as respostas do Celso.

Esta entrevista terá 90% das perguntas sobre o assunto e 10% não, a fim de corrermos o risco positivo de se beneficiar de um conteúdo inesperado 😉

Vamos lá:

1) Numa entrevista que fiz com Alisson Vale publicada neste site, uma das perguntas foi o “quanto experimentar“. A pergunta teve como base o possível desperdício que haveria ao se tratar tudo como uma necessidade de descoberta e especulei se não haveria momentos em que convergir mais rápido para a solução seria melhor. No seu livro você também irá ressaltar que em desenvolvimento de software estamos sempre navegando entre os domínios Complicado e Complexo, que requerem abordagens diferentes. Você poderia nos dar exemplos nos dois domínios e como saber quando estamos em um ou em outro?

R: Olá Buzon. Primeiramente ressalto que é um enorme prazer estar aqui e poder participar desta conversa que faremos sobre um assunto que venho estudando e que tem me agradado bastante, a aleatoriedade. Na verdade, a flutuação entre os domínios do Cynefin é bem maior. Podemos ir e voltar do caos, do óbvio, do complicado, do complexo e da desordem. Na desordem, estamos em todos os quatro domínios anteriores ao mesmo tempo. Então além da flutuação entre os domínios, podemos também estar em todos. Também podemos ter um sistema que está em dois domínios ao mesmo tempo, no complicado e no complexo sem que para isso estejamos na desordem.

Exemplo: Imagine que o Projeto A vai gerenciar uma loja de venda de rações para cães e o sistema de estoque já foi desenvolvido. Agora o comercial vendeu o Projeto B que vai gerenciar uma loja de aquários e também precisará de um sistema de estoques. Para o sistema de estoques do Projeto B, com o mesmo time ou time similar, você estará no complicado ou até mesmo no óbvio. Para o sistema A, você estará no complexo. Obviamente estou simplificando para facilitar o entendimento, pois com o conhecimento geral que existe atualmente, não seria nenhum absurdo considerar o Projeto A já de cara no complicado, mas provavelmente, neste caso, nunca estará no óbvio. Agora imagine que entrou um Projeto C que usará cálculos estatísticos para sugestão de restaurantes baseado no seu gosto e na cidade que você está, no celular. O time nunca mexeu com mobile. Neste caso estaremos no complexo e um alto nível de experimentos será exigido.

É impossível uma receita de bolo ou checklist que te posicione em um dos domínios. Isso acontece sempre de acordo com a análise da situação atual, que pode mudar em questão de minutos ou dias, ou semanas, ou de um projeto para outro. Ou você pode estar com uma demanda no complexo e várias outras no complicado. Ou com um objetivo de negócio no complexo e outro no complicado. Sim, a análise é complexa e como tal não cabe ferramentas do complicado/óbvio, como checklists.

2) As Retrospectivas clássicas do Scrum endereçam questões do domínio complexo? Como deveriam ser as retrôs para se extrair o melhor do que elas podem oferecer?

R: No complexo você não pode projetar o futuro a partir de análises do passado. Ponto. Conhecer o que aconteceu no passado só poderá te ajudar a deixar o seu processo ou o seu sistema mais robusto a impactos de variabilidades. Se uma variabilidade se repete, você terá o seu contexto, ou parte dele, no complicado. Perceber a migração entre os domínios do Cynefin é essencial para qualquer gestor que quer praticar a gestão moderna baseada na teoria dos sistemas. Então a retrospectiva da forma como conhecemos, mirando nos stressors (Ex: Web service não funcionou) e tentando mitigá-los é inerte. Os impactos continuarão acontecendo e deixar o sistema no mínimo mais robusto quanto a eles é uma decisão que dificilmente sai de uma retrospectiva tradicional. Hoje em dia vejo a retrospectiva tradicional mais como uma terapia de casais/grupo. Se o grupo tem roupa suja e ainda não passou do storming, é interessante ter. Se passou do storming é chata e desnecessária.

No complexo, experimentar é importante. Errar é importante. Com a teoria do Taleb aprendemos que é impossível validar se algo está correto, entretanto é relativamente fácil validar se está incorreto. Para validar a correção, você precisa que todos os resultados testem positivo. O que não conhecemos? Não podemos afirmar que existem apenas cisnes brancos, porque não conhecemos todas as amostras de cisnes existentes. Devemos focar nas consequências e não em adivinhação:

Robusto:

Como podemos adaptar nosso sistema (processo, projeto, processo + projeto, departamento, família, etc) para não sofrermos com impactos desta natureza?

Antifrágil:

Como podemos adaptar nosso sistema (processo, projeto, processo + projeto, departamento, família, etc) para que ele fique melhor com impactos desta natureza?

Taleb nos mostra algumas ferramentas, como a opcionalidade.

3) Antes de chegar ao fim do livro Black Swan confesso que fiquei angustiado, pois a todo instante parece que o autor está dizendo que não sabemos de nada ou que não valeria a pena planejar ou projetar… até que “caem algumas fichas”: o problema não são as estimativas e planos em si, mas a relação que temos com eles. Como se dá isso no desenvolvimento de software?

R: A resposta anterior foi uma introdução a esta.

Ao reconhecer que podem existir coisas que estejam nos escapando à percepção damos o primeiro passo em direção à robustez ou quem sabe à antifragilidade. Deixamos de ser fragilistas, que nada mais é que a pessoa que transfere fragilidade. Isso pode acontecer consciente ou inconscientemente. Uma das características do fragilista é a capacidade de manipular em seu favor a narrativa da análise dos fatos post-morten, que só é possível devido a distância e turbidez entre causa e efeito.

No software encontramos isso expresso pela gestão comum nas formas que já conhecemos bem: Este projeto está atrasado, porque… ” falhamos no planejamento, então temos que ter mais dois meses de planejamento no próximo” ou “falhamos na completude do documento XPTO, então precisamos do documento X e do documento Y para voltarmos ao controle…”

O fragilista recebe os payoffs positivos de um desastre econômico, enquanto quem acreditou nele recebe os negativos. Os profetas econômicos, os jornalistas, os consultores irresponsáveis ficam com os upsides e os empresários, a sociedade, com os downsides. Neste caso a antifragilidade foi transferida de quem tem skin in the game para quem não tem skin in the game, e consequentemente não está exposto aos impactos “previstos” ou não previstos, depende da narrativa que o fragilista vai querer contar pós-fato.

4) Um sistema de controle de enchentes deixa uma cidade confortável a ponto de permitir que se construam residências e prédios próximos às zonas de alagamento, pois há confiança nos procedimentos, alertas e controles definidos. Entretanto, um tsunami que extrapole toda a tolerância do sistema, ocasionará um impacto gigantesco, matando mais pessoas, provavelmente, do que se não houvesse um sistema no qual confiassem. Ou seja, as ações do plano de risco têm os seus próprios riscos. É possível estar imune a estes eventos? Qual seria a postura que deveríamos ter para minimizar esses impactos? Ou, para quem leu o livro: Como não ser o peru de ação de graças?

R: Querer ser possível “estar imune” pressupõe que essa análise esteja correta. No Black Swan existe um defeito cognitivo atribuído a isso: Epistemic Opacity. E se as medidas de segurança não fossem tomadas e este grupo de pessoas tivesse ido morar nas bocas de um vulcão que explodiu e matou todo mundo? Eu entendi o seu ponto, mas só estou tentando mostrar que algumas coisas óbvias não estariam tão óbvias assim quando o assunto é não fazer determinada coisa para minimizar riscos.

Neste caso, como você bem expôs, seria impossível obter 100% de proteção ao risco, pois você está tomando uma medida que tenta evitar o Black Swan negativo, e isso na maioria dos casos é impossível. No seu exemplo, as pessoas estão confiando nas estatísticas – um tsunami a cada 100 anos – e não nas medidas de segurança que, possuindo ganhos limitados, só conseguiria avisar que você vai morrer em alguns minutos.

Se você quer um sistema convexo neste caso, é preciso contar que o tsunami vai ocorrer na próxima terça e de alguma forma adaptar o seu sistema para que ele ou não sofra ou fique ainda melhor.

Robusta: Vamos fazer um sistema de contenção que aguente tsunami e desvie a força do oceano em várias direções diferentes;
Convexa: Vamos pegar essa força desviada do oceano e gerar energia;
Convexa: Vamos desviar essa água para nossa represa e, com nosso sistema de dessalinização, teremos água por 150 anos.

Concorda que, com a primeira, o tsunami não faz diferença e com a segunda e terceira podemos até ter casos em que torceremos para que um tsunami aconteça? A primeira é robustez, a segunda e terceira são antifrágeis.

5) Muita gente avaliou mal o livro do Tabeb, reduzindo seu conteúdo a: “Shit happens” (merdas acontecem). O que o livro agrega para além do óbvio na sua visão?

R: Taleb usa uma linguagem difícil, na minha visão, que às vezes passa da linguagem dos guetos para uma linguagem mais erudita, com um inglês difícil no mesmo parágrafo. Ele também não liga para métricas e planejamento de capítulos e módulos e muito menos para o que o leitor dele ou o editor vão achar. Isso é o que ele diz, não lembro se no Black Swan ou Antifragile.

Quem avalia o livro desta forma negligenciou todos os desvios cognitivos e o mergulho no mundo da matemática fractal no Black Swan, assim como todos os exemplos e até as explicações matemáticas do livro 5 no Antifragile. É provável que estas pessoas pularam o livro 5. Na verdade é provável que tenham pulado os dois livros.

Na contramão do shit happens, Taleb nos ensina uma forma de pensar e agir para quando o problema acontecer e nos avisa: ele vai acontecer, pare de contar com a sorte.

6) Hoje ainda vemos discussões sobre se usamos Scrum ou Kanban ou variações predefinidas destes. Olhando, entretanto, para esta transitoriedade do desenvolvimento de software entre o Complexo e o Complicado, você imagina que uma equipe deva ter a sensibilidade de escolher os approaches mais adequados de acordo com o período em que está vivendo, podendo mudar várias vezes dentro de um determinado período? Ou isso independeria do framework em uso?

R: Esta sua pergunta tem um pouco de gestão de mudanças. Um sistema precisa de algum tempo para absorver mudanças relevantes. Este é um ponto. Se você inserir muitas mudanças ao mesmo tempo vai provavelmente jogar o sistema no caos.

Outro ponto é: quase todos os métodos/frameworks/whatever quebram no complexo. Apenas um sobrevive – e aqui posso estar sofrendo de epistemic arrogance ou epistemic opacity – o método científico. Levantamento e invalidação (via negativa) de hipóteses de forma cíclica.

Não é glamouroso estar em qualquer um dos domínios do Cynefin. Inclusive o mais natural é tentarmos trazer do complexo para o complicado para que o que desejamos fazer seja gerenciável, caiba em algum método ou framework. Confie em princípios mais que práticas e mantenha sua cabeça aberta ao comportamento e formação do sistema. Essa é a lei.

Esta briga Scrum x Kanban é profundamente comercial, porque os dois atuam no complicado e não é nem um pouco relevante para os meus objetos de estudo atual e não possuo interesse comercial em nenhum método, portanto é irrelevante para mim. É bom para dar umas boas risadas.

7) Pra quem não conhece o fluxo unificado você poderia explicar rapidamente a ideia e mostrar como essa abordagem contribui com a antifragilidade do sistema?

Rapidamente será difícil. =)

O Fluxo Unificado é fortemente baseado em princípios bem solidificados, principalmente a teoria das filas e nos aspectos econômicos das filas. Vem para reduzir o custo de coordenação na operação e o custo de execução para o cliente – seja ele cliente interno ou externo.

Como o Fluxo Unificado dá o contexto dos projetos unificados a todos os envolvidos, nós reduzimos drasticamente o impacto da Lei de Brooks, habilitando a opcionalidade no processo de desenvolvimento de software. Segundo Taleb é praticamente impossível antifragilidade sem opcionalidade. A opcionalidade é a raiz da antifragilidade.

Cenário tradicional:

Imagine que o Projeto A encontre um problema para a definição de uma integração e isso bloqueie uma demanda. Se o seu sistema não trabalha com limite de WiP, provavelmente a solução será puxar outra.. e outra.. e outra até o seu estoque de trabalho-não-feito ficar ingerenciável. Em algum momento o time do projeto A vai parar e o que as empresas modernas fazem é tentar gerar conhecimento com esse tempo ocioso forçado. As empresas mais tradicionais tentam forçar atividades dentro do projeto, as vezes até puxando mais demandas.

Cenário Fluxo Unificado:

Agora imagine que no mesmo fluxo esteja fluindo os Projetos A e B. No momento do bloqueio do Projeto A, o time pode fluir, ou dar um gás no Projeto B, reduzindo a pressão do fluxo para quando o Projeto A desbloquear, esse gás no Projeto A seja possível. Você está, no presente, liberando capacidade para o Projeto A no futuro. O cliente não continua pagando uma equipe inteira para encher linguiça enquanto o projeto está bloqueado. O fato de continuar pagando vai aumentar a ansiedade do cliente, aumentar a pressão e pode fazer o sistema desandar. Esse “encher linguiça” pode até gerar problemas de iatrogenia, que o Taleb também coloca muito bem e aqui nos alongaríamos muito.

Outsourcing: pode ser interno ou externo.

O cenário tradicional é frágil: tem medo de variabilidade, ele quer ausência de impactos, até porque o planejamento inicial pede isso.

O cenário de fluxo unificado é robusto: ele não se importa com impactos, com variação, porque é muito barato remanejar o fluxo, mexendo na fila de entrada do sistema. Podemos mal associar essa flexibilidade dos times à flexibilidade das máquinas obtidas no TPS.

Mas perceba uma peculiaridade: se o Projeto B for um produto, o sistema estará antifrágil: uma variação de um stressor no sistema deixa o sistema “empresa” mais forte, pois estaríamos alocando capacidade ociosa para o produto, caminhando mais rapidamente para validar ou invalidar nossa hipótese – produto ou partes do produto – antifrágil.

Perceba também que se você já tem dois produtos no seu portfólio, você provavelmente tem alguma vazão planejada para estes projetos, mesmo com times diferentes. Se o projeto B é um produto, e estamos com times diferentes, o time do produto normalmente é desfeito para incêndios ou aumento da vazão para os projetos que significam ganho financeiro no curto prazo – sobrevivência.

Como o time está acostumado à vazão dos projetos A e B, mesmo que tenha começado com uma proporção de 90% para o projeto A e 10% para o B, o custo de coordenação e transação para aumentar a vazão do projeto B é estupidamente baixo.

Imagine agora que, mesmo sendo uma empresa 100% de produto e que haja mais de um produto no portfólio. Imagine que seja uma empresa de um produto, mas essa divisão de projetos passe a ser divisão de módulos. É comum em empresas que são 100% um produto tenha uma divisão de times por módulos ou por frentes.

É claro que existem os downsides e para isso indico a série de artigos que fizemos na Crafters e o ebook que fizemos na Taller.

O Value Crafting Cycle, criado por mim, Felipe Rodrigues e Rafael Cáceres cai como uma luva para a definição inteligente desta proporção de vazão.

Teoria das filas + aspectos econômicos das filas. Simples assim. =)

8) Algumas empresas buscam uma visão de entrega de releases de 3 ou 6 meses. Algumas até mais. Há problemas neste exercício sobre o futuro ou ele pode ajudar em algum sentido?

R: Se não for um contrato assinado à sangue e se não remeterem as causas de um projeto que falhou a este planejamento, não vejo muitos problemas. Neste caso, minha opinião é que os planejamentos para períodos de tempo maiores é no máximo inócuo. Este tipo de atitude nos coloca mentalmente contra as variações e se houver a disciplina de que as variações podem ser boas e de que o plano pode ser ajustado de acordo com elas, não vejo problema. Só me parece inútil e o tempo desperdiçado nessa inutilidade seria um downside.

9) Deveríamos estar investindo mais naquelas ideias tipo Chaos Monkey?

R: Não tenho a menor dúvida quanto a isso.

10) E procurando um potencial benefício da aleatoriedade: Celso, pra você, qual o sentido da vida, do universo e tudo mais? 😀

R: Minha doutrina indica que o sentido da vida é aprender e de que o universo é uma escola. Acompanho o Espiritismo nisso. Quero ser amanhã melhor do que fui hoje, intelectualmente e moralmente.

Bônus!

Poderia deixar uma frase de até 140 caracteres que resuma nossa entrevista e que as pessoas possam compartilhar? 🙂

R: Analisamos os aspectos assimétricos dos processos de tomada de decisão. Como o entendimento de assimetrias pode criar sistemas antifrágeis?

140 cravado!

Foi um prazer imenso trocar essa ideia sobre um assunto que hoje tem dominado minha vida pessoal e profissional.

Agradeço muito ao Celso pela entrevista e desejo sucesso em seus empreendimentos e no livro que logo vai sair!