11 princípios do profissional com mentalidade de campeão

8214644575_7d775da957
Padrão

Você já parou para pensar como é longa a estrada da carreira profissional?

Refletindo sobre minha carreira, (que ainda esta longe de acabar), percebi que a estrada é realmente longa, no meu caso serão quase 50 anos de labuta.

Porém, felizmente, logo após perceber que eu ainda teria muitos e muitos anos de trabalho pela frente, me lembrei de um artigo esportivo que falava a respeito dos segredos da mente campeã. Este artigo fazia referência a um tal de Stephen Long, autor do livro “Level Six Performance: A Gold Medal Formula for Achieving Professional & Personal”.

Então, seguindo a filosofia “Assim no esporte como na vida”, acabei adaptando estes 11 princípios do Stephen Long, trazendo-os do esporte para a carreira profissional. Veja como ficou:

1. Aprendizado sobre ignorância

  • Não chore sobre o leite derramado.
  • Os problemas sempre vão acontecer, mas cabe a você prender com eles (todos os dias, para sempre).
  • Aprenda com a diferença entre o resultado esperado e o resultado ocorrido.

Dica: Faça reunião de retrospectiva ao final de cada ciclo de trabalho (uma semana, 15 dias, 1 mês, …). A ideia é identificar e comemorar os acertos e enxergar e entender os erros bem como refletir sobre como evitá-los no futuro.

2. Simplicidade sobre complexidade

  • Mantenha as coisas simples.
  • Não invente fórmulas mirabolantes.
  • Coisas complexas tomam mais tempo e geram mais risco e stress.

3. Proficiência sobre incompetência

  • Nunca se de por satisfeito com a sua produtividade e rendimento. Sempre é possível melhorar.
  • Busque evoluir sempre. isto vai te manter motivado para atingir e manter um nível de excelência.

Cuidado: Fazer mais rápido não é sinonimo de fazer melhor.

4. Excelência sobre mediocridade

  • Faça simples, mas da melhor forma possível.
  • Se for necessário faça menos, mas faça com excelência.
  • As pessoas lembram primeiro de quem fazem algo bem feito, e não de quem faz algo rápido. Seja excelente e vencerás.

5. Processo sobre resultado

  • Goste mais de buscar o resultado do que atingi-lo.
  • Não trabalhe apenas pelo dinheiro, trabalhe com o que você gosta de fazer, em uma empresa que você acredita.
  • As chances de atingir o sucesso são mínimas se não há satisfação no seu dia-a-dia.

6. Progresso sobre deterioração

  • Multidisciplina e multitarefa não são a mesma coisa.
  • Se você fizer de tudo ao mesmo tempo, sem foco, vai estar se deteriorando.
  • Seja polivalente, isto vai te levar a entender o todo e vai te fazer progredir na carreira, mas faça uma atividade de cada vez. Um triatleta não nada, pedala e corre ao mesmo tempo.

7. Decisão sobre vacilo

  • Seja determinado.
  • Não reclame quando aparecerem problemas, resolva-os.
  • Não deixe trabalho para depois, principalmente se for algo importante.
  • Faltam 15 minutos para acabar o dia de trabalho? Então foque e torne estes 15 minutos produtivos.

8. Equilíbrio sobre extremismo

  • Não seja radical, equilibre outros prazeres com a sua carreira mesmo quando seu trabalho proporcionar prazer e realização.
  • Profissionais que seguem uma base extremista acabam frustrados e pouco recompensados.
  • Mais do que sair de férias curta as férias e desligue do trabalho.

9. Eficiência sobre desperdício

  • Pare de fazer tarefas que não agregam valor para sua empresa ou cliente.
  • Faça certo na primeira vez.
  • Quando o bolo é bom ninguém reclama que faltou a cereja. Foque no bolo, esqueça a cereja.

10. Confiança sobre a dúvida

  • Todos falham algum dia. É inevitável.
  • Não faça um dia ruim se tornar uma vida ruim, esteja sempre confiante.
  • Não deixe falhas pontuais abalarem sua confiança.

11. Humildade sobre arrogância

  • Escute mais, fale menos.
  • Troque conhecimentos com todos, sem preconceitos.
  • Não critique ideias, se não gostou questione ou sugira alguma coisa.

O que achou do post? Faz sentido? Deixe seu comentário.

Como criar um ambiente de aprendizagem em sua equipe?

Padrão

