Rafael Lima

Vou aproveitar um e-mail que escrevi hoje e postá-lo aqui, pois pode ser relevante para mais pessoas.

Toda meta deve ser SMART:

eSpecífica
Mensurável
Atingível
Relevante
Temporal

Específica -> Ela deve ser clara sobre o que você está definindo. Você pode ter metas sobre saúde, relacionamento com mulher/marido, trabalho, peso, prática de esporte, etc.. O importante é que ao ler a meta você consiga identificar com facilidade do que se trata. Ela tem que ser bem específica sobre um assunto e por isso eventualmente você terá metas concorrentes sobre âmbitos diferentes. Em geral uma meta apenas para cada assunto.

Mensurável -> É preciso quantificar. Por exemplo, muita gente coloca como meta: “Quero perder peso”. Isso não é nem um pouco mensurável. Quantos quilos deseja perder? Como você saberá se conseguiu atingir a meta ou não sem definir um valor? Resumindo, toda meta precisa de números, podemos dizer que ela tem que ser alfa-numérica! O número irá possibilitar você avaliar se foi bem sucedido ou fracassou. Todas as pessoas de sucesso se importam com números. Se tem haver com peso, coloque o peso alvo, se tem haver com grana, coloque o valor em reais.

Atingível -> É importante definir metas que somos capazes de realizar. Temos imperfeições e a natureza não dá saltos, temos que ser humildes para reconhecer nossas limitações e definir algo que esteja dentro da nossa capacidade. Não vale a pena definir metas impossíveis, por que senão a frustração será certa. No entanto, a meta depois de cumprida deve servir como motivação para a definição das próximas. Ao mesmo tempo é importante colocar alguma coisa que vai nos tirar da zona de conforto.

Relevante -> Relevância é fundamental, sem relevância não temos motivação para dar o máximo de nós para atingir a meta. Por que iria me ferrar todo, para correr atrás de alguma coisa que não é relevante pra mim? O objetivo de definir metas é que elas sejam cumpridas, e para isso temos que ter motivação para realizá-las. Pensar na relevância antes, faz com que filtremos melhor as ideias e escolhamos o que realmente importa. Eventualmente as pessoas determinam metas que não são importantes para elas, as vezes, por serem importantes para outras pessoas, mas isso não funciona. A SUA meta deve ser importante para VOCÊ.

Temporal -> A data é outro fator importantíssimo. Você pode colocar uma meta: “Quero acumular R$ 100.000,00″. Aí eu pergunto. Adianta acumular os cem mil dentro de 60 anos? Provavelmente não, neste caso. Então toda meta deve ter uma data. Uma data não é “ano que vem”. Ano que vem pode ser 365 dias diferentes, e se for assim, você poderá empurrar com a barriga e se enganar durante todo esse tempo. Uma boa meta tem dia, mês e ano definidos. Chegando no dia, você para para avaliar se conseguiu atingir a meta. No dia seguinte essa meta morre, independente de você ter sido bem sucedido ou não. Se aquilo continua sendo relevante, uma nova meta com nova data deve ser criada.

Aproveite a dica para criar as metas dos projetos que você está trabalhando e o final do ano para criar suas metas pessoais!

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.