Em junho de 2009 ocorreu a Velocity’09, onde John Allspaw e Paul Hammond fizeram a famosa apresentação 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr (ou você pode vir aqui para os slides.)
Essa mudança não causou um aumento na velocidade de entrega de novas funcionalidades. Ou melhor, não causou um aumento na quantidade de novas entregas – afinal, eles não falaram que aumentaram o time e sem mais recurso você não pode fazer mais.
Ao ir de um deploy por mês para dez por dia, eles reduziram o tempo entre uma idéia entrar em desenvolvimento e chegar ao mercado. Daí, ao invés de fazer um grande release por mês eles passaram a fazer dez pequenos releases por dia.
Tudo bem, vocês dirão, e daí?! Afinal, se cada release tem um custo, eles acabaram foi multiplicando esse custo (overhead) por 200 – 20 dias úteis no mês, vezes 10 deploys.
E que raios tem isso a ver com BI?!
Vamos chegar lá. Eu vou fazer o seguinte:
- Ilustrar o processo de como empresas criam diferencial competitivo;
- Extrair o fundamento desse processo na forma de um conceito;
- Extrapolar esse conceito no contexto de uma empresa contemporânea;
- Generalizar – aqui eu chego aos dez deploys por mês;
- Relacionar dados e o conceito acima;
- Relacionar os dez deploys a BI.
Pegue um café, vai ser um filme!
Um Dia na Vida
Imagine duas lojas, lado a lado, na mesma rua. Ambas vendem a mesma coisa, têm o mesmo tamanho e, portanto, atendem o mesmo público.
A Loja A é gerenciada por um experiente empresário, que cresceu naquele ramo e conhece tanto os produtos quanto a clientela. Ele sabe o que todos precisam e o que vender melhor, o que dá mais lucro e como acompanhar a sazonalidade do mercado. Ele está lá há dez anos, é apreciado por todos do bairro e reconhecido como um bom comerciante. As pessoas frequentam sua loja e sentem-se bem lá.
A Loja B está no bairro a menos tempo. Como a Loja A, seu dono e gerente é um profissional experiente, competente e boa praça. Apesar de seus preços serem um pouco menores que seu concorrente, e ele ter um relacionamento bom com o bairro, seu comércio raramente tem mais público que seu vizinho.
No fundo, a única diferença entre as lojas são as coisas periféricas – arrumação dos itens, empregados, decoração etc.
Um dia, o Gerente B está parado na porta e conversando com seu vizinho e concorrente, o Gerente A:
Gerente B: Você já recebeu o novo sorvete da Kifrio?
Gerente A: Sim, recebi hoje cedo. E você, não comprou?
GB: Sim, comprei também, mas chega só amanhã. Mas, se você já comprou, porque ainda não está na vitrine?
GA: Ora, porque estamos na terça-feira. Ninguém compra coisas novas na terça-feira. Vou te dar uma dica: todo mundo quer novidade às sextas-feiras. É quando as pessoas voltam de casa se preparando para o fim-de-semana e já aparecem aqui perguntando por alguma coisa diferente. Se eu botar o sorvete agora, não terei nada novo na sexta-feira, o sorvete já não será mais novidade.
GB: Puxa, obrigado. Você não tem medo que eu te copie?
GA: Ora, temos quase tudo igual e mesmo assim eu ainda tenho mais gente aqui. Além disso, tem espaço para todos.
Isso deixou nosso herói, o Sr. Gerente B, pensativo. “É verdade”, ele concluiu, “eu posso fazer qualquer coisa e o Sr. A ainda vai vender mais que eu.”
Liberdade, Liberdade
Como o Sr. B estava em uma situação confortável, com a loja gerando um lucro satisfatório, ele ponderou que não tinha nada a perder se experimentasse algumas idéias. Afinal, depois de anos copiando o vizinho e tentando fazer tudo que ele fazia, melhor – menores preços, melhor decoração (na opinião do Sr. B, claro), mais limpa, mais iluminada etc. – ele ainda era o segundo do bairro, a alternativa quando a loja do Sr. A estava muito cheia ou estava sem um determinado produto.
Ele percebeu que estava livre para inovar.
Sua primeira ação foi colocar o sorvete na vitrine assim que o recebeu. Claro, o Sr. A torceu o nariz e até ficou meio chateado. Puxa, ele deu uma dica daquelas e o Sr. B a ignorou! Era quase uma ofensa!!
Enfim, lá foi o Sr. B vender antes os sorvetes. Na sexta-feira, dito e feito, o Sr. A começou a vender o novo sorvete e, claro, sua loja encheu como sempre.
Porém, o Sr. B notou algo: ele recebeu mais clientes atrás de sorvete do que o normal. Não mais do que o vizinho, mas mais que ele mesmo recebia.
Pega-Pega
Na semana seguinte, o Sr. B mudou sua decoração.
Na outra, alterou a posição das gôndolas.
Em seguida, comprou outras marcas de diversos produtos e passou a oferecer uma opção a mais, e para isso ele precisou reduzir o estoque de seus produtos tradicionais.
No final do mês ele mudou a decoração de novo.
O Sr. A acompanhou tudo achanda uma graça o espernear do vizinho. Afinal, esse monte de mudanças só podia significar uma coisa para o Sr. A: a Loja B devia estar com dificuldades financeiras. Talvez o Sr. B estivesse gastando muito em casa, ou esteja passando por alguma doença na família – vai saber, se consolou o Sr. A.
Do ponto de vista do Sr. B, porém, o mundo estava diferente:
- Ao mudar sua decoração pela primeira vez, ele notou que apareceram mais crianças que o normal;
- Quando ele mudou as gôndolas, a clientela ficou mais tempo dentro da loja;
- As novas marcas não fizeram sucesso. Algumas pessoas voltaram por elas, mas a maioria ignorou-as;
- Na segunda mudança de decoração, as crianças pararam de aparecer.
A cada mudança, o mercado respondia. Nem sempre a resposta era boa – na verdade, nenhuma ainda não tinha valido a pena. Ele não chegou no final de semana com mais dinheiro do que na semana anterior. Porém, ele persistiu.
Um belo dia, algum tempo depois, o Sr. A tomou um susto ao notar que a Loja B tinha, aparentemente, quase tanta gente quanto a dele. No começo ele ignorou isso como uma impressão errada ou uma observação distraída. Porém, a cada semana que passava a Loja B parecia diferente e com um pouco mais de movimento. Em alguns meses a Loja B estava completamente diferente e com outros produtos. Apesar de seu movimento não ter mudado, parecia ao Sr. A que o vizinho agora tinha mais clientes, e clientes que ele não conhecia.
Consternado, mais aborrecido por perder seu posto de líder do que perder vendas, ele puxou conversa com o Sr. B, que contou que seus novos clientes eram amigos dos clientes antigos, que vinham ali por causa da propaganda boca-a-boca atrás de produtos específicos.
O Sr. A pensou e pensou e concluiu que não seria um problema se arriscar. Afinal, ele ainda era a loja do bairro. Começou a experimentar e passou pelo mesmo que o Sr. B: as mudanças alteravam as coisas (público variava, ocupação da loja variava), mas não os resultados (as vendas não mudavam).
Em pouco tempo o Sr. A desistiu de tentar fazer a mesma coisa que o Sr. B e voltou aos seus métodos tradicionais.
Eu não vou finalizar essa história, mas apenas dizer que o antigo equilíbrio estático entre as lojas acabou – a cada dia as coisas eram diferentes e nunca se repetiam. Os Senhores A e B continuam amigos até hoje, e o bairro continua com duas lojas de boa qualidade. (E foi essa paz até o dia em que o Sr. C abriu sua loja do outro lado da rua, mas essa fica para outro dia. ;-) )
O Nome do Jogo É Acumulação
Essa pequena história, totalmente fictícia e completamente baseada no filme Concorrenza Sleale, ilustra pontos importantes nos negócios:
- Quem decide qual é a melhor empresa é o consumidor, não o empresário;
- Ninguém nunca sabe o resultado de algo até tentar. Você pode suspeitar, mas só vai saber quando fizer;
- Imitação não cria vantagem.
No início, o Sr. B não conseguia fazer crescer seu negócio. Ele seguiu todas as boas práticas de mercado, alinhou-se com a empresa de maior NPS do segmento e mantinha um portfólio testado e aprovado pelos consumidores. Apesar de fazer tudo certo, a Loja B não conseguiu superar seu marketshare tradicional.
O Sr. B abandonou sua estratégia tradicional e decidiu adotar inovação como um meio de gerar novos fluxos de receita. A tática inicial era “uma novidade toda semana”. Depois de algum tempo ele descobriu quais novidades geravam maiores retornos e aprendeu como rotineiramente criar esss novidades e assim sustentar um nível maior de faturamento.
Seu segredo era fazer pequenas mudanças, que alteravam a loja de um dia para outro. Enquanto ele descobria como fazer isso, a Loja A seguia repetindo suas estratégias de inovação, como lançar produtos às sextas-feiras e decorar a loja em cada data comemorativa como Natal e Páscoa.
Como resultado, enquanto que a Loja A permaneceu estável no seu segmento, a Loja B atingiu novos públicos, descobriu outros produtos e combinou o processo de inovação com o ambiente local para agradar a um número maior de consumidores, enquanto alterava seu mix de produtos para ficar mais rentável.
O gerente da Loja B assimilou uma realidade: ele não sabe o que vai na cabeça do mercado, mas sabe que testar novas idéias é o mesmo que passear com a loja pelo bairro. Testar novas idéias permite descobrir oportunidades que, bem aproveitadas, tendem a melhorar sua lucratividade.
Já o Sr. A colocou a sua loja em risco, mesmo sem saber disso: as pequenas mudanças em seu entorno distanciam a empresa do mercado. Daí, num belo dia ele vai perceber que não fatura mais tanto quanto antes. Quando ele começar a se mexer já terá perdido o passo e terá que trabalhar dobrado para alcançar o Sr. B (que está na disputa com o Sr. C).
Pequenas mudanças permitem a uma empresa explorar o espaço de oportunidades. Cada pequena vitória, cada pequena melhoria soma-se ao longo do tempo, causando um acúmulo de mudanças que dão o diferencial competitivo.
Claro, existe o lado oposto: um acúmulo de pequenas mudanças erradas vão levar a empresa pouco a pouco para o buraco. Por isso o ciclo PDCA (planeje, execute, verifique e ajuste) é tão importante: ele é um instrumento que permite determinar a qualidade e a direção dessas modificações.
Velocidade é Agilidade
Vamos voltar ao tema da 10+ Deploys Per Day. Eles dizem:
- O negócio requer mudanças (slide 13);
- Mudanças causam a maior parte das quebras (slide 14);
- Diminuindo o risco de mudanças através da mudança de cultura (slide 16).
O argumento deles é que ao invés de fazer grandes mudanças a cada grande intervalo de tempo, mudanças menores a intervalos menores oferecem melhor controle sobre os resultados. Até então, o mais frequente era um grande atrito entre desenvolvimento e operação, com a operação resistindo a mudanças vinda dos desenvolvedores.
Ora, mas que danados esses desenvolvedores! Queriam mudar tudo o tempo todo!
Bom, os desenvolvedores não queriam mudar porque eram tipos irriquietos e bagunceiros, mas porque o negócio precisava mudar, ou poderia ir à falência.
Ao resistir à mudança, a operação não estava protegendo a estabilidade do serviço, mas sim barrando a inovação e impedindo a empresa de mudar e melhorar. Ao acharem como coordenar desenvolvimento e operação, criando o cerne da cultura DevOps, eles resolveram não um problema técnico, e sim um problema de negócio muito sério!
Habilitar uma grande velocidade na mudança teve um efeito intencional, aumentar a estabilidade do serviço sem barrar a mudança, e um efeito não-intencional, que foi diminuir o tempo entre a idéia e a execução. Se antes toda idéia nova levava mês ou meses até ser colocada em produção e ainda representava um risco de perda de faturamento, com DevOps a todo vapor isso caiu para o mínimo possível, deslocando o gargalo de criação de mudanças da operação para o desenvolvimento e o negócio.
Não importava quão rápido negócio e desenvolvimento conseguiam inventar moda, a operação dava conta. Pensou? Programou, implantou, mudou! (E se desse pau, era mais simples e fácil voltar atrás e consertar a situação.)
Já que agilidade é definida como “a capacidade de mudar rapidamente a posição do corpo”, então agilidade tem a ver com velocidade de mudança. DevOps é, portanto, um habilitador de agilidade de negócio pois DevOps permite ao negócio mudar a empresa rapidamente.
Não confunda “capacidade de mudar rapidamente” (agilidade operacional = agilidade de negócio) com Business Agility.
Em resumo, uma empresa atual precisa ter agilidade de negócio (operacional) para poder mudar constantemente, tanto para responder às variações do mercado, quanto para explorar novas idéias. Essa agilidade é, em grande parte, garantida por coisas como DevOps.
Vamos deixar essa questão pendurada e voltar nosso olhar para outro aspecto da vida de uma empresa.
A Empresa Invisível
Uma loja de bairro é uma empresa concreta, tangível: tudo está à vista e pode ser tocado com a mão, desde o estoque no quarto dos fundos, aos consumidores entrando pela porta da frente e a operação dos empregados. Mesmo os fornecedores são visíveis, ainda que esporadicamente. Eventualmente há um computador no balcão, que processa a contabilidade, mas isso é o tudo.
Empresas um pouco maiores, porém, tendem a ser mais informatizadas: os clientes interagem por telefone ou internet, estão registrados em um sistema, que também registra o estoque e os empregados, que não necessariamente estão no mesmo local. A empresa pode oferecer algum tipo de suporte, que é controlado por outro sistema informatizado, que pode acionar remotamente os times técnicos, e assim por diante. Computadores são o que unem e fazem a empresa rodar todo dia, o dia todo.
Isso significa que muitas das novidades não serão lançadas (apenas) como produtos ou serviços mas (também) como mudanças em processos e aplicações. Em 2023, e já há algum tempo, o departamento de informática tem para a empresa contemporânea o mesmo valor que o departamento de engenharia tinha para uma fábrica de 100 anos atrás. Sâo eles que constroem os novos produtos, que implementam a gestão dos processos, as novas linhas de produção e que aumentam as eficiências. Depende-se muito da Informática para realizar as melhorias que causam crescimento e que geram vantagens de negócio.
O livro The Phoenix Project, e sua sequência, The Unicorn Project, mostram como a informatização se torna o novo centro de negócios numa empresa.
Caso o Sr. B fosse o dono de uma empresa um pouco maior que sua loja de bairro, ele faria mais experimentações com sistemas e processos do que com decorações e linha de produtos.
Se você desligar os computadores de uma empresa dessas, e de qualquer outra maior, ela simplesmente some. Quem estiver na empresa continuará a ver o que (ainda) existe de material, como estoque, mesas, armários e o próprio prédio. Porém, tudo que a empresa faz – seu funcionamento, relacionamentos com clientes e fornecedores etc. etc. etc. – sumirá, porque estão nos sistemas informatizados. Mesmo com os computadores ligados, se você olhar para longe da da sua tela, o que você verá é uma fração do que a empresa realmente é e faz.
Uma empresas informatizada é invisível e quanto mais informatizada, quanto mais digital for, menos tangível e mais invisível será a empresa.
Os dados que são criados, alterados e movidos de um lado para outro são como feixes de luz que mostram o que está acontecendo na empresa. Por isso eu sempre digo que, ao contrário da analogia feita por Clive Humby em 2006, dados não são o novo petróleo, mas sim luz: são os dados que permitem a alguém ver o que está acontecendo na empresa, a qualquer momento.
Dados não são petróleo, mas luz. Ignorar os dados é o mesmo que fechar os olhos.
Dados e Exploração
Estamos chegando lá! Aguente só mais um pouco!
Pense comigo: se a empresa existe mais como dados que como coisas, então saber o que está acontecendo na e com a empresa depende de consultar os dados. Logo, criar mudanças e até mesmo inovar depende de analisar os dados.
Além disso, para inovar você precisa testar coisas. Para saber que coisas testar e se deram certo, você precisa examinar a empresa, que é o mesmo que examinar os dados.
Portanto, da mesma forma que uma equipe de desenvolvimento e operação é algo imprescindível para uma empresa muito informatizada, uma equipe de dados é imprescindível para entender a empresa, mudar, inovar, experimentar e avaliar os resultado de tudo isso.
Quando alguém vem com uma nova idéia, junto já traz a métrica e o indicador que será necessário para avaliar os resultados dessa idéia. Por exemplo, suponha que o Marketing decide oferecer um e-book em troca dos e-mails dos visitantes, e divulgam esse e-book em uma rede social. A métrica de sucesso é quantidade de novos e-mails capturados com a página/e-book e o indicador pode ser quantidade de novos e-mails capturados por dia.
Antes mesmo de a campanha ser posta na rua o indicador já terá sido definido e já estará sendo acompanhado – afinal, faz parte da inovação. Esse é um caso onde o dado a ser usado no ciclo PDCA já será coletado e analisado de saída ao invés de entrar pela esteira típica de projetos de BI, em que as coisas são construídas durante um tempo relativamente longo (mês ou meses).
Agora, e quando nasce uma pergunta de negócios do nada? Não há escapatória: é preciso ir até a equipe de dados, abrir uma demanda e esperar que ela aconteça.
Até esses dados serem obtidos e analisados, a empresa estará parada, aguardando.
Estamos em 2023. Desenvolvimento e Operações conseguem fazer não dez, não 100, mas DEZENAS DE MILHARES DE VEZES POR DIA:
Enquanto isso, quantas entregas de dados seu time está fazendo?
Uma por dia?
Uma Entrega por Dia
Se você está em uma empresa normal, dificilmente você faz uma entrega por dia. Talvez entregue um produto de dados por semana, por time, se tanto. Daí, se você tiver cinco times, talvez entregue em média um por dia a cada semana.
Por que é que em 2023 ainda não temos a tecnologia e gestão e cultura necessária para entregar um produto de dados por dia?
Se você quiser tornar a sua empresa verdadeiramente ágil, capaz de descobrir e explorar oportunidades enquanto elas existem, você precisa tornar o seu projeto de dados tão rápido (=ágil) quanto um projeto DevOps.
Você precisa receber uma demanda de dados de manhã e entregá-la à tarde.
Pergunte-me como. :-)
Conclusão
A Humanidade conhece a alvenaria há milênios e mesmo assim ainda dá trabalho construir uma casa. Temos Engenharia Civil, Arquitetura, Eletricidade, Hidráulica e um monte de outros conhecimentos envolvidos na construção que seja de um simples puxadinho no fundo do terreno. Depois de pronta, uma construção de alvenaria precisa receber manutenção periódica, sem contar a limpeza e eventuais tratamentos químicos (como descupinização).
Construir um prédio em alvenaria não é o mesmo que fazer um bolo de caixinha: requer conhecimento especializado, profissionais capazes e experientes, um bom plano, tempo e dinheiro. E, insisto, temos essa tecnologia há milênios. Milhares de anos. Centenas de milhares de dias.
A Informática com computadores eletrônicos nasceu há coisa de 70 anos e nesse curtíssimo espaço de tempo (todos os bebês que nasceram junto com o primeiro computador eletrônico do mundo ainda podem estar vivos) já mudou e mudou e mudou. Ainda estamos aprendendo a usar essa ferramenta. Já tentamos construir sistemas usando as mesmas técnicas de Alvenaria, e vimos que não funciona. Faz vinte anos que estamos testando outra abordagem e parece estar indo melhor.
Ainda falta muito para descobrir (ou para termos certeza) de qual é a maneira correta de se construir sistemas e desenvolver soluções informatizadas.
Agora, e com dados? Pior ainda!! Se erramos com desenvolvimento por décadas, imagine com dados, que está por aí há metade desse tempo!
Hoje estamos vivendo a Era Ágil, que entrega melhorias e mudanças rapidamente, com menos riscos de interrupções e menos tempo entre idéia e execução.
Os projetos de dados precisam atingir o mesmo patamar. Não existe motivo para um executivo descobrir uma pergunta de negócio de manhã e não ter a resposta à tarde.
Se você almeja sustentabilidade da sua empresa, isto é, que ela dure por gerações, você precisa estar sempre um passo à frente. Para isso, precisa saber o que está acontecendo nela que, graças à informatização, é invisível aos cinco sentidos. Você precisa de dados disponíveis e analisados em horas ao invés de meses ou mesmo semanas. Não dias, horas.
Para você conseguir fazer isso você precisa colocar a Tecnologia em segundo plano e subordiná-la ao Negócio.
Até a próxima! ;-)
Geek BI 