1 pontos por GN⁺ 2 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • “Mover-se rápido” deixou de ser apenas uma necessidade prática e passou a ser tratado como prova de seriedade e ambição, enquanto a análise cuidadosa é vista como uma atitude que atrapalha o impulso
  • A velocidade de verdade surge quando se entende o trabalho, as restrições e as dependências, toma-se decisões com clareza e só então se executa, mas muitas organizações disfarçam requisitos ambíguos e decisões inacabadas de velocidade
  • Quando a etapa de entendimento é apressada, retrabalho vira “iteração”, confusão vira “alinhamento” e falhas evitáveis viram “aprendizado”, enquanto sistemas nos quais ninguém confia e processos de contorno se consolidam como a estrutura central do negócio
  • Urgência é quando há uma restrição real de tempo para algo importante, mas pressa é o estado de buscar alívio emocional na ação sem o peso de garantir clareza
  • Para trabalhar direito, é preciso entender, decidir, revisar o suficiente e então agir; o preço de pular pensamento, contexto e responsabilidade volta na forma de sistemas quebrados, equipes esgotadas, clientes que vão embora e feridas operacionais de longo prazo

Como a velocidade é confundida com progresso

  • Lançar, responder, contratar, escalar e mudar rápido passa a ser tratado, por si só, como prova de ambição e seriedade
    • Pedir para desacelerar e pensar é visto como algo que atrapalha o impulso
    • Apontar um plano estruturalmente frágil é recebido como negatividade
  • A velocidade funciona como uma droga organizacional que dá a sensação de estar em movimento mesmo sem a disciplina do julgamento
    • Todo mundo se sente ocupado e na urgência, e a própria atividade pode ser usada como prova de avanço
    • Mas boa parte do que se chama de velocidade é só pressa com outro nome
  • Velocidade de verdade só é possível quando o trabalho e as restrições estão claros, a pessoa responsável tem competência para executar com base em decisões bem encerradas e não fica reabrindo discussões
  • O que normalmente se chama de velocidade costuma deixar para trás requisitos ambíguos, decisões inacabadas, dependências não examinadas e contexto insuficiente
    • Espera-se que a próxima pessoa resolva o que não foi decidido, e depois todos se surpreendem quando o resultado quebra
    • Isso falha porque foi construído sob a premissa de que pensar é a parte mais cara do processo
  • Esse padrão aparece não só em software, mas também em operações, gestão, contratação, logística, atendimento ao cliente e desenvolvimento de produto, quando atividade é confundida com progresso
  • A etapa que precisava ser entendida é apressada, depois se gasta dez vezes mais tempo consertando o resultado, e até o sentido das palavras muda nos registros
    • O trabalho apressado do começo vira “execução rápida”
    • O conserto vira “imprevisto”, o retrabalho vira “iteração”, a confusão vira “alinhamento” e a falha evitável vira “aprendizado”
  • Quando, em cada pequena decisão, a velocidade é escolhida acima do entendimento, acumulam-se sistemas nos quais ninguém confia, processos que ninguém entende, reuniões que ninguém quer e dashboards em que ninguém acredita
    • Soluções temporárias de contorno acabam virando a estrutura essencial que sustenta o negócio
    • Depois, a “modernização” muitas vezes só troca o caos visível, deixando intacto o culto à velocidade

