La maldición de los requisitos

1.   Introducción

Esta viñeta es de 1973 pero sigue siendo graciosísima… lo cual implica que, al menos donde nos hace gracia, sigue siendo verdad. Sin embargo, existen sistemas estupendos con una usabilidad excelente: Google o Amazon son los casos que más se ponen como ejemplo.

Es verdad también que los sistemas digitales suelen ser fáciles muy útiles: los supermercados on-line son una alternativa real a cargar peso, y zara.com vende más que cualquier otra tienda física, por muy grande que sea. Incluso en las industrias de servicios más complejos, casi todos los bancos, aseguradoras, empresas de telecomunicaciones o de utilities permiten hacer transacciones on-line, en general con bastante acierto.

Sin embargo, a pesar de años de esfuerzo, los procesos no están resueltos. Se comprueba con la cantidad de proyectos e incluso puestos de transformación que existen hoy en el mercado. La experiencia de cliente sigue siendo un problema, los procesos no terminan de ser omnicanal y el tiempo de evolución, el “time-to-market” no deja de alargarse. Incluso parece que sigue creciendo la cantidad de proyectos en los que se invierte tiempo y recursos (me refiero a millones de euros) para no ponerlos nunca en producción, aunque eso es un secreto muy bien guardado.

Lo interesante es pensar en por qué ocurre y, sobre todo, por qué sigue ocurriendo 50 años después de esa viñeta. 50 años en realidad es toda la vida de la industria del software. De hecho, quizás el software tiene un problema de juventud.

El software del que trata este artículo no es software técnico: los lenguajes, las bases de datos, los recursos de base no han parado de mejorar. Estamos hablando de la capacidad de articular elementos software para resolver un problema, obtener un comportamiento funcional.

Por lo visto, ahí está el follón.

2.   La vida según los usuarios de negocio

“¿Quién no tiene una hipoteca? ¿Cómo puede ser eso de difícil? ¡Pero si se llevan haciendo toda la vida!”

Estas son las primeras frases que todos los usuarios de negocio han dicho alguna vez. Éstas y la definitiva: “Mira, intuitivamente esto es muy fácil.” Cada vez que un usuario de negocio dice esto, muere un gatito. La palabra trampa es “intuitivamente”, porque ahí caben agujeros negros de incertidumbre. La felicidad es muy intuitiva; sin embargo, definirla es una pesadilla y construirla no es de este mundo.

Volviendo a la hipoteca, es verdad que una persona de negocio la puede describir con mucha facilidad: hay que tomar los datos del cliente, verificar la solvencia, verificar la solidez de la garantía y firmar la hipoteca.

Un paseo.

Una persona de negocio se preocupa por otras cosas, que son muy difíciles: cómo diferenciarse en un mercado en el que se lleva hablando de hipotecas toda la vida, cómo posicionarse y qué producto crear y a qué precio, cómo comunicar las ventajas, dónde hablar de ello… Así que, por favor, no molesten con preguntas técnicas, que estamos ocupados.

3.   Lo que entienden los analistas de procesos

Con esa descripción somera, los analistas de procesos son las personas a las que se les pide que describan lo que hace falta para que una organización eficiente (por supuesto) produzca contratos de hipotecas perfectamente documentados tal como define el regulador (por supuesto), creando una experiencia de cliente inolvidable (por supuesto). Como armas, se les supone el sentido común, un cierto sentido del orden, el conocimiento de la industria, la orientación al cliente y mucho amor por el detalle. La formación es escasa y discutible.

Sin embargo, tienen que producir los requerimientos para la construcción. No es demasiado sistemático pero suele consistir en una cantidad significativa de prosa, tablas de decisión y flujogramas más o menos complejos. Por ejemplo, se podrían encontrar los siguientes documentos de definición:

• Las pantallas de la captura de datos de la solicitud de hipotecas. En los canales que se necesiten, claro.
• La tabla de decisión con la que elaborar la lista de los documentos necesarios a la luz de los datos indicados.
• Las pantallas para verificar los documentos enviados por los clientes.

