Paulo Ramada

Comecei como operador de mainframe na SIBS — a processadora interbancária portuguesa — em 1992. COBOL, CICS, DB2. Se eu cometesse um erro, as consequências não eram abstractas. Mediam-se em filas nas caixas dos supermercados, em terminais que escureciam nos restaurantes, em transacções a falhar às três da manhã.

Foi a primeira lição, e a que enquadrou tudo o resto: o IT empresarial não é teórico. É operacional. O sistema ou funciona para a pessoa que está a passar o cartão, ou não funciona. Documentação, governance, escolha de framework — tudo isso vem a jusante deste único teste.

Durante anos, estive de prevenção numa organização onde cinco minutos de indisponibilidade davam telejornal. Vinte e cinco incidentes por semana, todas as semanas, entre a meia-noite e a madrugada. Tolerância a falha: quase zero. Tempo para discussão: zero. Ou se resolvia agora, ou se ligava a alguém que conseguisse.

Anos assim mudam a forma como uma pessoa lê os sistemas. Ensinam-lhe a diferença entre um sistema que parece resiliente num slide e um sistema que de facto se aguenta às três da manhã, quando nada devia partir e algo acaba de partir. Quase tudo o que escrevo hoje — runbooks como ilusão, monitorização sem contexto, a distância entre o que os executivos reportam e o que as equipas operacionais observam — foi aprendido nessas horas, e não em qualquer framework.

Uso Control-M há mais de vinte anos. Auditei programas de continuidade contra a ISO 22301 em sectores regulados. Vi os mesmos erros de arquitectura repetirem-se em organizações que pagaram milhões para os evitar — fornecedores diferentes, acrónimos diferentes, consultores diferentes, mesmos erros.

O que três décadas dentro de IT empresarial ensinam é incómodo: o sector confundiu movimento com progresso. Frameworks rodam de dezoito em dezoito meses. Ferramentas proliferam. Títulos profissionais inflacionam. Mas os sistemas que de facto fazem o mundo funcionar — pagamentos, energia, transportes, liquidação financeira — são os mesmos que o faziam funcionar há vinte anos, ligeiramente modernizados nas extremidades e cada vez mais frágeis no centro. A profundidade tornou-se contracultural. É também a única coisa que separa profissionais de performers.

Durante a maior parte da minha carreira, vi competência ser silenciosamente subordinada à política. Os engenheiros que viam o problema com clareza eram os que tinham menos hipóteses de ser ouvidos, porque ver com clareza era inconveniente. O custo da honestidade diagnóstica continuou a subir. O custo de encenar correcção continuou a baixar. Este padrão acumula-se, organização a organização, até que eventualmente chegam crises que surpreendem todos excepto as pessoas a quem não foi permitido falar.

A DiagnosticMind existe porque a alternativa é entregar o terreno aos que criaram a fachada. É uma plataforma que trata o diagnóstico como a disciplina que ele é — não como uma fase de um projecto, não como um entregável, não como postura de marketing. Honestamente feito. Independente de incentivos de fornecedor. Construído por alguém que viu o suficiente para deixar de fingir, e que constrói mesmo assim, porque fingir não resolve nada.

Tudo nesta plataforma funciona sozinho — os assessments, os scorecards, a newsletter. Por trás existe uma prática, e a prática aceita compromissos: uma leitura diagnóstica conduzida por um humano, sobre uma arquitectura operacional, um programa de continuidade ou um parque de automação, com a mesma independência de tudo o que aqui se escreve.

Vale a pena ser preciso sobre o que isso não é. Não é implementação. Não é consultoria moldada para justificar uma compra já feita. Um diagnóstico aqui pode concluir que nada deve mudar — e quando essa é a conclusão honesta, é entregue como tal, e o compromisso termina aí. Não é uma limitação. É a razão pela qual o diagnóstico merece confiança.

Se é disso que precisa: contact@diagnosticmind.eu — descreva o sistema e a dúvida. Sem formulários. Sem chamadas até uma ser útil.