Complicado vs complejo
Deje que utilice algunas fotos de un viejo libro (aunque no mucho, 2011), Management 3.0 por Jurgen Appelo para establecer un marco sobre el que hablar:
Por si no se lee bien:
Complicated referes to a system’s construction being too intricate to understand, unless you’re an expert, whereas complex and chaotic refer to a system’s behavior which is unpredictable to a small or large degree.
También interesantes en la imagen los dos modelos por David Snowden Cynefin y por Ralph Stacey The agreement and certainty model (o matriz)
Complejidad y predictabilidad
Complejidad en sistemas software
Destaco:
When it requires an expert to understand the structure of your software, I (the author) prefer to say it is complicated. And when the behavior of your system cannot be fully predicted (as in AI, neural networks, or multiplayer games), I say the software is complex.
Los proyectos software como systemas complejos adaptativos
…describes that systems composed of “agents” … can be molecules, neurons, web servers, or people, always organizing and reorganizing themselves into larger structures, and thereby forming new emergent structures with new emergent behaviors.
Resumen complejidad vs complicado
La complejidad aduce a cuán impredecible es un sistema o los sistemas en cuanto a los comportamientos que de ellos se esperan, mientras que el caracter complicado lo fija el nivel de experiencia de la persona que lo aborda.
Un sistema puede ser complejo y muy fácil de programar, por ej. El Juego de la Vida, que con unos patrones sencillos produce resultados inesperados. Y al contrario, un algoritmo u optimización para mejorar el rendimiento de un sistema puede ser muy complicado de conseguir, requiriendo a un experto que lo aborde, pero no afecta a su relación con su entorno y la salida siempre es la esperada.
El debate
Después de esta introducción larga, creo que por un lado podemos decir que estamos de acuerdo, o así lo veo yo, en que para abordar un problema, hay que pensar y rodearse de gente que ayude a descubrir qué se necesita (el gran QUÉ) por parte de clientes y usuarios con ayuda de expertos y el equipo multidisciplinar (recordemos que necesitar es distinto de querer).
Y el quid de la cuestión es la complejidad en las relaciones entre los diversos stakeholders como son clientes, usuarios, equipo de desarrollo (visto como desarrolladores y diseñadores de ux y ui) y otros elementos (márketing, legal, comercial, infraestructura o soporte). Complejidad por los resultados inesperados ante agentes con comportamientos impredecibles: ¿hemos entendido bien lo que nos pedían? ¿Cumplimos con el cliente, pero también con otros stakeholders? ¿Lo usarán los usuarios del cliente? ¿Que a lo mejor son sus propios clientes? Aquí puede haber preguntas mil.
Esta es la raíz del debate para mi, sea el proyecto optimizar el cuello de botella del cliente que ejecuta una transacción por minuto cuando lo deseado es 1 segundo (complicado) o conectarnos con una heterogenidad de sistemas para consultar fuentes de datos metereológicos algunos con APIs poco documentadas, otros con limitaciones de API por consumo temporal y otros a los que hay que hacer ingeniería inversa o web scraping donde cada semana cambián la forma de presentar los datos.
De modo que, complejidad vs complicado o expresado como eliminar la incertidumbre en el mejor de los casos para mi es semántica. Sabemos que queremos que el sistema responda en 1 segundo y no en 1 minuto (despejada la incertidumbre) y convertido en complicado, pero ahora entra la incertidumbre de cómo conseguirlo, aparece otra incertidumbre aunque despejamos la anterior. Puede ser que sea tan fácil como tocar un parámetro en algú sitio, o tener que cambiar media arquitectura o infraestructura.
Pero esto es un ejemplo muy sencillo, cuando hablamos de crear desde cero un software que tienen en la cabeza en forma de nebulosa nuestros clientes, la única forma de eliminar la incertidumbre es publicar cuanto antes, acortar los tiempos de entregabilidad (sic) de software funcionando, haciendo las actividades que sean necesarias para poder ponerlo en marcha cuanto antes, y esto es complejo porque intervienen de nuevo las personas y no sabemos cómo responderán: ¿les gustará a nuestros clientes? ¿les gustará a nuestros usuarios? y lo más importante ¿lo utilizarán? ¿pagarán por utilizarlo? Y no sé si les habrá pasado al resto, pero cuántas veces alguien describía un lanzador de satélites como que era lo que necesitaban, cuando en realidad les servía con un botón que copia&pegara un código.
Lo que aquí se ha comentado que es una receta para el desastre es abordar un desarrollo como un proyecto en cascada, caja negra, (ojo, que yo comentaba que puede tener sus aplicaciones y casos de uso en función del alcance, tipo de proyecto o de equipo) con una fase larga de extracción de requisitos ligándolo con que se eliminará toda la incertidumbre.
Y por enlazarlo algo, mínimamente al hilo, y ya que me perdonen los dioses o demonios del offtopic, nuestro Sistema 1 según Kahneman ha entrado sin pensar a contestar con un No a ¿eliminar incertidumbre por completo, desarrollo caja negra? Conseguir que tras varios meses analizando requisitos, sin validar nada, diseñar su ui, sin validar nada, programarlo, sin validar nada, probarlo, sin validar nada, y el último día, tras varios meses o años presentarlo, vuelvo a decir, que ya puede sonar la flauta (sin validar nada con cliente se refiere). Si esto sí que lo aborda, lo puede llamar agile o fragile, pero a fin de cuentas estaríamos de acuerdo en casi todo, salvo en la parte de eliminar la incertidumbre por completo que para mi, repito, se despeja en la cúspide del cono de incertidumbre.
Un saludo.
.
