Minha empresa é pequena. OKR não é coisa de multinacional?

Ao contrário: quanto menor o time, mais caro sai cada pessoa remando pro lado errado. O Orzon foi desenhado pra PME, começa simples e cresce junto com a operação.

Já tentei OKR e o time abandonou.

Quase sempre o OKR morre porque depende de disciplina. O Orzon ataca isso com duas regras: um placar público de pontos por entrega e lembretes automáticos que cobram a atualização, com escalonamento pro líder quando ignoram.

Tem preço público, por quantidade de pessoas na equipe, em reais e com nota fiscal, publicado em orzon.app/planos. Há um plano Gratuito para até 5 pessoas, sem cartão; nos outros planos o valor sai com a demonstração, junto com a implantação.

Quanto tempo pra implantar?

Nada de projeto de meses. Em times menores, uma sessão de configuração resolve; em operações maiores, a implantação é assistida, área por área. Você sai da demonstração com esse desenho pronto.

Preciso abandonar minhas planilhas?

Não de uma vez. Seus indicadores podem continuar nascendo no Google Sheets ou em CSV, e o Orzon importa e mantém o número sincronizado. Se o dado já vive num sistema com API, ele busca sozinho, no intervalo que você escolher.

Tem, e ela trabalha dentro do produto, não ao lado dele. O Orz consulta 19 fontes da sua operação para responder o que você perguntar, e executa 28 tipos de ação quando você pede: criar objetivo, lançar o valor de um indicador, abrir projeto, iniciar um processo. Com duas travas que não se desligam: ele age com a sua permissão, então o que você não pode fazer ele não consegue; e nada é gravado sem você ver o cartão com cada campo e confirmar.

Dá pra tocar projeto com prazo e orçamento aqui dentro?

Dá. Cada projeto tem escopo, período planejado versus real, cronograma em Gantt com etapas, marcos e dependências, equipe com papéis, documentos, agenda própria e custos linha a linha, comparando orçado com realizado. E as tarefas do projeto são as mesmas do Kanban: ninguém aprende uma segunda ferramenta.

Meu time não é de tecnologia. Vão conseguir usar?

A plataforma é em português, feita pra quem não tem tempo de aprender ferramenta. Cada tela tem um botão "Como funciona" que abre o artigo daquela tela, e a central de ajuda tem quase 100 artigos com print de cada passo. Além disso, o próprio sistema puxa a pessoa: quem tem pendência recebe o lembrete e resolve por um assistente que mostra um item de cada vez.

Como funciona a demonstração?

De 30 a 40 minutos, por vídeo, direto com quem constrói o produto. Você conta como a operação roda hoje; a gente mostra o caminho dela dentro do Orzon. Sem script de vendedor, sem compromisso.

Isolados por empresa, com controle de acesso por papel: cada pessoa vê só o que deve. Tudo em conformidade com a LGPD. Detalhes na Política de Privacidade, no rodapé.

OKR de TI deve ser por squad ou pela área toda?

Por squad, quando os squads têm produtos ou domínios separados de verdade. O erro comum é criar um OKR da área e distribuir pedaços, o que produz squads perseguindo fatias sem sentido próprio. Um resultado-chave transversal, como lead time, pode ser da área inteira com dono único.

Como fica o trabalho não planejado?

Ele continua acontecendo e não precisa estar em OKR nenhum. O que ajuda é medir quanto da capacidade do time ele consome: se 70% do trimestre foi incidente e chamado, escrever quatro resultados-chave ambiciosos é ficção, e o número torna essa conversa possível sem virar acusação.

Vale usar as quatro métricas de entrega como OKR?

Elas são um excelente ponto de partida porque já são reconhecidas, comparáveis e difíceis de fraudar. O cuidado é o de sempre: escolher duas ou três, não as quatro, e garantir que a coleta seja automática. Métrica de engenharia que alguém preenche à mão para o check-in vira ficção em três semanas.

E se a TI é uma pessoa só?

Aí o OKR de TI provavelmente não deve existir separado. Faz mais sentido que a pessoa seja dona de um ou dois resultados-chave dentro do OKR da empresa, tipicamente de confiabilidade ou de custo. Criar um ciclo próprio para uma pessoa é cerimônia sem ganho.

OKR para TI: 29 exemplos que não viram lista de tarefa

Por Érico Rodrigues21 de setembro de 20266 min de leitura

O OKR de TI erra quando vira roadmap: "entregar o módulo de relatórios" é entrega, não resultado. O jeito certo é medir o efeito da entrega. "Reduzir o tempo médio de restabelecimento de 4h12 para 45 min até 30/06" é resultado. Abaixo estão 29 exemplos em confiabilidade, velocidade de entrega, segurança, custo e produto.

Por que o OKR de TI vira roadmap?

Porque a área tem uma lista de entregas concreta, negociada e visível, e ela parece um plano trimestral pronto. Transcrever essa lista para o formato de OKR é o caminho de menor resistência, e o resultado é um documento que diz o que já ia acontecer de qualquer jeito.

O problema prático aparece no fechamento. O time entregou os cinco itens e ninguém consegue dizer se ficou melhor. A pergunta que corrige, feita item a item na hora de escrever: quando isto estiver pronto, qual número muda?

Escrito como entrega	Escrito como resultado
Migrar para a nova arquitetura	Reduzir o tempo de resposta do p95 de 1,9s para 400ms
Implantar monitoramento	Reduzir de 62% para 15% os incidentes descobertos pelo cliente
Refatorar o módulo de cobrança	Reduzir de 9 para 2 os incidentes mensais originados naquele módulo
Automatizar os testes	Reduzir o lead time de commit a produção de 6 dias para 4 horas
Revisar permissões	Reduzir de 34 para 0 as contas com acesso além do necessário

