Start-up versus Governo

Criamos a Ahgora a um tempo atrás com o objetivo de criar um serviço de registro de ponto eletrônico on-line na modalidade de serviço, algo que facilitasse a vida das empresas e simplificasse principalmente a vida das pequenas empresas.

Em agosto de 2009 aparece então a fatídica portaria 1.510 do MTE, que muda completamente e engessa os mecanismos de registro de ponto eletrônico. Nossa avaliação foi que a mudança definida é exagerada e cria um bocado de dificuldades para as empresas, mas ao mesmo tempo existia o lado bom para a sociedade de legitimar e regular o mercado de ponto eletrônico dado ao descrédito generalizado dos softwares e relógios que existiam no mercado.

Observando que os princípios adotados são semelhantes ao definidos para a impressora fiscal imaginamos que existiria uma boa chance desta mudança chegar ao resultado esperado pelo governo, o que nos levou a acreditar em transformar a Ahgora também numa indústria.

Nosso diferencial sempre foi a prestação de um serviço confiável e responsável para a gestão do ponto e então imaginamos como seria este equipamento perfeito para acompanhar o nosso serviço.

Nasce então o Ah10, um produto compacto, alta performance e com a melhor impressora do mercado sem falar do design assinado pelo escultor Adhemir Fogassa. Um produto que todo mundo que entra em contato sempre fica surpreso de como ele é agradável visualmente e compacto, chegando ao ponto de termos clientes reclamando que esperavam um equipamento mais trambolhão apenas porque os outros equipamentos do mercado eram assim... :-)

Agora, depois de quase dois anos estamos ainda esperando a definição da situação jurídica. No final de fevereiro tivemos o segundo adiamento, além de criação de regras incertas de flexibilização. Nesta situação a insegurança jurídica é certa e deixa as empresas em dificuldades de decidir enfim a aquisição de um equipamento como definido pelo governo.

Para uma start-up, esta situação passou do ponto de inaceitável e decidimos então deixamos de ficar na dependência do governo e estaremos lançando na Exposec nossa versão do relógio de ponto sem impressora, ainda menor, bonito e vendido apenas na modalidade de serviço integrado ao nosso sistema PontoWeb suportado pela nossa poderosa equipe de suporte e desenvolvimento aqui em Florianópolis.

Logo posto mais novidades...

Foco em serviço nas empresas

Processo industrial de produção está mudando

A revolução industrial, se utilizando da especialização das pessoas para produção massiva de produtos indiferenciados, desmontou o modelo até então usado de produção artesanal, onde existia uma estrutura em pirâmide de qualificações das pessoas, com poucas pessoas dominando totalmente a arte artesanal e com uma grande quantidade de aprendizes reproduzindo a arte dos especialistas.

Naquele tempo, o serviço era o maior valor do produto, e a matéria prima abundante e barata. A revolução industrial foi necessária para viabilizar a produção massiva de produtos mais elaborados cujo custos dos insumos eram altos.

Agora estamos na terceira onda, onde estamos vendo os produtos massificados serem produzidos de forma muito barata, seja pela mecanização da produção ou por uso de mão de obra extremamente barata como na China ou ainda pela construção de vantagens comparativas em diversos países através da disponibilização de meios de produção bancados pelas políticas industriais nacionais.

Ao mesmo tempo, como estes produtos se tornam abundantes e baratos, outros elementos passam a construir diferenciais, como o design, cor, estilo, marca e até a comunidade de seus usuários.

Ou seja, estamos voltando através das atividades de serviço para o modelo de produção mais do estilo artesanal, onde desenvolvimento do enfoque global das pessoas é mais relevante que a especialização das mesmas.

A horizontalização é o meio desta mudança

Quando Henry Ford iniciou a produção de seu modelo T, os carros eram todos iguais e na cor preta. Hoje as montadoras contratam de várias centenas de empresas seus insumos para a produção, transferindo a produção de insumos indiferenciados para pequenas empresas que abastecem sua linha de montagem de produtos customizados.

E esta linha de montagem está cada vez mais mecanizada e recebendo produtos cada vez mais "prontos" das pequenas empresas que produzem os insumos, tornando os elementos de trabalho mais importantes das montadoras a marca, o design, o gerenciamento de projetos e o gerenciamento de tecnologia de informação.

O mais curioso deste processo é que este mesmo mecanismo se replica em escala menor nestas empresas que produzem os insumos das montadoras, onde progressivamente um processo de customização, de marca e de design se desenvolve.

E onde ficou o valor dos produtos?

O valor dos produtos não desapareceram, apenas o mercado destes produtos, elaborados ou não, se tornaram disponíveis por muitas empresas, tornando estes produtos comoditizados. Com isso a rentabilidade se torna muito dependente de vantagens comparativas e sensíveis as flutuações do mercado.

E como serviço entra nesta discussão?

Tudo que chamamos de customização está relacionado a serviço, e os consumidores finais estão exigindo estes diferenciais. Até para comprar grãos, como feijão ou arroz, hoje olhamos para a marca do produto para satisfazer nossas necessidades de segurança e de qualidade, ou seja, o serviço de marca agrega valor ao produto.

Mas os serviços também podem ser oferecidos desagregados a produtos

Hoje em dia grande parte do que consumimos já são serviços sem produtos físicos. Educação é provavelmente hoje o principal exemplo, mas podemos listar ainda muitos outros, como a oficina das consessionárias de carro, escritórios de advocacia, TV a cabo, Internet, consultorias, desenvolvimento customizado de software, escritórios de arquitetura, de contabilidade, etc.

O posicionamento de mercado de um prestador de serviço é diferente do posicionamento de mercado de produtos

As empresas de produtos em geral se posicionam no mercado fortalecendo um destes elementos: o produto, a eficiência operacional ou o relacionamento. Isto por causa da própria segregação dos clientes que esperam exatamente ou o produto mais elaborado e evoluído, ou o produto  disponibilizado na forma mais eficiente e econômica, ou uma relação duradoura baseada na confiança com seus fornecedores.

Já os prestadores de serviços necessitam fortalecer a execução de suas atividades ou de forma excepcional, ou de forma experiente, ou de forma eficiente:

• Os clientes que esperam serviços excepcionais contam com a grande inteligência das pessoas prestadoras do serviço para resolver problemas novos e raros. São as atividades de maior rentabilidade e que exigem conhecimento global dos assuntos, e a marca se torna um dos principais forças para estabelecimento dos negócios.

• Já quem espera desempenho experiente, espera alguma previsibilidade das atividades desempenhadas e compromisso de execução conforme experiências passadas. Estas atividades são executadas por pessoas que já executaram atividades semelhantes mas que ainda exigem criatividade para resolução de problemas particulares.

• E, por fim, existem os clientes que esperam desempenho eficiente, atividades mais mundanas e que muitas vezes já tem preços estabelecidos pelo mercado. O cliente tem noção exata do que é esperado e normalmente são atividades de rentabilidade menor.

Obs: Escrevi este artigo no fim de 2006 e nunca o tinha publicado. Impressionante como é mais verdade hoje do que nunca.

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.