O Método Diagnóstico

Todo o projeto de TI empresarial começa com um diagnóstico. A maioria produz um documento e depois avança como se o documento fosse o diagnóstico. Não é. O documento é um registo da atenção prestada num dado momento. O diagnóstico é a própria atenção — sustentada até o problema ser resolvido ou explicitamente aceite como não resolvido. Todo o resto é papelada.

A confusão não é académica. É o mecanismo de fundo pelo qual as transformações consomem orçamentos sem alterar as linhas de base operacionais, pelo qual as migrações prometem substituição e entregam coexistência, pelo qual os ciclos de auditoria produzem volumes de papel enquanto o mesmo risco reaparece a cada trimestre. Em cada caso, confundiu-se um artefacto com uma prática. O artefacto fica arquivado. A prática nunca esteve presente.

O diagnóstico verdadeiro é mais antigo do que a TI empresarial. É a disciplina praticada em qualquer campo onde os riscos são altos e a confirmação importa — a medicina, a engenharia civil, a segurança aeronáutica, a investigação de acidentes. Domínios diferentes, estrutura idêntica. O que a TI empresarial fez, gradualmente e sem que ninguém lhe desse nome, foi substituir cada gesto dessa disciplina por um entregável. O método diagnóstico sobreviveu sob outros nomes; a própria prática recuou.

O que se segue é a disciplina, nomeada em sete princípios. Não são inovações. São fundamentos recuperados. Cada um pode ser testado. Cada um pode ser saltado. Cada um, quando saltado, deixa o mesmo rasto: um documento arquivado onde devia estar a compreensão.

1. O diagnóstico é contínuo, não episódico.

Um diagnóstico corre desde o surgimento do problema até à resolução. Não congela num arranque e reaparece na revisão trimestral seguinte. Uma disciplina diagnóstica que termina antes de o problema terminar deixou de diagnosticar.

A fase de descoberta de um projeto de TI empresarial não é um diagnóstico. É o início de um. Quando a fase de descoberta produz um relatório e o projeto segue em frente, o que ficou embutido no projeto é o pressuposto de que o diagnóstico está agora completo. Não está completo. Só ficará completo quando o próprio problema for fechado — e o problema fecha por uma de três portas: resolvido, explicitamente não resolvido com as razões documentadas, ou explicitamente adiado com as consequências conhecidas. Até uma dessas portas fechar, o diagnóstico continua em curso, independentemente do que tenha sido arquivado.

Quem já viu o mesmo problema operacional surgir em três revisões trimestrais sucessivas viu um diagnóstico que terminou cedo demais. A descoberta foi arquivada. A compreensão não foi mantida. Quando o problema surge uma quarta vez, a equipa mudou, o relatório está por ler, e o problema é tratado como novo. Nunca foi novo. Foi sempre o mesmo problema, à espera do diagnóstico que devia ter sido sustentado.

2. Ouça antes de analisar.

O primeiro gesto de um diagnóstico é atenção não estruturada ao sistema em movimento. Não entrevistas estruturadas em torno de uma hipótese. Não workshops delimitados a um entregável. Atenção ao que o sistema realmente faz, nas condições em que realmente falha, com as pessoas que realmente o operam.

A maioria das falhas de diagnóstico são falhas de escuta, não falhas de análise. Os dados já lá estavam. Os operadores tinham-nos reportado. Os logs tinham-nos registado. O padrão estava visível havia meses. O que faltava era alguém disposto a ouvir o sistema antes de decidir o que o sistema era.

Uma análise que começa antes de a escuta estar completa confirmará sempre as crenças prévias do analista. Não há método pelo qual o questionamento estruturado recupere o que a atenção não estruturada teria feito emergir primeiro. A ordem importa, e não se inverte sem custo. O custo é registado mais tarde como derrapagem de âmbito, requisitos em falta, ou — o mais frequente — uma reconstrução dezoito meses após o go-live original, quando o sistema finalmente revela o que sempre fez e ninguém tinha parado para reparar.

3. Verificações elementares antes das sofisticadas.

O eletricista verifica a lâmpada. O marinheiro bate no casco. O piloto inspeciona a fuselagem antes de recorrer à aviónica. Recorrer à revisão de arquitetura antes de se ter verificado a alimentação elétrica é negligência profissional em qualquer outra disciplina; na TI empresarial é tratado como senioridade.

A sofisticação chega no momento errado por uma razão. As verificações elementares são incómodas porque implicam alguém — normalmente alguém presente na sala — por não as ter feito já. A revisão de arquitetura é confortável porque implica toda a gente e ninguém. A sala recorre ao instrumento confortável. O sistema continua a falhar pela razão elementar.

Um diagnóstico que abre com sofisticação é quase sempre evitamento — não do problema, mas da conversa sobre por que motivo a verificação elementar nunca foi feita. A disciplina exige que a verificação elementar venha primeiro, independentemente da negligência que revele. Sem essa exigência, a sofisticação torna-se um abrigo permanente contra a responsabilização.

4. Teste o problema enunciado.

O problema-como-enunciado raramente é o problema-como-vivido. O primeiro gesto técnico de um diagnóstico é verificar o enquadramento antes de o aceitar.