Palestra realizada no FISL 2013 sobre cultura de aprendizagem por Rafael Helm e Guilherme Elias.

Nesta palestra Rafael e Elias falam sobre algumas ações que empresas e equipes podem realizar para disseminar conhecimento entre as pessoas, criando assim um ambiente de aprendizagem e melhoria contínua.

Pratique para sempre

Padrão

karate-kidPraticar para evoluir é algo necessário na vida de qualquer pessoa. Desde criança, usamos a prática como forma de aprendizado e evolução, basta você puxar da memória para lembrar como foi necessário praticar até conseguir amarrar os cadarços de um calçado sozinho, sem precisar da ajuda dos pais.

Atletas chamam está prática de “treino”. Atletas treinam quase que diariamente, muitas vezes de forma exaustiva e repetitiva. Se você acha que o jamaicano Usain Bolt (recordista mundial e bi-campeão olímpico nos 100 e 200 metros), atingiu o alto nível através de talento e boa genética (sorte), então de uma olhada neste vídeo e veja como ele treina.

É bem provável que ainda hoje você vai precisar executar alguma tarefa que não se sente confortável, que ainda não praticou o suficiente. Alguém pode te ensinar algo, te dar uma introdução ou até uma explicação bem detalhada; você pode ler livros e fazer treinamentos, mas muitas vezes você só vai aprender de verdade praticando, tentando, treinando, refletindo sobre os erros e acertos, e praticando novamente.

No desenvolvimento de software praticar/treinar é algo mais do que necessário, é obrigatório, é fundamental. Durante toda sua carreira, você precisará passar por ciclos de aprendizado que somente serão concluídos se você praticar.

Não importa se você está aprendendo uma nova linguagem de programação, ou aprendendo TDD, ou aprendendo uma nova forma de escrever requisitos que pode ser através de user stories, ou uma nova forma de estimar requisitos através de user story points e planning poker ou outras formas de estimativa, ou um novo modo de trabalhar em equipe através de Scrum e eXtreme Programming. Não importa o que você está aprendendo, você vai precisar praticar, refletir, e praticar novamente para aprender de verdade.

Assim como no esporte quanto na vida, praticar/treinar dói. Mas acredite, se você insistir e perseverar a dor vai passar, e com o tempo aquela prática que antes te machucava vai se tornar algo agradável. Eu vejo muita gente começar a correr para perder peso, (mesmo odiando correr), mas com o tempo, através da prática gradativa o que antes era algo desconfortável rapidamente deixa de ser algo tão ruim, e mais a frente a pessoa começa a curtir o hábito da corrida, e muitas vezes até começa a acordar mais cedo para correr mais tempo e distâncias maiores.

“Não se preocupe com a perfeição – você nunca irá consegui-la.” (Salvador Dali)

Um ponto importante a ser considerado quando estamos praticando é trabalhar com baby steps, ou seja, pequenos passos de forma gradativa, buscando sempre acertar o próximo passo ao invés de alcançar a perfeição. Desta forma seu aprendizado vai passar por várias pequenas vitórias que vão motivá-lo, e quem sabe, sem perceber, alcançar a perfeição.

No desenvolvimento de software eu vejo uma onda bacana de coding dojo acontecendo dentro de empresas, universidades e eventos, acho isto ótimo. Os coding dojos proporcionam um ambiente saudável de aprendizado, já que a troca de experiências entre os participantes é o ponto forte da atividade, e para pessoas como você que querem aprender e praticar, isto, vamos combinar, é uma enxurrada de motivação.

E você, já praticou hoje? ;)

Desenvolvedor profissional. Será?

Padrão

Desenvolvedor profissionalEm 2010 escrevi este post para o portal iMasters.

Passados 3 anos resolvi puxar o post pra cá e já aproveitei para revisar e complementar alguns tópicos.

Aviso: não se ofenda com o que vai ler a seguir, algumas comparações são na verdade uma provocação, o objetivo aqui é te fazer refletir, para quem sabe melhorar mais a frente – Hansei + Kaizen (Reflexão e melhoria contínua).

– — — — — — — –

Segundo o dicionário da língua portuguesa a definição de profissional é “pessoa que exerce uma certa profissão”.

Então, se você exerce profissionalmente o papel de desenvolvedor de software, logo, você pode ser classificado como um “desenvolvedor profissional”, correto?

Em tese sim!

