Rafael Lima

O Oxente Rails 2010 foi sensacional! Manteve o clima de família do ano passado e incluiu empreendedorismo na grade de temas. Nada mais perfeito que Rails + Empreendedorismo para mim, que trabalho com desenvolvimento de aplicativos web inovadores escritos em Rails pela BielSystems.

No final de cada dia rolou um #horaextra, é claro, e pudemos conversar bastante sobre o que a galera anda aprontando. Fiquei muito feliz, muito mesmo de ter participado e conversado com tanta gente maneira!

Eu gostaria de parabenizar toda a equipe da organização do Evento e especialmente ao Paulo Fagiani que idealizou o Oxente Rails.

A minha palestra foi “Transformando ideias em negócios rentáveis“. O objetivo foi compartilhar o que eu tenho feito e o que eu aprendi no processo de marketing do Cobre Grátis.

Abaixo os slides da minha palestra.

Vou confessar que no aeroporto, esperando o avião para voltar, eu já estava com saudades. Esse evento me fez refletir bastante e me ensinou muita coisa com os exemplos de cada um ali presente.

Muito obrigado a todos.

Que venha o Oxente Rails 2011…

…e até lá!

O EDTED foi legal, abaixo foto da galera que participou das lightning talks.

Minha palestra relâmpago foi sobre viabilizar um produto na web. Para a galera que pediu meus slides, vejam o post da palestra no Ceará on Rails, usei a mesma apresentação.

Nos vemos no pŕoximo!

Em resposta ao Tweete do Alan, resolvi publicar este post.

Após ter feito o Empretec, eu mudei bastante meu comportamento. Como o Fábio Seixas me disse ontem, no Circuito 4×1, o Empretec é um divisor de águas. Eu concordo plenamente.

No Empretec estudamos as CCEs (Característica do Comportamento Empreendedor). Uma CCE fraca em mim era o Estabelecimento de Metas. Estou melhorando. Defini minhas metas e estou trabalhando para alcançá-las. Para isso tenho algumas tarefas que estão devidamente priorizadas.

Escrever no blog é algo que acho muito importante, mas para o que estou buscando agora, existem outras tarefas mais importantes. Por conta disso meu blog está sem atualizações há um bom tempo.

Espero ter esclarecido a questão e posso adiantar que quando voltar, estarei acelerado.

Abraço e até a próxima.

Na Myfreecomm temos alguns programadores lentos, graças a Deus. Conversando sobre isso com o Henrique, ele disse que merecia um post. Atendendo a pedidos, aí está.

Depois de bastante tempo sem programar, eu passei dois dias escrevendo um pequeno sistema para integrar a parte de pagamento de uma aplicação com o Paypal.

O fato de ter voltado a programar, depois de mais de um ano apenas gerenciando projetos e equipes, e estudando metodologias ágeis, me fez optar por escrever uma aplicação 100% testada, em Ruby, utilizando Sinatra. Gostaria de aproveitar para agradecer o Rafael Souza que me ajudou bastante no início.

A escolha de Ruby (ao invés de Python por exempo) e Sinatra (ao invés de Rails por exemplo), não importa. O que importa é que eu poderia fazer tudo “scriptado” (aka cuspido), mas achei que não deveria. O primeiro motivo é que se trata de um middleware para um processo crítico que não pode falhar, o pagamento. Segundo, por que na minha cabeça não fazia sentido cuspir um código e fazer funcionar o mais rápido possível.

Isso me fez pensar sobre o paradoxo da qualidade x velocidade. A conclusão que tirei das minhas reflexões é que os programadores que se dizem lentos, na verdade não são lentos.

Para você dizer que alguém é lento, você tem que comparar com outra pessoa. Lentidão é relativo. Você não é lento e ponto final, você pode ser lento se comparado com outras pessoas.

Minha conclusão foi que na verdade o “programador lento” faz as coisas no tempo em que elas realmente precisam para serem feitas da maneira que funciona. Na verdade, os outros que são rápidos de mais. Adianta ser rápido e ter bug?

Analisando sob essa ótica, e considerando a premissa de que a maioria das pessoas (rápidas) fazem errado, vide relatório Chaos Report do Standish Group, posso dizer que programadores lentos são bem-vindos.