A mesma intenção, escrita das duas formas

29 exemplos de OKR para TI

Confiabilidade e operação

Os números são ilustrativos. Troque cada um pelo seu, e desconfie especialmente dos de engenharia: um lead time de 6 dias pode ser excelente num contexto e péssimo em outro. O que vale copiar é a forma, com valor de partida, chegada e prazo.

Reduzir o tempo médio de restabelecimento de 4h12 para 45 minutos até 30/06
Reduzir de 62% para 15% os incidentes descobertos pelo cliente antes da equipe
Reduzir o tempo de resposta do p95 das rotas principais de 1,9s para 400ms
Reduzir de 14 para 4 os incidentes de severidade alta por trimestre
Elevar de 20% para 90% os serviços críticos com alerta automático configurado
Reduzir de 38% para 10% os chamados reabertos por não terem sido resolvidos na raiz
Elevar de 0 para 12 os postmortems escritos com ação corretiva concluída

Velocidade de entrega

Reduzir o lead time de commit até produção de 6 dias para 4 horas
Elevar a frequência de deploy de 2 por mês para 5 por semana
Reduzir a taxa de falha em mudança de 22% para 8%
Reduzir de 11 para 3 dias o tempo médio de revisão de código
Elevar de 34% para 80% a cobertura de testes automatizados nos fluxos que geram receita
Reduzir de 45 para 12 minutos o tempo de execução da esteira de integração

Segurança e controle de acesso

Reduzir de 34 para 0 as contas com acesso além do necessário para a função
Elevar de 12% para 100% os administradores com segundo fator ativo
Reduzir de 180 para 15 dias a idade média das vulnerabilidades críticas em aberto
Elevar de 0 para 100% os repositórios com verificação automática de segredo em commit
Reduzir de 89 para 20 as sessões ativas com mais de 90 dias sem uso
Elevar de 0 para 4 os testes de recuperação de backup executados e documentados

Custo e eficiência

Reduzir o custo de infraestrutura por cliente ativo de R$ 18,40 para R$ 11,00
Reduzir de 41% para 12% os recursos de nuvem provisionados e ociosos
Reduzir de R$ 9.200 para R$ 5.000 o gasto mensal com ferramentas duplicadas
Elevar de 30% para 85% os ambientes que desligam sozinhos fora do horário comercial

Produto e uso

Elevar de 18% para 40% os clientes que usam o recurso lançado no trimestre passado
Reduzir de 21 para 7 dias o tempo até o primeiro valor entregue ao cliente novo
Elevar de 2,4 para 4,1 os recursos usados por cliente no primeiro mês
Reduzir de 44% para 20% os cadastros que abandonam antes do segundo acesso
Elevar de 6,1 para 8,5 a nota de facilidade de uso na pesquisa trimestral
Reduzir de 31% para 10% os chamados de suporte causados por confusão de interface

Como medir dívida técnica sem virar lista de refatoração?

Dívida técnica é o caso mais difícil de escrever, porque o time sabe onde dói e o número não existe. A tentação é listar o que vai refatorar, o que devolve a área ao roadmap.

O caminho que funciona é medir o efeito da dívida, não a dívida. Ela sempre aparece em algum lugar: incidentes concentrados em um módulo, tempo de revisão alto naquela parte do código, lead time que dobra quando a mudança toca certo arquivo, tempo de integração longo. Escolha o efeito mais caro e escreva sobre ele.

Esse enquadramento tem um efeito colateral político útil: "reduzir de 9 para 2 os incidentes mensais do módulo de cobrança" é uma conversa que a diretoria entende e aprova, enquanto "refatorar o módulo de cobrança" costuma ser adiada em favor de funcionalidade nova, trimestre após trimestre.

Por que uptime raramente serve como resultado-chave?

Porque na maioria das empresas ele já está em 99,9% e não tem para onde ir. Um resultado-chave que começa quase batido não orienta decisão nenhuma durante treze semanas, e ainda dá ao time a sensação falsa de que a confiabilidade está resolvida.

O que costuma ter espaço de melhora é a experiência em volta da queda: quanto tempo até perceber, quanto até restabelecer, e quantas vezes o cliente avisou antes da equipe. Esses três se movem, e mover eles é o que o cliente sente.

Perguntas frequentes

OKR de TI deve ser por squad ou pela área toda?: Por squad, quando os squads têm produtos ou domínios separados de verdade. O erro comum é criar um OKR da área e distribuir pedaços, o que produz squads perseguindo fatias sem sentido próprio. Um resultado-chave transversal, como lead time, pode ser da área inteira com dono único.
Como fica o trabalho não planejado?: Ele continua acontecendo e não precisa estar em OKR nenhum. O que ajuda é medir quanto da capacidade do time ele consome: se 70% do trimestre foi incidente e chamado, escrever quatro resultados-chave ambiciosos é ficção, e o número torna essa conversa possível sem virar acusação.
Vale usar as quatro métricas de entrega como OKR?: Elas são um excelente ponto de partida porque já são reconhecidas, comparáveis e difíceis de fraudar. O cuidado é o de sempre: escolher duas ou três, não as quatro, e garantir que a coleta seja automática. Métrica de engenharia que alguém preenche à mão para o check-in vira ficção em três semanas.
E se a TI é uma pessoa só?: Aí o OKR de TI provavelmente não deve existir separado. Faz mais sentido que a pessoa seja dona de um ou dois resultados-chave dentro do OKR da empresa, tipicamente de confiabilidade ou de custo. Criar um ciclo próprio para uma pessoa é cerimônia sem ganho.

Continue por aqui

Exemplos prontos23 de setembro de 20266 min de leitura