Concrete Logo
Hamburger button

A grande disrupção digital: como lidar?

  • Blog
  • 17 de Dezembro de 2016
Share

Introdução

Além da questão mais ampla, que o Brasil foi uma das duas economias (junto com a Venezuela) que menos cresceu no mundo em 2015, nossa visão é que estamos sofrendo de um processo sistemático de disrupção feito por companhias estrangeiras.

 

https://oglobo.globo.com/economia/para-fmi-brasil-so-voltara-crescer-partir-de-2018-18502256

Essa chamada Grande Disrupção seria a perda de relevância que empresas Brasileiras de diversos setores estão tendo quando atacadas por competidores digitais mais aptos, que conseguem ultrapassar as barreiras do chamado capitalismo de laços, seja o próprio custo Brasil ou questões regulatórias. Em resumo, o capitalismo de laços não vai proteger o Brasil do Vale do Silício.

Além disso, a Grande Disrupção parece seguir áreas de grande ROC (retorno sobre capital) e, levando em conta que só conseguimos competir em ambientes extremamente fechados ou protegidos pelo governo, poderíamos dizer que sofremos de uma ineficiência crônica em desenvolvimento de produtos digitais.

Ao analisar esse cenário, estabelecemos a hipótese de que ele tenha como uma das causas fundamentais a aplicação de um modelo mental errado (planejamento centralizado e de controle) para tentar modelar o problema de desenvolvimento de produtos digitais, e isso leva à incapacidade de entender a dinâmica do fenômeno e, consequentemente, otimizar um sistema.

Considerar que o problema à nossa frente se comporta como um sistema linear talvez esteja ligado à condição humana, que tem aversão à volatilidade. Este “bias” levaria à utilização de bom senso, a redução sucessiva para resolução de problemas e o planejamento centralizado, mesmo quando estamos lidando com paradoxos e sistemas dinâmicos complexos.

Entretanto, como disse Albert Einstein, “o senso comum é a coleção de preconceitos adquiridos aos 18 anos”.

Desenvolvimento de produtos digitais

O problema é que desenvolvimento de produtos digitais se comporta como um sistema dinâmico complexo, não linear. Isso significa que as implicações individuais dos integrantes deste sistema são aleatórias e não previsíveis. Os sistemas evoluem no tempo com um comportamento desequilibrado e aperiódico, no qual seu estado futuro é extremamente dependente de seu estado atual, ou seja, são possíveis alterações radicais a partir de pequenas mudanças no presente.

Para este tipo de sistema, a aplicação de ações baseadas em planejamento centralizado, instintos, crenças, ideologias e senso comum não produz melhorias sustentáveis. Assim como disse Craig Larman citando Forrester, a maior parte das pessoas tem um julgamento fraco sobre como melhorar sistemas em seu nível fundamental, normalmente aplicando senso comum e soluções rápidas que não geram melhorias sistêmicas de longa duração.

Modelando Sistemas

Quando encaramos um problema, assumimos que precisamos elencar opções, escolher a melhor e executar. O problema desta abordagem é que ela assume que sabemos a priori as relações de causalidade e portanto podemos estabelecer algum processo para eliminar as piores e escolher a melhor opção.

Sistemas que podem ser modelados de forma efetiva desta maneira são chamados de sistemas ordenados. O problema é que a grande maioria dos problemas de negócio que nos deparamos todos os dias são sistemas não ordenados e precisam de uma abordagem coerente com sua natureza.

Esta visão de modelagem de sistemas, chamada de Cynefin, é uma evolução de um framework de tomada de decisão proposta inicialmente pela HBS em novembro 2007.

Assumindo que trabalhamos todos os dias no quandrante de sistemas que podem ser modelados como complexos ou caóticos, temos duas grandes abordagens de tomada de decisão que podem levar a otimizações reais e produtos de sucesso.

Na nossa experiência, na eventualidade de estarmos nos deparando com um sistema caótico, a tomada de decisão deverá ser na direção de mover o ambiente para um espaço mais ordenado, decisões rápidas em busca de espalhamento de risco e detecção de padrões. O ambiente de venture capital e statups se comporta desta forma e quando as empresas mostram alguma tração podemos considerar que o ambiente deixou de ser caótico, se tornou complexo e portanto temos que mudar o framework de trabalho.