Digo em tese porque meu conceito (e não é apenas o meu conceito) de desenvolvedor profissional é diferente do que consta no dicionário. Tem muito desenvolvedor amador por ai no mercado, botando banca de super-herói, mas que na verdade gera mais bugs do que features de software.

Mas como podemos diferenciar profissionais de amadores? Algumas dicas:

- Desenvolvedores profissionais planejam suas implementações antes de sair despejando linhas de código na aplicação. Desenvolvedores amadores freqüentemente trabalham com o método de tentativa e erro, ou seja, sem nenhum planejamento prévio ou análise de impacto em outras classes/módulos da aplicação. Não subestime o poder de um fluxograma.

- Desenvolvedores profissionais se preocupam com o desempenho de suas soluções e não apenas se a especificação recebida foi atendida. Desenvolvedores amadores não se preocupam com desempenho, o importante é entregar o que foi pedido, afinal de contas no documento não falava nada em relação a performance.

- Desenvolvedores profissionais produzem códigos legíveis, frequentemente fazem refactoring em seus códigos e são apaixonados pelos livros Clean Code e Clean Coder do Robert C. Martin. Enquanto isto, os desenvolvedores amadores procuram no dicionário o significado da palavra refactoring.

- Desenvolvedores profissionais trabalham com desenvolvimento orientado a testes e criam testes funcionais, ou pelo menos estão ligados no assunto e buscam formas de “conectar” isto ao seu cotidiano. Desenvolvedores amadores não são pagos para testar; Azar do testador, compilou passa pra frente!

- Desenvolvedores profissionais estão atentos para outras atividades do ramo de desenvolvimento de software como análise de requisitos, banco de dados, padrões de projeto, metodologias de desenvolvimento, teste de software, etc. Desenvolvedores amadores apenas programam, isolados de tudo e de todos!

- Desenvolvedores profissionais trazem os problemas a tona sempre que os encontram. Desenvolvedores amadores varrem para debaixo do tapete.

- Desenvolvedores profissionais sempre buscam acertar na primeira vez e para isto não abrem mão da qualidade de código, para eles a qualidade nunca é opcional e está sempre presente. Desenvolvedores amadores evitam a fadiga, praticam pog no dia a dia, e quando a coisa fica feia procuram outro lugar para trabalhar. ;)

E você, é amador ou profissional?

Fuja da dívida técnica

Padrão

Dívida TécnicaO projeto começa e a equipe de desenvolvimento está produzindo muito, várias partes do software vão sendo construídas e o time está feliz.

Passadas algumas semanas a produtividade caiu um pouco, a euforia do time passou, mas o projeto ainda transcorre dentro da normalidade e o time de desenvolvimento não está aborrecido.

Passadas mais algumas semanas e a produtividade cai drasticamente, muito bugs começam a ser encontrados, neste momento o time já está com a moral baixa, o cliente notou que o projeto não anda bem, o custo de mudança de qualquer funcionalidade é muito alto, e você não entende o motivo desta queda de produtividade, afinal de contas o time é bom, a especificação foi bem feita, o cliente está próximo, a comunicação flui e as pessoas são comprometidas. Então o que está acontecendo?

É bem provável que o projeto possua uma dívida técnica grande.

O termo dívida técnica é utilizado para indicar trechos de código que foram mal escritos, ou escritos de qualquer forma, sem respeitar padrões, são as chamadas gambiarras. Com o passar do tempo estes trechos de código vão atrapalhar os desenvolvedores, e mudanças que teoricamente seriam simples passam a levar muito tempo para serem realizadas.

É natural que o custo de mudança do software aumente com o passar do tempo, pois logicamente quanto mais código um projeto possui maior tende a ser o impacto de adicionar uma funcionalidade (mais código). Se formos alterar uma funcionalidade o custo de mudança tende ser maior ainda, já que em alguns casos uma mudança de regra de negócio pode afetar várias partes do software.

É provável que você já tenha se deparado com uma funcionalidade impossível de ser evoluída, tamanho era a falta de qualidade do código, em alguns casos quando isto ocorre somos obrigados a refazer toda a funcionalidade, pois o código se tornou ilegível, e isto gera um grande desperdício de tempo e dinheiro.

