Não responda à primeira pergunta
(lalitm.com)- Em ferramentas de depuração de desempenho, diante de uma solicitação estranha, é melhor perguntar o contexto antes de responder de imediato; assim ficam mais claros tanto o problema real do usuário quanto as lacunas da ferramenta
- Isso vai além de simplesmente lidar com o problema XY: usa a própria confusão que gerou a pergunta errada como ponto de partida para ampliar o entendimento, tanto do usuário quanto do produto
- No Perfetto, usar traces para calcular todas as métricas pode ser possível, mas é ineficiente; um sistema dedicado de coleta de métricas pode ser mais adequado
- Quando a resposta aparente e a necessidade real diferem, como em pedidos para dividir traces, uma função já existente como periodic trace snapshots pode ser um caminho melhor
- Mudanças no produto tendem a ser mais bem decididas depois que uma necessidade recorrente aparece com clareza; adicionar recursos às pressas pode levar a uma grande dívida técnica
Por que não responder imediatamente à primeira pergunta
- Em ferramentas de depuração de desempenho como o Perfetto, quando um usuário faz uma pergunta que parece estranha, como “Como dividir um Perfetto trace em vários arquivos?”, é melhor perguntar primeiro “Por que você está coletando um trace tão grande?” em vez de sair mostrando o procedimento
- Essa abordagem vai um passo além de simplesmente resolver o problema XY
- Em vez de apenas reinterpretar a pergunta do usuário como a “intenção real”, responder e encerrar o assunto, ela usa a própria confusão que gerou a pergunta errada como ponto de partida da conversa
- O usuário passa a ter um modelo mental melhor da ferramenta, e quem a construiu consegue enxergar com mais clareza onde o produto está causando confusão
- Às vezes a conversa termina na conclusão de que o próprio produto precisa mudar
- É uma forma de trabalhar especialmente aplicável, de maneira bem direta, para quem cria ferramentas para engenheiros
- Em produtos de consumo ou serviços B2B, a aplicação pode ser menos direta, mas a abordagem básica ainda pode ser útil
Como diagnosticar uma solicitação
- Nem toda pergunta exige uma conversa profunda
- Perguntas simples e repetitivas que podem ser respondidas apontando para a documentação não entram nessa discussão
- Os casos interessantes são aqueles em que o primeiro pedido não traz contexto suficiente e a própria pergunta parece fora do padrão
- Em perguntas estranhas, o objetivo é identificar onde está o descompasso, com base nos seguintes critérios
- Ver se é uma pergunta já vista antes; se não for, tratá-la como um pedido raro e desacelerar
- Comparar com outras perguntas para avaliar se faz sentido; se não fizer, procurar se há por baixo uma pergunta mais geral
- Confirmar se a solicitação combina com a estrutura da ferramenta ou se o usuário, sem perceber, está lutando contra a arquitetura
- Depois de encontrar o ponto de desvio, faz-se perguntas para revelar o contexto que está faltando
- A resposta imediata para X pode existir, mas, por Y, o pedido parece bastante incomum, então vale pedir que o usuário explique o problema mais amplo
- A partir daí, o ritmo da conversa depende de quão bem o usuário consegue transmitir o que está pensando
- Em geral, a conversa leva a uma de três conclusões
- O usuário deixou passar a filosofia da ferramenta
- O caminho certo existe no produto, mas está pouco visível
- O próprio produto precisa mudar
Quando a filosofia da ferramenta passou despercebida
- É comum que o usuário procure uma ferramenta sem saber exatamente o que quer ou qual problema está tentando resolver
- Isso não é uma crítica ao usuário
- Equipes tentam resolver problemas com tempo e recursos limitados e, quando não avançam, passam a buscar uma nova ferramenta de depuração
- Mesmo que a ferramenta ofereça boa parte da funcionalidade desejada, se isso não bater com o modelo mental do usuário sobre “como isso deveria funcionar”, o resultado costuma ser um pedido de funcionalidade
- Um exemplo frequente no Perfetto é tratar o trace como uma solução universal para calcular qualquer métrica
- Um Perfetto trace registra, com grande detalhamento, o que o dispositivo fez durante um determinado intervalo de tempo
- Como é possível calcular métricas a partir do trace, o usuário tenta extrair dali também valores como frame rate e uso de memória do app
- Em princípio, qualquer métrica pode ser calculada a partir de um trace
- Mas calcular todas as métricas a partir de trace é ineficiente
- A coleta e o processamento de trace têm custo alto
- Mesmo quando só se precisa de um número isolado, acaba-se coletando dados do sistema inteiro
- Um sistema dedicado de coleta de métricas pode fazer a mesma coisa com muito mais eficiência
- Ferramentas têm uma filosofia de projeto, e o usuário pode facilmente deixar isso passar ao focar apenas no problema imediato
- Não basta ensinar só a usar o Perfetto; também é importante ensinar como abordar engenharia de desempenho
- É preciso mostrar como pensar e trabalhar com temas como tempo de inicialização, queda de frames, memória e energia
- O objetivo é fazer o usuário entender que ferramentas usar e como usá-las tanto em situações normais quanto quando há problemas
Quando o caminho certo está escondido
- Às vezes o usuário entende o problema em si, mas não sabe como combinar as ferramentas existentes
- A ferramenta foi deliberadamente construída para ser poderosa, e não dá para assumir que outras equipes compreendam todo o seu alcance funcional
- Quando se descobre o que a pessoa realmente quer, muitas vezes uma função criada para outro propósito já atende à necessidade
- O pedido de dividir traces é um exemplo típico
- O usuário diz que há um trecho de interesse dentro de um trace longo e quer recortá-lo
- O motivo é facilitar desempenho e visualização
- Mas, nesse caso, talvez seja mais apropriado evitar coletar um trace longo desde o começo
- O Perfetto já tem periodic trace snapshots
- É uma função que grava repetidamente registros curtos em vez de um único registro longo
- Isso elimina a própria necessidade de coletar um trace longo e depois dividi-lo
- A resposta pedida pelo usuário e a resposta de que ele realmente precisa podem ser diferentes
- A reação “era exatamente disso que eu precisava” é um sinal de que se encontrou a necessidade real, e não apenas se respondeu ao pedido imaginado pelo usuário
Quando o produto precisa mudar
- Algumas respostas revelam novas necessidades que podem levar a grandes mudanças no produto
- Esses casos são complicados
- Mesmo que a solicitação seja nova, quem a faz pode não conseguir expressar com clareza o que realmente precisa
- O custo de tomar uma decisão errada em software de base é alto
- Por isso, a preferência é não construir algo até que a dor de sua ausência fique real e evidente
- Quando várias equipes começam a relatar a mesma necessidade, normalmente aí já fica mais fácil enxergar o núcleo que realmente vale a pena construir
- Encontrar esse núcleo a partir de um único pedido é muito difícil; por isso, esperar pode ser uma estratégia poderosa
- A customização temporária de UI no Perfetto é um exemplo de decisão ruim
- As pessoas queriam hackear a interface para adaptá-la ao próprio fluxo de trabalho e reclamavam repetidamente de como isso era difícil
- No momento em que isso foi permitido, surgiu uma enorme dívida técnica
- Cada novo recurso passou a precisar interagir com todos os anteriores, e a estrutura inteira rapidamente deixou de escalar
- Levou cerca de um ano para sair desse problema com o desenho de uma plugin API adequada
- A necessidade real era “uma forma de personalizar a UI para uma equipe ou caso de uso sem afetar todos os usuários”
- Essa necessidade não foi expressa com clareza desde o início
- Cabia a quem construía o produto detectar isso cedo no fluxo de solicitações
- A funcionalidade que permite fazer merge de Perfetto traces é um exemplo de caso bem conduzido
- As pessoas pediram isso repetidamente, mas a equipe não implementou de imediato
- Preferiu orientar alternativas e observar o uso
- Já sabia que seria uma função trabalhosa de implementar e fácil de fazer do jeito errado
- Depois de entender suficientemente o espaço do problema, implementou no ano passado uma solução sustentável
Lição principal
- A primeira pergunta muitas vezes não é a pergunta real
- Antes de responder, é preciso perguntar por que aquela pergunta está sendo feita
- Em alguns casos, o usuário aprende como deveria usar a ferramenta
- Em alguns casos, fica claro que o caminho certo dentro do produto estava escondido
- Em alguns casos, conclui-se que ainda não existe nada que realmente valha a pena construir
- Em alguns casos, isso prepara o terreno para acertar o próximo grande recurso de uma vez, em vez de precisar fazê-lo duas vezes
- É uma técnica simples, mas fácil de ignorar
- A pressão para responder rápido sempre existe
- Respostas rápidas quase sempre parecem produtivas no momento
- Ainda assim, ao dar um passo para trás, quase sempre ambos os lados acabam ganhando mais do que no ponto de partida
1 comentários
Comentários do Lobste.rs
O autor diz que este texto vai muito além do problema XY, mas para mim ele parece justamente um texto que explica em detalhe como lidar com o problema XY, com insights interessantes
Se você enquadra a pergunta como problema XY, há uma grande chance de voltar às heurísticas contraproducentes que as pessoas usam ao responder perguntas que parecem problema XY
Já perdi as contas de quantas vezes, ao pedir conselho, as pessoas ao meu redor presumiram que eu estava passando por um problema XY, e eu tive que ficar me explicando até chegar a alguém que realmente lesse o que eu escrevi. Sinto que a cultura de programação em torno de responder ao problema XY está mal calibrada, e este texto soa como uma refutação dessa sobrecorreção
Mesmo quando parece que quem perguntou sabe muito menos do que você, é importante desacelerar e não fazer pattern matching. Para começo de conversa, a chance de ser problema XY não é esmagadoramente alta e, mesmo que seja, talvez seja melhor tratar como se não fosse
Foi um bom texto. Isso me lembrou do outro lado da mesma moeda: tomar cuidado para não transformar a pergunta recebida em uma versão mais simples e responder essa outra pergunta
Por exemplo, alguém pergunta “qual é a distância entre Amsterdã e São Francisco?” e a resposta vem como “leva 12 horas de avião”
A pergunta era sobre distância, mas como saber a distância é mais difícil e o tempo de voo é algo mais fácil de lembrar, a pessoa responde a uma pergunta mais fácil no lugar
Isso acontece com bastante frequência e parece ser ainda mais comum quando existe distância de poder entre quem pergunta e quem responde
Por vários motivos, durante a modernização do sistema adicionamos uma página 404 ao roteador de ingress e isso causou problemas. Um desenvolvedor pediu para restaurarmos o comportamento antigo do 404, porque a página antiga tinha barra de navegação e menu
Quando fomos investigar mais a fundo, descobrimos que, em algumas configurações de clientes, o login sempre acabava em 404, e os clientes de fato usavam a antiga página 404 para navegar até onde realmente precisavam ir
Inventeio lolcry para momentos assim 🤣😭
@lalitm, esse problema é mais antigo que a internet e já tem nome: análise de requisitos
Ed Yourdon e outros distinguiam o processo, que é o resultado que o usuário quer obter, do procedimento, que é como esse resultado é alcançado. Por exemplo, avisar um cliente que o pedido foi enviado é o processo; mandar essa informação por e-mail é o procedimento
Usuários de sistemas tendem a pensar na solução como se fosse uma funcionalidade do sistema. Programadores não são exceção, daí existirem tantas variações de “resolver Y a partir de X”. O trabalho do analista é extrair os requisitos de uma forma específica de implementação e, como engenheiro, depois implementar a solução por trás disso
Recentemente participei de uma discussão sobre tornar o logging mais rápido, porque o syslog(3) às vezes atrasava e eventos sumiam dos logs. Mas o problema real não era logging mais rápido. O usuário não quer logging mais rápido; ele quer resolver o problema. Fornecer a informação necessária é o processo, e escrever tudo no log é apenas uma das formas de fazer isso
Yourdon foi um dos defensores de ferramentas CASE. Talvez isso tivesse dado certo se a gerência conseguisse medir qualidade e produtividade, mas essa é uma reclamação para outro dia
Dizem que “a própria confusão que gerou a pergunta errada é uma oportunidade”, mas, a menos que você seja o maior especialista do mundo naquele domínio, é bem difícil julgar desde o início que uma pergunta está errada
Na verdade, você deve responder
A menos que seu papel seja o de guardião protegendo recursos mentais preciosos, vale a tática do improviso: “sim, e...”. Claro, você também pode acrescentar que talvez existam outras formas de chegar ao resultado desejado
Em vez de usar só uma estratégia para destravar a situação, é melhor usar todas as estratégias possíveis