As relações de causalidade de ambientes complexos são multivariadas e só podem ser conhecidas depois do fato ocorrido, então estratégias de experimentação sucessiva baseada em aprendizado tendem a funcionar, conforme proposto por Greg Brougham no seu livro “An introduction to complexity and the Cynefin Framework” e resumida na tabela abaixo:

A ortodoxia organizacional no desenvolvimento de software

Quando estava pesquisando literatura para escrever esse post, os primeiros resultados foram relacionados a uma velha disputa na economia entre Friedrich Hayek e John Maynard Keynes. Numa grande simplificação, o primeiro acha que a economia é um sistema não linear dinâmico e que deve ter liberdade para se ajustar, com os agentes econômicos se comunicando via formação de preços e que o planejamento centralizado leva à servidão (The Road to Serfdom) . Por sua vez, Keynes considera que por meio de gastos governamentais e medidas anticíclicas o Governo pode induzir centralizadamente o crescimento econômico.

A principal prova empírica de que o planejamento centralizado é falho é a relação direta entre liberdade econômica nos países e prosperidade, vide o livro Heritage Foundation, de Terry Miller e Anthony Kim. Nele, os autores mostram que existe uma relação direta entre perda de liberdade econômica precedendo a perda de liberdade política em movimentos focados no planejamento centralizado como o Nazismo, Fascismo, Socialismo e Comunismo.

Em software, até mesmo quando tentamos mudar o modelo mental e utilizar métodos empíricos (Agilidade, Lean, Customer Developement) e auto-organização dentro de estruturas de produto autogerenciadas, a busca por previsibilidade em um ambiente caótico gerou uma criação natural de controles, cargos de gestão e engessamento. A longo prazo, o resultado é que ninguém mais consegue produzir porque não há incentivos para produzir (criar software), apenas para estar no corpo de controle.

Monica de Bolle usou a alegoria das sombras na caverna de Platão para metaforizar o mesmo problema. Quem está na caverna acha que as sombras são a realidade e ignora que elas são projetadas por uma luz vinda de uma fogueira sobre coisas no mundo externo. Qualquer um que saísse da caverna e voltasse para falar que aquilo tudo era uma ilusão corria risco de morte (ironicamente, como aconteceu com Sócrates tempos depois).

A metáfora é que esse erro de interpretação da realidade e animosidade com quem pensava diferente levou novamente à aplicação de um modelo errado para otimizar o sistema econômico. Nesse caso, o planejamento centralizado do novo desenvolvimentismo, que já tinha produzido hiperinflação, baixo crescimento e perda de liberdade (destruição do sistema) na época dos militares, foi novamente usado.

Liberais e populistas, planejadores centralizados e pensadores sistêmicos raramente discordam do objetivo a ser atingido (que muitas vezes é bem intencionado), mas discordam diametralmente dos meios para se chegar lá e na interpretação da realidade.

Pensamento sistêmico, outras referências

Peter Senge, no livro “The Fifth Discipline”, criou um conjunto de leis para materializar o que ele chamou de pensamento sistêmico, o que nos ajuda a conectar algumas reflexões que pareciam ser desconexas:

As Leis:

1) Os problemas de hoje vêm de “soluções” de ontem;

2) Quanto mais foça você emprega ao empurrar, com mais força o sistema empurra de volta;

3) Comportamento cresce melhor antes de crescer pior;

4) O caminho mais fácil geralmente leva para trás;

5) A cura pode ser pior que a doença;

6) Mais rápido é mais devagar;

7) Causa e efeito não estão relacionados entre eles no tempo e espaço;

8) Pequenas mudanças podem causar grandes resultados… mas as áreas com a maior influência frequentemente são as menos óbvias;

9) Você pode ter seu bolo e comê-lo também, mas não os dois ao mesmo tempo;

10) Dividir um elefante ao meio não gera dois pequenos elefantes;

11) Não há culpa.

