Un problema no es una lista de tareas
Ackoff dijo que los problemas complejos no tienen soluciones simples. Por qué el backlog es un error de categoría y qué exigen los problemas retorcidos.
The only problems that have simple solutions are simple problems. The only managers that have simple problems have simple minds. Complex problems do not have simple solutions.
— Russell Ackoff
La segunda frase es la que hace que citen a Ackoff, y es la menos interesante. El peso lo lleva la tercera.
La observación no es que los problemas complejos sean difíciles. Eso lo acepta todo el mundo. La observación es que no tienen soluciones simples en absoluto: ni caras, ni lentas, ninguna. Lo que significa que la búsqueda de una no es meramente optimista. Es la búsqueda de algo que no existe, realizada con presupuesto real.
El backlog como error de categoría
Fíjate en lo que ocurre cuando un problema genuinamente complejo entra en una organización. En aproximadamente una semana se ha convertido en una lista.
«Los usuarios se van a partir del segundo mes» se convierte en once tickets: mejorar el correo de bienvenida, añadir tooltips, arreglar el cuadro de mando lento, lanzar una encuesta de NPS. Cada ticket es defendible. Cada uno se puede estimar, asignar y cerrar. Y la transformación ha hecho en silencio algo serio: el problema ha sido reemplazado por la teoría del problema que tenía alguien, y esa teoría es ahora incuestionable, porque cuestionarla parece obstruir el avance.
Una lista de tareas es una solución escrita en un formato que oculta que es una solución. Este es el error de categoría, y es casi invisible porque el formato resulta utilísimo para todo lo demás.
El relato del diseño de Simon apunta al mecanismo. La parte difícil del diseño no es elegir entre alternativas, es generar el espacio de alternativas, y la descomposición determina ese espacio antes de que nadie haya tenido ocasión de discutirlo. Christopher Alexander dedicó Notes on the Synthesis of Form precisamente a esto: la forma en que cortas un problema en partes determina en gran medida qué soluciones se pueden encontrar, y el corte suele ocurrir antes de que alguien se dé cuenta de que se está tomando una decisión.
Retorcido, no solo difícil
La distinción que conviene sostener es entre difícil y retorcido. Un problema difícil tiene una definición estable y una solución costosa: construir un compilador es difícil. Un problema retorcido cambia de definición mientras trabajas en él, porque cada intento altera la situación y revela restricciones que antes no se veían.
El ensayo de Richard Buchanan sobre los wicked problems en el pensamiento de diseño es el tratamiento más claro que conozco, y su conclusión incómoda es que para estos problemas no existe regla de parada. No terminas. Decides parar, que es un acto distinto y exige otro tipo de responsabilidad.
La mayoría de los problemas de producto que merecen trabajo son retorcidos. La retención, la confianza, la sensación de que un producto va rápido, si un equipo puede entregar sin miedo: ninguno tiene una definición que sobreviva al trabajo. Por eso los planes expresados como listas de tareas se degradan tan rápido: se escribieron contra una definición que caducó en la tercera semana.
Donella Meadows añade la lectura sistémica. En un sistema con bucles de realimentación, el efecto de una intervención depende de en qué parte de la estructura intervienes, no de cuánto esfuerzo apliques. Empujar fuerte en el punto equivocado produce movimiento y ningún cambio, y el movimiento resulta extremadamente convincente en un informe de estado.
La consecuencia para cómo trabajamos
No Silver Bullet de Brooks es el mismo argumento apuntado al software en concreto. Hay una complejidad esencial, que viene del problema, y una accidental, que viene de nuestras herramientas. Las herramientas no dejan de mejorar. La parte esencial no se mueve, y ninguna metodología la ha movido nunca.
En la práctica, esto defiende algo modesto. Antes de descomponer, pasa tiempo con el problema en su estado sin descomponer, que es incómodo porque no produce artefactos y parece que no está pasando nada. El libro de Gause y Weinberg son cien páginas sobre exactamente esta disciplina, y su pregunta central merece ser robada: ¿de quién es el problema? La respuesta reorganiza la situación más a menudo que cualquier cantidad de análisis.
La segunda consecuencia tiene que ver con la masa. Como el trabajo es no lineal, añadir gente a un problema complejo no lo divide. Multiplica la coordinación y deja el problema intacto: lo que podría haber sido atómico acaba siendo sistémico.
Goldratt construyó una novela entera alrededor de la tercera consecuencia: en un sistema, mejorar cualquier cosa que no sea la restricción no mejora nada. La optimización local no es una victoria pequeña. Es un coste con apariencia de victoria, y la apariencia es lo que sube en el informe.
Un backlog es un instrumento excelente para coordinar trabajo que ya se ha pensado. Es un instrumento terrible para pensar, y con mucha frecuencia es el único que hay en la sala.