Hoje, eu vejo essa característica como um sintoma de que ele programa com boas práticas e com o cuidado necessário para o software funcionar.

No final da conversa eu disse para o Henrique: “Se em uma entrevista de emprego, um programador me diz que é lento, eu vou vê-lo com bons olhos”.

Abraço e até a próxima.

Na minha última palestra, no Ceará On Rails, eu tive que preparar tudo de um dia para o outro e não pude organizar melhor as idéias colocadas nos slides. Em um deles eu escrevi “A procura da batida perfeita”, no momento que eu ia falar sobre as características de uma aplicação web ideal, da maneira que eu busco.

De lá pra cá eu venho pensando sobre o termo “batida perfeita” e relacionando com os acontecimentos do dia-a-dia na minha vida.

Então me veio a pergunta: Qual seria a batida perfeita para a gestão de uma empresa de desenvolvimento de software?

Antes de responder, é bom lembrar que a batida perfeita é aquela que dá gosto de ouvir.

Respondendo a pergunta acima, na minha opinião, a batida perfeita para gestão em software, envolve em parte o seguinte:

Utilização de metodologias ágeis

Se eu pudesse dar uma só dica sobre o futuro, seria esta: use metodologia ágeis
Os benefícios a longo prazo do uso de metodologias ágeis estão provados e comprovados pela ciência; já o resto de meus conselhos não tem outra base confiável além de minha própria experiência errante.

As metodologias ágeis começaram a ter força no Brasil, neste ano de 2009. O Scrum, Lean, Kanban, XP foram as filosofias e metodologias mais faladas entre os Brasileiros. Eu estou convicto de que o agile, como é chamado pelos íntimos, é mais eficiente que as metodologias adotadas atualmente, assim como sou convicto que haverá metodologias melhores no futuro próximo. O legal é que o agile já é o primeiro passo para se aceitar mudanças com velocidade.

Fixar qualidade, negociar escopo. Preço e prazo são consequência
É muito importante que você fixe a qualidade do serviço, seja para clientes externos ou clientes internos. Negociar o escopo é chave para o sucesso de projetos de desenvolvimento de software, pois assim fica garantido que o que foi feito vai funcionar, que é um dos maiores problemas neste setor.

Entendimento do perfil do desenvolvedor
Em geral, o desenvolvedor é um funcionário um pouco diferente dos demais. Um amigo meu já disse uma vez “É mais fácil tocar uma indústria com 600 funcionários do que uma empresa de software com 10”. É claro que não passa de uma opinião, mas o que ele queria dizer é que desenvolvedores são problemáticos.

O primeiro problema que deixa qualquer gestor neurótico é o horário. Difícil fazer o Daily Meeting no horário todos os dias, não é mesmo!?

Confiar no desenvolvedor é importante, principalmente nos prazos dados. É sério, eles sabem dar prazos. Os gestores que não sabemos aceitar.

Escolha de uma tecnologia para trabalhar
Escolher um ambiente e as tecnologias para as soluções que serão desenvolvidas é indispensável. Pequenas empresas principalmente precisam fazer uma escolha e segui-la.

As opções são inúmeras, dentre elas temos: software desktop, software para Windows, aplicações para mainframe, sistemas web na plataforma Windows, sistemas Ruby on Rails, etc. Perceba que não existe um critério, você pode deixar mais abrangente dizendo desktop x web ou especificar que será só pra Windows ou usando o framework X.

Embora não seja aconselhável você se prender a uma tecnlogia, quanto mais você especificar com o que deseja trabalhar, é melhor para evitar ficar perdido e gastar energia com falsas oportunidades.

Estes foram apenas quatro pontos que estavam na minha cabeça e resolvi colocar em um post. A batida perfeita não pára por aí evidentemente. Muitos outros fatores são relevantes, inclusive aqueles que dizem respeito à programação em si.

Havendo oportunidades escreverei sobre abatida perfeita para desenvolvimento de código de programação e fatalmente falarei sobre os tópicos abaixo:

Framework, Programação orientada a testes (TDD), Deployment automatizado, Integração contínua, Controle de versão distribuído, Definição de um Commit Pattern, Ambiente de Staging, etc.

Conforme eu for descobrindo características importantes, vou escrevendo aqui. Por enquanto é só.

Abraço e até a próxima