Pedidos pequenos e imprecisos desperdiçam muito tempo da equipe
(staysaasy.com)- Pedidos ambíguos de gestores e líderes podem parecer perguntas pequenas, mas podem abalar muito o tempo, as prioridades e a direção de execução da equipe
- Expressões como “dê uma olhada nisso” ou “precisa ser moderno” podem facilmente levar a respostas exageradas, como relatórios, slides, trabalho no fim de semana ou grandes upgrades
- Quem faz o pedido deve dizer também o investimento de tempo esperado, o impacto nas prioridades, se é para verificar materiais existentes ou criar algo novo, e onde o resultado será usado
- Quem recebe o pedido também deve perguntar qual é o nível de esforço esperado e esclarecer o que não sabe; não deve presumir que o líder está ocupado demais para responder
- Ser específico logo no início, mesmo que pareça um pouco constrangedor, pode reduzir muito a confusão, o trabalho errado e o desperdício de custos que surgiriam depois
Como um pedido pequeno vira um trabalho grande
- Dentro das organizações, pedidos curtos e aparentemente leves repetidamente se transformam em trabalhos muito maiores do que o esperado
- Há casos em que um gestor pergunta “Você pode fazer X?”, o subordinado direto gasta 10 vezes mais tempo do que o previsto, e o gestor reage dizendo “eu não queria que você gastasse tanto tempo assim”
- Uma frase breve de um executivo em uma reunião, como “você pode verificar isso?”, pode levar 24 pessoas a criarem 4 versões de um deck de slides e a trabalharem até o fim de semana
- Na reunião em si, o executivo pode olhar apenas o resumo da primeira frase do primeiro slide e dizer “não é necessário apresentar tudo”
- A frase “precisa ser moderno, sem desculpas” também pode ser interpretada como um grande upgrade tecnológico se o significado não for confirmado
- A intenção real pode ser apenas atualizar, ao longo de alguns anos, a sintaxe das APIs em novas versões
- Enquanto isso, o lançamento de projetos importantes pode ser adiado
O que quem faz o pedido deve definir primeiro
- Líderes devem dizer diretamente, ao fazer um pedido, qual é o limite de tempo esperado
- Ex.: “Não gaste mais de 20 minutos; depois de 20 minutos, traga apenas o que tiver”
- Também devem explicar que impacto isso deve ter nas prioridades
- Ex.: “Espero que leve cerca de 2 semanas, e isso não deve reduzir muito a prioridade de outros trabalhos importantes”
- Devem dizer para a pessoa entrar em contato imediatamente se o cronograma real for diferente ou se houver conflito com outras tarefas
- É preciso distinguir se basta verificar materiais existentes ou se é necessário analisar ou criar algo novo
- Ex.: “Diga apenas se já temos algo sobre esse tema. Se você ainda nunca pensou nisso, saber apenas isso já é suficiente”
- Informar onde o resultado será usado facilita para a outra pessoa ajustar o nível de esforço
- Ex.: uma resposta a enviar para um prospect de vendas, preparação para o Q&A do próximo All Hands, temas centrais da próxima reunião do conselho etc.
O que quem recebe o pedido deve confirmar
- Quem recebe o pedido deve fazer perguntas de esclarecimento
- Deve confirmar o nível de esforço, por exemplo: “Você espera um resultado muito detalhado que exigirá várias horas, ou um resumo curto?”
- Fazer perguntas não faz você parecer tolo; mais arriscado é não perguntar e acabar fazendo algo completamente errado
- Em vez de gastar tempo interpretando o e-mail ou a mensagem do líder como um artefato antigo, é melhor confirmar diretamente com o líder que fez o pedido
- Se o líder teve tempo para fazer o pedido, também tem tempo para esclarecê-lo
1 comentários
Comentários do Hacker News
O que mais detesto é quando um líder não técnico pula uma ou duas etapas e fala diretamente com profissionais técnicos juniores, em vez de falar com profissionais técnicos seniores que têm experiência para fazer perguntas de esclarecimento ou definir cronograma e entregáveis.
É um padrão que vi com frequência em várias organizações de campanha e organizações de tecnologia política.
Profissionais técnicos juniores também entendem a cadeia de comando, então, quando alguém de cima a quebra, intencionalmente ou não, isso gera confusão e bagunça.
Muitas vezes quem faz o trabalho físico de fato é o engenheiro júnior, e ele pode responder melhor a certas perguntas do que alguém com uma visão de nível mais alto.
Parece desnecessário ficar brincando de telefone sem fio.
Quando um coordenador de projeto de um fornecedor inexperiente, técnicos do fornecedor acostumados a ter o coordenador resolvendo as coisas e um cliente novo nesse meio se encontram, pode surgir uma confusão considerável.
Sobre as frases “se você não fizer perguntas e acabar fazendo algo completamente errado, com certeza vai parecer burro” e “nunca presuma que a outra pessoa estará ocupada demais para responder a perguntas de esclarecimento durante o trabalho”, fico me perguntando qual é a melhor abordagem quando se trabalha remotamente e nem há chat online.
Presencialmente, é fácil fazer muitas perguntas pequenas, rápidas e meio rascunhadas; por e-mail, parece mais formal e intrusivo, então dá mais trabalho explicar o que está confuso e até antecipar possíveis respostas.
Chamadas de vídeo levam tempo para marcar e têm um custo adicional alto.
Em projetos para clientes, sempre que surge uma pergunta pequena, acrescento-a a um Google Doc e, de tempos em tempos, aviso o cliente para verificar o documento, ou faço com que ele assine as notificações de edição.
O cliente escreve as respostas diretamente no documento, e o processo se repete conforme o trabalho avança.
As vantagens são que o cliente não precisa responder tudo de uma vez, há menos notificações, os dois lados podem escrever de forma menos formal sem problema, passa uma sensação de colaboração, é fácil anexar perguntas de acompanhamento ao lado das partes relevantes, comentários no documento permitem discussões curtas ou atribuir e acompanhar pequenas tarefas, e também fica mais fácil para outras pessoas lerem e contribuírem.
Aqui estou pensando em situações com muitas perguntas pequenas, como trabalho contratado com clientes não técnicos que você não conhece bem.
Outras pessoas não impõem esse tipo de restrição ao e-mail.
Se não for para o CEO, você pode escrever a pergunta conforme ela vem à cabeça e enviar logo.
Também não precisa ter medo de mandar um segundo e-mail em seguida, do tipo “Ah, esqueci desta pergunta também. Obrigado! $QUESTION”.
Ao ver os e-mails de altos executivos em https://twitter.com/TechEmails, a maioria é bastante informal.
Alguns e-mails antigos trocados entre Bill Gates e executivos da Microsoft não são muito mais organizados do que mensagens de texto de adolescentes.
Não estou dizendo para colocar emoji em mensagens para o chefe do chefe do chefe do seu chefe, mas um e-mail rápido e informal não vai acabar com a sua carreira.
Entendo que para muita gente pareça maior, mas não sei se, na prática, é mais incômodo para ambos os lados.
Se esclarecer a pergunta exige uma conversa de ida e volta, faça isso.
A abordagem do documento compartilhado também é uma boa ideia, e tem mais duas vantagens.
O ato de escrever vira uma etapa adicional para deixar a pergunta mais clara, e perguntas e respostas ficam documentadas para depois.
Ambas são grandes vantagens em relação a uma conversa rápida que você precisaria registrar de novo mais tarde.
É só repassar a carga cognitiva para a outra pessoa.
Porque é melhor interromper uma vez do que várias vezes ao dia.
Quando recebo uma nova issue, primeiro dou uma olhada geral, planejo o que vou fazer, investigo mentalmente possíveis problemas ou conflitos e às vezes monto uma lista enorme de perguntas; depois separo quem provavelmente pode responder a cada uma e só então inicio a conversa online.
Dentro de uma empresa, normalmente basta pedir uma chamada de vídeo rápida de 5 minutos por um mensageiro interno como o Slack.
Se for um colega próximo, às vezes ligo direto sem avisar.
Com clientes externos, se isso tiver sido combinado com antecedência, dá para fazer algo semelhante por telefone real ou chamada de vídeo.
Por exemplo, na reunião de kickoff, dá para definir a frequência de contato que o cliente deseja e quais perguntas exigem comunicação imediata versus quais bastam em uma comunicação assíncrona mais lenta.
O tempo é um indicador muito ruim para representar esforço, substância e escopo
Por exemplo, ao ver um pedido como “dê uma olhada por só 20 minutos e traga o que tiver depois de 20 minutos”, a quantidade que cada pessoa consegue realizar em 20 minutos varia um pouco
Mesmo ignorando essa diferença, não há garantia de que o gerente que fez o pedido obterá aquilo de que precisa a partir desses 20 minutos de esforço
Em ambientes ágeis, é comum ver trabalhos de descoberta e investigação serem chamados de “spikes” e receberem um “timebox”; mas, quando se pergunta “o que acontece se você não descobrir o que quer dentro desse tempo?”, geralmente não há uma boa resposta
Na prática, o timebox é estendido até se descobrir o que é necessário
Por isso, o tempo é uma proxy ruim para esforço, substância ou escopo
Acho melhor o exemplo mais adiante no texto: “você espera algo muito minucioso que leve várias horas, ou basta um resumo rápido?”
Isso porque ele fala do escopo do trabalho, não do tempo que levará
Se medir por tempo, não há garantia de obter o que se quer dentro daquele período e, no fim, mais tempo acaba sendo acrescentado
A resposta para “e se você não descobrir o que quer dentro desse tempo?” é que se descobre que não foi possível encontrar a resposta dentro do tempo esperado, e então se ajustam as expectativas sobre o esforço necessário para essa investigação
Para um gerente, essa é justamente uma das informações centrais que ele quer saber
Por isso, para evitar que um projeto saia dos trilhos e vá parar no lixo, qualquer coisa precisa de um timebox
Isso também se aplica a trabalhos individuais ou feitos sozinho
Como é possível ficar preso a qualquer coisa para sempre, é muito melhor criar à força um ponto de parada, receber feedback ou lançar algo, e então decidir se vale a pena continuar
O mecanismo que funciona aqui é forçar as pessoas a priorizarem
Se você for muito bom em julgar prioridades, talvez precise menos de timeboxes, mas, mesmo nesse caso, sem um timebox pode ser difícil resistir à tentação de continuar trabalhando até um nível de qualidade maior do que o necessário
Esse padrão de trabalho é útil quando há muito mais coisas desconhecidas do que conhecidas
O objetivo é aumentar pouco a pouco a proporção do que se “sabe”, até que seja possível fazer um palpite informado, não um chute no escuro
Por exemplo, se há um bug em uma base de código legada, mas o sistema substituto está quase pronto e será lançado daqui a dois meses, como lidar com esse bug?
Você poderia ignorá-lo, ou pedir a alguém “corrija de qualquer jeito”, mas nenhuma das duas opções é boa
Então se diz: “investigue esse bug, mas não passe de uma hora, e me diga até onde chegou”
Depois disso, você passa a entender melhor o formato do problema
Se a pessoa volta dizendo “encontrei a área do problema, mas só consigo corrigir junto com alguém que conheça bem a lógica de negócio”, basta alocar os recursos adequados e seguir para a correção
Se diz “é esta parte do código, e ela está razoavelmente organizada, mas ainda não consegui rastrear tudo”, você pode conceder mais tempo com a confiança de que não será algo gigantesco
Por outro lado, se diz “está em algum lugar nesse espaguete bizarro; quando olhei para ele, o abismo olhou de volta para mim, senti um arrepio na espinha e os quadros na parede choraram lágrimas de sangue, então por favor não me mande de volta para lá”, fica claro que não vale a pena rastrear mais e você pode deixar isso de lado
Acredito que você tenha vivido a experiência de acrescentar mais tempo quando não conseguiu obter o que queria dentro do período, mas isso não é universal
O problema está em tratar o próprio “o que se quer” como objetivo final
Por isso o texto também diz: “diga por que isso é necessário”
“Nosso maior cliente precisa saber antes de renovar o contrato” merece mais dinheiro e mais horas da equipe do que “eu só estava curioso”
No nível de liderança, é preciso perceber que não dá para perseguir todos os benefícios e concentrar-se estrategicamente naquilo que tem a melhor relação custo-benefício
Isso não significa apenas colocar uma pessoa em uma tarefa, mas também atribuir o trabalho certo à pessoa com as habilidades adequadas
Um CEO de startup me pediu algo, e acho que o pedido tinha só uma ou duas frases
O resultado foi que produzi um relatório de 14 páginas, gastei várias horas nisso e fiz a maior parte no meu tempo pessoal
Enviei o relatório ao CEO, mas depois disso não houve nenhuma resposta, e nada aconteceu
Depois disso, criei uma nova regra para mim
O custo de uma solicitação deve ser proporcional ao custo de transmiti-la
Agora, quando recebo uma solicitação cara, eu espero, atraso e peço escalonamento
A pessoa que fez o pedido precisa fazer a diligência e obter aprovação de níveis superiores para mostrar que vale a pena pagar aquele custo
Se for uma solicitação sem sentido, nunca mais ouvirei falar dela; se for uma solicitação valiosa, eu a tratarei; e há o benefício adicional de que esse esforço não acontecerá às escondidas, sem a visibilidade adequada
Primeiro, nunca faço nada no primeiro pedido
Se for importante, a pessoa pedirá de novo, e aí eu penso no assunto
Segundo, se eu tiver que fazer hora extra, a outra pessoa também tem que fazer hora extra
Se ela não quer fazer hora extra, então não era tão importante assim
Passei por vários níveis na engenharia, de júnior a C-level, e aprendi algumas coisas.
Primeiro, todos precisam agir de boa-fé.
Já vi líderes pedirem algo por impulso a um subordinado direto sem pensar nem 5 segundos; e, no sentido oposto, também vi subordinados diretos só se moverem quando recebiam uma sintaxe exata, como uma “linha de comando humana”.
Nenhuma das duas coisas pode acontecer.
Segundo, para gerentes ou líderes, não existe “pedido pontual”.
Qualquer pedido passa a ter uma prioridade implícita acima de todo o resto.
É preciso agir dentro do sistema e do contexto como um todo; caso contrário, você está empurrando essa escolha para a equipe.
Terceiro, se você está do lado de quem recebe o pedido, deve ajudar quem pediu a entender o que realmente precisa.
É preciso eliminar pressupostos implícitos, e é exatamente aí que os dragões se escondem.
Comunique, informe, ensine e confirme o que a pessoa quer, garantindo que os dois lados estejam de acordo.
Esse tipo de situação surge por eficiência — para não desperdiçar tempo quando não é necessário —, mas, quando solicitante e destinatário tentam se ajudar, a vida em geral fica muito mais suportável.
Há uma diferença gritante entre um líder que força os limites para ver até onde pode ir e um líder que tenta construir uma relação de boa-fé com a equipe.
Um gerente que continua fazendo exigências impensadas vai perdendo, de forma constante, seus melhores funcionários.
Pela minha experiência, passado tempo suficiente, sob esse tipo de líder acabam ficando apenas juniores, porque as pessoas experientes evitam essa equipe.
O membro de equipe “linha de comando humana” também é um bom exemplo de alguém agindo de má-fé.
Já trabalhei com pessoas que exigiam que até o menor pedido começasse pelo preenchimento de um formulário ou documento criado por elas, e só pensavam numa tarefa pequena depois de dias de discussão, críticas ou circulação para revisão.
Elas acham que se protegeram de pequenos pedidos ao fazer com que ninguém mais queira se dar ao trabalho de formular a pergunta com exatidão, mas, com o tempo, ganham a reputação de serem pessoas difíceis de trabalhar.
Outra variação é a pessoa que explora a ambiguidade de todo pedido.
Mesmo sabendo, em linhas gerais, o que foi pedido, entrega algo que, “para dar uma lição”, corresponde literalmente ao pedido, mas que ela sabe que não era o que todos precisavam ou queriam.
Não por acaso, a maioria das pessoas que faziam esses joguinhos foi demitida no último ano.
As pessoas conseguem tolerar por um tempo um colega ruim que entrega alguma coisa, mas, na hora dos cortes, ele vai para o topo da lista de remoção.
Há um mês, percebi uma falha que eu mesmo cometia como líder.
Por fora, minha intenção era dar senso de propriedade à equipe, e eu despejava várias coisas que precisavam ser feitas; mas, na prática, estava jogando para a equipe o estresse de decidir “o que deve ser feito neste exato momento”.
É uma armadilha sutil em que é fácil pensar “estou delegando muita autonomia à equipe!”, quando, na realidade, você está estressando a equipe e reduzindo o foco dela.
Segundo o OED, a nominalização começou no inglês coloquial australiano.
https://www.oed.com/search/dictionary/?q=ask
Todos sabemos que a língua é um produto cognitivo biossocial em constante mudança e que não há regras de verdade, mas esse uso incomoda como mastigar areia, especialmente quando já existem bons sinônimos funcionando perfeitamente.
Eu não queria que essa informação determinasse a decisão.
Achava que deveríamos fazer o melhor para o negócio e para os usuários finais, não o que fosse mais fácil para mim.
Só que a outra pessoa escolheu a opção mais longa e difícil; depois, descobri que ela na verdade queria a outra, mas achou que aquela seria mais difícil para mim.
A mesma coisa acontece na vida real.
Quando fui fazer armários novos para a cozinha, dei à minha esposa duas opções para o trilho superior das portas; uma era mais difícil, mas não falei porque queria que ela escolhesse a que preferisse.
Naturalmente, ela escolheu a mais difícil; depois, descobri que ela achou que seria a mais fácil e, na verdade, preferia a outra.
Por isso, é preciso sempre dar todas as informações à outra pessoa.
Por que não podemos dizer que a pergunta feita pela diretoria não faz sentido?
A resposta, claro, é para não ir contra a hierarquia.
Mas essa conformidade hierárquica não ajuda o negócio de verdade.
Parece um valor que deveríamos conseguir descartar com mais facilidade.
A pergunta “você espera algo bem completo ou uma síntese rápida já serve?” é engraçada.
Se um engenheiro disser com honestidade a uma pessoa não técnica quanto tempo algo vai levar, a pessoa não técnica ficará chocada e dirá que não dá.
Um pedido como “não gaste mais de 20 minutos; depois de 20 minutos, traga o que tiver” soa absurdo.
Não existe trabalho que leve 20 minutos.
Seria melhor dizer: “não olhe para isso; vá tomar um café e depois volte com uma estimativa por alto”.
Fazemos trabalho complexo e precisamos de tempo para pensar.
Se você não quer que gastemos tempo pensando, então é melhor nem perguntar.
Parte do problema é que você não quer mandar seu chefe se danar, nem dizer que gastou 6 horas em algo que ele achava que levaria 20 minutos.
Então, em vez disso, todo o resto acaba atrasando.
É por isso que uma boa gestão de engenharia mantém os engenheiros o mais longe possível de pessoas que, mesmo sem querer, vão fisgar técnicos para suas demandas.
Um sinal típico de gestão fraca é pedir relatórios ou atribuir tarefas cujas implicações totais a própria pessoa não entende
Um sinal típico de engenharia fraca é responder “sim” a esse pedido
Quando um gestor fraco pede algo que foge do escopo do que pode ser tratado como trivial, quem executa deve fazer uma de três coisas, dependendo do contexto técnico e social
A) Perguntar: “Como isso deve ser feito?”
Funciona quando o gestor é técnico e joga a tarefa de forma vaga para compensar a própria incompetência técnica
Ao devolver a besteira do mesmo jeito, ele é forçado a encarar o escopo do que está pedindo e a realidade dos mecanismos envolvidos
B) Informar: “Esse trabalho exige X recursos. Quais são as expectativas?”
Aqui, X pode ser uma enorme quantidade de horas-pessoa, dinheiro, GP do RuneScape antigo, ou qualquer outra coisa
É adequado para gestores não técnicos e, de modo parecido com A, os força a encarar que isso é uma grande solicitação, não algo a ser aprovado no improviso, mas sim pelos procedimentos normais
C) Dizer “não”
Isso não é possível em toda organização nem em todo contexto social, mas organizações de alto desempenho tornam isso possível
Em ambientes de engenharia de alto desempenho, a organização de engenharia tem forte poder de veto contra trabalho absurdo e inútil, que só pode ser revertido pela alta liderança de nível C
Saber quando e como exercer esse veto também é uma habilidade importante que a engenharia precisa desenvolver
Então qualquer coisa que você dissesse sobre isso podia acabar te empurrando para a porta
Toda vez que vejo “ask” usado como substantivo, meu senso linguístico coça; fui procurar e encontrei este texto
https://english.stackexchange.com/questions/4246/can-or-shou...
Pode ajudar quem se incomoda de forma parecida
Um dos maiores desperdícios de tempo acontece quando falta contexto em uma solicitação
Parece uma tentativa de economizar tempo, informando só quem precisa saber, mas o “porquê” e o contexto são realmente importantes para chegar a uma boa solução
Sem isso, não dá para saber o que a outra pessoa já considerou
Por exemplo, se alguém diz “precisamos bloquear solicitações vindas do país X”, isso não é difícil com a maioria dos serviços de firewall
Mas por que isso precisa ser feito?
Se a ideia é dar uma garantia contratual de que não haverá tráfego vindo de determinado país, esse método não funciona, porque qualquer pessoa consegue contornar a detecção por código de país em 2 minutos usando uma VPN
O usuário quer fazer X, mas não sabe como; acha que Y vai funcionar e pede ajuda com Y; outras pessoas ficam confusas porque Y parece estranho
https://xyproblem.info/
Muita gente já morreu nessa colina, e mesmo assim isso foi implementado
É melhor não virar mais uma vítima
No fim, isso depende muito da cultura da empresa e de quão à vontade as pessoas se sentem para contestar líderes seniores
Esse ônus recai sobre os líderes seniores, que precisam fazer com que as pessoas abaixo deles se sintam confortáveis para discordar
Pela minha experiência, os melhores líderes são humildes e demonstram disposição para ouvir
Dito isso, às vezes fazer trabalho inútil também faz parte do emprego
Se for demais, claro, procure outro trabalho; mas é melhor não se tornar alguém que está sempre desconfiando da direção e questionando tudo