domingo, 17 de enero de 2010

Problemas Perversos en Acción.

Problemas Impíos (Wicked Problems) y SharePoint

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 yhttp://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...

Published 29/3/2009 22:55 por Gustavo Velez
Archivado en:

Comentarios

# re: Problemas Impíos (Wicked Problems) y SharePoint

Sunday, March 29, 2009 11:19 PM por Juan Carlos González Martín

...curioso el tema de la CQWP, parece un tema recurrente que al usuario le cuesta ver...

Un abrazo

JC's

# re: Problemas Impíos (Wicked Problems) y SharePoint

Sunday, March 29, 2009 11:48 PM por Jorge Dieguez

Hola Gustavo, intereante entrada, desde la perespectiva tecnica esta muy clara la necesidad de la separacion de los distintos contenedores por las razones que indicas en el post, ahora bien, tal y como "vendemos" el producto, como una solcuion que permite agregar grandes cantidades de infromacion y documentos en el unico punto y compartirla(sharePoint:-) tiene que resultar frustrante para los usuarios que les pongan fronteras, vamos que entiendo perfectamente el disgusto y es una de esas cosas de sharepoint que me molestan, que al enfocarlo a grandes propositos nos encontramos con limitaciones por todos los lados:-(

Un Saludo

Jorge Dieguez

# re: Problemas Impíos (Wicked Problems) y SharePoint

Monday, March 30, 2009 1:20 PM por Gustavo Velez

Hola Juan Carlos, Jorge...

Probablemente un jefe que tuve hace algunos años tenia razón: el no veía problemas por ninguna parte sino desafíos... En este caso es muy claro que una tarea muy importante es "educar" y "guiar" al cliente desde el principio, y no dejarlo que siga su camino propio por si mismo...

Un abrazo,

Gustavo

# re: Problemas Impíos (Wicked Problems) y SharePoint

Saturday, May 02, 2009 6:20 PM por Liliana Godoy

Hola, Gustavo!

Así como no tienes que ver con los asuntos de la planificación social, yo no tengo que ver con los de la tecnología. Sólo quería decirte que me pareció genial la aplicación que hiciste del concepto de "Problema Perverso" (así es que se traduce al menos en los textos sobre gerencia). Soy docente de Planificación estratégica y decisiones bajo presión y me resultó bastante didáctica la aplicación que hiciste. Suerte con los problemas colaterales que puedan aparecer con la solución que conseguiste a tu sistema...

# re: Problemas Impíos (Wicked Problems) y SharePoint

Saturday, May 02, 2009 6:56 PM por Liliana Godoy

Sé que por naturaleza los profesionales del área tecnológica son muy concretos y pese a la complejidad de su trabajo, no son afectos a las disertaciones y análisis propios de las ciencias sociales. Aún a riesgo de parecer fastidiosa, me animo a enviar un artículo no muy extenso pero sí bastante interesante sobre el concepto de Problema Perverso, pero asociado a la estrategia, que tal vez puede ser también soporte de tu elaboración sobre el tema y hace referecias a algunos autores, por si quieres ahondar...

Pienso que un punto interesante y que fue mencionado por tu tocayo en un comentario arriba, es el involucrar a los clientes desde el principio, para evitar "interpretaciones libres" de las posibilidades de los usuarios.

LA ESTRATEGIA COMO PROBLEMA PERVERSO.John C. Camillus, en www.portafolio-inversiones.com/.../395

Durante los últimos 15 años he estudiado cómo las empresas crean estrategias, que es la responsabilidad más importante de los altos ejecutivos. He visto cómo muchas corporaciones han reemplazado el rito anual de la planificación de arriba abajo, basado en las proyecciones macroeconómicas, con procesos más sofisticados. Para desarrollar una estrategia, procesan enormes cantidades de datos de los consumidores, realizan sesiones frecuentes de planificación, y usan técnicas como el modelamiento de competencias y el análisis de opciones reales.

Este tipo de enfoque representa una mejora debido a que se basa en el cliente y en las capacidades, y permite a las empresas modificar sus tácticas rápidamente, pero aun así no acierta la mayoría de las veces. Las firmas suelen obviar una complicación durante el proceso: no pueden modelar los entornos cada vez más complejos en los cuales operan. En consecuencia, los procesos contemporáneos de planificación estratégica no ayudan a las empresas a resolver los grandes inconvenientes que enfrentan. Varios CEO reconocen que confrontan cuestiones que no pueden ser solucionadas simplemente recopilando datos adicionales, definiendo los obstáculos con mayor claridad, o dividiéndolos en problemas más pequeños. Sus técnicas de planificación no generan ideas nuevas, y la implementación de las soluciones que se derivan de estos procesos está plagada de peligros políticos.

En mi opinión, esto se debe a que muchos de los percances estratégicos no son simplemente difíciles o persistentes, sino que son "perversos". La perversidad no es un grado de dificultad. Los problemas perversos (wicked problems) son distintos porque los procesos tradicionales no son capaces de resolverlos, según Horst W.J. Rittel y Melvin M. Webber, profesores de diseño y planificación urbana de University of California en Berkeley, quienes acuñaron el término en un artículo publicado en 1973, en la revista Policy Sciences. Un problema perverso implica innumerables causas, es difícil de describir y no tiene una solución correcta, como veremos en la siguiente sección. La degradación ambiental, el terrorismo y la pobreza son ejemplos clásicos de ello. Son lo contrario de los inconvenientes difíciles, pero normales, los que las personas pueden resolver en un período de tiempo definido aplicando técnicas estándar.

Los procesos convencionales no sólo son incapaces de resolver problemas perversos, sino que a veces también pueden exacerbar situaciones al generar consecuencias indeseables. En áreas como la elaboración de políticas públicas, el desarrollo de software y el diseño de proyectos, expertos como Peter DeGrace, Leslie Hulet Stahl y Jeff Conklin han concebido formas de detectar y abordar problemas perversos. En 1990, DeGrace y Stahl escribieron Wicked Problems, Righteous Solutions: A Catalogue of Modern Software Engineering Paradigms; y en 2006, Conklin escribió Dialogue Mapping: Building Shared Understanding of Wicked Problems.

El concepto de perversidad ha sido particularmente bien empleado por las autoridades públicas, pero ha estado notablemente ausente de las discusiones sobre estrategia. Aunque muchos de los percances que las empresas enfrentan son intratables, éstas han tardado en reconocer la perversidad de algunos asuntos estratégicos.

Saludos, y espero que sea de utilidad el artículo!



2 comentarios:

Anónimo dijo...

Manolo
entiendo que quiera hacer la analogia del wicked problem
pero, en alguno de esos he estado y le diria
a el usuario no quiere aprender nada mas que lo que usaba, salvo que le apaguen el sistema viejo, ahi se las tiene que rebuscar y, puteando, aprende
b por mas buena voluntad que le pongan los del nuevo, el viejo era, mas rapido, mejor
c los boards solo ven las pantallitas y en general opinan adecuadamente sobre los colores.
d los vendedores dicen que hace 1000, la realidad es 500, y si queres los 1000 salen 4 veces mas, y los usuarios usan 10

le dejo las analogias

ayj

tiovik dijo...

...don manolo, se esta metiendo con un gremio que es peor que le de los politicos. Le tiro algunas lineas:

1) En informatica la ley de Murphy se cumple con absoluta precision.

