Lean Startup, primeira teoria sobre startups

Steve Blank participou na criação de quase uma dezena de empresas startup e após a sua aposentadoria ele escreveu um livro com notas sobre as experiências que teve e criou uma teorização sobre este processo. Este material se tornou um livro chamado The Four Steps to the Epiphany.

Eric Ries, também um empreendedor na área de tecnologia, observou as experiências que passou e procurou juntar uma série de elementos que estão contribuindo para uma nova forma de pensar sobre a criação de Start-Ups.

Basicamente ele observou que os conceitos para desenvolvimento ágil (SCRUM/XP/Lean) poderiam ser transpostos também para o processo de criação de novas empresas, bastando para isso modelar de alguma maneira o ciclo de feedback do processo de teste de mercado, reposicionamento e descoberta do cliente, e que os conceitos apresentados por Steve Blank descrevem exatamente esta visão.

Esta nova visão passou a ser chamada de Lean Startups e que acabou se tornando um fenômeno mundial de reavaliação das StartUps e de extensão das metodologias ágeis para a gestão das mesmas.

A grande sacada do Steve Blank é relativamente simples: uma StartUp não é simplesmente uma empresa grande que ainda está pequena. Na realidade é uma organização totalmente diferente de uma grande empresa, com um objetivo muito claro, interagir rapidamente com o cliente/mercado, aprender com os erros e executar pivots, numa espiral contínua até encontrar um modelo escalável de crescimento.

As implicações deste pensamento são bastante interessantes e relativamente muito pouco discutidas entre os empreendedores:

• é necessário botar a cara a tapa para o cliente o mais rápido possível para acelerar o processo de aprendizardo;
• não se pode tentar escalar o negócio até a localização do modelo escalável, ou seja, todo o dinheiro é para aprender rapidamente, e não contratar gente ou estoque;
• executar pivots rapidamente, algo como colocar um dos pés naquilo que foi percebido como valor para o cliente e movimentar o outro pé para outra direção até conseguir apontar o corpo da empresa para a direção que valha a pena o crescimento da escala.

Seguem aqui os slides e um vídeo aonde ele explica melhor este processo de "Customer Development".

A Construção Civil é que busca uma metáfora com desenvolvimento de software

O meu amigo Rodrigo Machado da OnCast escreveu um artigo muito interessante discutindo como podemos trabalhar a metáfora batida ente o desenvolvimento de software e a construção civil.

Esta metáfora da construção civil comparando com software é usada a muito tempo e acho que hoje todo mundo já suspeita que a relação não é muito clara.

Uma forma de aproveitar a metáfora na linha que o Rodrigo trabalhou, levando a construção do software a ser comparada com construção apenas do projeto é uma forma de melhorar esta comparação, mas ainda acredito que a questão ainda fica mal posicionada, pois o resultado tangível de um projeto é apenas um papel, e o software bem desenvolvido é uma aplicação funcional que altera o nosso mundo ao redor.

Eu diria na realidade que a construção civil como conhecemos hoje é uma péssima referência para comparação, pois a mesma está em crise justamente por tentar se basear num ideal de fixar antecipadamente num projeto algo que não se pode prever sem custos absurdos, como a qualidade do terreno ou a definição final de como o espaço criado vai ser utilizado, além de provocar quantidades gigantes de retrabalho para poder mudar depois de pronto uma especificação "escrita numa pedra".

O sucesso do uso dos conceitos lean baseado em fluxo em vez do modelo de transformação em várias atividades humanas está provocando uma revolução também na construção civil. Estes conceitos caminharam da produção enxuta inicialmente aplicada no Japão para construir carros de baixo custo e alta qualidade e progrediram para vários segmentos, e em especial o desenvolvimento de software.

Esta evolução não era esperada nem mesmo pela Toyota, pois a mesma até a pouco ainda usava o modelo de transformação para sua área de desenvolvimento de produto.

A comunidade Ágil, que estava experimentando as técnicas XP, SCRUM e uma série de outras menos conhecidas começaram a reparar que as técnicas que estavam sendo criadas tinham relação muito forte com os conceitos lean, permitindo o casamento, cruzamento e transformação, fortalecendo o paradigma de fluxo de valor no software.

Agora o desenvolvimento de software passou a ser referência, e podemos encontrar até na construção civil uma revolução acontecendo: o Lean Construction.

Então acho que podemos dizer com orgulho que, na realidade, a construção civil é que tem que usar o desenvolvimento de software ágil como metáfora. A construção civil precisa tanto como o software:

