No pasado, antes de que todo estivera informatizado, para un oficinista era trivial encher un impreso e inserilo no medio dun arquivo como se tivera estado alí desde o principio. Por suposto, esta práctica omitía todos os procedementos establecidos para crear e manter arquivos, e calquera que puidera subverter o proceso con tanta facilidade tamén podía facer auténticas falcatruadas con pouco risco de ser descuberto. Por ese motivo, cando se informatizaron as oficinas e as administracións públicas, un dos requirimentos habituais para o novo sistema era que non se puidese saltar, por ningún motivo, o proceso establecido.
“Con isto xa queda totalmente bloqueado o paso.”
Non é unha boa idea ser tan radical. Os procesos nunca están libres de erros: ás veces, un expediente entra nun estado inconsistente que non se pode arranxar seguindo o procedemento normal, o que nos obriga a usar medidas extraordinarias para podelo arranxar. Se é imposible facer cambios fóra deste procedemento, vanse multiplicar os erros e moita xente vai sufrir por iso.
Pensade nese amigo que temos todos, que ten a electricidade a nome dos anteriores inquilinos do piso porque, cada vez que chama para corrixilo, os teleoperadores da Fenosa dinlle que hai unha débeda de medio céntimo que bloquea os cambios e non hai maneira de pagar ou eliminar.
Outro inconveniente desta rixidez é que cando alguén quere facer algo pero hai un obstáculo que llo impide, vai buscar unha maneira alternativa de facelo. Hai pouco escoitei un podcast no que Gumersindo (nome ficticio) dicía que aprender SQL lle axudara a ser máis efectivo no seu traballo de soporte técnico. Grazas a saber SQL, podía conectarse directamente á base de datos e facer cambios nela para arranxar os problemas dos clientes. Seguro que a empresa pronto lle ía quitar o acceso se o soubera, e que el pronto había atopar outra maneira de seguir facéndoo.
O motivo polo que nos piden aos deseñadores de sistemas que forcemos o cumprimento das regras é o control. Esas regras e procedementos están deseñados para controlar o acceso a datos persoais e financeiros e para asegurarse de que as distintas operacións produzan indicios e rastros que se poden investigar e comprobar a posteriori. Cando Gumersindo fai un “SELECT” na base de datos evita eses controis e non queda constancia en ningures de que consultou un rexistro; cando fai un “UPDATE” tampouco queda rexistrado o feito de que modificou datos.
A bo seguro, hai operacións que hai que bloquear por motivos legais ou éticos, pero hai moitísimas outras que non paga a pena bloquear totalmente. No seu lugar debería haber un mecanismo que permite aos usuarios, cos permisos axeitados, realizar esas operacións preservando a posibilidade de investigar e esixir responsabilidades despois do feito.
Por exemplo, é certo que non debería ser posible para Gumersindo entrar na base de datos e executar as ordes SQL que queira, pero tamén é útil que teña a posibilidade de facer cambios para arranxar os problemas do cliente. No canto de bloquear o seu acceso totalmente, poderíamos ter un sistema que solicite unha xustificación para cada conexión á base de datos e a rexistre xunto co contido da sesión SQL. Desta maneira, alguén podería revisar todo iso máis tarde e ver se a xustificación é válida e as ordes SQL que escribiu corresponden á xustificación.
Isto non é o único que podemos facer. Por exemplo, se non chega con poder revisar máis tarde o SQL que escribiu Gumersindo, podemos usar un sistema no que alguén teña que revisar e aprobar o SQL de Gumersindo antes de el podelo executar. Isto funcionaría igual que os sistemas nos que alguén revisa o código que outra persoa escribiu antes de incorporalo no sistema de control de versións.
Moi poucas veces é necesario bloquear totalmente unha operación. Cando un cliente volo pida, tratade de buscar unha alternativa, ou os usuarios van sentirse acurralados e buscala eles mesmos. Vós veredes.
A ilustración desta Folla está baseada nun debuxo de Rembrandt e un gravado de “Germania: dos mil años de historia alemana”.
.jpg){kind=link}
1 comentario