2) Todo lo que digan los "vendors" debe ser reducido un 50% si las comisiones de compra no exceden el 10% o al 30% si las comisiones alcanzan al 20%. Para comisiones mayores la reduccion tiende exponencialmente a cero.

3) Todo lo que digan los "vendors" debe ser usado en su contra, sin excepcion.

4) Invariablemente el problema se encuentra entre el teclado y la silla.

5) Los sistemas antiguos deben ser desconectados y reemplazados de un solo golpe. Por cuestiones operativas esto debe hacerse de preferencia durante un fin de semana o en un feriado.

6) El entrenamiento del personal es irrelevante. No importa cuanto se haya invertido en reentrenarlos para el nuevo sistema, al usarlo por primera vez en un entorno de produccion invariablemte olvidaran todo el entrenamiento. Es mucho mas positiva proceder a entrenarlos mientras trabajan (aparte se gasta menos dinero que puede reinvertirse en una buena cafetera express para el area de sistemas)

7) Las interfaces de usuario las diseñan entre los cuatro craneos de sistemas. Solo se necesita algo de papel, las PC para trabajar, agua caliente y un mate, gaseosas cola, pizza de muzzarela, caramelos de menta y eventualmente cigarrillos. Reunidos estos insumos basicos los craneos podran trabajar y generaran una interface perfecta entre el usuario y el sistema. Nadie debera ver el producto antes de terminarlo y cualquier critica sera contestada con un chorro de agua caliente no le digo donde.

...y hay mas, por cierto la sigo otro dia. Me olvidaba, lo que dice ayj es horriblemente veraz...