Quando o dono da meta não é uma pessoa: OKR por departamento ou pela empresa inteira

Todo objetivo pede um dono — é a primeira regra que qualquer guia de OKR ensina. Mas alguns objetivos não são de ninguém em particular: são de um departamento inteiro, ou da empresa toda. Até 25 de agosto, a Spire resolvia isso do jeito que a maioria dos produtos resolve: escolhendo uma pessoa mesmo assim, de preferência quem estava mais perto do teclado na hora de cadastrar. De lá para cá, isso mudou em três movimentos — o mais recente há três dias. Nenhum deles, porém, fechou a divergência que este mesmo blog registrou como limite do produto na semana passada — e vale explicar exatamente por quê, no meio do post.

Três formas de dono, um objeto só

Já explicamos aqui que resultado-chave e métrica de saúde são dois objetos diferentes no banco de dados da Spire, não duas leituras da mesma tabela. O que muda agora é ortogonal a essa distinção: os dois objetos — o objetivo/KR de um lado, a métrica de saúde do outro — ganharam o mesmo terceiro campo, owner_scope, com três valores possíveis.

A regra que a tela já cumpria — "ou é gente nomeada, ou é grupo, nunca os dois" — agora é aplicada uma vez só, no servidor, para as duas rotas (objetivo e métrica) e para os dois clientes (a tela e o agente): pedir um dono de grupo com uma lista de pessoas anexada faz a lista ser descartada em silêncio, não gera erro. E o corte de permissão vale nos dois sentidos, o que é a parte menos óbvia. O comentário que ficou no código depois do ajuste explica por quê: rebaixar um objetivo de empresa inteira para uma pessoa só passava, antes, pelo mesmo caminho de "atribuir a mim mesmo" que qualquer usuário comum já podia fazer — ou seja, sem o ajuste, alguém sem permissão de administrar metas conseguiria transformar um objetivo de todo mundo em um objetivo particular seu com um único PUT. Hoje entrar ou sair de um dono de grupo exige a mesma permissão nas duas direções.

Uma exceção estreita e deliberada: quem gerencia um departamento pode editar uma métrica de saúde que o próprio departamento possui — mas não apagá-la. Apagar continua exigindo a permissão de administrar metas, porque a exclusão é irreversível e leva junto todo o histórico de medições; editar um alvo ou uma descrição, não. Uma métrica de saúde da empresa inteira não tem esse atalho — não existe "gestor da empresa inteira", então ela fica sempre atrás da permissão de administração.

Veja como isso aparece no card de aprovação quando é a Roberta quem cria o objetivo — o card não lista 128 nomes, mostra a contagem:

Exemplo ilustrativo — números e nomes não correspondem a uma empresa real. O card soma a contagem de pessoas do grupo; antes de 1º de setembro, um objetivo assim aparecia sem dono nenhum.

A Roberta não sabia fazer isto até 1º de setembro

A tela já aceitava dono de grupo desde 25 de agosto. O agente de IA nativo e o MCP, não — e a razão é simples de descrever e mais simples ainda de ter deixado passar: owner_ids estava marcado como campo obrigatório na ferramenta que cria um objetivo, então qualquer pedido de "crie uma meta para o departamento de Suporte" morria dentro da própria ferramenta, com um erro de validação, antes de qualquer chamada ao servidor. A metade da funcionalidade que a tela já tinha simplesmente não existia do lado do agente.

A correção trocou três coisas ao mesmo tempo. Primeiro, owner_ids deixou de ser obrigatório — um resultado-chave dentro de um objetivo da empresa inteira não tem uma pessoa para nomear, e exigir uma tornava esses KRs impossíveis de criar por ali. Segundo, chegou um list_departments: antes, a única forma de descobrir o id de um departamento pelo agente era listar pessoas e ler o campo de departamento de alguém que já estivesse nele — o que deixava cego exatamente o departamento novo, sem ninguém ainda. Terceiro, o card de pré-visualização (o mesmo card de aprovação da tela) ganhou os mesmos campos que a interface já mostrava — antes, um objetivo de empresa inteira criado pela Roberta aparecia no card sem nenhum dono listado, porque o card só sabia ler uma lista de nomes.

Quem tenta os dois escopos de grupo sem ser administrador de metas recebe a mesma recusa que a tela dá: um 403 com o código FORBIDDEN e a mensagem de que só administradores podem atribuir um departamento ou a empresa como dono. O post sobre o agente de IA já registrava essa regra em geral — "não escreve sem aprovação" é arquitetura, não instrução de texto — e ela continua valendo aqui sem exceção: a Roberta não contorna a permissão de ninguém, só herda a que o pedido já tinha.

