Wikis de proyecto en consultoría, segunda parte

by Julen

Actualización.- El video «Wikis in Plain English» para comprender qué es un wiki y cómo funciona (en menos de 4 minutos) también lo tienes con versión subtitulada en castellano, euskera, gallego y catalán.

Hace tres semanas escribí Consultoría: un proyecto, un wiki. Tenía pendiente profundizar algo más en el asunto. La conciencia aprieta y he tenido que darle rienda suelta. Allá van nuevos hilos comunicantes. No sé si voy a ser capaz de explicarme bien porque esto con un par de ejemplos se veía en dos minutos. Pero, claro, esa limitación que tengo, porque no puedo abrir los proyectos a las sabías multitudes.

Un proyecto de consultoría supone una cierta concentración de actividades en un tiempo más o menos reducido: desde las gestiones de la oferta hasta que está terminado con su evaluación. El proyecto nace, se reproduce y… muere mediante fagocitosis al incorporarse a las rutinas de gestión del cliente. Bueno, eso querríamos, ¿verdad?

¿Qué hacemos en un proyecto de consultoría en el que tratamos de mejorar algún aspecto de la gestión? Se me ocurre que:

  • Analizamos información, sea documental o mediante reuniones.
  • Extraemos conclusiones de forma progresiva a medida que el proyecto avanza.
  • Hacemos propuestas tentativas para entrever cómo se aceptan determinados cambios.
  • Incorporamos nuevos puntos de vista, nuevos ángulos de análisis.
  • Redactamos actas con compromisos para llevarlos a cabo.
  • Avanzamos y damos algún que otro paso para atrás.
  • Conversamos formal e informalmente con el cliente, cruzamos perspectivas.
  • Tratamos de coordinar acciones y reacciones.
  • Elaboramos borradores de trabajo.

Pues está claro: wiki, wiki, wiki. Es evidente que todo lo anterior llama a las puertas de la tecnología wiki. Simplemente porque nos aporta ese lugar único donde el equipo de proyecto, consultor+cliente, comparte toda la información del proyecto. Los correos electrónicos llevan enlaces a lugares concretos de ese wiki y no sobrecargan las bandejas de entrada.

Claro que trabajar con un wiki requiere una explicación previa de las reglas del juego. Hay que explicar estos conceptos básicos:

  1. Altas de usuario en herramienta de wiki o en aquellas otras que se decida utilizar. Vamos a empezar por el principio.
  2. En vez de correo con documentos: edición de wiki (se explica cómo) y correo enriquecido con enlaces.
  3. RSS como herramienta básica de información rápida del proyecto: lector de feeds y suscripciones como forma de estar al día.
  4. Cómo visualizar la trazabilidad del proyecto a través de los historiales de versiones generados por el wiki para perder el miedo a la equivocación.
  5. Plaza pública de información = lugar donde se reúnen todos aquellos documentos que tienen relación con el proyecto. Para ello bien se suben al wiki o se enlazan si están albergados en algún otro servidor web.
  6. Actas y compromisos van a un lugar concreto del wiki, con suscripción «obligatoria» para el equipo de proyecto.

Yo utilizo wikispaces en su versión de pago (5 dólares/mes) mientras dura el proyecto. Es un gasto ridículo con el que consigues un espacio seguro https y que sólo sea el equipo de proyecto quien vea y edite las páginas. Proporciona 2 Gb de espacio para la documentación adicional, suficiente si no andas liado con cosas raras. Hablo de wikispaces pero existen muchas otras alternativas. Suelo insistir con wikispaces porque es muy simple. Y esto es básico para no liar el asunto.

Una prestación nada desdeñable es que al terminar el proyecto puedes generar un fichero comprimido con todo el material. Una vez descomprimido, puede ubicarse en servidores del cliente para que mantengan acceso a la información generada si lo creen conveniente. Adiós al documento único tocho gordo para que se vea que la consultoría ha engordado la balda de turno.

Por concretar respuestas a las preguntas que hacía Sergio:

  • Tecnología que uso: wikispaces.
  • Satisface todas mis necesidades: casi al 100% (echa un vistazo a lo que digo luego respecto a mi wiki perfecto).
  • Problemas: tienen que darse de alta como usuarios de wikispaces y a veces cuesta explicar el RSS, aunque tienes la opción de suscripción a páginas mediante correo electrónico.

Respecto a mi wiki perfecto:

  • Simple, simple, simple (al estilo blogger: 1+2+3).
  • Integrado con correo electrónico para discusiones ágiles que complementen a los contenidos.
  • Robusto: no puedes permitirte no acceder a él.
  • Editable off-line y que sincronice cuando haya conexión. ¿Ciencia ficción?
  • De código abierto.
  • Con extensiones que incorporen funcionalidades concretas.
  • Con plantillas para diferentes actividades tipo: reuniones, planes de trabajo…
  • Con un buen soporte de comunidad.

Me paro porque ya sabes que «ante el vicio de pedir, la virtud de no dar» 😉

Artículos relacionados

3 comentarios

Diego 08/06/2007 - 11:11

Me reiteraré por enésima vez 😛

En cuanto Google abra su projecto JotSpot, vamos a vivir la verdadera revolución wiki. Jamás vi un wiki tan usable por los non-techies (a uno ya le aburre editar como si programase) y tan lleno de funciones útiles.

Llevo tiempo cavilando un post sobre los wikis como los verdaderos headquarters. A ver si me pongo a ello.

Responder
fernand0 08/06/2007 - 16:28

Wiki con posibilidad de edición off-line: Socialtext.

Tengo que probarlo, además hay versión de soft libre. ya contaré 🙂

Responder
joseba 09/06/2007 - 02:00

He enredado un poco en wikispaces, y un poco más en Wetpaint con mis alumnos en MU. No consigo el sistema perfecto. Pero con algunos clientes utilizo Google Docs aprovechando el panel de discusión que incorpora y me parece perfecto. En cuanto Google generalice Google Gears para trabajar off-line veremos cómo queda la cosa.

Responder

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.