• aceitar mudança de especificação do cliente, mesmo que cinco pavimentos já tenham sido construidos;
• focar no aprendizado durante o processo, nem que seja por protótipos;
• não perder tempo demais com projetos superdetalhados, que logo serão invalidados na prática da construção;
• reduzir a quantidade absurda de retrabalho, usando o valor para o cliente como principal métrica do progresso;
• adiar o máximo possível decisões de custo de retrabalho alto;
• implantar projetos de escopo variável.

Entretanto, se o desenvolvimento de software que é relativamente recente na história humana tem dificuldade de usar o paradigma lean, imagina quanto vai custar para a construção civil desenvolver isso.

MongoDB na Ahgora

Depois de várias experiências de uso de armazenamento de dados na plataforma S3 e SimpleDB da Amazon, nós na Ahgora acabamos decidindo pelo uso do MongoDB.

Desde o ano passado já tínhamos decidido abandonar a estruturação convencional de dados por um banco relacional convencional e caminhar para uma modelagem mais simples orientada a documentos.

Nossa idéia era utilizar o S3 como um "document store" e o SimpleDB como uma maneira de indexação simples dos documentos e de vetores de dados que precisassem de busca rápida.

Os serviços S3 e SimpleDB da Amazon são bem feitos e muito confiáveis, implementando mecanismos poderosos de redundância e com escalabilidade massiva, mas dois pontos complicam seu uso: a consistência eventual e as ferramentas de acesso e depuração um tanto complicadas.

A consistência eventual dá para lidar simplesmente evitando a tentativa de reler imediatamente o dado que acabou de escrever ou por cache local ou por temporização forçada. Já a falta de ferramentas simples de depuração e acompanhamento dificulta bastante.

Estávamos usando as extensões do Firefox S3Fox e SDBTool, mas eles não são ferramentas rápidas e são complicadas de lidar quando se tem plataformas separadas de teste e produção, além de depender de conectividade constante para cada ciclo de teste.

Tentando buscar uma alternativa que pudesse nos ajudar a acelerar o desenvolvimento e simplificar os conceitos, começamos a olhar os "document stores" (CouchDB/MongoDB) e "key-value stores" (Riak/Redis) que estão em voga na Internet.

Coincidentemente observamos um crescimento muito acentuado do uso do MongoDB neste início de ano, o que incentivou uma prototipação interna para uma parte do sistema da Ahgora.

A prototipação foi um sucesso e observamos que usando o MongoDB conseguimos unificar as demandas para S3 e SimpleDB a apenas um mecanismo de armazenamento de dados.

Fora isso, ele possui uma interface de linha de comando que lembra a interface de linha de comando do MySQL, permitindo manipulação simples e rápida dos dados, mesmo em nossos notebooks, com ou sem conectividade para a Internet.

A instalação é simples e dá para começar a brincar em 10 minutos em seu computador. Pelo browser dá para brincar em 10 segundos pelo link: http://try.mongodb.org/.

A documentação não é perfeita, mas é muito melhor do que a disponibilizada para as plataformas da Amazon. Inclusive apresentando documentações extensivas para várias linguagens de programação diferentes.

A modelagem de dados é diferente com um "document store" devido a flexibilidade permitida. O item mais importante da modelagem é descobrir como o dado vai ser lido e escrito, e tentar modelar os documentos o mais próximo destes ciclos de leitura e escrita. Só brincando mesmo para entender o impacto, e o MongoDB permite brincar rapidamente e testar as alternativas.

Semanas atrás conseguimos concluir a mudança completa do nosso sistema de gestão de controle de ponto para o MongoDB. Foi muito mais fácil que pensávamos, já que já estávamos com vários dados modelados como documentos.

A principal desvantagem desta troca é que perdemos a escalabilidade e redundância nativa da Amazon e temos que manter nossas estruturas próprias de redundância entre servidores. Entretanto o MongoDB possui mecanismos bons para replicação, e bem mais simples que do MySQL.

Obs: No Slideshare tem uma apresentação ótima para uma primeira visita ao MongoDB.

Faltam profissionais em Florianópolis

Já não é a primeira vez que ouço que os empresários aqui da região de Florianópolis estão reclamando da dificuldade de contratação e do "roubo" de profissionais entre as empresas.

Florianópolis está sofrendo um boom de novas empresas e empreendimentos na área de tecnologia que está demandando uma quantidade crescente de pessoas e as faculdades da região estão a algum tempo colocando uma quantidade relativamente constante de pessoas no mercado de trabalho.