Como agir certo sem agir na pressa

  • Desacelerar não significa trabalhar devagar, e sim não pular o processo de tornar o trabalho claro
    • É preciso confirmar o que de fato se está tentando construir e quem depende disso
    • É preciso examinar o que quebra se uma premissa estiver errada, o que já se sabe e o que se está fingindo não saber
    • Também é preciso verificar onde as falhas aconteceram no passado e quais condições são necessárias para o sucesso
  • Essas perguntas básicas eliminam a satisfação imediata de simplesmente se mover e impedem que alguém se esconda atrás de urgência ou PowerPoint
    • Como exigem entender de verdade o trabalho e assumir responsabilidade por decisões de detalhe, costumam ser evitadas
  • A velocidade permite manter decisões vagas e empurrar os detalhes para a emergência de outra pessoa
    • Quando a emergência surge, a solução volta a ser corrigir, contratar, substituir ou lançar ainda mais rápido, repetindo o mesmo problema como se fosse tratamento
  • Urgência é adequada quando há uma restrição real de tempo para algo importante, mas a pressa aparece quando se busca alívio emocional na ação sem o peso da clareza
  • Criticar a velocidade não significa defender lentidão deliberada nem transformar toda decisão em reunião
    • Também não é preciso gastar seis meses construindo a própria infraestrutura de deploy só para provar que se está sendo criterioso
    • A ideia é respeitar o trabalho o bastante para fazê-lo direito desde o começo
  • A ordem correta é entender → decidir → revisar o suficiente → executar
    • Quando essa ordem é invertida, o preço vem em sistemas quebrados, equipes exaustas e clientes que vão embora em silêncio
    • Também ficam cicatrizes operacionais que exigem anos de contornos, porque já não há paciência para entender a causa de novo
  • Mudanças de mercado, concorrência, clientes exigentes, equipes pequenas, orçamento apertado e janelas de oportunidade se fechando podem ser restrições reais
    • Mas também podem virar desculpa para evitar o trabalho mais lento e mais difícil de entender a situação antes de agir
  • A forma melhor é continuar decidindo e lançando, mas com calma
    • Sem confundir pânico com seriedade, toda pausa com fraqueza, nem movimento em si com progresso
    • Quando pensamento, clareza, contexto e responsabilidade são pulados, pode até parecer mais rápido por um momento, mas os sistemas e quem faz a manutenção continuam pagando a conta
    • Algumas coisas só podem ficar mais rápidas depois que se para de ter pressa

