Na informática adoramos as métricas. Poucas cousas hai que nos gusten tanto como ter un “dashboard” cheo de gráficas con liñas de cores. Queremos medilo todo, e para iso non hai nada mellor que asignarlle números a todos os fenómenos e facerlles un seguimento total.
Con razón: todos eses números e gráficas e “dashboards” son moi útiles e axúdannos a ver o estado do noso proxecto ou do noso negocio dun só golpe de vista, pero tamén teñen os seus problemas.
“Esta gráfica indica claramente que é necesario usar un lenzo máis alto para esta gráfica.”
O principal problema é que é moi doado caer no erro de confundir as métricas co mundo real. “Se non o mides non existe”, din algúns, sen se decatar de que toda a súa atención está monopolizada por un número nunha caixiña que non se sabe moi ben o que representa, mentres ignoran totalmente un foro de Internet cheo de queixas.
O segundo problema chega cando comezamos a tomar decisións para facer que as métricas vaian na dirección que queremos. Isto é particularmente pernicioso cando a xente recibe incentivos polo movemento desas métricas. Como exemplo, sabede o que ocorreu en Hanoi cando as autoridades quixeron erradicar as ratas e ofreceron unha recompensa por cada rata morta. Como proba, había que entregar o rabo da rata. Pouco tempo despois, todas as ratas de Hanoi quedaron rabenas pero seguían vivas e reproducíndose, asegurando un subministro constante de rabos.
Este problema é especialmente nocivo porque non precisa de grandes incentivos para levar a consecuencias fatais. Un truco moi coñecido para manipular unha enquisa é aceptar as respostas positivas inmediatamente pero solicitar unha explicación para as respostas negativas: para unha persoa normal, ter que escribir unha liña de texto é incentivo dabondo para seleccionar unha resposta que non o requira.
Uxía pensou que estaba a tolear. O seu director acababa de abrir un chat con ela para lle preguntar por que tiña no Jira un erro con prioridade alta que levaba máis de 7 días aberto.
—Pensaba que para un director habería cousas máis importantes nas que reparar que os erros que teño eu abertos no Jira— dixo ela.
—Eu tamén o pensaba, pero o meu xefe acaba de me preguntar a min por ese erro.
Esta historia baseada en feitos reais é un exemplo moi común deste fenómeno. Os xefes de Uxía descubriron que o seu sistema de xestión de incidencias ofrecía unha morea de informes e estatísticas. Estes informes falaban da velocidade coa que o equipo respondía ás incidencias ou engadía funcionalidade, e os xefes de Uxía comezaron a lelos cada semana e a celebrar os seus movementos.
— Estamos pechando erros máis rápido do que os abrimos!
A semana na que as métricas non ían na dirección preferida, o cantar mudaba.
— Uxía, por que tés unha incidencia aberta desde hai tres meses?
No seu esforzo por guiar a evolución dos números, non tardaron moito en establecer “niveis de servizo”: os erros urxentes tiñan que seren atendidos en 4 horas, os moi importantes nun día, etc. Os xefes e directores recibían informes diarios sobre as incidencias que non cumprían os niveis de servizo e, por suposto, tiñan conversas coma a de enriba.
Pouco tardou Uxía en adoptar un costume moi peculiar. Dúas veces ao día, Uxía abría a lista de novas incidencias e mudáballes as prioridades ao valor mínimo, que non tiña un tempo de resposta establecido. Desta maneira todos estaban felices: os xefes porque todas as incidencias cumprían os seus niveis de servizo, e Uxía porque así non tiña que ter conversas absurdas co seu director.
A ilustración desta Folla está adaptada dun retrato de Giovanni Altoviti.
1 comentario