Pero habrá que pensar también en cómo se organiza todo ello y qué recursos técnicos hacen falta:

• Los diferentes intercambios de información con los diferentes proveedores que participan en la contratación: gestorías, tasadoras, notarios.
• Todo lo que hay que hacer después de firmar, como pagar Hacienda, informar al Registro, enviarle las escrituras al cliente…. O mejor aún enviárselo a otro proveedor que se ocupe y que nos tenga al tanto.
• Crear el alta de la hipoteca en el libro de créditos del banco con los datos de la operación, guardar las escrituras en un archivo a prueba de tiempo…

Al definir todos estos aspectos, se incluirán en el diseño detalles técnicos muy necesarios, de seguridad por ejemplo, o de seguimiento. Habrá que organizar verificaciones para asegurar que se hacen los envíos de información por canales seguros, de forma periódica y securizada, y que se reciben con las mismas garantías.

Fácil que se trate de más de 150 páginas de diversa documentación, distribuida entre diferentes equipos, para diferentes funciones.

4.   Lo que construyen los ingenieros de software

La cantidad de información es muy relevante y habrá mucho que hacer, y habrá que distribuir el trabajo en varios equipos. Por ejemplo, estará clarísimo cómo enviar y cómo recibir ficheros. Un módulo.

Estará clarísima la secuencia de las pantallas para la captura de datos de las solicitudes. Otro módulo.

Otro más las pantallas de validación de documentos.

Incluso se podrá pensar en los mensajes de error en las pantallas, tanto para clientes como para usuarios internos.

Se probarán todos los módulos de forma independiente. Todo correcto. Se podrá hacer el despliegue. Se podrán empezar a hacer casos fáciles, los famosos caminos felices (“happy paths”), incluso ver si se es capaz de hacer una hipoteca de principio a fin.

Supongamos que todo bien. Estamos listos.

En la primera semana de producción empiezan a pasar cosas raras. Por ejemplo, no se recibe la tasación de un expediente:

-¿Y eso? ¿Qué ha pasado?¿Por qué no se ha hecho la tasación de este expediente?¿Hemos enviado el fichero a la tasadora?

-Pues deja que mire…

…

Oye que sí, que resulta que lo mandamos bien.

-¿Y entonces?

-Pues que no la han enviado…

-¿Y eso?

-Pues espera que les pregunto

…

Pues no, que sí que lo tasaron pero que se envió en el fichero de ayer.

-¿Y entonces?

-Pues que no se cargó.

-Y ¿por qué?

-Espera que me entero.

…

Pues que traía el nombre mal y se rechazó.

-¿Y no avisaron a nadie?

-Pues no…

-¿Y entonces?

-…

…

O un expediente empieza a dar error:

-Oye que el sistema está mal porque me dice que el cliente me tiene que enviar sus nóminas.

-Vale… ¿y?

-Pues que el cliente es autónomo…

-¡Anda! Pero entonces ¿ha fallado el cálculo de documentos necesarios?

-Pues espera que miro.

…

No, se calcularon bien.

-¿Entonces qué ha pasado?

-Pues que el cliente ha cambiado sus datos, dijo que era empleado y ahora dice que es autónomo.

-¿Y el sistema no lo recalcula?

-No, no parece…

-¿Y entonces?

-…

…

O una persona del call center muy enfadada:

-Oye que el cliente me ha llamado para lo de la cita de la firma pero me acaba de colgar, furioso.

-¿Y eso?

-Pues que quería incluir el trastero en la hipoteca, que al ver la tasación ha visto que es una propiedad aparte.

-¿Y qué ha pasado?

-Pues que no me deja añadir un inmueble y me ha hecho empezar todo desde el principio.

-¿Cómo?

-Sí, que le he tenido que volver a pedir el DNI.

-Pero ¿por qué?

-Pues que no está previsto que se cambien los datos.

-…

Y así, una infinidad de casos configurando una catástrofe de granitos de arena. Un Golem de libro, muy parecido a los que comentamos aquí.