Além disso, os profissionais de tecnologia também são recrutados para assumir papéis comerciais, administrativos ou de gerência por uma série de empresas, além de todos os concursos para cargos públicos. É uma pena que tantas pessoas abandonem as atividades para o que estudaram por estar desiludidos com as oportunidades que se apresentam.

Um sintoma bem visível da situação é a publicação dos classificados de domingo entupidos de ofertas de vagas que parecem nunca preenchidas, pois vivem se repetindo nos classificados por meses.

Acho que está claro que o mercado de trabalho está extremamente "comprador" de profissionais, o que indica que o poder de negociação hoje em dia está no lado do empregado.

Está mais que claro que hoje é o empregado que escolhe a empresa, e não mais o contrário. Esta mentalidade de brigar para a universidade produzir o "gado" para poder "entupir" as empresas tem que acabar, principalmente porque a tendência é continuar a aumentar a demanda de software, acima da capacidade de geração de novos profissionais.

Os empresários precisam entender que, ao mesmo tempo que tentam vender seus produtos para o mercado precisam vender suas empresas para os colaboradores e potenciais colaboradores com o mesmo grau de importância.

Da mesma maneira precisam entender que esta massa de pessoas são o nosso futuro. Se não é através de nossa empresa, que seja por outra, pois quando a maré sobe, sobe para todo mundo.

Trocas de empresa por parte dos profissionais não deveriam ser motivo de brigas entre empresários, deveriam na realidade ser encorajadas. Não há nada melhor para o desenvolvimento pessoal destas pessoas do que conhecer experiências diferentes, e não há nada melhor para as empresas do que ter a polinização cruzada de conhecimentos para crescer o potencial de todas elas.

Não é a toa que as empresas que estão no Vale do Silício são o que são: lá o tempo médio de um profissional ficar numa mesma empresa é de 2 a 3 anos. Consegue imaginar o que uma empresa adquire de know-how em 5 anos apenas se instalando lá?

Além da questão da troca de empresas, o "volume" de pessoas não pode ser o nosso objetivo, e sim uma pequena massa de "super profissionais" que causassem inveja a sociedade brasileira e internacional.

Tendo este grupo de "super profissionais", e vendendo este diferencial aos quatro ventos, não vai faltar gente querendo se mudar para a cidade maravilhosa de Florianópolis para vir aprender com as empresas de mente aberta e com estes profissionais.

Temos que vender o potencial de "aprendizado", o potencial de fazer a diferença da sociedade e de poder mudar o mundo. Só assim conseguiremos segurar estes "super profissionais".

Para fazer isso, acredito que temos que "vender" estes "super profissionais". Eles tem que ter blogs, dar palestras, escrever livros. As empresas tem que ajudar a construir a "marca" destes "super profissionais", inserindo suas opiniões controversas em seus sites e nos press-releases.

As empresas tem que parar de vender apenas produtos, mas também vender plataformas, conceitos, diferenciais tecnológicos, até mesmo as idiossincrasias que as tornam únicas, e isso só é possível montados e legitimados pela "venda" destes "super profissionais".

Para tudo isso, acredito que temos urgentemente que fabricar uma indústria local de conferências tecnológicas patrocinadas pelas empresas. Não poderia ter um mês que não tivesse uma conferência sobre FPGA, bancos NOSQL, linguagens como LUA, WebDesign, ferramentas sociais na Internet ou desenvolvimento Lean/Kanban.

Será que ninguém mais percebe que a gente tem que fabricar o nosso futuro e não esperar que isso caia do céu?

Kanban de Desenvolvimento de Software na Ahgora

Uma das vantagens de poder iniciar uma empresa é ter a liberdade de adotar as tecnologias, processos, ideais e conceitos que os empreendedores entendem como mais importantes para a empresa.

E está sendo muito gratificante poder adotar na Ahgora os conceitos que acreditamos mais interessantes para incutir como valores da empresa e permitir a empresa desempenhar da melhor maneira que acreditamos possível.

Nestas últimas semanas estamos implementando o gerenciamento do fluxo de desenvolvimento através de Kanban visual e com post-it, e está sendo uma experiência interessante: as pessoas rapidamente percebem o progresso e o sucesso do projeto olhando a evolução, e se envolvem diretamente para avaliar os escopos das unidades de valor, reorganização do próprio kanban e reorganização e repriorização contínua dos itens em backlog.

Este é o nosso quadro de Kanban que está valendo nesta semana.

Dois fluxos estão visíveis: Desenvolvimento de Software propriamente dito e Marketing/Design.

