Metodología 2.0 (I)

Hace unos días mostramos el mapa para dosificar una organización, o sea, para que actúe de acuerdo con la filosofía 2.0 y use sus herramientas. Como comentábamos allí, vamos a ir desgranando en sucesivos posts la metodología que proponemos. Hoy toca capítulo introductorio. Es decir, estamos desarrollando los cimientos del edificio, explicando eso que dice:

Tecnologías que nos hacen personas, tecnologías que desarrollan nuestras organizaciones.

Para empezar, creo que hay dos asuntos a dejar claros. Hasta donde se pueda, por supuesto. El primero tiene que ver con la pérdida de control. La organización tiene que asumir que la migración no es controlable al 100%, ni siquiera al 50%. La migración parte de la convicción de que debemos intensificar el diálogo con todas las partes que componen el ecosistema en que opera la empresa e incluso estar dispuestos a transformar ese ecosistema inicial.

La segunda cuestión es que quizá sea todo más fácil si lo hacemos con quienes ya están cerca de los territorios 2.0. Es decir, conviene hacer un pequeño y rápido análisis de las competencias que ya poseemos. Las personas que trabajan en las organizaciones tienen muchas capacidades ocultas para sus empleadores. Busquemos personas con blogs personales, que ya usan lectores de RSS o que etiquetan contenidos. Así que mejor miramos qué sabemos. Nos ayudará a concitar entusiasmo en torno al proyecto.

Claro que es bastante probable que quienes habiten en la cúspide de la organización no tengan este tipo de competencias y que sus actitudes sean peligrosas. Tranquilidad, que muros más altos han caído. Eso sí, que nadie se asuste si descubre que el dominio de este tipo de competencias 2.0 es inversamente proporcional al lugar que las personas ocupan en los organigramas formales: cuanto más arriba, menos competencia. ¿Una amenaza? Quién sabe, puede ser una oportunidad.

De estos dos principios debemos deducir que hay que andarse con tiento con la antes llamada "dirección". Porque aquí, llamar "dirección" a quien no sabe ni puede "dirigir" no tiene sentido. Así que necesitaremos navegar en aguas paradójicas: reconocer que el proceso es puritita emergencia y, al mismo tiempo, generar un mecanismo de planificación clásico vía equipo de proyecto.

Este equipo de proyecto debe asumir el rol impulsor, facilitador, amable, servicial y todas esas cosas que... es tan difícil encontrar en muchos departamentos de sistemas de información (*). El equipo de proyecto debería incorporar cuatro tipos de personas:

• gente de sistemas de información (y que haya suerte)
• alguna que otra persona de las que antes llamábamos "directivos" (y que haya más suerte)
• early adopters (seguro que las hay en tu organización)
• líderes informales que puedan ayudar a la causa (cada casa es diferente)

Este equipo de proyecto debe llegar a un acuerdo de mínimos. Admite, claro está, su divergencia interna, pero consensúa tres o cuatro puntos fundamentales que de forma machacona va repitiendo por todos los rincones de la organización. Estos consensos debería ir en la línea:

• Si no hay participación no hay nada, esto es la web social.
• Somos más persona y más organización en tanto que usamos la tecnología.
• Todo es más fácil si nos ayudamos entre nosotros, sólo hay que poner en contacto a quien tiene la respuesta con quien tiene la pregunta.
• Son pocas las personas que aprenden en solitario, en general necesitamos acompañamiento para adquirir nuevas destrezas.
• Una organización son muchas personas y es muy difícil cobijar tantos proyectos personales, así que tenemos que dotarnos de unos mínimos comunes.
• Muestra en tu actividad profesional la responsabilidad que muestras en tu vida personal y aplícalo, por supuesto, al manejo de las tecnologías de información.

Bueno, ¿qué pretendemos con este equipo y estos consensos? Trabajar la parte cultural, los principios que están detrás de los comportamientos. No nos sirve con entrar de lleno en la parte herramental, por mucho que podemos utilizarlo a veces como caballo de Troya.

También en esta fase 0 de un proyecto de migración, hay que pararse para otear el panorama inicial: ¿de dónde ha surgido la iniciativa?, ¿hay mimbres suficientes para hacer un cesto digno?, ¿alguna persona en la dirección que pueda jugar un rol positivo?, ¿quizá sólo necesitemos que la dirección no moleste y no tanto que impulse?, ¿algún éxito rápido que podamos vender?, ¿en sistemas de información cuáles son las actitudes?, ¿qué políticas están implantadas en torno a la seguridad?, ¿si hay superusuarios, qué relación tienen con el departamento de sistemas de información?

En fin, hasta aquí puedo leer. Sólo es el capítulo introductorio.

-------

(*) Pueden presentar alegaciones vía comentarios ;-)


Technorati tags | metodología 2.0