Como eu escrevo meu 'notebook WTF' (2021)
(simplermachines.com)- Logo após entrar em uma nova equipe, em vez de apontar imediatamente as coisas estranhas que aparecem, reunir tudo em um notebook WTF ajuda a ganhar contexto para construir confiança como alguém que ajuda o time, e não como alguém que só reclama
- O que vale registrar são sinais de atrito no funcionamento da equipe e no fluxo técnico, como retrospectivas que terminam sem ação, impossibilidade de testar localmente, painel de builds sempre vermelho e dependência de uma única pessoa para certas tarefas
- Com o tempo, a lista vai sendo filtrada entre itens que têm um motivo válido, correções já em andamento, baixa prioridade para o time e itens fáceis de corrigir
- Os problemas que continuam após algumas semanas devem virar conversa com colegas, líder técnico ou gerente para entender causa e histórico, e então resolver junto começando pelos incômodos antigos, mas relativamente simples
- Em vez de explodir um problema na hora, acumular contexto e prioridade permite que até uma pessoa nova no time construa uma reputação de resolvedora de problemas sem perder a confiança
Como usar um notebook WTF
- A reputação que se quer construir no time é a de “pessoa que me ajuda a resolver meus problemas” e “pessoa que conclui o que eu considero importante”
- Sempre que entra em uma nova equipe, a autora abre uma nova página no bullet journal com
WTF - [Team Name]e registra toda vez que encontra algo que parece estranho - Quando surge algo que ela quer mudar, também registra como um trabalho separado
- Nas duas primeiras semanas, o foco fica apenas em registrar
- Não sai dizendo imediatamente tudo o que acha que o time está fazendo errado
- Não despeja na retrospectiva uma lista de coisas que precisam mudar
- Observa, escuta e anota o que parecer profundamente estranho
- Essa abordagem é uma técnica para gerar mudança no time e, ao mesmo tempo, se gerir bem sem parecer alguém que só reclama
Sinais estranhos captados em uma nova equipe
- Sempre há coisas em um novo time que fazem pensar “wtf”
- Alguns exemplos típicos:
- O time passa uma hora falando de problemas sérios na retrospectiva, mas termina sem itens de ação
- Os testes não rodam localmente e ninguém parece se importar
- Uma parte grande do painel de builds está sempre vermelha
- Só uma pessoa consegue lidar com um trabalho importante e sensível ao tempo
- O time gasta muito tempo em certa funcionalidade, mas ninguém sabe bem por que ela é importante ou como ajuda os clientes
Itens que saem da lista
- Quando a lista cresce o suficiente, começa a hora de apagar os itens um a um
- Normalmente, eles saem por quatro motivos:
- Existe de fato um bom motivo
- O time já está trabalhando na correção
- O time não considera aquilo importante
- É algo realmente fácil de corrigir
- Mesmo o problema de não conseguir rodar testes localmente pode não ser tão grave, dependendo do contexto
- Pode já ser um problema conhecido, com esforço de resolução em andamento
- O time pode fazer todo o trabalho em máquinas virtuais, provisionadas facilmente por um comando no chat
- Pode haver um sistema de integração contínua bem estruturado e o hábito de fazer deploys frequentes de pequenas mudanças, de modo que a falta de testes locais não impeça várias entregas por dia
- Em alguns itens, aparece uma solução simples
- Dá para escrever a documentação se você souber onde ela fica
- Pode ser uma mudança fácil se você encontrar o script certo
- Se a solução fácil estiver visível, vale corrigir na hora
Lidar com os problemas restantes junto com o time
- Se, depois de algumas semanas, ainda restarem problemas estranhos e não resolvidos, é hora de começar conversas com colegas, líder técnico e gerente
- O foco das perguntas é entender por que aqueles itens estão daquele jeito e como chegaram àquele ponto
- O objetivo é construir confiança como alguém genuinamente curioso e empático, paciente e respeitoso com a experiência dos colegas
- Em geral, os problemas continuam existindo por alguns motivos recorrentes:
- O time não percebeu
- O time se acostumou
- O problema é relativamente novo, e o que havia antes era muito pior
- Ninguém sabe como corrigir
- Já tentaram corrigir antes e falharam
- Os primeiros tipos muitas vezes podem ser resolvidos só com perguntas
- A outra pessoa corrige na hora ou encontra uma forma de resolver junto
- Se for um problema técnico, dá para escrever uma story ou ticket em conjunto e trabalhar nisso
- Se for um problema de processo ou social, dá para discutir com o time inteiro na retrospectiva
- Nessa fase, é bom encontrar um ou dois problemas que já incomodam um colega há algum tempo e que tenham solução relativamente simples
- Ao levar para o quadro da retrospectiva, escolha algo que não incomode só você
- Durante a conversa com o time, transforme o que esse colega sugeriu em um item de ação que possa ser testado imediatamente
- O time começa a sentir que a pessoa nova está ajudando a resolver os problemas deles
Problemas mais difíceis e conversa com a gerência
- Com o tempo, surgem os problemas espinhosos que o time conhece, mas tem medo de enfrentar
- Podem ser coisas vistas como “não é tão ruim assim”, mas sobre as quais ninguém quer falar
- Pode faltar a capacidade técnica necessária
- O centro da questão pode ser um problema humano complexo
- Nesse estágio, vale conversar com o gerente levando a lista construída até ali
- O que foi observado ao longo de algumas semanas
- O fato de que alguns pontos estão avançando, mas outros parecem exigir mais tempo
- Se há algo importante que esteja passando despercebido
- Em quais áreas o gerente gostaria que o foco fosse colocado
- O gerente também pode estar preocupado com os mesmos problemas, mas sem conseguir pressionar muito porque o time não parece tão incomodado
- A partir daí, dá para organizar junto as preocupações do gerente e os problemas identificados, além de discutir o que funcionou ou não no passado
- O gerente começa a enxergar essa pessoa como alguém de bom julgamento, capaz de ajudar a resolver questões mais difíceis
Por que não apontar tudo imediatamente
- A reputação desejada é: “Nat me ajuda a resolver meus problemas” e “Nat conclui o que eu considero importante”
- Essa reputação pode trazer os resultados desejados na avaliação de desempenho do ano seguinte e até render recomendações alguns anos depois
- Antes, a autora apontava os problemas assim que os via
- O resultado foi ganhar a fama de “vive reclamando” e de “acha que nunca fazemos nada direito”
- As pessoas paravam de ouvir, isso gerava frustração pessoal e também era ineficiente profissionalmente
- Quando alguém novo no time faz muito barulho por algo que pode não ser um problema real, que o time talvez não veja como problema, que já esteja sendo resolvido ou que tenha uma solução simples não percebida de início, a confiança desaba rapidamente
- Sempre existem muitos problemas que podem ser melhorados em uma equipe, mas só alguns são realmente solucionáveis
- A ordem em que os problemas são percebidos raramente é a ordem mais eficaz para resolvê-los
- O notebook WTF serve para guardar por um tempo o impulso de “quero consertar isso agora” até que exista contexto suficiente para decidir por onde começar
1 comentários
Opiniões no Hacker News
Acho que o texto não enfatiza o suficiente uma coisa: o olhar de uma pessoa nova só acontece uma vez
O motivo de avaliarmos mal a usabilidade de um produto é que já sabemos como usá-lo e ficamos insensíveis a erros e falhas
Uma pessoa recém-chegada à equipe ainda não está nesse estado, então observar o que ela pergunta, onde trava e onde realmente precisa de ajuda pode dar muitos insights à equipe
Sentamos com um caderno, anotamos e conversamos enquanto a pessoa usa o produto
Por mais terabytes de dados de telemetria que você colete, nada permite entender como o produto é usado tão bem quanto conversar com usuários reais
O setor de tecnologia precisa superar um pouco esse medo de outros seres humanos
É parecido com um professor experiente esquecer que certo conteúdo é difícil de explicar a quem está aprendendo pela primeira vez
Mas nem todo mundo é igualmente ruim nisso; pesa muito ter empatia e interesse suficientes para se colocar no lugar de um iniciante
Duas pessoas que usaram o shell Bash inúmeras vezes podem ter entendimentos completamente diferentes sobre o que é estranho e pouco intuitivo para um novato
Ver com olhos novos também é uma habilidade, e pode melhorar com treino, assim como aprender a desenhar observando luz e objetos reais
Ao anotar em vez de expressar imediatamente, você ganha tempo para aprender por que as coisas são daquele jeito e para conhecer o terreno da organização
Depois que coisas como contas, permissões e aprovações estiverem resolvidas, dá para agir com base nessa lista
Assim, aumenta a chance de a equipe enxergar você como alguém que quer ajudar, não como “a pessoa que vive aparecendo e gritando WTF”
Funcionava muito bem em uma empresa de 12 a 15 pessoas, mas não sei se escalaria bem em um porte maior
Anotar e esperar é algo imediato, de baixa carga, e ainda traz uma pequena recompensa de “a lista cresceu”, então, com prática sistemática, pode ser fácil reaprender
Gosto de como o processo mantém separadas a etapa de perceber e registrar e, depois, a etapa de mapear, observar, aprender e reunir pessoas com a mesma percepção do problema para liderá-las
Manter um diário de trabalho é sempre uma boa ideia, mas há algo no tom deste texto que me incomoda
Eu não gostaria de trabalhar com alguém que age como Borg ou segue um roteiro que parece tirado de 『How to Win Friends and Influence People』
Se alguém parece estar tentando me manipular, fica difícil confiar nessa pessoa, pelo menos a partir do momento em que percebo isso
Ainda assim, é melhor não se deixar levar apenas por essa rejeição imediata
Eu também tenho objetivos sobre como quero que stakeholders se sintam em relação a mim, e isso foi bastante útil como critério de comportamento
Mesmo fazendo um bom trabalho tecnicamente, ignorar a dimensão das relações humanas causava problemas; quais rumores circulam, como sou percebido e como meu trabalho é apresentado realmente importavam
Só dizer “basta fazer um bom trabalho” não elimina o fato de que meu trabalho e a impressão que causo nos outros importam
Nunca li 『How to Win Friends and Influence People』, mas achei o texto em si muito bem escrito
Seja um contribuidor individual experiente, um novo gerente ou um oficial, os primeiros 30 a 90 dias costumam ser parecidos: não mude nada e tente entender como as coisas funcionam e, mais importante, por que funcionam daquele jeito
Há muitos benefícios organizacionais nisso e, resumindo, é assim que isso realmente se faz
Engenheiros já trabalharam sob maus gestores e muitas vezes têm uma noção disso, mesmo que não consigam explicar exatamente por quê
Essa sensação de “mau gestor” frequentemente vem da incapacidade de exercer uma boa liderança tática e, assim como engenharia, liderança também é uma habilidade que pode ser aprendida
O problema é que não há muitos lugares que ensinem isso de forma deliberada, como no Exército ou em treinamentos para executivos seniores
Se você quer trabalhar para um bom gerente, na verdade quer trabalhar para um bom líder, e liderança é uma habilidade tática, como escrever código C++ eficiente
Como se trata de coordenar e conduzir pessoas para alcançarem objetivos maiores do que a soma do que cada membro da equipe conseguiria separadamente, de certos ângulos isso pode parecer manipulação
Ainda assim, a liderança de que engenheiros costumam gostar é de alguém que protege a equipe de bobagens externas, garante os recursos necessários, elogia em público e critica em particular, dá direção sem microgerenciar demais, reconhece e recompensa resultados e não deixa baixo desempenho passar sem ação
Por outro lado, quando um jogador político carismático com MBA e sem conhecimento técnico usa essas técnicas por motivos ruins, vira alguém com quem ninguém quer trabalhar
Pessoas que sobem de cargos técnicos para gerência, mas não aceitam que gestão é diferente de competência técnica, também costumam ser detestadas
No fim, para que haja mais líderes competentes em todo o setor, precisamos tratar liderança, como este tipo de texto faz, não como um instinto inato nebuloso, mas como um conjunto de táticas explicáveis sobre como agir
Ganhar a reputação de que “Nat resolve meus problemas” pode ser bom para recomendações, mas pode ser perigoso para a carreira
Fiz isso por 20 anos em vários departamentos, e toda vez tentavam me manter preso como solucionador de problemas, não me colocar como candidato a promoção
Um colega que trabalhou 40 anos e se aposentou também era alguém que resolvia qualquer problema, e era muito mais competente do que os gerentes, mas nunca foi promovido
Era o trunfo de todo mundo, mas quase nunca recebeu reconhecimento; resolver problemas era visto como algo “óbvio”, e não havia recompensa
Para outras pessoas no mesmo nível, aplicavam-se padrões muito mais baixos, e até na última avaliação de desempenho o gerente disse que “avaliava pelo desempenho em relação às metas, não em comparação com colegas”
Eu também ouvi a mesma coisa de outro gerente, então não foi coincidência
Acima de tudo, meu gerente sempre ficava do meu lado ao barrar pedidos que não vinham dele
Se alguém desconhecido pedia algo que não era trivial e eu não tinha tempo ou interesse, bastava dizer: “Não tenho tempo para olhar isso agora. Se precisar de prioridade, fale com meu gerente”, e em 99 de 100 vezes a coisa nem chegava ao gerente
A maior vantagem de se tornar a pessoa a quem todos recorrem no departamento ou na empresa inteira é acumular conhecidos e uma rede de contatos
Quando você precisa de informações fora da equipe ou precisa atravessar a burocracia para algo importante, isso funciona como um pequeno superpoder
Você também ganha uma rede para acionar ao procurar novas oportunidades; em 15 anos no setor privado, todos os empregos que consegui vieram por conexões desse tipo
Mas dá para dizer que uma das duas abordagens passa bem pelo processo de promoção, e a outra não
Não é fácil, mas estabelecer limites é uma habilidade importante
A parte “quando eu apontava os problemas assim que os via, ganhei a reputação de que Nat está sempre reclamando e acha que tudo que fazemos está errado” deveria estar perto do topo do texto
Esse nível de autoconsciência é uma habilidade real que vale a pena desenvolver
O ex-astronauta Chris Hadfield também diz em seu livro que usava uma abordagem parecida ao entrar em uma nova missão e em uma nova equipe
Primeiro entrar em modo de observação, aprender se os momentos WTF realmente fazem sentido, e fazer isso de um jeito que não irrite os novos colegas de equipe
Vale a leitura
Depois de trabalhar muito tempo no mesmo cargo, criar um lugar para despejar o ruído ajuda ao menos a não deixá-lo preso na cabeça
Não é só uma questão de julgar se o problema é válido; está mais perto também de aprender a deixar algumas coisas para lá
Seria bom se alguém pudesse dizer qual livro é
Ao entrar em uma situação já existente, em geral adotei uma abordagem assim
Na primeira semana, reviso tudo enquanto anoto perguntas e observações
Registro não só os momentos “WTF”, mas também o que funciona bem e o que me parece uma ideia realmente boa
Só depois disso reviso, priorizo e entro na discussão
Isso parece um princípio que combina bem com a cerca de Chesterton
É a história de dizer a alguém que quer remover uma cerca: “Se você não sabe para que ela serve, não posso deixar que a remova. Vá pensar, e quando puder dizer que entendeu a utilidade dela, então poderá derrubá-la”
Em termos mais claros, significa que, mesmo quando algo parece estranho, é melhor presumir que as pessoas que vieram antes eram inteligentes e tinham um motivo para aquilo
Esse motivo pode ter ficado obsoleto, mas, se você não o levar em conta, acabará repetindo o mesmo erro
Além de manter uma lista do que você quer corrigir, é uma boa ideia porque, se deixar passar algum tempo, você consegue entender por que certas coisas são do jeito que são
Muitas vezes terão sido feitas às pressas ou por erro, mas às vezes existe de fato uma complexidade oculta que é difícil entender de imediato olhando apenas uma linha de código
O primeiro é uma falha evidente, e o segundo geralmente se esclarece quando você mergulha o suficiente naquele ambiente
Ainda assim, é útil anotar os dois
Justo nesta semana eu estava dizendo a dois colegas que mantenho no meu computador um arquivo “How the F”
Não é exatamente igual ao que a autora descreve, mas é muito parecido; quando entro em uma nova equipe, anoto tudo que me faz pensar “como é mesmo que se faz isso?” sempre que surge um problema
Não levo isso ao gerente como no texto original, mas isso me dá uma perspectiva sobre quais são os pontos de atrito da equipe e da empresa, e sobre como resolvê-los ao longo do tempo
Vivo colocando em uma lista todas as ideias que me ocorrem
Não há uma ordem especial; vou acrescentando em papel ou em um arquivo de texto
Ideias não costumam aparecer bem na hora em que são necessárias; elas surgem o dia inteiro enquanto faço outras coisas, e, se eu não anotar, pelo menos eu não consigo lembrar
Quando chega a hora de fazer algo, basta ir riscando uma por uma, então não preciso ficar pensando no que fazer em seguida; como as ideias não acabam, isso permite uma explosão de produtividade bem grande
Parece uma conversa sobre organizar uma lista pessoal de tarefas, enquanto o texto original trata de como se adaptar e se comunicar dentro de uma equipe
A vida é curta demais para organizar notas; acho melhor simplesmente anotar tudo e depender da ordenação inversa e da busca
Ironicamente, sei que tenho um tesouro de ideias incríveis, mas, com a idade, já não me importo em executá-las como me importava na casa dos 20 anos