68. No existe el error humano

---

LO QUE EXISTE ES UN PROCESO que falló en anticipar donde una persona podría realizar algo de manera incorrecta y en prevenirlo.

Pensar que los errores pueden ser humanos implica que la solución sería reemplazar al humano. Hasta que nos encontremos con otro humano que falle, y luego con otro, y luego otro más. Todos en el mismo punto.

Si una persona cometió un error, otra también podría cometerlo.

Corregir el proceso en donde las personas fallan es la única manera de escalar.

Asumir que existen los “errores humanos” lleva a que los procesos y las herramientas sean cada vez menos resilientes, requieran mayor capacidad de los usuarios y, en consecuencia, restrinjan su marco de acción.

Quizás pienses: “Conozco gente que hace la diferencia. Conozco gente que tiene resultados extraordinarios en el mismo proceso en donde otras personas tienen resultados mediocres.” Eso es cierto. Aunque no escapa a la regla que planteamos en este punto.

Las personas pueden mejorar el proceso y pueden obtener resultados por encima del promedio, pero debemos asegurarnos de que las herramientas y los procesos aseguren un mínimo de seguridad y resultados independientemente de quién lo opere.

Existen dos conceptos que quiero introducir para desarrollar mejor esta idea.

Poka-yoke: a prueba de tontos

Poka-yoke es un método introducido por el Toyota Production System (TPS) que pretende reducir ineficiencias y errores involuntarios en los procesos.

Este método pretende reducir la cantidad de decisiones que una persona debe tomar para lograr resultados satisfactorios en su tarea.

Dicho de otra manera: “Poka-yoke nos permite construir interacciones ‘a prueba de tontos’”.

Algunos ejemplos:

• El tomacorriente que sólo tiene una forma de ser conectado.
• El conector de tipo USB-C, que puede ser conectado de cualquier manera y ambas son correctas.
• El agujero que tienen algunos lavamanos que previenen que el mismo desborde.
• Las moldeadoras de metal que requieren que el operario presione simultáneamente dos botones para asegurarse que las manos no quedarán expuestas a la prensa.
• Las interfaces de usuario de productos digitales que implementan los patrones inductivos (IUI — Inductive User Interfaces), también conocidos como Wizard o Asistentes. En donde el usuario es guiado por un proceso en donde toma decisiones acotadas y con un marco de información contextual para soportar la decisión.
• El lavarropas que no funciona si la puerta no ha sido trabada.
• Las lapiceras con punta retráctil, en donde es imposible perder la tapa (porque no existe tapa).
• Las puertas de los ascensores, que detectan resistencia y vuelven a abrirse para evitar lastimar a los usuarios.

En fin, existe un método que nos permite reducir la cantidad de decisiones de los usuarios, reducir en consecuencia la potencialidad de cometer errores y, de esa manera, no resignarse a pensar que el error puede ser humano.

Ley de la conservación de la complejidad de Tesler

Larry Tesler fue un pionero en el área de Human-Computer Interaction (HCI). Trabajó en los años dorados de Xerox Parc y Apple. Se lo considera uno de los padres fundadores del Diseño formal de la Experiencia del Usuario (UX).

La Ley de Conservación de la Complejidad de Larry Tesler, indica:

No es posible reducir la complejidad de una tarea más allá de cierto punto.

Una vez alcanzado ese punto, sólo es posible desplazar la complejidad de un lugar a otro.

La única duda es quién deberá lidiar con dicha complejidad.

Conclusiones para productos de software:

La complejidad que no resuelva el programador, la va a absorber el usuario (tantos usuarios como tenga el producto).

Si el usuario no puede absorberla, recaerá en un Manual de Uso, Documento de Ayuda o Centro de Atención al Usuario (Soporte Técnico, Call Center, etc.)

Decisiones de última milla, de un programador frente a su pieza de código fuente, determinan la experiencia de muchos más usuarios.

Un programador que desconozca el impacto de sus decisiones en la experiencia de estos usuarios expone a los mismos a complejidad innecesaria.

Las respuestas a las siguientes preguntas contribuyen al éxito o al fracaso de un producto:

• ¿A cuántos usuarios impactará una decisión dada?
• ¿Es más relevante el tiempo de los programadores en resolver algo o el de todos los usuarios lidiando con ese problema sin resolver?
• ¿Qué puede hacerse para que el software sea capaz de absorber más complejidad (Interfaz de Usuario, algoritmia, servidor, infraestructura, etc.)?

No siempre es necesario reducir la complejidad absorbida por una pieza de software a su mínima expresión. Aunque sí es mandatorio analizar el impacto antes de alcanzar dicha conclusión.

Todo miembro del equipo, especialmente el management, deben discutir la siguiente ecuación antes de concluir que una funcionalidad ha alcanzado su máxima madurez. Los componentes de esta son:

• Costo total de la operación de la funcionalidad (CTf):
• Costo de la operación (Co): Este es el costo intrínseco de la operación del producto. Se sugiere cuantificar en costo monetario.
• Cantidad de usuarios (Qu): Esta es la cantidad de usuarios expuestos a esa complejidad.
• Frecuencia de uso de la funcionalidad en cuestión (Fu): Cantidad de veces por unidad de tiempo que el usuario es expuesto a la funcionalidad.
• Probabilidad de error (Pe): Esta es la probabilidad de que el usuario cometa el error.
• Costo de los errores (Ce): Es el costo de la recuperación del error. Podría ser el costo de emitir una factura con errores y corregirla, de operar una prensa de metal exponiendo al operario o que el usuario no advierta que el correo electrónico no fue enviado. Se sugiere cuantificar en costo monetario.

CTf = (Co * Qu * Fu) + (Qu * Fu * Pe * Ce)

El COSTO de la operación, y la probabilidad de error pueden ser aproximado a través de Pruebas de Usabilidad o a través de la obtención de información empírica acerca del uso del software (analytics, time trackers, etc.).

Pongamos un ejemplo:

• Operación:
  - Emitir factura.
• Error analizado:
  - El usuario emite la factura por un concepto erróneo.
• Costo de la operación (Co):
  - 3 minutos por factura = US$ 6.- por factura
• Cantidad de usuarios (Qu):
  - 100
• Frecuencia de uso (Fu):
  - 20 veces por día
• Probabilidad del error (Pe):
  - 0,05
• Costo del error (Ce):
  - US$ 6.- por cada factura + costo de advertir el error más adelante en el proceso (vamos a estimar este segundo término en US$ 0.- para no sumar mayor complejidad en el ejemplo. Sin embargo, puede resultar en un costo alto, dependiendo del punto en el cual se advierta el error).

CTf = (Co * Qu * Fu) + (Qu * Fu * Pe * Ce)

CTf = (US$6 * 100 * 20) + (100 * 20 * 0.05 * US$6)

CTf = (US$12.000) + (US$600)

CTf = (US$12.600/día)

Estos resultados nos permiten derivar varias conclusiones:

1. El costo diario de la emisión de las facturas en este escenario es de US$ 12.600.- por día.
2. El costo de cometer errores en este escenario es de US$ 600.- por día (como mínimo, dado que no hemos incluido en el análisis el costo de transferir el error a otras partes del proceso).

Si el software se encuentra en operación, digamos, 5 años, exponiendo a los usuarios al mismo error, eso es un costo oculto de más de US$700.000.- durante el ciclo de vida de este.

Este mismo cálculo puede ser utilizado para estimar el ROI de un proyecto que se proponga la eliminación del error.

Podemos ser extremadamente metódicos y actualizar frecuentemente los resultados para los errores más frecuentes, aunque podemos también estimar un valor en nuestras cabezas al indagar en las variables descriptas.

Tenemos dos opciones entonces:

1. Considerar que los usuarios son tontos y por eso cometen errores y no hay mucho que hacer. Podemos cambiar al usuario y resolver el problema.
2. Considerar que debemos reducir complejidad y exponer a los usuarios a menos errores para lograr mejores resultados.

¿Qué eliges?

Lo importante es comprender que detrás de cada error hay un costo oculto, y la posibilidad de eliminarlo suele estar en nuestras manos.

Resulta de vital importancia incorporar esta manera de ver los “errores humanos” dentro de la cultura. Para encontrar la frontera de nuestros productos y descubrir nuevas miradas sobre cómo podemos ampliarlas.