Quando o problema muda de forma enquanto você tenta resolvê-lo
Alguns desafios de T&D não têm enunciado fixo: cada tentativa de solução muda a própria compreensão do problema. A ideia vem do planejamento urbano, e a analogia com T&D é útil, mas imperfeita.
Todo projeto de T&D começa com um pedido de escopo fechado: qual é o problema, qual é o prazo, qual é o formato. Alguns problemas cooperam com esse pedido. Outros não. A área pede uma trilha sobre gestão de tempo, descobre no meio do diagnóstico que o problema é sobrecarga de reuniões, redesenha o escopo, e no meio da nova versão descobre que a sobrecarga de reuniões é sintoma de uma estrutura de decisão mal desenhada. O problema não estava mal descrito no início. Ele muda de forma conforme se tenta resolvê-lo, e isso incomoda quem precisa aprovar um orçamento fechado.
Um vocabulário emprestado do planejamento urbano
Horst Rittel e Melvin Webber, trabalhando com problemas de planejamento urbano e de política pública, propuseram uma distinção entre dois tipos de problema. De um lado, problemas que os autores chamam de bem estruturados: têm enunciado estável, critério claro do que conta como solução e um ponto em que se pode dizer “resolvido”. De outro, problemas que eles descrevem como mal estruturados, ou perversos no sentido de resistentes a esse tratamento: não têm formulação definitiva, porque entender o problema e propor uma solução são a mesma atividade, não duas etapas em sequência. Cada tentativa de solução revela algo novo sobre o problema, o que obriga a reformular o próprio enunciado. Não existe um critério objetivo de parada, apenas versões melhores ou piores de lidar com a situação, e cada problema desse tipo carrega particularidades que impedem tratá-lo como cópia de um problema anterior.
O exemplo dos autores era redesenhar um bairro ou desenhar uma política pública de habitação, contextos em que múltiplos grupos com interesses legítimos e conflitantes disputam o que conta como problema e o que conta como solução, sem que exista uma autoridade única capaz de arbitrar isso de forma definitiva.
A analogia com T&D, e onde ela para de valer
Alguns desafios de desempenho em T&D se comportam de um jeito parecido. A área pede uma coisa, o diagnóstico revela outra, e a nova formulação do problema só aparece depois que a primeira tentativa de solução expõe o que estava por trás dela. Isso é real, e vale nomear: nem todo problema de T&D chega com enunciado estável, e insistir em fechar o escopo antes de entender a situação produz solução para o problema errado.
Dito isso, a analogia com o planejamento urbano é útil e imperfeita, e a parte imperfeita importa mais do que costuma ser admitido. Um problema de política pública urbana é, por definição dos próprios autores, disputado por natureza: não existe instância que decida com autoridade final o que conta como solução, porque grupos diferentes legitimamente querem coisas diferentes para a cidade. Um problema de desempenho dentro de uma empresa quase sempre tem uma autoridade capaz de validar o que conta como resolvido, mesmo que leve tempo para chegar lá. Não é uma disputa política sem fim, é uma investigação que ainda não terminou. Tratar um projeto de T&D como se fosse tão irresolúvel quanto uma política de uso do solo é emprestar da analogia uma característica que não se aplica, e usá-la assim tende a justificar indefinição em vez de descrevê-la com precisão.
A aplicação correta da ideia de Rittel e Webber a T&D é mais modesta: alguns problemas de desempenho têm enunciado instável durante a fase de investigação, não para sempre. A instabilidade é uma fase, não uma condição permanente do problema.
A crítica que precisa ser enfrentada de frente
O rótulo de “problema mal estruturado” tem um uso torto, e ele é comum o suficiente para merecer nome: usar a linguagem da complexidade para justificar a ausência de rigor. “Esse problema é complexo demais para diagnosticar” vira desculpa para pular direto da queixa inicial para a solução, sem nunca de fato investigar o que está por trás da queixa. Isso não é reconhecer um problema instável, é evitar o trabalho de estabilizá-lo o quanto der.
A diferença entre as duas situações está no comportamento de quem conduz o projeto. Reconhecer legitimamente um problema instável significa investigar ativamente, testar hipóteses, revisar o enunciado à luz do que cada rodada de investigação revela, e documentar por que a versão nova do problema é melhor que a anterior. Usar o rótulo como desculpa significa não investigar nada, manter o enunciado original vago o bastante para nunca ser contrariado por evidência, e tratar qualquer questionamento como falta de compreensão da complexidade do tema. O primeiro caso avança em espiral, ficando mais preciso a cada volta. O segundo caso gira no lugar, e a vagueza é a própria função do rótulo ali, não um efeito colateral.
Quem está do lado de fora de um projeto assim consegue distinguir um do outro perguntando uma coisa simples: o que mudou na formulação do problema desde a última reunião, e por quê. Se a resposta é um enunciado mais específico e uma razão concreta para a mudança, o problema está sendo trabalhado. Se a resposta é o mesmo enunciado vago de três meses atrás, o rótulo virou desculpa.
O que fazer quando o enunciado ainda está se movendo
Um problema com enunciado instável não pede menos disciplina, pede uma disciplina diferente. Em vez de fechar escopo e orçamento antes de entender a situação, o projeto trabalha em ciclos curtos: uma hipótese sobre o problema, uma investigação pequena o suficiente para testá-la rápido, e uma decisão explícita sobre manter, ajustar ou substituir o enunciado antes de seguir. É o raciocínio que sustenta a fase de Conceito do método CCPS, que existe justamente para não deixar a pergunta de partida ser assumida como resolvida antes de ter sido investigada.
Isso muda a forma como a área se compromete com prazo. Em vez de prometer entrega de conteúdo em data fixa desde o primeiro dia, vale prometer uma data para a próxima revisão do enunciado do problema, com critério explícito do que faria a equipe mudar de direção. É desconfortável para quem está acostumado a aprovar escopo fechado, mas é mais honesto do que fechar um escopo em cima de um enunciado que ainda vai mudar de qualquer forma.
O que fazer na segunda-feira
Antes de aprovar o próximo projeto que chegou com queixa vaga, vale perguntar se o enunciado atual é mesmo a versão final do problema ou apenas a primeira leitura dele. Se for a primeira leitura, não adianta fingir precisão que ainda não existe: melhor estruturar o início do projeto como investigação, com pontos definidos de revisão do enunciado, do que fechar escopo sobre uma base que ainda vai se mover. Testar se a formulação atual do problema já é sólida o suficiente para sustentar uma decisão de solução é o que um diagnóstico de causa faz, e é o passo que precede qualquer proposta.