Rafael Lima

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

Mesmo que você não tenha feito o Empretec, pode ler este post, pois não revelo nada sobre a metodologia.

Uma semana se passou do seminário Empretec que participei e meu ritmo continua acelerado. Quem me acompanha no Twitter já sabe que eu fiz o Empretec e ficou sabendo da minha evolução.

Segundo a definição do Sebrae, realizador do Empretec no Brasil, o EMPRETEC é um seminário que tem por objetivo desenvolver, nos participantes, características de comportamentos empreendedores. O programa foi desenvolvido pela ONU – Organização das Nações Unidas visando o fortalecimento destas características empreendedoras. O participante deverá primeiro identificar seu potencial empreendedor e verificar quais são seus pontos fortes e fracos.

Eu não posso falar sobre o seminário em si, todos os participantes assinam um termo de compromisso de sigilo sobre a metodologia e além disso, falar o que acontece, estragaria por completo o seminário para você, caso queira fazer.

O que eu posso dizer é que, se você busca empreender, seja na empresa onde trabalha ou com sua(s) própria(s) empresa(s), faça o Empretec!

Este seminário é uma oportunidade ímpar de você crescer e entender todos os seus pontos fracos e fortes como empreendedor. Eu já me conhecia bastante, isso ficou evidente pra mim durante o seminário, mas se conhecer não basta, eu precisava de um empurrãozinho para mudar meu comportamento na prática.

Durante o seminário recebi alguns feedbacks positivos e depois dele, já tive algumas reuniões em que me disseram que eu parecia ser “um outro Rafael”.

Se você deseja fazer o Empretec, seguem algumas dicas:

• Prepare-se, escolha uma data que você não tenha compromissos e que você possa ter o tempo livre;
• Pense bem antes de se inscrever, o Empretec só pode ser feito uma vez na vida e depois de iniciar você não pode voltar atrás;
• Escolha um Sebrae perto da sua casa ou arrume um lugar para ficar durante o seminário, próximo do Sebrae (eu fiz isso e foi fundamental);
• Converse com marido, esposa e filhos antes de começar para deixar bem claro que você não poderá dar a atenção que eles merecem durante o seminário;
• Deixe bem claro na empresa onde trabalha, que você não estará disponível neste período e que poderá resolver qualquer problema somente após retornar;
• Se possível, marque suas férias no período do Empretec de forma que você tenha tempo livre após o seminário para descançar e refletir sobre sua vida.

Eu estou muito feliz de ter feito o Empretec neste momento da minha vida e de ter aproveitado bastante. Particularmente, eu finalizei com uma sensação de dever cumprido. Foi uma sensação que eu vou lembrar pro resto da vida.

Eu agradeço esse momento aos meus pais que, pela educação que me deram, possibilitaram que eu chegasse aonde estou, aos dois principais facilitadores, Almeirão e Joaquim, que me fizeram parar para refletir me dizendo a coisa certa no momento certo, aos facilitadores Mauro, Francisco e Carloman, que me passaram diversas informações úteis e me ajudaram bastante durante o seminário e por fim, a todos os empretecos da minha turma, pois seus exemplos foram fundamentais para meu aprendizado.

Agora é olhar pra frente e colocar em prática tudo que aprendemos e vivenciamos.

Um abraço e até a próxima.

Esses últimos três dias foram muito loucos pra mim. Uma sequência de acontecimentos resultou em um final de semana bem interessante, pelo menos até agora.

Tudo começou quando eu coloquei no ar, na noite de quinta-feira (05/11/09), o site do Cobre Grátis, uma nova aplicação web que estou lançando. Na sexta-feira de manhã o Tapajós me ligou dizendo que teve um problema pessoal e que não poderia realizar a palestra sobre CouchDB no Ceará On Rails e me perguntando se eu gostaria de ir no lugar dele.

Eu gostaria de agradecer imensamente ao Tapa por ter lembrado de mim e ter feito o convite. Gostaria também de deixar um grande abraço e vibração positiva para que fique tudo bem em relação ao problema que ele teve.

Voltando ao dia de sexta-feira, depois de alguns telefonemas, fechamos a minha vinda para o Ceará On Rails por volta das 12:00h. A partir daí foi uma loucura. Depois do dia de trabalho normal na Myfreecomm, fui pra casa me arrumar e ir para o aeroporto. Meu voô era 1:25h da manhã de sábado.

Quando estava com a mala arrumada e sentei para começar a pensar na palestra, faltavam 30 minutos para eu sair de casa e ir para o aeroporto. É claro que não deu pra fazer nada!

Chegando no aeroporto fiz o check-in e comecei a preparar a palestra, foram duas horas, com uma pequena interrupção para um doido que pediu para comprar uma passagem pela internet no meu laptop.

