A minha experiência com o Kindle da Amazon.

O Kindle da Amazon está custando cerca de R$500,00 incluindo transporte e taxas para Brasil, o que é um preço bem interessante apesar da quantidade de impostos no preço original de U$139,00.

Adquiri o meu a um pouco mais de um mês e achei um ótimo equipamento para leitura. O display baseado em e-ink é show, tem uma definição incrível e torna a leitura muito agradável.

Como não emite luz, é necessário o uso de um spot de luz para poder ler na cama como qualquer bom livro.

A conectividade por Wifi é mais que suficiente, e não vejo justificativa para o uso da versão com 3G a não ser se você realmente vive viajando. Ainda assim, acredito não haver dificuldade de achar Wi-Fi nos hotéis por aí.

Além disso, a conveniência do WhisperNet, que é o protocolo de comunicação com os servidores da Amazon, só é realmente justificada para os livros comprados pela mesma. PDFs, CHMs, LITs e outros livros eletrônicos obtidos de outras formas são mais convenientemente enviados por USB usando um software como o Calibre.

O software Calibre é bem completo, implementando a conversão de formatos de livros e também construir edições limitadas de jornais periódicos consultando diretamente os sites na Internet.

O formato nativo usado pelos livros vendidos pela Amazon é o AZW, só que este formato é proprietário e possui DRM. O melhor formato aberto para usar no Kindle é o MOBI que fica perfeito no Kindle, preservando toda a navegabilidade dentro do documento.

Todos os Kindles vendidos recentemente já nativamente suportam o formato PDF, entretanto é extremamente inconveniente de ler. O PDF descreve o desenho da página e não permite a alteração das quebras de linhas dentro das mesmas tornando muito difícil de se ler, pois para caber a linha inteira é necessário trocar a orientação da tela do Kindle e reduzir o tamanho da fonte para um ponto bastante desconfortável para a leitura.

O Calibre consegue fazer conversões do PDF para o MOBI, mas os resultados são variáveis, indo as vezes de conversões perfeitas a conversões aonde o documento é destruído.

A principal desvantagem do Kindle para um brasileiro é que ele é incompatível com o DRM da Adobe, que é o esquema adotado pelas livrarias brasileiras para distribuição de e-books em português. Isto nos obriga a leitura de livros em Inglês, o que é bacana para quem já tem alguma fluência, permitindo a leitura antes da tradução muitas vezes mal feita aqui no mercado brasileiro.

Existem leitores de Kindle para PC, para iPad e para dispositivos Android permitindo ler os livros em praticamente qualquer dispositivo a sua mão hoje em dia, mas o Kindle verdadeiro é único por uma série de razões:

• dá para ler até no sol;
• a bateria deve durar um mês com o Wifi desligado;
• é pequeno e leve;
• não é tão caro;
• apesar de ter um browser Web, é tão lento e desconfortável para este uso que você não vai ficar chaveando para ver se chegou um e-mail ou um novo twitter.

E este último item é incrivelmente uma grande vantagem. Nesta vida aonde tudo a nossa volta fica nos interrompendo e destruindo a nossa habilidade de se concentrar e se envolver numa obra escrita, o Kindle permite você se enfurnar num quarto fechado e se envolver apenas com os nossos próprios pensamentos por um bom tempo.

Relógio de Ponto Eletrônico de graça para quem usa nosso serviço

Como já tinha comentado no post anterior, acabou de nascer o novo equipamento de registro de ponto Ah07 especificamente desenhado para quem está pagando para ver se a portaria 1.510 vai valer.

Implementamos um equipamento sem impressora para registro de ponto nativamente integrado ao sistema PontoWeb, e a estratégia comercial é bem diferenciada.

Decidimos chamar de PontoWeb Fácil, e o preço do equipamento para todos os efeitos tem o preço de R$0,00, pois vamos oferecer o equipamento em comodato para quem assinar o contrato mensal do sistema PontoWeb nestas condições, entregando o equipamento em definitivo ao final do contrato de dois anos.

Agora, estou curioso para ver algum concorrente nosso bater este nosso preço.. :-)

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.