DEV Community

Tiago Vilas Boas (Montanha)
Tiago Vilas Boas (Montanha)

Posted on

Ownership não é o PR. É não deixar o problema só na sua cabeça

#career #architecture #productivity #discuss

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, pra mim, era pegar o código. Se eu vi, eu conserto. Ou o contrário: se não tem task, não é comigo. Os dois lados quebram o time.

O que você leva daqui: uma distinção de uma frase e um ritual de três perguntas. Ver um problema não te obriga a implementá-lo. Obriga você a não fingir que não viu.

Tabela de Conteúdo

1. Todo mundo via. Ninguém possuía

O salto não é de júnior pra Staff. É de pergunta.

Enquanto a unidade for o card, o time otimiza “done”. O problema que não virou card continua existindo. Só mudou de lugar: saiu do board e foi morar na cabeça de três pessoas.

Eu fiquei um tempo nos dois extremos. Herói (vi, então eu implemento). Ou espectador (não tem task, não é comigo). Os dois normalizam o mesmo buraco: o sistema não tem dono do problema, só dono do ticket.

2. Quatro posturas: a pergunta muda

Nenhuma é “errada” sozinha. O problema é o time inteiro parar no primeiro degrau.

Postura Pergunta que guia Sinal
Task “Está done?” Fecha o card sem olhar comportamento em produção
Delivery “Está em produção?” Acompanha o deploy, não o resultado
Outcome “Resolveu o problema do usuário?” Olha métrica depois do merge
Ownership “O que mais está errado aqui?” Percebe o adjacente sem esperar task

Task e delivery

Task pergunta pelo card. Delivery pergunta pelo deploy. As duas são necessárias. Nenhuma das duas pergunta se o usuário parou de sofrer, nem se o modo de falha do lado ainda está aberto.

Outcome e ownership

Outcome pergunta pelo resultado. Ownership pergunta pelo sistema: o que mais está errado aqui, mesmo sem task.

Ownership não substitui as outras. Ela impede que o time chame de “resolvido” o que só foi movido.

3. See it, own it. OWN não é CODE

Na prática eu uso quatro passos. Nomes feios de propósito, pra não virar poster.

SEE          percebi algo estranho
UNDERSTAND   isso importa? recorrente? quem se ferrar?
EXPOSE       o problema precisa de dado, não de feeling
OWN          existe decisão ou dono. Inclusive “aceitamos o risco”.
Enter fullscreen mode Exit fullscreen mode

OWN não significa CODE.

Pode ser um card com contexto de verdade. Uma conversa com quem prioriza. Um parágrafo escrito. Uma investigação com prazo. Inclusive: “vamos conviver com isso por enquanto”, desde que isso seja decisão, não esquecimento.

Se ownership virar “quem viu implementa”, o Senior/TL vira o único adulto da sala. Isso não escala. E queima gente boa.

O que isso não é

Ownership não é resolver tudo que passar na timeline, furar priorização porque você ficou inquieto, trabalhar fora do horário pra “provar” que é dono, nem caçar culpado no post-mortem.

Se o framework criar ansiedade, ele falhou. O objetivo é sistema mais saudável, não indivíduo exausto.

4. Evidência antes de feeling

“Corrigimos um bug” é output.

O que costuma destravar priorização é outra frase:

Problema → evidência → impacto → ação → (depois) resultado.

Exemplo sintético, de propósito:

Uma API crítica seguia respondendo 200. Em três semanas o P95 foi de ~400 ms para quase 2 s. Ninguém tinha aberto incidente porque “ainda funciona”. Alguém colocou o gráfico no canal e perguntou o que tinha mudado. Aí deixou de ser feeling.

Sem número, o problema compete com o backlog e perde. Com número, ele vira escolha consciente.

DORA coloca o dedo nisso há anos: time de alto desempenho não é só o que mergeia rápido. É o que detecta e responde. Achar tarde custa mais. A indústria de qualidade, incluindo trabalhos associados ao NIST, repete isso em variações. O ponto prático pra mim não é o fator exato. É que “ainda está 200” não é saúde.

5. Três perguntas, três saídas

Dá pra usar numa retro, num 1:1 ou sozinho no fim da semana. Cópia solta: gist do radar.

  1. Que problema você viu nas últimas duas semanas que ninguém está tratando?
  2. Se continuar um mês, o que piora (usuário, on-call, lead time)?
  3. Quem deveria ser o owner, ou quem decide que não tem owner agora?

Ignorar, investigar ou abrir card

Cada item sai com um status, sem teatro:

  • ignorar com consciência (risco aceito, data pra rever);
  • investigar (hipótese + evidência);
  • abrir card (com as duas linhas de cima, não “olhar depois”).

Quinze minutos de retro bastam: cada pessoa traz um item. Sem ranking de herói. Se ninguém trouxer nada, o dado também vale: ou o sistema está saudável, ou o time ainda não se sente seguro pra expor.

Se a mesma coisa aparecer toda quinzena, o problema não é o card. É o sistema que ensinou o time a esperar o card.

A frase que eu ainda seguro em público:

Seu trabalho não termina quando o código funciona. Termina quando o problema deixa de existir, ou quando você garante que alguém é responsável por fazê-lo deixar de existir.

6. Onde o seu time para?

Não preciso do seu pior incidente. Quero a postura.

No último problema chato que todo mundo já via: vocês ignoraram com consciência, investigaram ou abriram card? E o que impediu a opção que vocês não escolheram?

Referências

O framework SEE → UNDERSTAND → EXPOSE → OWN e a distinção OWN ≠ CODE são síntese minha. Os links abaixo são o contexto público que usei pra amarrar “detectar tarde custa” e “entrega ≠ resultado”:

Top comments (0)