1 comentários

 
GN⁺ 2 시간 전
Comentários do Hacker News
  • Devagar para ficar suave, suave para ficar rápido
    O que aprendi sobre velocidade é que as pessoas tendem a não medir, ou a medir errado apenas aquilo que é conveniente no momento. A medição correta objetiva tudo em números, mas há também quem simplesmente não consiga medir direito, como alguém incapaz de se autoexaminar. Números estimados erram mais de 80% das vezes e facilmente passam várias ordens de grandeza longe. Pequenas melhorias encontradas por medição se acumulam de forma inesperadamente grande, e a maneira mais confiável de ficar mais rápido é mudar a tecnologia e as técnicas. Contratar é lento, adicionar pessoas a um projeto atrasado o torna ainda mais lento, e quanto mais se melhora as camadas inferiores da stack tecnológica, mais se ganha velocidade e flexibilidade ao mesmo tempo, o que pode então ser usado para escalar

    • Remadores chamam o estado de se mover sem atrito de swing. Assim como é melhor deixar o corpo seguir a gravidade e o impulso em vez de forçar um balanço, o barco também quer se mover rápido por natureza, então o importante é não atrapalhar com contorções desesperadas. Esforço excessivo estraga a velocidade, e swing não é um estado de esforço, mas um estado já alcançado — Houghton Mifflin, Mind Over Water
    • É difícil entender por que algumas pessoas não conseguem se autoexaminar, e se realmente existem pessoas para quem a autoanálise em si é impossível
    • Se você é a primeira pessoa a medir corretamente um codebase, não vai parar em pequenas melhorias. Em geral há grandes e óbvias oportunidades de melhoria por toda parte
    • Não dá para medir tudo, e o próprio ato de escolher o que medir é uma decisão editorial que introduz viés
  • Mesmo que tecnicamente não esteja errado, um projeto pode fracassar se você gastar 6 meses em vez de 6 semanas para encontrar uma solução prática para o problema do cliente e acabar exaurindo esse cliente. Do ponto de vista do cliente, velocidade é uma funcionalidade e um valor econômico
    Basta imaginar como é chamar um técnico para consertar um ar-condicionado quebrado numa tarde de agosto no Texas. Em áreas complexas e incertas, um processo de iteração rápida é importante, e é melhor julgar se está rápido demais pela reação que o cliente demonstra

    • Os clientes de software são muito diversos: a empresa que encomendou um app para evento, o Walmart criando uma plataforma de e-commerce, um desenvolvedor usando serviços da AWS, ou usuários comuns de Windows e iOS. Como o cliente também não controla qualidade, confiabilidade e a própria solução, não há como saber de antemão se o desenvolvimento está rápido demais
      Consertar ar-condicionado é mais parecido com um hotfix; uma analogia melhor seria passar 6 anos consertando uma casa construída em poucos dias para escapar do calor do Texas, com isolamento ruim, paredes soltas, fiação externa e encanamento despejando água sob a casa
    • O texto também parece ver a verdadeira velocidade como algo que surge quando se entende o trabalho e as restrições, e pessoas experientes tomam decisões claras e executam sem discussões repetidas. A afobação que atrapalha planejamento e consenso aumenta erros e custos, e tende a destruir projetos, confiança e moral; se o pânico vira padrão, até resultados rápidos falham
    • Também é preciso considerar a situação em que o técnico aparece seis vezes em uma semana, toda vez dizendo que consertou, mas o ar-condicionado continua quebrando
    • Fico em dúvida se este texto quer mesmo ignorar a urgência em si, e também quantas empresas ou pessoas realmente ignoram a urgência
      Em incidentes graves para o negócio, era comum gente de qualquer nível hierárquico tentar qualquer ação e aumentar a confusão, o que acabava ampliando o tempo total e o impacto em comparação com quando se colaborava, entendia o problema e então se resolvia. Uma abordagem calma e constante que para por um instante, respira e entende o problema inteiro, inclusive a urgência, no fim foi mais rápida, e isso é compatível com manter o cliente informado sobre o andamento e acalmar suas preocupações
    • Antes de tudo, é preciso definir o critério de solução prática. Julgar que dá para fazer em 6 semanas é tão subjetivo quanto 6 meses, e se você continuar atualizando um resultado que inicialmente parecia utilizável, também precisa considerar até quantas vezes o cliente vai tolerar isso e quão grave será o problema na sétima semana. No fim, passamos a viver em soluções práticas constantemente atualizadas depois de trocar o modelo em cascata por agile
  • A adoração da velocidade vem do capital de risco. Investidores de venture capital precisam devolver retorno aos cotistas dentro de um prazo, então só atraem atenção se conseguirem fazer os outros acreditar que haverá crescimento de 10x dentro desse cronograma
    Se você se prende de verdade a esse calendário, acaba facilmente se tornando alguém que define prazos arbitrários ignorando a realidade técnica e elimina projetos só porque não cumpriram esse prazo

    • Para investidores de venture capital, esse prazo não é arbitrário; ele é determinado pelo custo do capital. Situação de mercado e tecnologia não importam: se lucro, receita ou participação de mercado não crescerem rápido o suficiente, a empresa entra como perda e é liquidada
      Se sua estrutura e seus objetivos não combinam com a lógica de crescer loucamente ou morrer, você não deveria captar venture capital. Se quiser desenvolver sem pressa, é melhor escolher uma startup com product-market fit (PMF) comprovado e uma excelente equipe comercial responsável pela curva de crescimento
    • Empresas financiadas por venture capital são só uma fração minúscula do total. A alternativa, financiamento por dívida, muitas vezes traz ainda mais prazos e urgência
    • A urgência em empresas que crescem com recursos próprios pode ser ainda maior. Se não houver um grande acerto logo cedo, a pressão para entregar rápido, gerar receita e receber um salário decente é bem real, e também é difícil contratar mais gente para dividir o trabalho
      Startups com venture capital, por terem uma boa reserva de caixa e possibilidade de apoio adicional, às vezes eram até menos duras. Investidores querem retornos maiores que o mercado acionário, e fundadores querem riqueza maior do que teriam trabalhando em uma FAANG, então a pressão por recompensa proporcional ao risco surge independentemente da forma de financiamento
    • Marcos e cronogramas arbitrários de projeto também são úteis. Não precisam ser usados como critério para matar um projeto, mas servem como referência que revela o resultado do esforço em comparação com mudanças externas
    • O venture capital é como um câncer do mundo, no sentido de fazer você ignorar não só a realidade técnica, mas quase tudo que valha a pena
  • Um coronel do Exército, de humor cínico, dizia com frequência: “em intervalos de tempo suficientemente curtos, até movimento periódico parece progresso” e “devagar para ficar suave, suave para ficar rápido”

    • Numa curva fechada de corrida em pista, ela parece lenta e dá vontade de forçar mais, mas na verdade é melhor reduzir ainda mais para fazer a curva com suavidade, controle e precisão, o que melhora a aceleração depois. É o princípio de entrar devagar e sair rápido
      Até pelas contas, é mais vantajoso ganhar 1 mph numa reta de um quarto de milha do que ganhar 1 mph numa curva lenta de 100 pés
    • No treinamento militar básico, os instrutores repetiam isso sem parar. Durante a formação de oficiais, ao entrar num bunker de concreto onde se aqueciam grânulos de gás lacrimogêneo, os olhos começaram a arder intensamente, mas antes mesmo de pensar conscientemente eu já tinha tirado a máscara de gás e colocado no rosto, executando corretamente até os procedimentos do filtro e do creme de descontaminação
      O que permitiu resistir ao impulso de tirar a máscara e esfregar os olhos foi o fato de que um treinamento lento e repetitivo levou a ações rápidas automatizadas. Troca de carregador e acionamento do forward assist seguem o mesmo princípio
  • Do ponto de vista da engenharia, fazer devagar é o que torna tudo mais fluido e rápido, mas do ponto de vista comercial, lento é simplesmente lento. Enquanto você promete mais qualidade daqui a 6 meses, se um concorrente fechar um contrato raro de 5 a 10 anos, a empresa pode acabar não apenas mudando o foco para outra coisa, mas demitindo uma equipe inteira sem ter onde alocá-la
    O ponto de falha é exigir resultado desde o início enquanto ao mesmo tempo se dá tempo para a empresa construir do jeito certo. Se você gastar 6 meses ou 1 ano em infraestrutura, design system, biblioteca de componentes e arquitetura de sistemas sem nada para mostrar, a cobrança de custos e o acompanhamento ficam estranhos, e a promessa de que o desenvolvimento ficará muito mais rápido no futuro não convence a diretoria

    • A urgência pode ser real, mas pular o planejamento não te faz mais rápido. Muitas vezes, algumas horas de planejamento já evitariam semanas de trabalho inútil e retrabalho
    • No curto prazo, correr pode parecer a escolha certa, mas os atalhos acabam cobrando seu preço. Quem já viveu situações em que o time comercial enfiou funcionalidades especiais para fechar um grande contrato sem tempo para pensar na estrutura, ou exigiu lançamento antes de terminar os testes, sabe bem disso. O outro lado pode até ganhar um contrato, mas raramente vence a corrida de longo prazo
      É preciso distinguir entre fazer devagar com rigor e responsabilidade e ser lento por incompetência. A pressão do mercado é real, e equipes que continuam lentas desaparecem. Às vezes, lentidão leva à fluidez e à velocidade; às vezes, é só lentidão mesmo, então o essencial é saber a diferença entre as duas
  • No início da carreira, percebi que às vezes a liderança acha que, se você não demonstra estresse externamente, não está levando a situação a sério. Ouvir coisas como “não parece urgente” abalou bastante minha cabeça na época

    • Gestão de verdade é decidir como alocar recursos limitados entre opções concorrentes. Mas muitos gestores e membros da equipe tratam gestão como controle de pessoas e acabam presos ao papel de fiscal, monitorando se os outros estão mesmo trabalhando mais
    • Eu ouvi exatamente a mesma coisa, mas em vez de me abalar concluí que alguém que não consegue distinguir aparência de realidade não deveria ser CEO
    • Gestores inseguros tendem a ficar ansiosos até com a calma dos outros, mas também há muitos gestores que não são assim
  • “Não confunda movimento com progresso. Uma cadeira de balanço está sempre se movendo, mas não vai para frente” — Alfred A. Montapert

  • Não é difícil concordar com o texto, mas prazos estão completamente ausentes da discussão. A exigência de velocidade nem sempre surge no vácuo; se for injusta, deve ser enfrentada, mas fica a dúvida de se na prática sempre existe escolha

    • O texto parece olhar o trabalho de forma um tanto idealizada e relaxada. Há uma vantagem clara em se mover rápido, mesmo quebrando algumas coisas, em vez de cair no perfeccionismo esperando feedback ou construindo o que não precisa. Essa é uma lição básica da gestão ágil e, mesmo não sendo absoluta, em geral um ritmo mais rápido do que o nível confortável é vantajoso
    • Como autor, vejo prazos em geral como restrições artificiais. Há datas imutáveis, como janela de lançamento ou cronograma de produção de fornecedores, mas muitas vezes eles servem como distração do objetivo real, desculpa para apressar as coisas ou um chicote psicológico
      Quando se corre só para cumprir o prazo, pode até parecer mais rápido no momento, mas o resultado sai pior do que o melhor que a equipe poderia entregar, e depois se gasta ainda mais tempo limpando a bagunça. A ideia não é defender relaxamento em toda situação, e sim que, em ambientes onde se está sempre correndo e quase nunca se atinge o objetivo, vale examinar se a própria pressa é a causa do fracasso
      Depois que a FedEx implantou um novo dashboard para funcionários de entrega, o sistema travou durante o processo de recebimento de um MacBook, e o funcionário fez o atendimento manualmente e entregou o recibo, mas uma etiqueta errada foi impressa. Como resultado, o notebook nunca chegou à Apple, e durante semanas foi preciso explicar repetidamente a situação a vários funcionários, até que um mês depois a Apple teve de enviar um novo notebook de 5 mil dólares. É um caso em que um software apressado por causa de um prazo arbitrário desperdiçou enorme tempo e dinheiro, e falar em reduzir a velocidade não significa conforto psicológico, mas evitar o caos atual e futuro
    • A maioria dos prazos é uma restrição artificial e autoimposta. Isso não quer dizer marcar uma reunião e discutir no Slack enquanto metade da casa está pegando fogo; algumas coisas realmente são mais urgentes. O texto não é absolutista: ele critica a adoração da velocidade e exige a disciplina de julgar conforme a situação
  • Rapidez e vetor de velocidade não são a mesma coisa. Alguém caindo de um prédio de 100 andares pode achar que está voando em altíssima velocidade, mas o vetor de velocidade em direção ao objetivo surge quando se consideram cuidadosamente as muitas dependências e se navega corretamente
    Em grandes empresas, muitas vezes nenhum dos dois importa, e a maioria das entregas é péssima. Os prazos são planejados para bater com avaliações anuais de desempenho, e os preferidos da liderança criam histórias de sucesso dizendo que atingiram os indicadores certos ou mudando os marcos para serem recompensados. A própria liderança também é recompensada por supostamente ter supervisionado brilhantemente esse sucesso

  • Quanto mais longa a carreira, mais claro esse princípio fica. Mas pode virar um problema quando colegas mais jovens, que ainda não perceberam isso, ficam acima de mim na hierarquia de gestão
    Costumo provocar reflexão com frases como: “Alguns dos maiores resultados que entreguei foram códigos que decidi não escrever