9 pontos por GN⁺ 2024-11-12 | 2 comentários | Compartilhar no WhatsApp

Por que lançar (shipping) é difícil

  • Muita gente acha, por engano, que “lançar” é algo fácil, mas o estado padrão é o lançamento atrasar, ser cancelado ou sair com baixa qualidade e causar problemas.
  • Escrever todo o código ou resolver todos os tickets no Jira não faz o lançamento acontecer automaticamente. Para lançar, alguém precisa assumir a liderança.
  • O lançamento precisa ser a prioridade máxima. Focar demais em experiência do usuário (UX) pode, na prática, atrasar o lançamento.
  • Para lançar um projeto com sucesso, é preciso haver um líder técnico ou um DRI (Directly Responsible Individual). Times que têm um engenheiro nesse papel têm mais chance de sucesso.

O que é “lançar”?

  • Muitos engenheiros pensam em “lançar” apenas como fazer deploy do código ou ativar uma feature, mas em grandes empresas de tecnologia a definição é diferente.
  • Um lançamento acontece quando as pessoas importantes dentro da empresa acreditam que ele “foi lançado”. Se o VP ou o CEO não estiver satisfeito, então, mesmo que o código tenha sido implantado, aquilo não foi realmente “lançado”.
  • Se o projeto faz muito sucesso com os usuários ou gera receita, então foi lançado; mas mesmo que a reação dos usuários não seja boa, se a liderança estiver satisfeita, ele ainda é considerado lançado.

A importância da comunicação

  • É preciso entender com clareza qual é o objetivo do projeto. Dependendo da meta, a forma de trabalhar e a estratégia de comunicação mudam.
  • A liderança da empresa quase não conhece os detalhes técnicos do projeto. Por isso, para manter a confiança, são importantes estimativas precisas, resolução de problemas e atualizações adequadas.
  • Como manter a confiança:
  • Ter um histórico de lançamentos bem-sucedidos ajuda.
  • É preciso demonstrar confiança.
  • A comunicação deve ser profissional e concisa, como no controle de missão da NASA.
  • É preciso fornecer informações de forma proativa por meio de threads de atualização diárias ou semanais.

Resolvendo problemas de deploy em produção

  • A maioria dos problemas surge em detalhes inesperados. Por exemplo, pode haver problemas com tamanho de bloco do Memcached, erros de previsão de tráfego ou questões envolvendo dados sensíveis de usuários.
  • Para resolver rapidamente os problemas, é necessário ter um entendimento técnico profundo do sistema.
  • É preciso reagir rápido aos problemas previstos e conseguir explicar com clareza se um problema é grave ou não.

Dá para lançar agora mesmo?

  • É importante se perguntar se dá para lançar agora mesmo. Se a resposta for não, é preciso pensar no que teria de mudar para que isso fosse possível.
  • É preciso usar feature flags e ambientes de staging para obter feedback o mais cedo possível.
  • Perto do lançamento, é melhor reduzir o trabalho técnico e se preparar para responder rapidamente caso surjam problemas.

Resumo

  • Lançar é muito difícil e deve ser tratado como prioridade máxima.
  • O significado de lançamento não é apenas fazer deploy, e sim satisfazer o time de liderança.
  • Ganhar a confiança da liderança é o ponto-chave de um lançamento bem-sucedido.
  • É importante ter planos de contingência para prever e lidar com problemas.
  • Logo antes do lançamento, é preciso reduzir o trabalho de desenvolvimento e conseguir focar na resolução de problemas.
  • É preciso sempre fazer a pergunta: “Dá para lançar agora mesmo?”.
  • É preciso deixar o medo de lado e ter coragem.

2 comentários

 
GN⁺ 2024-11-12
Comentários do Hacker News
  • A observação de que "shipping" é uma construção social dentro da empresa foi marcante. Está concluído quando as pessoas importantes acreditam que o projeto foi concluído
  • Este artigo trata de satisfazer a diretoria, não de fazer deploy de software. Mesmo que os usuários odeiem e o mercado zombe, se a diretoria gostar, foi entregue
  • Assim como nos esportes vencer resolve todos os problemas, em software entregar resolve todos os problemas. Não existe produto perfeito, mas se você entregar cedo, os usuários podem ficar satisfeitos
  • Em alguns casos, engenheiros que resolvem problemas recebem mais reconhecimento do que aqueles que os previnem. Tentamos prevenir problemas, mas às vezes os líderes não percebem isso
  • Em grandes empresas, "entregar" precisa ser entendido em um contexto mais amplo, não apenas como tornar uma funcionalidade real. Alguns podem chamar isso de antiético, mas em grandes empresas é um tipo de "jogo"
  • Já entregou muitos projetos, mas sem exemplos concretos é difícil confiar. Se incluísse casos reais de projetos, seria mais fácil de entender
  • Este artigo é spam de blog autopromocional
  • Bate com a experiência, mas faltam conselhos práticos. São necessários exemplos concretos de como obter reconhecimento da liderança
  • É diferente da experiência em grandes empresas. Mesmo sem apoio da diretoria, se o feedback dos usuários ou as métricas forem positivos, isso é considerado sucesso. Projetos pequenos também podem ter valor
  • Para ser confiável, é preciso quantificar e qualificar as afirmações. "Entregar em big tech" é uma afirmação ampla, e precisa de explicações específicas
 
signaling 2024-11-13

Separei um trecho de opinião marcante.

“Algumas pessoas só querem construir feudos técnicos para si mesmas ou receber elogios de quem está acima delas, em qualquer camada da hierarquia. É assim que o "jogo é jogado". Jogar esse jogo acaba levando à morte da organização, e é exatamente por isso que existem ciclos de vida das empresas. No fim, essas pessoas corroem a organização por dentro e afastam quem tem opiniões reais ou quem é otimizado para realmente fazer o trabalho acontecer.”

“A maneira de vencer o jogo é não jogá-lo”