Como este tema funciona na sua empresa
Demanda não-planejada é 70-80% do trabalho. Gestor recebe pedidos diretos do sócio, cliente liga pedindo ajuda, servidor cai. Não há "roadmap" formal. Estratégia aqui é criar rotina básica (ticket informal, SLA mínimo) e documentar recorrências para planejar depois. Objetivo não é eliminar, mas gerir visível.
Demanda não-planejada rouba 40-50% da capacidade de roadmap. TI tem processo de priorização, mas frequentemente é quebrado por "urgências" de diretores. Necessário: sistema de submissão (ITSM), comitê de urgências, e comunicação clara de que 25-35% da capacidade é buffer para não-planejado. Sem isso, roadmap é apenas ficção.
Demanda não-planejada (break-fix, feature requests urgentes) consome 25-35% da capacidade. Existe SLA documentado: crítico = resposta em 4h, alto = 1 dia, médio = 3 dias. Processo formal de intake: service request entra em fila, avalia urgência, aloca recurso. Desafio é proteger projetos estratégicos de "urgências" que não são verdadeiras crises.
Demanda não-planejada de TI é solicitação de trabalho que chega sem aviso prévio e interrompe o roadmap de projetos agendados. Inclui correções urgentes (incidentes), pedidos de mudança rápida, ajustes operacionais e feature requests apresentadas como "emergência". Gerenciar demanda não-planejada significa reduzi-la onde possível e alocá-la de forma previsível.
Por que demanda não-planejada é o maior inimigo do roadmap
Projeto que deveria sair em 3 meses atrasa 1 mês porque TI foi deslocado para "urgências". Essa pessoa volta para o projeto, precisa relembrar contexto (ramp-up), código estava no meio de refatoração. Context-switching custa mais tempo que o próprio trabalho urgente.
Pesquisas mostram que um profissional interrompido a cada 15-30 minutos leva 45 minutos para recuperar foco completo no que estava fazendo. Múltiplas interrupções reduzem produtividade em 40-60%[1]. Logo, "demanda rápida" que leva 2 horas de interrupção real custa 4-5 horas de produtividade perdida.
Reduzindo demanda não-planejada: estratégias preventivas
Estratégia 1: Comunique proativamente sobre status operacional
Muita demanda "urgente" vem porque stakeholder não sabe que algo está quebrado. Se TI comunica proativamente — "email está lento, estamos investigando" — pessoa não precisa ligar pedindo ajuda. Reduz 10-15% da demanda reactiva.
Mecanismos: status page (website que mostra saúde de sistemas), notificações automáticas (email quando sistema sai), dashboard visível ao negócio.
Estratégia 2: Implementar autoatendimento para problemas comuns
Se usuário pode resetar própria senha, não precisa ligar. Se pode conferir status de seu dispositivo em portal, não precisa de chamado. Autoatendimento reduz 20-30% da demanda operacional.
Mecanismos: portal de self-service (Jira Service Desk, ServiceNow, Zendesk), FAQs, vídeos de como fazer.
Estratégia 3: Estruturar processo de submissão formal
Sem processo, demanda chega por WhatsApp, email, conversa no corredor — sem prioridade. Com processo (ticket formal, formulário), tudo entra em fila, avalia urgência com critério, aloca com transparência.
Impacto: não reduz volume, mas organiza. Stakeholder sabe sua demanda vai ser avaliada, não desaparece na multidão.
Estratégia 4: Definir critério de urgência comum
Sem critério, tudo é urgente. Com critério claro (compartilhado com negócio), "urgência" é mais objetiva:
- Crítico: Negócio parou (sistema produção cai). Resposta: imediata, SLA < 1h.
- Alto: Operação afetada (100+ usuários não conseguem trabalhar, mas alternativa existe). Resposta: < 4h.
- Médio: Incômodo significativo (feature não funciona, mas não é crítico). Resposta: < 1 dia.
- Baixo: Melhoria desejável, sem impacto operacional. Resposta: na próxima fila de planejamento.
Muitas "urgências" reclamadas como críticas são na verdade médio ou baixo. Critério claro permite "desescalar" sem parecer que TI está ignorando.
Alocando capacidade para demanda não-planejada
Em vez de tentar eliminar demanda não-planejada (impossível), aloque previsivamente:
- PME: 100% reactivo (não há roadmap formal). Gestão = criar rotina: priorizar por impacto, documentar padrões, planejar depois.
- Média: 40-60% reactivo, 40-60% de roadmap. Significa: 2 pessoas no time que toca roadmap, 1 pessoa (50%) em não-planejado (operações, incidentes). Comunicar ao negócio: "30% da capacidade é buffer para não-planejado".
- Grande: 25-35% reactivo, 65-75% roadmap. Significa: times separados (operações vs. projetos) ou pessoas que rodam ambos com alocação clara.
Sem essa declaração, negócio espera 100% de roadmap, e quando atrasa (porque demanda não-planejada comeu 40%), TI parece incapaz.
Gestão de demanda não-planejada por porte de empresa
Sistema informal: pedidos chegam (WhatsApp, email, telefone), gestor avalia urgência (rápido, mental), aloca. Documentação é planilha de incidentes. Sem SLA formal, resposta é "quando conseguir". Foco: reduzir via autoatendimento, comunicar antecipadamente problemas conhecidos.
ITSM básico (Jira Service Desk ou similar): requisição chega em sistema, entra em fila, prioridade é avaliada, SLA é definido. Relatório mensal: quantas requisições, tempo médio de resolução, principais causas. Foco: comunicar que 30% de capacidade é buffer, planejar roadmap com essa restrição.
ITSM full (ServiceNow, BMC): SLA por severidade, escalação automática, assignment por skillset. NOC (Network Operations Center) 24/7 para crítico/alto. Análise contínua: quantos incidentes por tipo, qual é taxa de resolução primeira vez. Foco: reduzir incidentes via automação (alertas evitam ação manual).
Diferenciando demanda urgente legítima de pseudo-urgência
Gestor de TI enfrenta pressão: como dizer "não é urgente" para diretor que diz que é? Critério objetivo ajuda:
| Situação | É urgente? | Por quê |
|---|---|---|
| Sistema produção cai (100 usuários afetados, operação paralisa) | SIM - Crítico | Impacto negócio é imediato, mensurável |
| Diretor quer report novo (que ninguém pediu) "até amanhã" | NÃO - Baixo | Sem usuários esperando, pode esperar próximo ciclo |
| Cliente grande reclama que feature não funciona (mas tem workaround) | MÉDIO | Impacto é real mas não crítico; workaround existe |
| 50 usuários não conseguem acessar sistema (erro de conectividade) | SIM - Alto | Operação afetada substancialmente, sem workaround |
| Sócio gosta de ter UI nova "logo" | NÃO - Desejo, não urgência | Impacto é futuro (quando feature é usada), não presente |
Como comunicar "não" sem soar que TI está recusando
Desafio: priorizar roadmap significa dizer "não" a algumas coisas. Comunicação é crítica:
- Não use "não". Use "vamos avaliar" ou "essa demanda entra em análise para próximo ciclo".
- Ofereça alternativa. "Não podemos fazer em 1 dia, mas podemos fazer em 2 semanas" ou "esse projeto é crítico, podemos postergar feature X para acomodar?"
- Mostre a fila. "Temos 5 demandas críticas antes desse. Você quer que deslocar recursos de uma delas, ou prefere esperar?"
- Documenta. "Demanda Y foi rejeitada pela decisão de manter foco em projeto Z (estratégico). Será reavaliada em [data]."
Reduzindo incidentes: raiz das demandas não-planejadas
Grande parte de demanda "urgente" é incidente — algo quebrou. Reduza incidentes, reduz demanda:
- Monitoramento proativo: Alertas detectam falha antes de usuário notar. Tempo de resposta: minutos vs. horas.
- Automação: Sistema auto-remedia (reinicia serviço, limpa log cheio). Sem intervenção manual.
- Teste de mudança: Código novo tem bug? Detecte em teste, não em produção. Reduz incidente post-deploy.
- Análise de raiz (RCA): Incidente ocorre ? analisa por quê ? previne futuro. Banco de dados cai 3 vezes em 6 meses? RCA revela que storage estava cheio. Fix = automação de limpeza.
Sinais de que demanda não-planejada está descontrolada
Se você se reconhece em três ou mais cenários abaixo, demanda não-planejada está derrubando roadmap.
- Não há "roadmap formal" — apenas lista de projetos que nunca sai porque demandas as deslocam constantemente
- Mesmos incidentes ocorrem repetidamente (servidor X cai todo mês) sem ação preventiva
- Equipe trabalha frequentemente fora de horário (noite, fim de semana) para cobrir demandas urgentes
- Cronograma de projeto é revisado toda semana porque prioridades mudam
- Não existe processo formal de submissão de demandas — chegam por WhatsApp, email, conversa
- Não há critério claro para "urgência" — tudo que diretor diz é urgente vira prioritário
- Equipe reclama de sobrecarga porque está tocando múltiplos projetos simultâneos (context-switching)
Caminhos para reduzir e gerenciar demanda não-planejada
Gestão de demanda pode ser estruturada internamente ou com apoio de consultoria para design de processo.
Viável quando gestor de TI tem autonomia para estruturar processo e consegue comunicação clara com negócio.
- Perfil necessário: gestor de TI que entende operação e consegue comunicar valor de planejamento
- Tempo estimado: 4-8 semanas para desenhar processo, implementar sistema (ITSM), comunicar, calibrar
- Faz sentido quando: demanda é conhecida e estruturável; objetivo é organizar, não revolucionar
- Risco principal: sem pressão externa, processo pode não ser respeitado (voltam a usar WhatsApp)
Indicado quando demanda está caótica ou quando TI precisa de aliado para comunicar mudanças ao negócio.
- Tipo de fornecedor: Consultoria de processos de TI / ITSM, assessoria em governance TI
- Vantagem: design de processo testado, facilitação com negócio, treinamento de equipe, legitimidade externa
- Faz sentido quando: pressão de roadmap é crônica ou negócio desconfia de "TI não entrega"
- Resultado típico: em 6-12 semanas, processo documentado, ITSM implementado, negócio alinhado, primeira rodada bem-sucedida
Precisa de apoio para gerenciar demanda não-planejada?
Se demanda não-planejada está derrubando seu roadmap, o oHub conecta você gratuitamente com consultorias especializadas em processos de TI e gestão de demandas. Em menos de 3 minutos, descreva seu desafio e receba propostas personalizadas, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Como reduzir demandas não-planejadas em TI?
Estratégias: comunicação proativa (status page evita ligação), autoatendimento (usuário resolve próprio problema), critério de urgência claro (menos falsos "urgentes"), análise de raiz de incidentes (previne recorrência), monitoramento proativo (alerta detecta falha antes de usuário).
Por que TI recebe tantas solicitações inesperadas?
Falta de visibilidade (negócio não sabe se algo está quebrado), falta de processo formal (demanda chega por qualquer canal), não há autoatendimento (usuário não consegue resolver sozinho), critério de urgência não existe (tudo é urgente), problemas recorrem (mesma coisa quebra repetidamente).
Como proteger o roadmap de TI contra interrupções?
Aloque percentual de capacidade como buffer (25-35% para médias/grandes). Defina SLA por severidade (crítico = imediato, médio = próxima semana). Implemente processo formal (todas as demandas viram ticket, não WhatsApp). Comunique ao negócio: "30% da capacidade é reservada para não-planejado".
O que é "break-fix" e como gerenciar?
"Break-fix" é correção de algo quebrado (incidente). É demanda não-planejada por natureza. Gestão: monitoramento (detecta falha cedo), automação (auto-remedia), análise de raiz (previne recorrência), SLA claro (quanto tempo para responder?). Objetivo não é eliminar, mas reduzir e formalizar.
Como comunicar que TI não pode fazer tudo de imediato?
Use critério objetivo: "Avaliamos urgência conforme impacto (quantos usuários?) e tempo de resolução. Sua demanda é médio (entra em 1 semana), não crítico (que seria hoje). Se precisa antes, que demanda de prioridade alta você quer que deslocar?" Transparência reduz pressão.
Qual é o impacto de demandas não-planejadas no roadmap de TI?
Contexto-switching reduz produtividade em 40-60%. Project que deveria sair em 3 meses pode atrasar 1 mês. Além disso, equipe fica estressada e burnout aumenta. Impacto é real: empresas sem gestão clara de demanda entregam 40% menos que deveriam.