5.   La maldición de los requisitos

Se da una reunión de crisis. Tremenda.

La gente de negocio dice que cómo es posible.

La gente de procesos dice que cómo es posible.

La gente de ingeniería los mira sin comprender: “Pero si hemos hecho lo que se pidió…”

Y acabamos de llegar al problema. Ahí está todo el problema: Ingeniería de software hizo todo lo que se le pidió.

La cosa es que nadie pidió cosas raras como “avísame si algún expediente se ha enviado para hacer un servicio pero no ha vuelto”, o “recalcula la lista de documentos si el cliente cambia los datos”, o, ya puestos “recalcula la lista de documentos cada día porque, con el paso del tiempo, puede que haga falta un documento más, porque acaba de caducar su DNI”.

Nadie dijo nada de eso, con lo que no se hizo, claro.

Y en esa reunión, unos dicen “pero… ¡vamos a ver! ¿Qué menos? No querrás que te lo diga todo…¡el sistema tiene que funcionar bien!” y los otros dicen “Pero… ¡si ni siquiera saben lo que quieren!”. Estas dos frases también matan gatitos.

Entonces empiezan a trabajar para resolver los problemas: “A ver, que si algo no funciona, hay que poner una alerta. Y si algo cambia, habrá que poner una alerta. Y si algo se retrasa, habrá que poner una alerta».

Todo eso se hace, poco a poco, como se puede. Y suelen pasan dos cosas curiosas: primero, que no es posible imaginar todos los casos posibles, y por tanto no es posible imaginar todas las alertas posibles, de modo que se van amontonando las alertas y los apaños para evitarlas. Parches, lo llaman los técnicos.

Segundo, que, para ser útiles, las alertas necesitan alguien que las gestione. El día a día suele ser tenso. Los lunes son heroicos. La vuelta de un puente suele ser tan tremenda que no hay forma de achicar la tormenta de alertas.  Así que se olvidan, y cada olvido puede ser un golem…. Que no se va a ver porque no se puede salvo que se mire cada caso, o que sea el padre del jefe, que se le rescata del pozo porque sí.

Pero el peor efecto, y el menos visible, es que ya nadie sabe qué funciona cómo y por qué. Y eso en realidad da lugar a la esclerosis de la compañía, porque impide eficazmente cualquier cambio. Este efecto se nota por la cantidad de tiempo que hace falta para saber qué hace un sistema. Es peor cuanto más técnico sea el perfil que se lo tiene que mirar, y definitivamente mortal cuando hay que mirárselo en más de un sistema. La momificación de las empresas digitales, de la que se habla aquí, también tiene que ver con este efecto tumoral en sus sistemas internos.

6.   Falta la traducción

Y esta maldición, ¿es propia de la informática? ¿Del desarrollo de software? ¿De la organización?

¿Cómo sería en otras ingenierías? Imaginemos la construcción de una casa. En el estudio de arquitectura, llegaríamos a pedir la casa que nos hemos imaginado. Soleada, acogedora, de espacios abiertos… Puede que traigamos algún croquis, algún dibujo de lo que nos gustaría. Puede ser que el arquitecto nos haga dibujos en 3D o incluso una maqueta, para ver cómo es y si nos gusta, y nos iríamos encantados con la idea.

En la construcción de las casas, hay una enorme cantidad de información que estamos dando por hecha, y que nos sorprendería que no estuviera prevista en el sistema aunque no la mencionemos.

Todas las puertas tienen que poder abrirse. Y cerrarse. Y volverse a abrir y cerrar tantas veces como queramos. No, no sabemos cuántas.

Todos los grifos deben poder dar agua, caliente y fría, regulable, de temperatura estable. Igual: abrirse y cerrarse, tantas veces como se quiera.

Todos los sumideros deben sacar las aguas grises y negras a donde sea que vaya eso.

Todos los cuartos deben tener luz eléctrica.

Todas las ventanas tienen cristales. Que cubran todo el vano de la ventana.