Dá para observar na foto que acabamos organizando o Kanban de maneira que a evolução do WIP (atividade em andamento) caminha para linhas diferentes: o desenvolvimento de software vai para teste de desenvolvimento seguido de teste de usabilidade, já o MKT/Design caminha para uma etapa de aprovação.

Kanban é isso mesmo, o objetivo é conseguir manter um fluxo contínuo de geração de valor e que precisamos continuamente nos reorganizar para maximizar o desempenho deste fluxo.

As limitações de quantidade de itens em WIP não estão ainda do quadro porque estamos ainda tentando achar um valor apropriado para cada fase.

Não queria deixar a amarração a priori para que a equipe pudesse experimentar os excessos e descobrir naturalmente os limites mais saudáveis.

E não demorou muito esta descoberta. Em três dias, chegou a juntar uns seis itens no WIP e acabei escutando de uma pessoa da equipe que para melhorar a eficiência precisamos botar um limite de três lá... Este tipo de coisa não tem preço: a exposição visual das atividades induziu intuitivamente nas pessoas a percepção de que não vale começar outra coisa sem terminar outra em andamento.

A nossa equipe é pequena e nova, e a gestão visual do Kanban nos está parecendo perfeita para o nosso caso. O envolvimento, aprendizado e crescimento de maturidade dão um salto gigantesco em apenas algumas semanas de operação.

Vida: aguendar os maiores socos e ainda assim continuar brigando

A Ahgora não tem parado de crescer. Mesmo não sendo diretamente nossa intenção, as demandas vão surgindo e nos obrigando a nos organizarmos e posicionar novas pessoas na nossa frente de batalha.

Estamos agora com 3 designers/web-designers, 4 desenvolvedores, uma pessoa no administrativo e mais uma pessoa no comercial como colaboradores parceiros da nossa empreitada. Somando os 3 sócios que praticamente atuam em todas as frentes e um projetista mecânico free-lance temos 13 pessoas trabalhando para criar esta nova fase da empresa.

Além disso, temos duas empresas parceiras no lado de fornecimento e mais duas no lado comercial que estão apostando na nossa visão e participando do nosso sonho.

É incrível, mas provavelmente estamos afetando diretamente a vida de umas 20 pessoas e provavelmente 2 a 3 vezes mais indiretamente pelos laços familiares ou por estar participando e ajudando em alguma parte deste desafio.

Este é um motivo de orgulho do nosso lado e ao mesmo tempo de imensa responsabilidade.

Além da responsabilidade, uma série de outras preocupações inundam nossas mentes de empreendedores: demandas de desenvolvimentos, contratempos, necessidade de aprendizado interno, gerenciamento de capital e de riscos.

O fardo é pesado e várias vezes as dificuldades nos derrubam emocionalmente. Segurar a onda e continuar assumindo a responsabilidade são desafios pesados e eu sou grato de ter meus dois sócios me mantendo alerta nesta briga.

A gente tem sempre que lembrar que no passar dos dias nós percebemos que as dificuldades, apesar de aparecerem o tempo todo, muitas vezes acabam não sendo tão difíceis quanto imaginamos, e que também de certa forma a vida oferece a cada dia uma oportunidade de desenvolvermos nossa humildade, aprendizado e superação pessoal.

Escutei na rádio hoje um locutor citando uma fala do Rocky Balboa que curiosamente me pareceu muito apropriada para o momento (YouTube):

The world ain't all sunshine and rainbows. It's a very mean and nasty place and I don't care how tough you are it will beat you to your knees and keep you  there permanently if you let it. You, me, or nobody is gonna hit as hard as life. But it ain't about how hard ya hit. It's about how hard you can get it and keep moving forward. How much you can take and keep moving forward. That's how winning is done!

Sobrecarga de trabalho numa startup

Paul Graham foi bem feliz quando disse que você pode pensar numa startup como uma maneira de comprimir toda sua vida profissional em apenas alguns anos. Em vez de trabalhar em baixa intensidade por 40 anos, você trabalha muito além do seu limite por quatro.

Esta é exatamente a sensação de estou sentido agora. As horas passam numa velocidade descomunal e quando parece que o dia apenas começou já são quatro horas da tarde.

Não foi sempre assim, pois os primeiros meses a gente fica preso por diversos fatores alheios a nossa vontade, mas de uma hora para outra a coisa se inverte e uma tonelada de coisas só começam a acontecer na hora que a gente se envolve.

E como destravar a evolução da empresa? Contratar mais gente? Motivar as pessoas? Empoderá-las?