O número que se contradizia sozinho

O post da semana passada sobre KPI e OKR listou, como limite declarado do produto, que "o percentual de progresso não é uma conta só" e que uma métrica de saúde do tipo que deveria cair podia mostrar um número diferente na tela inicial e na aba de métricas. Vale ser direto sobre o que o ajuste de 8 de setembro fez e o que não fez: ele corrigiu um bug real e diferente, dentro da própria tela de OKR — e não tocou na tela inicial. A divergência que o post da semana passada registrou continua exatamente como estava.

O bug que foi corrigido é de ausência de medição. Uma métrica de saúde do tipo decreasing (o número deveria cair) sem nenhuma medição registrada tinha o valor atual tratado como zero antes de a fórmula rodar — e para esse tipo, "atual = 0" é o melhor resultado possível, então a conta devolvia 200% de progresso para uma métrica que, na prática, ainda não tinha um único dado. Nenhuma medição não é a mesma coisa que uma medição de zero, e a fórmula antiga, dentro da aba de métricas da tela de OKR, não fazia essa distinção.

O segundo ajuste é de exibição: o cartão de progresso arredondava o número mostrado para 100% sempre que o resultado real passava disso, junto com o desenho do anel — então um objetivo que tinha, de fato, superado a meta em 40% aparecia igual a um que só bateu 100% em cheio. Hoje só o desenho para em 100%; o número ao lado mostra o valor real. E o produto diz isto, literalmente, na dica que acompanha o número:

"Resultados acima de 100% entram integralmente na média. Apenas o desenho do círculo ou da barra para em 100%. O percentual final é arredondado para um número inteiro."

"Média simples dos objetivos exibidos: cada objetivo conta uma vez, independentemente da quantidade de responsáveis."

Essa segunda frase descreve uma regra que já valia antes de 8 de setembro: agrupar por departamento já contava objetivos, não pessoas, desde 25 de agosto — o mesmo dia em que o dono de grupo chegou à tela e um objetivo da empresa inteira, contado por engano uma vez para cada pessoa dele em vez de uma vez só, deixou de inflar a média do departamento em que aparecia. O que 8 de setembro fez foi dar a essa conta uma dica explícita na tela e movê-la para um arquivo compartilhado, além de trocar o layout das métricas de saúde para cartões no mesmo formato dos de OKR — apresentação, não fórmula nova.

Por que isso importa além da conta certa

Um objetivo sem dono nomeado tende a ser tratado, na prática, como um objetivo de ninguém — e o inverso, "todo mundo é responsável", costuma significar a mesma coisa com um verniz mais bonito. É esse o problema estrutural que um dono de grupo, resolvido a membros de verdade em vez de deixado em branco, tenta fechar. A robustez desse ponto não vem de uma pesquisa de 2026: o meta-estudo Gallup Q12, 11ª edição (736 estudos, 347 organizações, 53 setores, mais de 3,3 milhões de respondentes em 90 países, publicado em maio de 2024) segue sendo a maior evidência disponível de que clareza de expectativa — item 1 do próprio questionário Gallup — anda junto com desempenho de equipe; o instrumento é antigo, a escala é que garante o peso. Usamos aqui pela robustez da amostra, não porque seja de 2026 ou do Brasil.

Já registramos, no guia de implementação de OKR, o número da Betterworks State of Performance Enablement 2026 (n = 2.387) sobre o descompasso entre o quanto a liderança diz confiar nos instrumentos de meta e o quanto quem executa concorda — reaproveitado aqui só como contexto, não reconferido nesta rodada.

Um objetivo sem uma pessoa para nomear não precisa continuar sem dono, e um número sem medição não devia sair do zero sozinho — as duas frases descrevem o mesmo tipo de defeito, só que uma é de modelagem de dados e a outra é de aritmética. O que uniu as três datas deste post é que nenhuma delas resolveu a outra: a tela ganhou o dono de grupo em agosto e passou duas semanas com um agente que não entendia o conceito; o agente aprendeu em 1º de setembro e passou uma semana repetindo um número que a própria tela contradizia em outro lugar. Só ficou completo quando as três peças — o campo no banco, o agente que escreve nele e a conta que resume o resultado — contaram a mesma história. É o tipo de acabamento que não aparece em nenhuma tela sozinha, e por isso vale registrar aqui, com a data de cada parte.