Por que criar o BizAgility ?

• A criação do BizAgility é apenas uma consequência natural de um acumulo de experiências. Um passo importante em um longo caminho de aprendizados em que esperamos juntar muito conhecimento coletivo.

  Estes vários aprendizados tiveram custos diferentes e resultados também muitos diferentes. Em muitos casos perdemos tempo, dinheiro, motivação, erramos e acabamos aprendendo muito pouco. Em todos os casos, sempre aprendemos mais errando do que acertando.

  Para abrir este espaço de compartilhamento de conhecimento, experiências e aprendizados, vou começar com a minha na Concrete Solutions.

  Na Concrete Solutions, empresa que ajudei a fundar, erramos bastante também. Ainda assim, conseguimos a predominância de uma mente científica e com isso separar o que era ilusão ou reserva de mercado do que era ciência. Felizmente continuamos a evoluir e fazer software cada vez melhor.

  Passamos por algumas epifanias fundamentais e acho que as duas últimas foram provavelmente as mais contra intuitivas e reveladoras.

  A primeira veio com o nosso aprendizado junto com o movimento ágil. Nós aqui no Brasil ainda sentíamos em 2007 o mesmo sofrimento que os criadores do manifesto ágil sentiam no idos de 2001.

  Tentávamos repetidas vezes fazer nossos projetos de software e mesmo nos casos de “absoluto sucesso”, sentíamos um gosto ruim na boca e decepção. As entregas sempre pareciam demorar muito. O uso dos produtos pelos clientes finais sempre exigiam muito retrabalho, mostrando uma clara falta de participação e envolvimento dos vários stakeholders. Além disso, quando o produto ia para produção vinha a surpresa: o negócio já tinha um novo concorrente fazendo algo diferente e o sistema já não atendia às novas necessidades.

  Depois de muita literatura e de levantar a cabeça para o que a ciência demonstrava sobre fazer software resolvemos implantar Scrum na Concrete, e felizmente nunca mais olhamos para trás.

  Fazer software, de fato, precisa de muito mais entrega e participação dos stakeholders. Está muito longe da visão especifícação-ganttchart-tocar bumbo que ainda domina o mercado brasileiro. Escrever um documento para dizer para o programador o que fazer e só olhar no final não é apenas ineficiente do ponto de vista da comunicação (Darwin, Mehrabian, Birdwhistell, etc). É um tiro no pé que congela o que foi pedido no tempo e no espaço. Desconsidera o apropriado balanceamento de todos os interessados naquilo que está sendo construído.

  Hoje, o desenvolvimento iterativo e incremental é comprovadamente melhor do que o velho waterfall. A entrega é mais rápida e mais barata. O produto final gera mais valor, e tem qualidade melhor tanto do ponto de vista técnico (com menos bugs, por exemplo) quanto na percepção do usuário final.

  Já ouvimos inúmeros casos da sequinte sequência de eventos em um projeto waterfall:

  1. Empresa acha projeto interessante e resolve encomendar.
  2. Entre 1 e 6 meses preparando uma RFP. (nesse ponto já há pressa para receber o projeto pronto pois a oportunidade de negócio está diminuindo de valor)
  3. Projeto tem prazo reduzido para 3 ou 4 meses.
  4. Entre 1 e 2 meses para escolher vencedor da RFP.
  5. Inicia projeto, entre 1/2 e 2 meses escrevendo especificação técnica. (agora só falta programar, no prazo há entre 1 mês e 2 e 1/2 meses)
  6. Entre 3 e 6 meses, o código está 99% pronto, só falta integrar, fazer o deployment e começar a usar.
  7. Entre 6 e 15 meses de retrabalho, descobrindo informações fundamentais dos usuários e integração.

   
  Para o projeto médio, desde a idealização do projeto até o sistema ver o seu primeiro uso e começar a gerar valor em produção se passaram entre 11 e 31 meses, isso se não desistiram em algum lugar no meio. E aí os donos de projetos passam então pelos 5 estágios de Kübler-Ross. Na aceitação ou se desiste de inovar ou se resolve procurar o que os estudos sérios dizem a respeito, é a chance que esse projetos tem de tentar algo diferente, que tal Scrum ?

  Na Concrete, usar Scrum, nos ajuda a manter baixo o débito técnico, como também mantém o negócio suportado por aquele produto competitivo, porque em momento algum sua velocidade para fazer software novo diminui. E isto tudo sem mencionar a felicidade dos times de poder fazer algo gratificante, e evitando completamente a marcha mortal das noites viradas em projetos atrasados e de gerentes acreditando que ao se colocar nove mães no projeto, o filho nasce em um mês.

  Mesmo com toda a melhora com a adoção de Scrum, na Concrete, ficávamos com um gostinho de quero mais. Foi durante o ano de 2011 que veio nossa mais recente epifania. Esta epifania foi a combinação nas nossas práticas de Scrum com as práticas de Customer Development e do processo iterativo aplicado aos modelos de negócio.

  Usando XP e Scrum os projetos já melhoraram muito, mas sem o uso das práticas de Customer Development pelos Product Owners, ainda viamos a seguinte sequência de eventos:

  1. Empresa acha projeto interessante e resolve encomendar.
  2. Entre 1 e 6 meses preparando uma RFP. (nesse ponto já há pressa para receber o projeto pronto pois a oportunidade de negócio está diminuindo de valor)
  3. Projeto tem prazo reduzido para 3 ou 4 meses.
  4. Entre 1 e 2 meses para escolher vencedor da RFP.
     Repare que até aqui nada mudou. A agilidade começa no projeto, mas o negócio não é ágil, é waterfall
  5. Inicia projeto, após 1/2 e 1 mês já temos algum software em QA sobre o qual podemos evoluir a visão.
  6. Entre 2 e 3 meses, o sistema está essencialmente pronto e já bastante testado.
  7. Entre 2 e 3 meses de retrabalho, muitas vezes stakeholders fundamentais que achavam que só precisariam olhar quando o sistema estivesse pronto são surpreendidos. E mais vezes ainda o feedback dos usuários finais exigem várias outras modificação.

   
  Para o projeto médio, desde a idealização do projeto até o sistema ver o seu primeiro uso e começar a gerar valor em produção se passaram entre 4 e 12 meses, entre 6 e 15 meses o sistema entra em pico de potencial de geração de valor.

  Mesmo no pior caso, o projeto médio ainda é muito superior que o velho waterfall.

  Só que isso ainda não estava bom para a gente.
  A pergunta que ressonava tinha relação direta com a visão de MVP. Ainda parecia muito grande, desconsiderando a necessidade de um rápido ciclo de feedback direto do usuário final. E o ciclo curto é ainda mais fundamental no caso de Startups de Internet. Nós já fizemos os sistemas de muitas desde 2001 e sabíamos muito bem disso.

  O Product Owner tem um grande desafio em suas mãos.
  Se o Product Owner tiver uma visão Lean do seu MVP e souber substituir as respostas pelas perguntas corretas com os conceitos de Customer Development, a entrega utilizando os conceitos ágeis será sua melhor aliada.

  Um projeto típico poderia muito bem ser expresso como:

  1. Empresa acha projeto interessante e resolve começar.
  2. Entre 1/2 e 1 mês montando o seu time de Customer Development e gerando as primeiras hipóteses de geração de valor.
  3. Entre 1/2 e 1 mês com potencialmente 1a hipótese validada.
     Ao mesmo tempo, entre 1/2 e 2 meses já montando times com RFP/contratação de pessoal/fornecedores enquanto isso outras hipóteses continuam a ser testadas e as primeiras validadas começam a ser construídas.
  4. Entre 2 e 3 meses não só se gera grande quantidade de conhecimento validado, mas o sistema está em produção e começar a gerar receita.

   
  A perspectiva passa a ser de um projeto que entre 3 e 6 meses pode começar a se pagar e com um processo muito melhor de validação do modelo de negócios utilizado. O produto final é melhor, com ainda menos débito técnico e com um negócio em si, muito mais saudável.

  Depois de todo este aprendizado, criamos o BizAgility para ser mais uma oportunidade de compartilhamento de conhecimento visando trazer o estado atual da arte para Empreendedores, Gestores de Tecnologia, Inovadores e Donos de Produto. Para ajudar as empresas na competição por inovação. Ao mesmo tempo fornecer a tal ajuda aos Product Owners.

  Ajudando a inovação, ajudamos a sociedade em geral e como consequência, criamos condições para que trabalho de quem faz software, não seja apenas mais satisfatório, mas também mais profissional e mais eficaz.

  E o que vem por aí no BizAgility além deste próximo evento ?

  Este é só o primeiro post neste blog. Eu e a Concrete Solutions estamos longe de pretender ficar sozinhos nessa nova visão. Acompanhe este blog e verá quem mais nessa indústria pode falar sobre o potencial do que está por vir. O nosso BizAgility é um passo. Nós fizemos o primeiro evento porque ele precisava existir. Precisamos dele agora e não depois.

 

Posts Relacionados

 

WorkChopp #3 na Intacto 05/03/2012 1 comment