Fiz o que pude até a hora do embarque, por volta das 2:00h da manhã. Cheguei no hotel em Natal umas 5:00h e fui dormir. No dia seguinte acordei por volta das 8:00h e fui fazendo a palestra nos momentos que davam até o último minuto, literalmente.

[...]

Estamos desenvolvendo na Myfreecomm um sistema de cobrança que está ficando muito interessante. Ele irá resolver um problema real e trará muita conveniência no dia-a-dia das empresas que realizam cobrança com integração com os bancos.

O sistema está quase pronto e estamos neste momento definindo aqueles detalhes que fazem toda a diferença.

A concepção foi baseada em um fluxo único de uso, de forma que os itens de menu contemplassem as ações que o usuário irá realizar, como se o sistema todos fosse um grande wizard. As páginas acessórias são acessadas apenas por links contextuais. Não temos menu e submenu, nem breadcrumb. E te digo, fazer o sistema assim é um desafio!

A interface ficou bem simples, sem muitas opções e com links no lugar certo e na hora certa. Quando fazemos sistemas deste gênero as palavras e termos utilizados nos itens de menu, nos títulos e nos links são muito importantes. É preciso que o usuário consiga se situar de forma rápida e entenda o que irá acontecer a cada clique.

O Allan é o responsável por fazer com que o sistema seja entendido pelos usuários. Ele está escrevendo o manual, pensando em que lugares existirão links para o manual, quais são os pontos que podem gerar dúvidas, etc. E nesse processo ele está revendo os termos utilizados a todo momento. Inclusive nas interações chegamos a perceber e incluir na histórias novos status para determinada entidade e tudo.

Hoje ele levantou uma bola que gerou uma discussão muito saudável. Uma das ações do usuário no sistema é juntar várias cobranças para que elas sejam enviadas para o sistema do banco. Até hoje, o termos utilizado para esse conjunto de cobranças era Remessa. Tínhamos termos tais como: Preparar Remessa, Enviar Remessa, Remessas Pendentes e Remessas Enviadas.

A questão levantada foi: “Não deveria ser Lote ao invés de Remessa?”

A conclusão imediata depois de um rápido brainstorm foi de que tanto faz, afinal dá no mesmo, lote e remessa são a mesma coisa. Bem, depois de muita conversa e esclarecimento sobre entidades, estados, tempos, etc chegamos a uma opinião diferente.

Buscamos definições de lote e remessa no Google, depois fomos aos dicionários priberam e Aurélio. Mais alguns minutos de discussão e desenho foram neecessários para concluirmos que Remessa é algo que foi enviado, ou seja, que já passou pelo processo de envio. Se existe algo que pode ser remetido, mas ainda não o foi, isso não pode ser chamado de Remessa.

Donde se concluí que  dizer “Enviar Remessa” está errado e o termo “Remessa enviada” é um pleonasmo. Se é Remessa, é por que já foi enviado.

No meio da discussão chegamos a lembrar que muitas vezes não importa o “certo” e “errado” na gramática formal e que o mais importante é o entendimento do usuário. Mas é o que eu digo, se podemos usar o correto de acordo com a gramática sem afetar o entendimento do usuário, melhor. Se, usando o termo gramaticalmente corrento, ainda assim facilitamos o entendimento do usuário, como foi o caso, melhor ainda!

Por fim decidimos usar o termo Lote ao invés de Remessa e mudaremos para “Preparar Lote”, “Enviar Lote”, “Lotes pendentes” , “Lotes enviados” e outros termos presentes na interface. Como escrevemos todo código de programação em inglês, não tivemos maiores problemas.

Essa experiência foi muito interessante, pois foi legal estudar e discutir sobre o significado destas palavras e foi incrível perceber como uma mudança simples pode ao mesmo tempo melhorar o sistema e facilitar nosso trabalho. Ficará mais fácil agora escrever o manual. É aquela velha história: Se está difícil, está errado!

Uma vez eu li um post da 37signals extamente sobre isso. Agora eu entendo perfeitamente o que eles queriam passar com o post, e é o que eu espero deixar de recado também.

A definição de termos corretos e fáceis de serem compreendidos pelo usuário é fundamental para a boa usabilidade do sistema.

Além disso, escolher as palavras certas facilita a compreensão da relação do que elas representam com o sistema como um todo.

São diversos fatores que tornam um sistema bom ou ruim, difícil ou fácil de usar e complexo ou simples. Usar palavras corretas e de simples entendimento é um fator muito importante. Às vezes parece que está tudo bom, e que as palavras estão certas e serão compreendidas, mas nem sempre é verdade.

Pense no sistema que você usa ou está desenvolvendo. Será que mudando alguns termos não ficaria muito mais fácil de usar? Você tem algum caso similar? Deixe sua história nos comentários!

Abraços e até a próxima.