Um pedido para «modernizar a plataforma legada» é um problema enunciado. O problema vivido pode ser que a plataforma legada é o único sistema que a equipa de operações compreende por inteiro, e que os modos de falha de qualquer substituto moderno são desconhecidos das pessoas que serão chamadas às 3 da manhã quando aquilo rebentar. O problema enunciado e o problema vivido não são o mesmo problema. Resolver o problema enunciado deixa o problema vivido no lugar, muitas vezes de forma pior. A equipa que compreendia os modos de falha é agora chamada para um sistema cujos modos de falha ninguém ainda compreende.

O diagnóstico trata o enquadramento inicial como uma hipótese, não como um mandato. É examinado, testado contra o comportamento real do sistema, e ou confirmado, ou estreitado, ou substituído. Saltar esse passo entrega soluções para problemas que nunca foram o problema real. A falha original persiste, vestida de vocabulário novo, e o projeto é dado por concluído na mesma.

5. Documentação não é compreensão.

Um documento sobre um sistema e uma compreensão de um sistema são coisas diferentes. A disciplina reconhece a diferença e recusa substituir uma pela outra.

A maioria dos artefactos de arquitetura empresarial ratifica decisões; não captura diagnóstico. O diagrama mostra o que foi aprovado. O runbook mostra o que foi prometido. A base de dados de gestão de configurações (CMDB) mostra o que foi inventariado. Nenhum desses artefactos responde à pergunta diagnóstica: o que é que este sistema realmente faz sob carga, no limite, nos modos de falha que ainda não ocorreram mas são estruturalmente possíveis.

Um teste prático separa o documento da compreensão. Faça ao documento uma pergunta que só o sistema pode responder — uma pergunta sobre o comportamento na periferia, não no centro. Se o documento fica em silêncio, ou é genérico, ou é contrariado pelos logs reais do sistema, então o documento era um registo de atenção prestada uma vez. A compreensão nunca foi escrita porque nunca esteve presente. O que ficou arquivado foi papelada. O que era preciso era uma pessoa que tivesse mantido contacto com o sistema o tempo suficiente para saber.

6. Quem diagnostica tem nome e responde por isso.

O diagnóstico prende-se a uma pessoa, ou a uma equipa pequena, que pode ser questionada seis meses depois. Diagnóstico anónimo não é diagnóstico. «O sistema diz...» não é diagnóstico. «O fornecedor confirmou...» não é diagnóstico. O diagnóstico é assumido por alguém que pode estar errado — e que, por isso, também pode estar certo.

A disciplina da medicina aprendeu isto há séculos. Um diagnóstico é assinado. O médico que assina carrega as consequências se estiver errado. A assinatura não é cerimonial; é o mecanismo pelo qual o diagnóstico se torna responsável perante o doente, perante os pares e perante a área. Sem esse mecanismo, o que resta é opinião, e a opinião não melhora com o tempo porque ninguém é dono dos seus erros.

A TI empresarial substituiu isto por anonimato. Um statement of work é assinado pelo departamento de compras e pela entidade comercial de um fornecedor. Um relatório de descoberta é da autoria da «equipa de consultoria». Um registo de decisão de arquitetura nomeia a reunião, não a pessoa que concluiu. Cada uma destas construções é uma forma sofisticada de garantir que nenhum indivíduo pode ser responsabilizado se o diagnóstico estiver errado. O que significa que não pode ser melhorado. O que significa que o mesmo diagnóstico errado é entregue, por equipas diferentes, a clientes diferentes, ano após ano — porque ninguém alguma vez pagou o preço de ser a pessoa que se enganou.

7. O diagnóstico tem uma condição de saída definida.

A disciplina termina quando uma de três portas fecha: o problema é resolvido; o problema é explicitamente aceite como não resolvido, com as razões registadas e as consequências conhecidas; o problema é explicitamente adiado com uma data definida para revisitar. Tudo o resto é papelada sem fim.

A maioria dos diagnósticos empresariais termina por uma quarta porta, que a disciplina não reconhece: o orçamento esgota-se, o contrato encerra, a consultora sai de cena, o patrocinador executivo muda de funções. O problema não é resolvido. Não é explicitamente aceite. Não é adiado. Simplesmente deixa de ser olhado. Os artefactos são arquivados e o diagnóstico é tratado como completo porque o contrato está completo. Não são o mesmo acontecimento.

Uma disciplina que sai pela quarta porta não concluiu um diagnóstico; abandonou-o. O problema há de reaparecer. À equipa seguinte dir-se-á que é um problema novo. Fará uma nova descoberta, produzirá um novo relatório, e sairá pela mesma quarta porta. O ciclo não é uma falha de nenhum projeto em particular. É a consequência estrutural de deixar o contrato definir a condição de saída em vez do próprio problema.

As Substituições

Estes sete princípios não são inovações. Eram os fundamentos de qualquer prática diagnóstica rigorosa — médica, mecânica, náutica, investigativa — muito antes de a TI empresarial existir. O que a TI empresarial fez, lentamente e sem que ninguém lhe desse nome, foi substituir cada um deles por um entregável.

Cada substituição foi pequena. Cada uma parecia progresso. Nenhuma foi chamada pelo que era: a substituição silenciosa de uma prática pela sua papelada.

A DiagnosticMind existe porque a disciplina ainda funciona onde quer que seja restaurada. Não como nostalgia de uma era antiga. Não como crítica a qualquer profissional em particular. Como um método que pode ser nomeado, ensinado e responsabilizado — recuperado de uma profissão que o extraviou sob vinte anos de entregáveis.

A disciplina começa quando alguém está disposto a chamar a papelada pelo seu nome e a prestar atenção ao sistema em vez disso.