{
  "id": 3787088,
  "title": "Ownership não é o PR. É não deixar o problema só na sua cabeça",
  "url": "https://urgent.news/2026/08/27/ownership-nao-e-o-pr-e-nao-deixar-o-problema-so-na-sua-cabeca",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-27T18:01:31.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/tiagovilasboas/ownership-nao-e-o-pr-e-nao-deixar-o-problema-so-na-sua-cabeca-57gg"
  },
  "original_language": "pt",
  "account": "Posse não é a responsabilidade de um único indivíduo. É a postura de não deixar os problemas apenas na sua cabeça. Há um padrão que ela observa em times que entregam bem: o erro está no board de observabilidade há meses, mas ninguém assumiu a responsabilidade. Alguém comentou no canal, mas o suporte só reclama depois. O problema costuma virar um incidente somente quando a pergunta aparece: de quem era a responsabilidade? Antigamente, ela pensava que a posse era pegar o código. Se ela viu, ela consertava. Mas essa visão quebrava o time, uma pessoa se tornava herói ou gargalo, enquanto o outro normalizava o problema até que explodisse. Ela percebeu que o tempo de ver um problema não significa que ela deve implementá-lo. O importante é reconhecer que ela viu, sem fingir que não viu. Eles distinguem quatro posturas: Pergunta que guia, Task “Está done?”; Delivery “Está em produção?”; Outcome “Resolveu o problema do usuário?”; Ownership “O que mais está errado aqui?” O verdadeiro problema não é alguém ficando preso na tarefa. É o time inteiro parar e ninguém carregar a visão de sistema. Ela usa quatro passos práticos para lidar com o problema: SEE → UNDERSTAND → EXPOSE → OWN. \"See\" significa perceber algo estranho, \"Understand\" se trata de entender se isso importa, \"Expose\" é colocar o problema em evidência com dados, não sentimentos, e \"Own\" envolve tomar uma decisão ou assumir a propriedade, mesmo que não seja codificação. A posse não significa apenas codificar o problema, pode ser abordar a questão com o dono do card, escrever um parágrafo de contexto, ou enquadrar um problema com um prazo, inclusive: \"vamos conviver com isso por enquanto\". Se assumir a posse virar \"quem viu implementa\", o Senior ou Time Lead se torna o único adulto na sala, o que não escala e pode deixar boas pessoas cansadas. O framework que ela usa para mudar a conversa é: \"Corrigimos um bug\" é output. A frase que usa para priorizar é: Problema → evidência → impacto → ação → (depois) resultado. Por exemplo, ela observou que uma API crítica mudou de tempo de resposta, passando de 200ms para 2 segundos. Sem um número, o problema seria ignorado, mas com o gráfico e a explicação, a priorização muda. A indústria de qualidade, incluindo aqueles que trabalham com NIST, repete que o time de alto desempenho não é só quem mergeia rápido, mas quem detecta e responde. Ela destaca que o verdadeiro objetivo é um sistema mais saudável, não quem fica exausto. Ela deixa três perguntas para refletirem: qual problema você viu nas últimas duas semanas que ninguém está tratando? Se continuar um mês, o que piora? E quem deveria assumir a posse ou quem decide que não tem posse agora?",
  "summary": "Ownership não é o PR. É não deixar o problema só na sua cabeça Pessoal, tem um padrão que eu vi demais em time que já sabe entregar. O erro está no board de observabilidade há meses. Alguém já comentou no canal. Suporte eventualmente reclama. Nunca virou card. Um dia vira incidente. Aí a pergunta aparece, desconfortável: de quem era a responsabilidade? Eu costumava responder errado. Ownership,…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}