Tudo isso é necessário e nós trabalhamos duro para isso, mas o que estou percebendo que a situação é um moto contínuo, pois no momento que você consegue delegar atividades, imediatamente se percebe que o potencial da empresa aumenta e desafios maiores podem ser alcançados.

O tempo tem ficado escasso, mas vou ver se consigo voltar a manter um post por semana aqui no blog. Alguém tem algum comentário?

Uma nova casa para a Ahgora

Desde novembro estou envolvido diretamente em fazer a Ahgora acontecer, e está sendo um período bastante difícil, trabalhoso, mas ao mesmo tempo muito gratificante.

A quantidade de coisas a fazer são gigantescas, e diariamente bate uma sensação horrível de que nem tudo que precisaria ser feito vai acabar sendo feito. Sou um cara muito ansioso e esta sensação somada com a responsabilidade inerente de ser um dos empreendedores do negócio deixa a gente um pouco desestabilizada emocionalmente.

Mas se ficamos olhando em retrospecto dá para ver o progresso que estamos conseguindo num curto prazo de tempo. Uma startup em processo de montagem tem que ser avaliada com base nos "ativos" construídos que estão associadas a empresa Ahgora e temos muito orgulho de dizer que estamos conseguindo estes resultados muito rapidamente.

Um dos resultados recentes que nos mais orgulha foi receber no final do ano passado a grande notícia de que fomos aprovados como empresa residente na seleção do Midi Tecnológico, a incubadora da ACATE. Logo o Midi, que é uma das melhores incubadoras do Brasil, com uma infraestrutura e suporte de primeiro nível!

Acabamos de completar 3 semanas de estadia na sala 16 do terceiro andar do prédio da ACATE e ficamos surpreendidos positivamente com o bom astral, a sensação de extrema boa vontade da equipe do Midi, e do apoio mútuo com as outras empresas incubadas.

Os desafios tem sido gigantescos, e o mais difícil tem sido conciliar desenvolvimento de software, reuniões de negócios, reuniões de consultoria, entrevistas de candidatos para emprego, suporte aos clientes atuais, prototipação de produto, busca de parceiros, decisões estratégicas, marketing, etc. É tanta coisa que 12 horas num dia não é suficiente para a metade destas tarefas.

Pelo jeito vou ter que aprender a conviver com uma "verdade" que aprendi numa consultoria do Midi recente de que, já que decidimos virarmos empreendedores, perdemos os 3 "F"s: Fim de semana, Feriado e Férias... :-)

Freelancers versus empregados

Algumas pessoas tem me perguntado sobre a minha opinião se é melhor trabalhar com freelancers ou com empregados.

Na realidade existem vantagens e desvantagens em ambos e é necessário trabalhar com ambas as alternativas e utilizá-las como for melhor em cada caso.

O freelancer é um ser mais autônomo, e que aproveita suas experiências passadas para potencializar os resultados nas atividades que desenvolvem. Normalmente, ou já recebem o prato pronto do que é para fazer ou ganham liberdade plena para fazer a atividade como melhor convier para ele.

Esta é uma estratégia vencedora para ele, pois consegue resultados em curto prazo e evitam dependências técnicas ou operacionais que poderiam bloquear o avanço das atividades. Como não há um compromisso de longo prazo, não há tanta preocupação com a dificuldade de manutenção futura ou facilidades para acompanhamento dos projetos.

A comunicação é limitada, pois a atividade em geral não é executada in-loco, o que implica necessidade de acompanhamento contínuo e periodicamente ajustes constantes de rota.

O empregado já tende a se preocupar mais com o médio/longo prazo e se envolver mais com os problemas do dia a dia da empresa. O enfoque não é tanto entregas a curto prazo e sim a eficácia no trato de todas as questões "quentes" na empresa.

Isto pode implicar em resultados menores em curto prazo mas maior comprometimento com aquele resultado obtido.

Como a atividade é feita in-loco, em geral a comunicação chega até a ser excessiva e uma sobrecarga de atividades de curto prazo e a preocupação com a "perfeição" dos resultados de médio/longo prazo podem chegar a debilitar os resultados. Uma falta de gestão pode levar o funcionário a virar um bombeiro para incêndios, um perfeccionista permanentemente bloqueado, ou ainda um animal político que explora o excesso de informações, as vezes conflitantes, para proveito próprio.

Em compensação, através de uma boa gestão, envolvimento e motivação, um empregado pode entregar o seu coração para a causa da empresa, algo bem difícil de acontecer com um freelancer.