Eso sin hablar de las cosas que ni siquiera somos capaces de mencionar pero que utilizamos constantemente y cuyo funcionamiento descontamos: los botes sifónicos, las vigas de carga, las zapatas -que no sé qué son-, la toma de tierra, los pararrayos, etc.

En el software, la ingeniería del comportamiento del sistema está todavía en un estadío anterior: si un usuario de negocio dice que quiere un coche para ir a Aranjuez con el viento en el pelo, le entregaremos un coche con un depósito de litro y medio y sin techo.

Estamos tomando como requisito lo que es un ejemplo de uso y solo un ejemplo, porque igual que voy a Aranjuez, me puedo ir a Oslo, y el viento en el pelo es siempre que no esté cayendo la tormenta del siglo, en cuyo caso prefiero que no, que no me dé el viento en el pelo.

La traducción de los requisitos de procesos forma parte de la ingeniería de sistemas aunque aún no se tenga como parte del trabajo. Por ejemplo, cuando un analista de procesos dice:

“Cuando estén todos los datos, se establecerá la lista de documentos necesarios”

 Lo que el requisito técnico debe leer es:

“Constantemente (i.e. si se cambia un dato, si se añade un interviniente, si pasa un día) se vuelve a calcular la lista de documentos necesarios, contrastando si ya se tienen.”

Que es lo que el analista de procesos ha querido decir y no ha dicho porque a otro humano no le hace falta, pero a un sistema automático sí.

Es muy frecuente oír hablar de Pareto para justificar una definición que atiende sólo al caso inmediato. En realidad, es un ejercicio de ingeniería insuficiente, igual que si nuestra casa solo fuera impermeable cuando caen menos de 100 litros por metro cuadrado.

7.   Ejemplos de procesos embrujados

La hipoteca es un caso paradigmático donde se ve la maldición de los requisitos. Cualquier caso en el cual haya variedad de opciones, de actores, o un tiempo largo, es candidato a este problema debido a la casuística. Cualquier automatización que no atienda a esta variabilidad dará lugar a casos absurdos sin atender.

El proceso de on-boarding, por ejemplo, es una pesadilla en todas las industrias en las que hay que verificar la identidad. También lo es el proceso de ticketing o de incidencias, el de baja, el de la gestión de incidencias de cobro…

En banca, además de las hipotecas, se puede pensar en los traspasos de fondos, los fraudes de identidad, o las testamentarías.

En seguros, son famosos los siniestros y muy visibles para todos los siniestros de hogar.

En la industria de telecomunicaciones, las portabilidades tienen fama, pero también la gestión de incidencias y el on-boarding y baja de servicios.

En todos esos casos, hay que recordar la frase de Einstein: “hay que hacer las cosas simples, pero no simplificar”.

Para que la automatización funcione, los requisitos deben reflejar la realidad que se necesita, no la simplificación con la que puede funcionar un humano porque, como dice Elon Musk, la capacidad de los humanos de lidiar con la complejidad está completamente infravalorada.

8.   En resumen

La viñeta del columpio es una representación maravillosa del problema de la construcción de procesos de alta variabilidad. En estos casos, la visión intuitiva de los workflow no es suficiente para obtener un sistema automático funcional. Esta frase se pone en negrita porque es la frase más difícil de todo el artículo. Es muy contraintuitivo pensar que los sistemas automáticos no puedan comprender cosas tan sencillas. Y es que los sistemas no comprenden, solo ejecutan, sin criterio, al pie de la letra. Son #Golems.

Es necesario diseñar con el mundo real en mente para crear un proceso que pueda aceptar la realidad como venga y adaptarse a ella lo mejor posible. La buena noticia es que se tarda un poco más en diseñar, pero se tarda mucho menos en construir y muchísimo menos en adaptar.

Ya hay mucho escrito sobre ello. Se llama Artifact-Centric y puedes encontrar más información aquí.

Hay un problema adicional y es que la gente de negocio sea capaz de ver por qué el sistema funciona como funciona. Pero eso es otro capítulo…