Por esas cosas del trabajo, los últimos tiempos me he tenido que enfrentar a montañas de Problemas Impíos. La verdad, no se me ocurre una mejor traducción a «Wicked Problems»… mirando un diccionario veo que se podría traducir como «Problemas Maliciosos» o «Problemas de Broma», pero la cosa es demasiado seria (por lo menos personalmente), por lo que lo dejo en Impío…
Wicked Problems, según la explicación de la Wikipedia (http://en.wikipedia.org/wiki/Wicked_problems), es una frase usada en planificación social que describe un problema que es entre difícil e imposible de solucionar porque sus requerimientos son incompletos, contradictorios o constantemente cambiando. Peor aún, las acciones encaminadas a solucionar Wicked Problems conducen muy probablemente a la creación de nuevos Wicked Problems, por lo que el asunto se reproduce como las cabezas de Medusa…
En realidad, no tengo ninguna idea de planificación social, así que no se me ocurre como llegue al nombre. Pero pensando en cómo describir el asunto de una forma sencilla, se me vino el nombre a la cabeza. Volviendo a la Wikipedia, Jeff Conklin (no me pregunten quien es, no tengo ni idea, pero su nombre está escrito allí mismo) nos indica que hay cuatro características que definen un Wicked Problem:
1 – El problema no se entiende hasta después de formular una solución
2 – Participantes en el problema lo ven de formas radicalmente diferentes
3 – Limites y recursos para resolver el problema cambian constantemente
4 – El problema nunca se soluciona completamente
Veamos a que me refiero. En el proyecto en el que estoy trabajando actualmente, la primera implementación fue hecha como un piloto para saber cómo se podría utilizar SharePoint en la empresa. Como piloto, es utilizado por solamente una fracción (3.000) del número de usuarios finales (50.000), y en una sola sucursal de la empresa (finalmente será utilizado en 14 países en dos continentes). Por lo tanto, el primer diseño fue sencillo: una Aplicación Web con una Colección de Sitios. Nada en contra, para ese número de usuario iníciales SharePoint se muere de la risa por la carga, esta 90% del tiempo haciendo nada y el diseño es más que valido.
Cuando comenzamos a hacer el diseño definitivo, lo primero que hicimos fue distribuir la información lógicamente en diferentes «contenedores» o Aplicaciones Web (una para Portal, otra para Colaboración, otra como Record Center, etc.). Y dentro de algunos de los contenedores, una distribución más granular por medio de Colecciones de Sitios. Esto nos garantiza poder crecer de una forma organizada en el futuro, manteniendo la información separada tanto lógica como físicamente (diferentes Bases de Datos que no crezcan más de lo necesario y se puedan hacer BackUps y Restauraciones en tiempos decentes). Y aquí empiezan los Wicked Problems…
Según la definición que les comentaba anteriormente, nos encontramos con el primer punto: hasta después de formular la solución (separar la información en diferentes Aplicaciones Web y Colecciones de Sitios), no resulto que no entendíamos el problema: los usuarios del sistema Piloto se habían acostumbrado a agregar información a lo largo y ancho del sistema utilizando la WebPart de Content Query (http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=3&itm=681 y http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=3&itm=685) y, por supuesto, querían seguir trabajando de la misma manera con el nuevo sistema. Como recordará, con esta WebPart es muy fácil «arrejuntar» listas y mostrar manzanas junto con naranjas, pero tiene un problema pequeñito: solo puede agregar información presente dentro de la misma Colección de Sitios.
Y aquí llegamos al segundo punto de la definición: nosotros, tecneutas, vemos el problema de una forma muy diferente a como lo ven los usuarios. Nosotros queremos dividir la información de una forma lógica, usando lo que nos ofrece SharePoint para hacerlo. Los usuarios quieren ver información regada por todas partes en un solo sitio, el problema es visto desde perspectivas completamente diferentes…
Por supuesto el tercer punto se ve venir de inmediato: el usuario quiere regresar al sistema antiguo cambiando los limites, luego cambia de opinión para regresar al nuevo diseño, luego viene con las ideas mas alrevesadas de este mundo y el otro… pero eso sí, el sistema tiene que ser operativo en la fecha determinada de antemano… limites y recursos cambian constantemente…
Finalmente llegamos al cuarto punto: el problema no se soluciona nunca completamente. A final de cuentas hay que buscar el compromiso en el que todo el mundo consigue una parte del botín, pero nadie se hace rico de verdad… Un par de Colecciones de Sitios por aquí, y otro par por allá, pero no más de un cierto número limitado… el cliente contento porque puede hacer algunas de las cosas que hacia anteriormente, nosotros contentos porque podemos separa de una forma (imperfecta, pero separar al fin y al cabo) la información de una forma lógica. El cliente descontento porque no puede tener todo como lo tenía anteriormente, nosotros descontentos porque nos han quitado una buena parte de flexibilidad en el diseño…
En fin, es un caso recursivo que supongo todos ustedes se han encontrado más de una vez en la vida. Lo malo del asunto es que, por definición, Wicked Problems no tienen una solución satisfactoria y, como veíamos al principio, si un Wicked Problem se acerca a una solución, tiene la tendencia a crear nuevos Wicked Problems… ya veremos que nos trae el futuro en este proyecto…
Gustavo – http://www.gavd.net
Escriba un Comentario que me haga reir…