Muitos desenvolvedores ainda consideram que qualidade do código é algo extra, que se der para produzir código de qualidade legal, mas o foco é entregar software com qualidade, não necessariamente produzindo código de qualidade. Esta é um escolha perigosa, pois a menos que o projeto seja bem pequeno o desenvolvedor vai precisar pagar a conta da dívida técnica produzida, ou simplesmente o projeto vai parar.

Mas como desenvolver software sem gerar dívida técnica? Ah meu amigo, isto é assunto para outro post ;) mas recomendo assistir um vídeo do Alexandre Freire da Industrial Logic, que falou sobre isto no Agile Brazil 2012 -> Link do vídeo na InfoQ.

Cliente distante! Qual impacto?

Padrão

Best_Friends_Forever_by_toxicdisaster_x

Você é desenvolvedor, e recebeu uma especificação para trabalhar, e enquanto está codificando percebe que algum detalhe passou despercebido durante a análise do requisito. Ou seja, você não consegue prosseguir enquanto não esclarecer este detalhe, esta dúvida. O que você faz?

Normalmente você vai procurar o analista ou a pessoa responsável por aquela especificação (ou pelo menos deveria fazer isto), e vai questionar esta pessoa a respeito da dúvida que te impede de avançar no código com a certeza de que estás seguindo na direção correta.

Quando isto ocorre, você espera que o analista saiba responder suas dúvidas e te conduza de volta ao caminho correto a seguir. O problema é que as pessoas não sabem tudo, você não sabe tudo, e o seu analista também não sabe. É normal que em alguns casos o analista não consiga te responder, pelo menos não de forma imediata. E ai, o que fazer?

Quando as dúvidas surgem e ninguém da equipe sabe o que fazer, a melhor decisão é falar com o cliente, seja através de uma reunião, telefone, skype, e-mail, ou qualquer outra forma de comunicação. Mas precisamos falar com o cliente!

Ficar praticando tentativa/erro/tentativa/erro, ou adivinhação são péssimas alternativas, você até pode acertar de vez em quando, mas na média, esta atitude vai gerar retrabalho lá na frente, além de frustrar o cliente e posteriormente frustrar a equipe.

Mas sabemos que nem sempre o cliente vai estar disponível, mesmo que o cliente esteja fisicamente próximo de você e sua equipe, ele pode simplesmente não estar livre ou interessado em te atender, ou seja, ele não quer se envolver, até porque ele pagou uma boa grana para sua empresa fazer o software dele, e ele espera que você e sua equipe saibam como fazer isto.

Este cenário é o que chamamos de cliente distante, e acredite, projetos com cliente distante tem uma grande tendência de serem entregues com atraso, ou estourarem o orçamento, ou frustrarem o cliente entregando funcionalidades que não atendem suas expectativas, ou todas as alternativas anteriores (o que é um fracasso tremendo).

Mas como evitar que isto ocorra? Aproximando o cliente desde o inicio do projeto e deixando bem claro para ele que a qualquer momento ele poderá ser acionado para tirar dúvidas, e também deixar claro que a cada funcionalidade ele poderá ser chamado para realizar uma validação, ou seja, dar um aceite de que aquele recurso ficou de acordo com o que ele esperava, ou nos indicar o que precisa ser ajustado para atendê-lo, caso o resultado não tenha ficado de acordo com suas expectativas.

Mas tome cuidado, pedir o aceite do cliente não significa pedir para o cliente testar. O teste do software é sua responsabilidade, e acredite em nós, os clientes não gostam de testar software, e principalmente, os clientes não ficam muito felizes quando encontram bugs.

Quando você pede para o cliente validar a funcionalidade, você está na verdade buscando feedback. Você está buscando confirmar que aquela funcionalidade que acabou de sair do forno está de acordo com a expectativa do seu cliente. Você está buscando segurança para continuar o desenvolvimento do projeto, tendo certeza que os passos dados até agora foram realizados seguindo na direção correta.

E se o cliente odiar a funcionalidade que você entregou, dizendo que está totalmente fora do que ele esperava? Ótimo! Você conseguiu falhar rápido, e terá tempo para corrigir, adaptar ou até mesmo refazer a funcionalidade, conseguindo assim finalmente entregar algo de valor para seu cliente. Imagine como seria desagradável se somente no final do projeto você descobrisse que algumas (ou várias) funcionalidades não ficaram de acordo com a expectativa do seu cliente. Seria terrível!

Aproxime-se de seu cliente! Mantenha-se próximo!

Se você curtiu este post, te sugiro ler este também -> A Importância do Aceite