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

Os Pequenos Notáveis!

5100243292_5a908a8383

Times pequenos (até 5 ou 6 pessoas) podem fazer mais do que times grandes (mais de 10 pessoas) simplesmente porque são menores.

Em times pequenos, a execução de tarefas do tipo “cereja do bolo” ficam sempre em último lugar, pois como o time é pequeno (e a lista de tarefas importantes é maior do que a lista de tarefas menos importantes) todos do time se mantêm trabalhando no que realmente precisa ser feito. Isso reduz significativamente o desperdício de esforço em tarefas que não precisam ser trabalhadas (pelo menos não agora).

Complementando o que já foi comentado pelo Daniel aqui no pingos de agilidade, as restrições de um time pequeno obrigam as pessoas do time a irem além do ponto em que geralmente iriam se trabalhassem em um time grande, pois geralmente (para não dizer sempre) os times grandes possuem especialistas: O Joãozinho só testa, o Pedrinho é o cara do HTML e CSS e o Huguinho conhece todos os segredos do deploy. Já em times pequenos é rotina que todos trabalhem escrevendo estórias, desenvolvendo software, fazendo tunning de banco de dados, testando, fazendo deploy, etc. E, naturalmente, este trabalho multi-disciplinar vai proporcionar ao time uma maior visão “do todo” do projeto.

Em times pequenos é fácil todos saberem o que todos estão fazendo. Isso porque as reuniões diárias são muito rápidas e, é mais fácil uma pessoa processar a informação sobre o que outras 4 ou 5 estão fazendo do que escutar e processar o que uma dúzia de pessoas falaram.

Outro ponto importante é que em times pequenos não faz muito sentido eleger uma pessoa para exercer o papel de gerente/coordenador/supervisor/seja lá o que for, já que todos fazem tudo e dominam o projeto inteiro. E, como neste caso “todos” não é sinônimo de um número grande de pessoas, o cliente (seja interno ou externo), se sente a vontade para participar das reuniões de planejamento juntamente com o time. Quem já trabalha com o hábito de realizar reuniões de planejamento sabe o quanto a presença do cliente é positiva nestas reuniões.

Sendo assim, eu acredito que treinar o time buscando continuamente melhorar as habilidades e, principalmente, a multi-disciplina de todos é melhor solução do que contratar mais pessoas.

É claro que existem casos em que a contratação é inevitável, mas lembre-se “Contrate apenas quando doer!” (e muito). 😉

Contrate apenas quando doer!

4129400323_03d17b79b0

Para quem conhece o pessoal da 37Signals, e já leu o livro Rework, deve se lembrar do tópico: “Hire when it hurts“.

Eu particularmente gosto deste tópico, por gostar de trabalhar com equipes pequenas e por entender que as restrições são excelentes para mostrar como somos capazes de ir além e de nos superar.

Demonstra como podemos realmente ser multidisciplinares e como conseguimos crescer como equipe.

Então a dica é sempre esperar o máximo possível antes de partir para uma nova contratação. Trabalhe com o time as restrições, garanta qualidade e excelência técnica do seu time. Garanta o aprendizado e gestão de conhecimento. Garanta a colaboração e práticas que fazem o time crescer.