As 2 Leis de Borba – Parte 2 – Sua aplicação a modelos de negócios
No primeiro post desta série, enunciei as 2 Leis de Borba para Arquitetura de Software, neste post vamos ver como essas leis se aplicam a modelos de negócios.
Primeira Lei de Borba para Modelos de Negócio: "Todo Modelo de Negócio está Errado."
Um modelo de negócio não vale nada enquanto está só no papel. Somente um negócio funcionando e gerando receita pode provar o valor do modelo. Não adianta passar meses elaborando o modelo mais maravilhoso do mundo, e apenas mostrar aos amigos. Enquanto não existir um negócio rodando e sendo usado por usuários (clientes) de verdade, você ainda estará na estaca zero.
Agora digamos que eu tenha lançado o meu produto, baseado em um modelo de negócios que foi desenvolvido utilizando as metodologias de Customer Development e Lean Startup e que conseguiu atingir o product/market fit e está gerando receita. Consegui finalmente provar que meu modelo de negócios funciona, porém neste caso se aplica a segunda lei...
Segunda Lei de Borba para Modelos de Negócio: "Todo Modelo de Negócio definido e que comprovadamente funciona, estará errado em breve"
Tudo muda o tempo todo. Pessoas mudam, usuários mudam, clientes mudam. Lembre-se que depois de lançado seu produto não é mais seu, é de seus usuários. Se você não conseguir adaptar seu sistemas às mudanças do ambiente, será extinto. A seleção natural de Darwin funciona aqui também.
Exemplos não faltam. Vejam por exemplo o que aconteceu com o Myspace, que era líder das redes sociais, mas foi exterminada pelo Facebook porque não soube se reinventar e lidar com o novo concorrente. Nokia, RIM e Yahoo são exemplos de empresas dominantes em outros tempos e que hoje estão atoladas em prejuízos com dificuldades para reagir.
O problema é ainda mais grave hoje, porque a frequencia de aparecimento de inovações disruptivas está aumentado a cada dia. Olhem esse gráfico que mostra a média de tempo de vida das 500 principais empresas do mundo.
As principais empresas do mundo estão cada vez mais jovens. As grandes empresas normalmente são mais pesadas para se mover, para se reinventar e estão sendo sucedidas por empresas novas, criativas e ágeis. Poucas grandes empresas conseguem se reinventar e permanecer relevantes, mas temos nobres exceções como a IBM e a Siemens.
A melhor forma de enfrentar esse tipo de situação é monitorar sempre o que está acontecendo, no seu empreendimento e no mercado.
Dicas:
- Conheça seu cliente e seu mercado
- Acompanhe de perto as mudanças e sempre procure inovar em seu segmento
- Não tenha receio em canibalizar parte do seu negócio, as vezes é necessário
- Mantenha sua empresa ágil
Esteja disposto e preparado a mudar sempre. Não seja um Dodô.
As 2 Leis de Borba – Parte 1
No ano passado preparei uma aula sobre Arquitetura de Software para a turma de mestrado do CIN/UFPE. O fio condutor da aula era a desmistificação do conceito de arquitetura, oferecendo uma abordagem mais pragmática. Ao invés de uma arquitetura torre de marfim, cheio de diagramas e regras, apresentei uma opção evolutiva, incremental e flexível. Durante a preparação do material tive um insight interessante, que se transformou nas 2 Leis de Borba para Arquitetura de Software.
Primeira Lei de Borba para Arquitetura de Software: "Toda a Arquitetura definida está errada."
Uma arquitetura definida não vale nada enquanto não construimos um sistema em cima dela. Somente um sistema rodando em produção pode provar o valor da arquitetura. Não adianta passar meses elaborando a arquitetura mais maravilhosa do mundo, implementando apenas código de infraestrutura, porque enquanto não existir um sistema rodando e sendo usado por usuários de verdade, você ainda estará na estaca zero.
Agora digamos que eu tenha lançado o meu produto, baseado em uma arquitetura definida e tenho pessoas usando de forma satisfatória o meu sistema. Consegui finalmente provar que minha arquitetura funciona, porém neste caso se aplica a segunda lei...
Segunda Lei de Borba de Arquitetura de Software: "Toda Arquitetura definida e que comprovadamente funciona, estará errada em breve"
Tudo muda o tempo todo. Pessoas mudam, negócios mudam e consequentemente empresas mudam e requisitos mudam. Lembre-se que depois de lançado seu produto não é mais seu, é de seus usuários. Se você não conseguir adaptar seu sistemas às mudanças do ambiente, será extinto. A seleção natural de Darwin funciona aqui também.
A melhor forma de enfrentar esse tipo de situação é adotar uma abordagem evolutiva. Defina e construa sua arquitetura/infraestrutura a medida que for construindo seu sistema. Instale seu sistema o mais rápido possível e aprenda com seus usuários.
Dicas:
- Crie uma solução de baixo acoplamento e alta coesão, para facilitar as mudanças
- Use TDD para poder integrar o novo código de forma mais rápida e econômica
- Utilize design incremental
- Refactoring sempre
- Crie uma estrutura para fazer (ou desfazer) deployments na maior frequencia possível (Facebook faz 5 vezes por semana)
- Colete métricas para aprender com seus usuários e tomar decisões baseadas em dados reais
Esteja disposto e preparado a mudar sempre. Não seja um Dodô.
O mais importante é que a aplicabilidade dessas leis não se limitam ao contexto de Arquitetura de Software. mas isso é assunto para o próximo post desta série.
Métricas em Desenvolvimento de Software e BI
Estou participando aqui no trabalho do ajuste do data mart de projetos. Esse trabalho me fez lembrar de uma apresentação que fiz no Developer's World 2004: "Métricas em Fábricas de Software" ou "Tudo o que você sempre quis saber sobre o seu projeto mas tinha medo de perguntar".
Tudo evolui tão rápido na nossa área, que normalmente essas apresentações antigas ficam facilmente obsoletas, mas dando uma olhada nessa, achei que as perguntas ainda são bem relevantes e interessantes. Cá pra nós eu odeio mesmo o título oficial, não suporto o termo "Fábrica de Software". Fábrica dá uma conotação próxima a manufatura, que não representa de forma alguma o conceito de desenvolvimento de software.
De qualquer forma, estou querendo chamar a atenção para as ferramentas que estamos usando para implementar nosso data mart de projetos. Estamos usando uma suite open source chamada Pentaho. Plataformas de BI normalmente são complexas e muito caras, mas a ferramenta de ETL do pentaho (Kettle ou Pentaho Data Integration) é muito boa. Tem seus pequenos problemas de interface mas em termos de funcionalidades é bastante poderosa. Me irrita bastante quando as pessoas precisam fazer um trabalho específico e não usam a ferramenta adequada, por isso quando precisar criar um data warehouse ou mesmo quando for fazer uma migração de um banco para outro, utilize uma ferramenta de ETL, e em especial considere utilizar o Kettle. Você vai ganhar muito tempo...
Para curtir um pouco a nostalgia, aqui está a apresentação de 2004.