Outro conjunto de princípios simétricos foi definido por Don Reinertsen no livro “Principles of Product Development Flow”. Na lista do autor, são onze os problemas na atual ortodoxia no desenvolvimento de produtos:

1) Falha em medir corretamente sob o ponto de vista econômico;

2) Falta de capacidade de enxergar filas;

3) Adoração pela eficiência;

4) Hostilidade em relação à variabilidade;

5) Institucionalização de tamanhos grande de lotes;

6) Subutilização de Cadência;

7) Gestão de cronogramas e não de filas;

8) Falta de controle de “WIP” (trabalho em andamento);

9) Falta de flexibilidade;

10) Controle de fluxo não-econômico;

11) Controle centralizado.

Eliyahu M. Goldratt, no livro “A Meta”, também ressalta o problema de otimização local, ou seja, o aumento de produtividade de uma etapa do processo pela super ocupação das máquinas versus a otimização global ou o retorno sobre capital investido. Se você produz estoques, ou filas invisíveis, em uma etapa específica com rateio de custo indireto, na verdade você não está produzindo lucro. É o que o autor chama de falsa eficiência ou otimização local.

Escalando estruturas de produto e métodos ágeis

No livro “The Mythical Man Month”, Fred Brooks define a “lei de Brooks”, que simplesmente diz que adicionar mão-de-obra a um projeto atrasado o torna ainda mais atrasado. Isso porque o bom senso educado defende a lei com uma equação matemática simples, na qual o ganho de produtividade é linear e os problemas de comunicação gerados pela adição de novos profissionais é quadrático. N*(N-1), ou seja, todas as pessoas devem falar com todas as outras ou Nˆ2, se você fala com as vozes na sua cabeça.

Mas essa premissa (não é possível escalar times sem perder produtividade) parece sofrer de um bias de planejamento centralizado e lida com experiências empíricas do contrário, como o desenvolvimento em larga escala de software open source (Linux, por exemplo) ou os times de produto do Google, Apple e Amazon.

O problema não está na adição de novos coders isoladamente, mas na adição de novos coders e na aplicação de um modelo mental errado que identifica erroneamente as variáveis a serem otimizadas e vê falsas relações de causalidade, o que faz com que qualquer ação gerencial que busque melhorias seja muito parecida com uma criança brincando de fazenda de formiga.

Como disse Daniel Kahneman, no livro “Thinking Fast & Slow”, nossa predileção pelo pensamento causal nos expõe a erros sérios quando avaliamos eventos realmente randômicos (de comportamento aleatório).

Existe um viés humano de falsa causalidade. Em ambientes de produto, a maioria das relações de causa e efeito é multidimensional e não óbvia, o que faz com que você não se depare com problemas, mas com paradoxos.

O ponto central é que se você aplica um processo de modelagem e melhoria continuada correto, com estruturas autogeridas e organizadas, pesos e contrapesos entre produto e engenharia e uma cultura de empirismo e aprendizado, a escalabilidade é incrivelmente maior, sem um teto conhecido.

Conclusão

O ser humano tem aversão à incerteza e, quando confrontado por um sistema complexo, aplica naturalmente uma modelagem linear e começa a tentar otimizá-lo utilizando redução de problemas, planejamento centralizado, bom senso e ortodoxia.

O resultado deste processo é a desarticulação do sistema com resultados não previstos que são causados por medidas de supostas melhorias, o que leva à destruição do sistema em longo prazo. A reação dos agentes de controle é normalmente de negação, o que leva à imposição de mais controle e a diminuição da eficiência do sistema como um todo.

Por outro lado, se criarmos uma cultura de pensamento sistêmico e liberdade, podemos otimizar e escalar continuamente a nossa capacidade de desenvolvimento de produtos digitais com experimentos e geração de aprendizado validado empiricamente. Essa mudança de modelo mental aplicada permite que as empresas se apropriem de uma vantagem competitiva que é muito dificilmente de ser copiada, afinal o que fica aparente são sintomas de melhoria, e não o modelo mental que as viabilizou.

Quer conhecer melhor como nossos times trabalham aqui na Concrete? Entre em contato!