11 princípios do profissional com mentalidade de campeã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?

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

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á?

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

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?

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

Minha equipe / empresa quer adotar Metodologias Ágeis. Quais os benefícios?

O principal? Uma mudança de atitude na organização. Ter pessoas que estão interessadas em mudar e melhorar. E neste ponto, as empresas começam a encontrar e buscar um perfil profissional com características de trabalho em equipe, atitude, pessoas focadas em melhorar continuamente. Em colaborar.

O grande ponto é criar mecanismos nas organizações que ajudem na fomentação, criação e realização de mudanças. E que estas mudanças ocorram pela equipe de trabalho. Não por alguma gerência específica ou consultores externos. Através de ciclos curtos de revisão e adaptação, as equipes podem validar se a mudança foi válida ou se uma nova estratégia precisa ser definida. Falhar faz parte do processo de aprendizado. Seu contexto é diferente do contexto de outras empresas. Copiar nem sempre é opção.

As empresas que não possuírem um ambiente propício para mudanças vão em breve ver uma série de pessoas deixando e buscando empresas que valorizem isto. Ser infeliz no ambiente de trabalho não é mais uma opção.

Se a organização criou mecanismos de mudança, é agora hora de ensinar as pessoas do poder que elas tem. Criar autonomia. Com isto, as empresas terão braços de inovação crescendo, pouco a pouco. Um ritmo de trabalho começa a ser formado. As pessoas começam a achar normal sair da zona de conforto e buscar resolver problemas internos e a trabalhar harmonia e colaboração com toda a equipe.

E aqui tem outro detalhe. As pessoas que não entrarem neste ritmo de mudanças e melhoria contínua, de querer ajudar e focar no trabalho em equipe, serão levadas a se retirarem da organização. De forma natural. Elas deixam de ter a identidade do time. Vão acabar por buscar uma organização compatível com as suas expectativas de dedicação (envolvimento / comprometimento). Não é que tenha algo errado. Afinal, como dizia Deming, a mudança não é obrigatória, afinal de contas, sobreviver é opcional.

No final o sistema se ajusta como um todo. E a atitude positiva é o que vai valer.

Em resumo? Melhorar continuamente. Através deste caminho, as empresas se tornarão  “organizações em contínuo aprendizado“. A criação de conhecimento se torna meta. Ou melhor ainda, um hábito. Definir um ritmo para que este aprendizado possa ser discutido e evoluído. Aí se tem reuniões de retrospectiva e outras dinâmicas que permitem as equipes terem alinhamento e reflexão. A melhoria de comunicação vai minimizar riscos, conflitos e aumentar a possibilidade de sucesso da organização olhando a evolução da sua cultura.

Aproveite o caminho, e saboreie as mudanças!

Vá e veja com seus próprios olhos!

Quantas vezes durante sua carreira você trabalhou na solução de um problema, que na verdade, não existia?

Ou utilizou uma informação incorreta para criar uma funcionalidade em seu software?

Ou tomou alguma decisão baseada em boatos que escutou pelos corredores?

Eu já passei por isto algumas vezes, e provavelmente você também.

O que precisamos fazer é simples: Genchi Genbutsu!

Vá e veja com seus próprios olhos!

Quando um cliente te pedir uma funcionalidade nova, que por exemplo, resolva um problema em sua linha de produção, vá até o cliente e veja com seus próprios olhos como funciona a linha de produção e qual é o problema do cliente.

O ponto aqui é: Vá na origem, observe pessoalmente, verifique dados, em vez de teorizar com base no que os outros te falam.

Quando você vê algo por si mesmo, você entende completamente a situação, e não é traído pelas falhas de comunicação que ocorrem com frequência.

Isto vai exigir que você saia da famigerada zona de conforto, porém reduzindo significativamente o desperdício de energia (e muitas linhas de código) para resolver problemas que não existem. 😉

Qual a melhor estimativa usada em ambientes Ágeis?

03082012TrenaFotoMarcosSantos009

Qual funciona melhor, qual é mais precisa?

E a minha resposta é ao mesmo tempo nenhuma e todas. O ponto não é este.

O que seu time deve buscar em uma reunião de estimativa não é uma certeza, mas sim conseguir entender que o time está alinhado e aprendendo sobre o negócio. Em uma brincadeira com planning poker, onde os números possíveis são 1,2,3,5,8,13… se uma pessoa indica o número 1 e outra pessoa indica o número 13, você tem um momento para discussão, para nivelar conhecimento ou conhecer um risco que estava “escondido” no sistema.

Todas as técnicas funcionam para guiar o time e criar um modelo de pensamento… conforme o time evolui em conhecimento de negócio e tecnologia, a tendência é a estimativa funcionar melhor e ajudar o time a visualizar questões que estejam “fora de padrão”.

O principal benefício dos exercícios de classificação/estimativa é gerar discussão e basear o conhecimento das pessoas sobre as funcionalidades a serem desenvolvidas. Ou seja, se você usa uma técnica de estimativa, deveria ser para crescer conhecimento da equipe. Não para poder culpar alguém depois.

E se você precisa estimar algo que é nebuloso? Você vai precisar seguir no conceito do 3C, para poder conhecer mais sobre a funcionalidade e possivelmente adicionar Spikes no planejamento, assim poderá experimentar e aprender mais sobre algo antes de fazer a definição da funcionalidade por completo.

Você deveria conversar até ter visão de que o que precisa ser feito é algo factível. Eu gosto de quebrar coisas e entender que elas cabem no máximo em três dias (idealmente no máximo 1 dia). No fim, isso é uma “regra de dedão“, ou seja: vamos aprender mais se o que temos para fazer ainda não está sendo percebido por todos da equipe. Vamos nos manter em modo descoberta, até que possamos caminhar para o modo entrega.

Se o seu time chegar nesta regra de que tudo tem um tamanho pequeno para executar, você não precisa mais estimar! Tudo vira “1”. E isso só quer dizer que o seu time tem um objetivo de “até quando vamos nos manter em modo descoberta” antes de iniciar a executar / entregar algo.

A reunião da manhã – melhoria contínua

8135229928_de131d8c4d

Seth Godin fala duas coisas que eu acho muito legal. Uma delas é porque perguntar porque? E a outra é sobre a qualidade das nossas perguntas. Nós crescemos e evoluímos e cada vez mais aprendemos a perguntar de forma especializada, sobre como está o tempo hoje.

Melhoria contínua será um processo muito melhor e simples se aprendermos a fazer perguntas diferentes, além de perguntar sobre o tempo durante a manhã.

Além de melhorar a qualidade das perguntas, precisamos estar presentes no local dos problemas, para poder ver de perto e sugerir melhorias, com o devido contexto. Estar presente no Gemba, e poder trabalhar com o conceito de Genchi Genbutsu é o que precisamos.

Mas o objetivo é falar de melhoria contínua e sobre uma prática da Fastcap, sobre a reunião da manhã para puxar melhoria contínua.

Prática simples, que busca criar uma cultura de aprendizado, diário, e que permite as pessoas exercitarem inovação, permite as pessoas trabalharem em equipe, melhorando o sistema e o ambiente de trabalho como um todo.

Na sua empresa, como sua equipe exercita a melhoria contínua?