Como criar uma startup: Capítulo 2 – Porque precisamos empreender
Este é o segundo post da série "Como vou criar uma startup". Para entender e aproveitar melhor, é interessante ler os posts na sequência:
- Capítulo 1 - A morte de um empreendedor
- Capítulo 2 - Porque precisamos empreender
- Capítulo 3 - De onde vem as ideias?
- Capítulo 4 - Como transformar uma ideia em um produto
- Capítulo 5 - Customer Development e Lean Startup
Capítulo 2 - Porque precisamos empreender
No capítulo anterior eu contei a história de como o fracasso com a minha primeira empresa matou a vontade que tinha dentro de mim de ser um empreendedor. E o que aconteceu depois?
Desde que saí da NetPE construí uma carreira na área de desenvolvimento de software trabalhando em várias tipos de empresas diferentes: softhouses tradicionais, empresas de produtos, pontocom, fábricas de software e institutos de inovação. Todas essas variadas experiências além da minha própria sede por conhecimento e evolução me fizeram um profissional bastante respeitado.
O maior orgulho que eu tenho é de ter conseguido progredir na carreira sem precisar sair da área técnica. Adoro o que faço e se tivesse que me transformar em gerente de projetos para atingir um patamar salarial que eu desejava ia ser muito frustante. Mas agora tudo acabou...
Desde o fim do ano passado eu comecei a sentir que cheguei no fim da linha. Daqui pra frente seria apenas mais do mesmo. Mais consultorias, mais projetos, mais produtos, mas nada de novos desafios. Como aceitar limites? Como reconhecer que não há mais nada de novo a fazer? E pensando nessas coisas, de repente deu um click. Eu estava errado.
Depois de muitos anos acordei o espírito empreendedor que tinha dentro de mim. Como diz o ditado, vingança é um prato que se come frio e a partir daquele momento comecei a me preparar para a revanche. Estava aí o desafio que eu estava procurando.
Depois de todo esse histórico, acho que dá para entender poque estou abraçando este desafio, mas quero ir além. Quero dizer que VOCÊ também precisa empreender. O Brasil já tem funcionários públicos demais e o que precisamos para crescer ainda mais como nação são mais (e melhores) empresas inovadoras.
Se sua ambição for financeira, ser um empreendedor talvez seja a única alternativa para ficar rico. Ter um emprego funciona de maneira semelhante a uma empresa que tem o faturamento atrelado ao custo, ou seja, quando fatura mais, o custo sobe na mesma proporção. O seu custo são as horas trabalhadas a única forma de ganhar mais é trabalhando mais. Com um emprego você não consegue rentabilizar o valor gerado pelo seu trabalho.
Garanto que sendo um empreendedor não vai faltar emoção e aventura na sua vida. Você nunca vai ficar entediado. Não existe segurança mas o importante é que também não existe limites para o sucesso. Quem sabe não vai ser você (ou eu) o criador do próximo Google ou Facebook? Parece impossível? Acredite, NÃO É!
Outra coisa boa é que não falta dinheiro para investir em empresas inovadores. Quase todo dia me deparo com notícias sobre fundos procurando bons negócios para investir, especialmente em nossa área. Infelizmente faltam boas ideias. Mas, como ter boas ideias? De onde vem as ideias?
continua em: Capítulo 3 - De onde vem as ideias?
Para mais informações sobre esses assuntos, siga-me no twitter: @luizborba
Como criar uma startup: Capítulo 1 – A morte de um empreendedor
Este é o primeiro post da série "Como vou criar uma startup". Para entender e aproveitar melhor, é interessante ler os posts na sequência:
- Capítulo 1 - A morte de um empreendedor
- Capítulo 2 - Porque precisamos empreender
- Capítulo 3 - De onde vem as ideias?
- Capítulo 4 - Como transformar uma ideia em um produto
- Capítulo 5 - Customer Development e Lean Startup
Introdução
Começo hoje a publicar uma série de posts sobre empreendedorismo na internet e o que estou fazendo para entrar neste mundo. Espero que estes posts motivem uma discussão construtiva, que ajude todas as pessoas que estão pensando em empreender.
Capítulo 1 - A morte de um empreendedor
Eu ainda estava na universidade quando consegui o meu primeiro emprego como desenvolvedor. Foi em 1991 e eu gostava muito do meu trabalho, mas o que eu queria mesmo era ter minha própria empresa. Obviamente eu nem sabia o que significava ter uma empresa, mas o que me movia nesta direção era a vontade de criar algo importante, de mudar o mundo. Em 1994 eu saí do meu emprego e junto com alguns amigos fundei a minha primeira empresa, a NetPE BBS.
Para quem não sabe, BBS (Bulletin Board System) é um sistema onde os usuários podem se conectar utilizando um modem e ter acesso a vários tipos de serviço como download, upload, forums, chat, jogos, etc. Talvez possa ser visto como uma internet do tempo das cavernas.
O início foi promissor, como quase não tínhamos concorrência, a empresa cresceu muito rapidamente. Chegamos a ser a maior BBS do Norte/Nordeste, com mais de 40 linhas telefônicas (cada linha representava 1 usuário conectado). Imagine só, 40 computadores conectados em um servidor... parece ridículo hoje em dia, mas acredite, naquela época era algo grandioso. Empolgado com o sucesso, cada vez mais eu acreditava de que aquele seria o negócio da minha vida, entretanto, um belo dia tudo mudou. A internet chegou.
Em 95 a internet comercial chegou no Brasil, até então apenas as universidades tinham acesso. De cara várias grandes empresas entraram neste novo negócio. Em Recife a Elógica foi a maior delas. Nessa época a NetPE ia muito bem das pernas, mas o investimento para se tornar um provedor era alto e nós não tivemos condições. De quebra nós ainda recusamos uma proposta de compra pela Elógica (a gente se achava...).
Como era de se esperar, nosso negócio mixou. Levou um bocado de tempo para nos tornarmos um provedor internet e quando finalmente conseguimos, já tínhamos perdido metade de nossos clientes. Mesmo assim, viramos a NetPE Internet.
Com a NetPE Internet voltamos a crescer, mas as margens eram bem mais apertadas do que na época do BBS. Como BBS éramos gigantes, mas como provedor internet éramos nanicos. Para compensar, fazíamos vários serviços na web: jogos, mecanismo de busca, catálogo de médicos, e tantas outras coisas que nem me lembro. Em 96 submetemos ao Softex, em parceria com a Ecossistemas (atual Facilit), um projeto de desenvolvimento de jogos para internet. O projeto foi aprovado.
A idéia do projeto EasyGames (que depois virou Coliseum) era desenvolver jogos simples mas que pudesse ser jogado pela internet. O primeiro desses jogos foi o NetPong (atualização do clássico Pong). Para resumir, vendemos muito pouco e quando dinheiro acabou fomos obrigados a parar.
A situação do provedor não melhorou, mal se pagava e quase não crescia. Em 98 eu desisti. A NetPE continuava funcionando, mas eu decidi não trabalhar mais lá. Fui procurar emprego. Continuei como sócio ainda por um bom tempo até finalmente sair da sociedade. O resultado me deixou muito frustrado. Morreu um empreededor. Aquilo não era para mim. Minha vontade era ser um empregado assalariado... e foi assim até 2011...
continua em: Capítulo 2 - Porque precisamos empreender
Para mais informações sobre esses assuntos, siga-me no twitter: @luizborba
Arquitetura Pragmática
Fui convocado por Silvio Meira para dar uma aula sobre Arquitetura de Software para a turma de engenharia de software na pós-graduação da UFPE. Minha intenção foi fugir do óbvio e mostrar uma nova visão sobre arquitetura, fortemente influenciada pelas metodologias ágeis e pela evolução das tecnologias web. A aula foi bem proveitosa e estou satisfeito por mostrar algo que vai além das abordagens tradicionais. Este trabalho é marcante porque contém pela primeira vez os enunciados das primeira e segunda lei de Arquitetura de Software de Borba 
))))))
Todas as coisas que todo programador não pode deixar de saber
Fiz essa apresentação com o objetivo de resumir e simplificar as coisas mais básicas que todo profissional de desenvolvimento de software simplesmente não pode deixar de saber. Acho que ficou bem legal e funcionou bem em 2 níveis: para os iniciantes se prepararem para o mercado de trabalho e para os experientes lembrarem de coisas que muitas vezes são esquecidas. Foi apresentado no C.E.S.A.R e em várias universidades daqui de Recife. A primeira apresentação foi gravada e você pode ver e ouvir clicando aqui (é o webseminar 15).
Será o Java o novo COBOL?
O projeto Green foi iniciado em 1991 pela Sun com a intenção de criar uma plataforma para desenvolver sistemas embarcados, em especial para set-top boxes da indústria de tv a cabo. Nesta época a internet era menor que uma ameba se compararmos com hoje. A web já existia (foi criada em 91), mas ainda não era notada. Apenas em 94, quando o browser Mosaic foi criado é que a world wide web começou a ser popularizada. O pessoal da Sun não esteve alheio a esse movimento e ainda em 94 redirecionou o projeto para web. Finalmente em 1995 a plataforma Java (rebatizada) foi lançada, já contando com o suporte do principal browser da época, o Netscape.
O Java trouxe uma quantidade imensa de inovações para a indústria de desenvolvimento de software na época: máquina virtual, multi-plataforma ("write once, run everywhere"), garbage collector e em especial a integração com a web através dos applets. Foi como juntar a fome com a vontade de comer. A web começando a bombar no mundo todo e uma plataforma de desenvolvimento inovadora e integrada com essa nova tecnologia.
Identificado como inovação o Java aglutinou o interesse de inúmeros desenvolvedores open source, que com suas criações e o poder de difusão da web, alavancaram em tempo recorde o Java para ser a principal plataforma de desenvolvimento de software do planeta. As grandes empresas não ficaram de fora e com mais alguns investimentos tornaram Java também a principal solução para o mundo enterprise. Curiosamente os applets que foram a ponta de lança para a divulgação da plataforma acabou não tendo sucesso.
A característica multi-plataforma do Java prejudicava diretamente a estratégia da Microsoft, que dependia de máquinas Intel com o sistema operacional Windows. A Microsoft não deixou barato e em 2002 lançou o .NET Framework, que era conceitualmente uma cópia do Java, mas que só rodava no Windows. A partir deste momento, as duas plataformas começaram a disputar uma corrida de inovações para conquistar mais mercado. A cada nova versão, cada plataforma trazia inovações que superavam a outra. Neste processo, a Microsoft acabou por conquistar uma boa fatia do mercado, porém sem desbancar a liderança do Java.
Essa tendência se manteve ao longo dos anos, mas desde 2006 a Sun não lançou mais nenhuma nova versão do Java. Como Java parou no tempo e a a Microsoft com sua política fechada de preservação do Windows não atrai os desenvolvedores open source, a inovação começa a aparecer em outras plataformas como o Ruby (on Rails), Python, Scala, Groovy, Closure, Erlang, etc. Todas essas novidades, são absorvidas rapidamente pelas startups, mas não pelas empresas tradicionais, e portanto o cenário de liderança de Java nesse setor ainda não mudou.
No início do ano passado a Oracle concluiu a aquisição da Sun, e no final de setembro divulgou o roadmap do desenvolvimento do Java dos próximos 2 anos. O resultado foi esperado, o Java vai levar 2 anos para incorporar as novidades apresentadas por essas linguagens. Para quem procura inovação, é um balde de água fria, porém é uma estratégia conservadora e segura para as empresas tradicionais (que são típicos clientes Oracle).
O COBOL durante muitos anos também foi a principal plataforma para desenvolvimento de Enterprise software, mas não conseguiu acompanhar a evolução tecnológica. Hoje COBOL existe apenas no legado. Mas o que aconteceu com COBOL? O que fez ele perder a liderança?
A partir de meados da década de 70, começam a surgir e se popularizar os computadores pessoais. Durante a década de 80 esse fenômeno começa a atingir as empresas, em especial as que não tinham condições de ter um mainframe. COBOL é uma solução forjada para o mainframe, e os microcomputadores demandavam plataformas de desenvolvimento novas, mais adaptadas as suas características. Neste cenário, soluções como o Clipper eram cada vez mais usadas especialmente para pequenas empresas, que não tinham dinheiro para comprar um mainframe. Nenhuma dessas plataformas (como Clipper, Delphi, VB, SQLWindows, etc) conseguiram substituir em larga escala o COBOL nas grandes empresas. Essa substituição maciça em só acontece com a adoção do Java, combinada com o aparecimento do Linux e a evolução do Windows.
O cenário atual parece criar um momento semelhante ao que foi vivido pela revolução da microinformática, mas com algumas diferenças significativas.
A revolução atual é o cloud computing. Java, diferentemente do COBOL na época dos micros, ainda é adequada para soluções cloud, além disso, falta surgir uma plataforma tão disruptiva e confiável quanto foi o Java em seu tempo. A estratégia da Oracle compromete a liderança de Java como uma plataforma inovadora, mas não sua posição para soluções Enterprise. COBOL foi criada no final da década de 50 e levou uns 40 anos para ser desbancada. O domínio de Java não deve durar tanto, mas ainda será uma aposta confiável para sua empresa por vários anos. De quebra, ainda não sabemos quem será seu sucessor. Java é sim o novo COBOL, mas essa é a pergunta errada. A pergunta correta é quem será o novo Java?
Nota do autor: Nunca programei em COBOL, não sou tão velho assim.
O Browser Morreu?
Finalmente entrei de cabeça no mundo móvel, agora sou proprietário de um iPad e um celular Android (Samsung Galaxy S). Mesmo usando meus novos brinquedinhos por poucos dias, reforcei uma visão que já estava percebendo: A era de ouro dos browsers web está acabando.
Já faz tempo que a popularização dos celulares pressionou a indústria de software a criar soluções específicas, que atendessem as características particulares dos celulares (telas menores, teclado numérico, limitações de memória, etc). De uma forma geral, especialmente quando falamos de aplicações web, essas limitações poderiam ser identificadas como um subconjunto das características de um computador completo. Sendo assim, as soluções técnicas na web seguiram a linha da simplificação. WML e HTML atendiam perfeitamente a demanda da web no celular, e todos os sites relevantes fizeram versões de suas páginas para celulares utilizando essas tecnologias. Mas aí, a Apple criou o iPhone.
Com o iPhone tudo mudou. Novas características como touch screen e o acelerômetro tornaram inviável a criação de uma interação rica com usuário na web utilizando as tecnologias disponíveis. Era preciso criar aplicações específicas para o iPhone. A última peça do quebra-cabeça foi o App Store, com ele o problema da busca e distribuição das aplicações estava também resolvido. O sucesso de vendas forçou imediatamente a todos os distribuidores de conteúdo a criar suas aplicações iPhone. Este modelo deu tão certo que todos os fabricantes acabaram o seguindo. E depois surge o iPad.
Com a criação do iPad, se popularizou um novo segmento de dispositivos móveis, os tablets. O sucesso do iPhone se repetiu aqui, e como esperado o resto da indústria seguiu o modelo. Só que, mais uma vez, características específicas do iPad, especialmente relacionada ao tamanho fez com que as aplicações criadas para o iPhone não sejam suficientes. É preciso criar versões das suas aplicações para o iPad, e isto está acontecendo. Mas é necessário ter tantos dispositivos diferentes?
Eu acho que sim. Uso prioritariamente o meu notebook para produzir conteúdo (estou escrevendo este post nele), o iPad para consumir conteúdo e o celular para comunicação (através da telefonia celular ou internet). Não abro mão de nenhum. E também não acredito que vá aparecer um dispositivo único capaz de ser tão adequado para todas as essas atividades. Acho que a situação só deve piorar no futuro. Acho que vai aparecer cada vez mais dispositivos com características diferentes (e nem falamos sobre tv digital) que vão exigir softwares específicos para acesso a conteúdo da rede. Acredito que toda essa diversidade vai impedir que exista uma tecnologia única que abrace todos esses conceitos e seja tão universal como o HTML é hoje. Sendo assim, o que é que vai ser da minha vida?
Agora o desafio está lançado. Temos que criar soluções que englobem interfaces para Android, iPads, iPhones, Google TV, Apple TV, HTML, Flex e o diabo a quatro... Temos que nos preparar e investir cada vez mais em qualidade nos softwares que produzimos. Separação da lógica de negócio da apresentação é vital. Investimento em criação de ferramentas que facilite a criação de interfaces tão diferentes é importante. De qualquer forma, isso representa mais trabalho e mais dinheiro. Mas como ficam os browsers web nesse contexto?
Bem, os browsers ainda vão ser muito importantes, especialmente para uso nos computadores. Mas não deve ser a única ferramenta dominante para acesso a conteúdo. E a web como infraestrutura?
MAIS FORTE DO QUE NUNCA!
Tum tum tum tum tum tum tum
Cloud Computing, REST, JSon, Web Services, SOA, Azure, Web como plataforma, oAuth, NoSql, Cassandra, Redis, Memcached, MySql, PostgreSql, MongoDB, CouchDB, RDBMS, Data Warehouse, BI, Twitter, Microblog, Blog, Facebook, Orkut, Redes Sociais, Scala, Haskell, C#, Java, Groovy, Ruby, Ruby on Rails, Python, Javascript, Smalltalk, F#, Clojure, JRuby, JVM, Polyglot Programming, Agile, Scrum, XP, TDD, BDD, Design Evolutivo, DDD, DSLs, Grasp, OOAD, iPhone, iPad, iTunes, IOS, App Store, Android, Bada, Symbian, Dalvik, Windows 7, OS X, Linux, Unix, VPN, Html 5, Flex, GWT, RIA, Actors, Múltiplos Cores, ESB, Camel, MP3, DivX, H234, Amazon, Google, Apple, Microsoft, Adobe, Oracle, Intel, Ubuntu, Samsung, Subversion, Mercurial, Git, Chrome, Firefox, IE, KVM, Virtualização, e por aí vai...
overloaded... e o pulso ainda pulsa...
TDD mais importante que tudo
No dia 18/09/2010 apresentei a palestra "TDD direto das trincheiras" em João Pessoa, no evento "Agilidade Paraíba" promovido pelo grupo Scrum-PB. O público era bastante jovem e poucos conheciam ou usavam TDD. Espero ter conseguido despertar a curiosidade de várias pessoas, mas na verdade eu ainda fico bastante chocado como tão poucas pessoas/empresas adotam TDD. Como eu coloco no último slide da minha apresentação, "TDD é mais importante que tudo".
A prática do TDD viabiliza economicamente o design evolutivo e em última instância o próprio desenvolvimento iterativo incremental. Através principalmente do TDD é que a curva de custo da mudança pode ser suavizada.
Usando TDD as pessoas perdem o medo de fazer refactoring para remover código duplicado ou para evoluir funcionalidades existentes. O uso do TDD induz ao programador ter um melhor entendimento do negócio. Além disso, usamos menos o debug (que toma um baita tempo), localizamos mais rapidamente os bugs e enfim, escrevemos um código de melhor qualidade.
Se você não usa TDD, sugiro que avalie melhor esta prática. Não é fácil fazer a transição. Leva tempo e esforço, mas quando a ficha cai, você não vai querer trabalhar de outra forma. Estude, se prepare bem. Se precisar de ajudar é só chamar
Como brinde, deixo aqui um link com uma introdução ao TDD bastante legal. Boa Sorte!
Curado da IDE-dependência
No post "Jogue Fora sua IDE" eu falava sobre a IDE-dependência, de como ficamos dependente de IDEs e de como isso é ruim especialmente quando estamos aprendendo uma nova tecnologia. Pois bem, eu estou CURADO! Já faz um tempo que estou usando (aprendendo) Scala, e sem usar nenhuma sofisticada IDE.
Configurei um ambiente para programar em Scala utilizando apenas o gEdit (linux). O máximo que me permiti foi um syntax highlight, mas nada de code assist. De quebra, estou usando o sbt em um terminal integrado ao editor. Veja só:
Cuidado com a IDE-dependência. IDEs são ótimas ferramentas de produtividade, mas só funciona para quem domina o que está fazendo.
Agilidade Paraíba 2010
No dia 18/09/2010 vai acontecer o evento "Agilidade na Paraíba 2010", organizado pelo Grupo de Usuários Scrum Paraíba. Vou participar deste evento apresentando "TDD direto das trincheiras".
Acho muito legal que TDD venha gerando cada vez mais interesse, especialmente em nossa região. Isso porque eu digo e não me canso de repetir que TDD é a prática relacionada com engenharia de software mais importante do universo ágil. Através de TDD que você consegue suporte para design evolutivo, simplicidade e consequentemente desenvolvimento iterativo e incremental que DÁ CERTO! Nos vemos lá...
Para inscrições e mais informações, acesse: http://scrumpb.org