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.
Praticar 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? 😉
Em 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?
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!
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. 😉
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?
No dia 19 de outubro de 2011, eu escrevi no Twitter: “Cuidado, as vezes mesmo em estrutura flat de empresa você pode criar um mundo dilbert. Evite, dê poder de verdade as pessoas! #empowerment”
Gostaria de evitar ver nas empresas qualquer coisa que se relacione com um post que fiz no primeiro de abril, onde trago a tona uma expectativa sobre como não viver no ambiente de trabalho. Enfim, parece que alguns não dão risada e ainda ficam imitando.
O principal é manter as coisas simples.
É poder trabalhar e criar um ambiente onde as pessoas se sintam responsáveis e com vontade de funcionar não apenas como profissionais que executam tarefas, mas também como profissionais que criam e puxam iniciativas, que estão presentes quando o time precisa de ajuda.
Que encontram na equipe um ambiente que se identificam e que querem ajudar a ficar melhor sempre.
Ao centralizar o poder no ambiente de trabalho, você dá a chance das pessoas criarem uma zona de conforto, e isto não deve ser alimentado, nunca. Steve Jobs falou uma vez, “Stay hungry, stay foolish“.
A moral de tudo isto é que você precisa se perguntar o quanto você é capaz de mudar algo onde está trabalhando. Será que a cultura de aprendizado existe mesmo ou você só pode e deve fazer o que está na descrição do seu cargo? E de quem é a responsabilidade sobre isto? #pense
Henry Mintzberg disse “You cannot create a manager or leader in a classroom“. O contexto vem de uma discussão sobre o mercado precisar de gerentes e não de MBAs. Que os cursos são muito bons para ensinar as práticas que gerentes vão precisar no mercado, pensando em “o que” aplicar… mas isto é diferente das situações de como aplicar, que se ganha com a prática do dia a dia.
Mintzberg também trabalha a questão que todos deveriam conhecer gerenciamento, para então buscar um cargo onde a necessidade de gestão seja um requisito.
O ponto é que a prática é o que nos leva a experiência e a realmente conhecer algum assunto.
Não é a teoria. É a prática. É a experimentação. É o trabalho em campo.
Então, da próxima vez que você entrar em uma sala de aula, lembre-se disto: um treinamento, o trabalho em sala de aula, serve para consciência e reflexão!
Para ganhar experiência, seja em projetos, em técnicas de apresentação e escrita, você precisa enfrentar situações no seu dia a dia. Existem formas de criar estas situações de realidade, exemplo:
O simples fato de participar de ações como estas, vão resultar em experiência. Prática. Esta prática vai ajudar a criar cultura. A criar um ambiente, de puro aprendizado, mas lembre, prático!
No dia 26 de junho de 2010, o Rafael Helm publicou aqui mesmo no Pingos de Agilidade o que era para mim Agilidade. O Rafael pediu para eu mandar em uma frase.
E eu mandei: Atitude, foco em entrega de software, trabalho em equipe e melhoria contínua.
Só que como todo desenvolvedor Clean Code, tudo pode ser refatorado. 🙂
E nesta declaração, se eu for simplificar em algo, como já vi o @KlausWuestefeld fazer com os valores do eXtreme Programming, chegando no Learning and Coolness, entendo que atitude e foco em entrega fazem o resto acontecer.
Vejamos:
Trabalho em equipe não é opcional. Você nunca vai ser melhor do que uma equipe em sinergia. Não quer uma equipe? Pense em um par, pense nos benefícios de ter conhecimento navegando e se tornando algo consciente e consistente entre as pessoas que fazem parte da equipe.
Melhoria contínua também não é opcional. Se sua equipe não melhora, ela sempre vai piorar. Simplesmente não se consegue “manter” a qualidade porque conforme o aumento da base de código, prazos, decisões mal feitas no projeto, novos problemas relacionados a modularidade e outros aspectos no desenvolvimento de software vão ficar mais visíveis. Então melhorar continuamente é algo que se faz sempre.
É a continuidade do processo de questionar aquilo que está sendo feito e buscar sempre melhorar, faz parte da atitude.
E é o que sobra e ao mesmo tempo faz a diferença. A atitude da equipe perante os obstáculos e como ela encara as situações de planejar novas funcionalidades para um produto, como ela encara o feedback ao cliente depois de um problema na operação do produto. Ou ainda como cada pessoa que faz parte da equipe vê a resolução de um defeito.
Se eu foco na entrega de software, quero garantir que o trabalho será o melhor possível, pois ninguém quer ter que trabalhar a noite ou final de semana ajustando algum problema de produção, causado na liberação de versão.
Então focar em entrega exige busca por qualidade, exige melhoria contínua. Só que sem atitude e foco em entregar aquilo que o cliente precisa, pensando em simplicidade, nada ocorre.
Exige aprender novos truques, em buscar novos conceitos como DevOps e Continuous Delivery.
Pingos de Agilidade 