En realidad, y como cualquier sector relacionado con las tecnologías de la información, hay una creencia bastante generalizada que concibe la producción de materiales de formación como un proceso casi automático… “te paso un word y me lo conviertes a curso”. Es un mal común que hay que gestionar en las primeras reuniones con el cliente, haciéndole comprender que el trabajo de calidad es mucho más complejo que eso, y que en la mayoría de los casos, requiere de la intervención de varias personas durante un periodo de tiempo significativo.

Es bastante habitual encontrarte haciendo una consultoría a responsables de Recursos Humanos o incluso de tecnología de las empresas (algunas significativamente grandes) sobre conceptos y procesos de la generación de contenidos e-learning. Salvo  excepciones hay un significativo desconocimiento de qué implica crear un contenido para formación on-line.

Hace unas semanas, se publicó un informe que mostraba el coste de producción de una hora de e-learning (1 hora real de alumno: en algunos cálculos del sector se utiliza el ratio de 4 o 5 páginas word por hora de formación). Con datos de EEUU, y un precio/hora que no es equivalente al de España, el resultado era que para producir una hora de formación básica (textos, gráficos, animaciones, algún cuestionario, y quizás algún vídeo pregrabado), hacían falta 79 horas de trabajo. El coste de producirlo, rondaba los 10.000 dólares (pantalla 11).

El proceso de producción e-learning

Es por ello que para entender mejor el proceso, los tiempos y costes, vamos a explicar las fases y la importancia de cada una de ellas. En todo momento hablamos de un modelo de producción que he visto aplicar en otras empresas en las que he participado y que se utiliza en FactorSIM, pero seguro que hay otros modelos mejores o peores que el que voy a describir y seguro que tienen sus ventajas. No seré yo quien descubra América.

Como punto de partida, recomiendo la siguiente presentación. En ella se describen algunos conceptos de la formación on-line y encontraremos ejemplos de contenidos y materiales formativos.

Para realizar el análisis, he pensado en un modelo de curso e-learning cuyo origen sean unos materiales facilitados por el cliente (por ejemplo el famoso Word) y el objetivo del proceso sea generar un material autoformativo que se pueda implementar en la plataforma. Para el supuesto, concretamos que el contenido tendrá alguna animación que explique mejor una parte del contenido, esquemas, un vídeo de 5 minutos que hay que digitalizar y añadir al contenido, así como un cuestionario de 20 preguntas. En total, unas 20 pantallas que derivan de un documento word de 40 páginas y 3 documentos adicionales. Además, lo haremos en 1 idioma y en formato web.

Lo primero de todo, hay que entender que los materiales se reproducirán en una maqueta de contenidos (en la imagen se puede ver una prueba conceptual de diseño para un curso tipo).

Esta maqueta incorpora las herramientas básicas de interacción (un menú lateral, botones de navegación, carga de objetos, y todo el diseño gráfico de los diferentes recursos). Además de controlar la comunicación con la plataforma de formación. Aunque tengas una maqueta base, siempre hay matices que hay que adaptar al cliente, así como la imagen gráfica general.

Es importantísimo saber que hoy en día estamos condicionados por la tecnología. No es lo mismo desarrollar para un IPAD que para un PC que para una Blackberry. Aunque hay contenidos que podemos desarrollar de forma transversal, hay matices importantes que condicionan el producto. Por ejemplo, en IPAD no hay flash y no hay rollover, además de tener un navegador específico, en PC/Mac hay al menos de 10 navegadores diferentes (sólo contando los más habituales) que pueden interpretar de diferentes formas el código que programas. Para Blackberry, o bien desarrollas para web o bien adaptas el contenido a pantalla más pequeña, con la consiguiente duplicación de costes. Sumemos otros tablets, iphone, notebooks…

Es por ello, que muchas veces, se realiza un único desarrollo pensando en visualización en web (navegador), buscando unos mínimos de visualización, y acotando los navegadores principales. Asegurar que un proyecto se vea bien en todos los entornos es como pedir que un traje vaya bien a todos. No podemos controlar quien llevará el traje, si será alto o bajo, gordo o flaco, así que tenemos que diseñarlo para un par de modelos.

Una vez hecha esta introducción, vamos a ver qué perfiles/fases deberían intervenir y cuales son sus funciones:

Gestión/Gestor de proyecto. Es el gran “olvidado” de la producción. Realiza un trabajo invisible pero fundamental. Un buen gestor ha de saber conducir el producto a lo que el cliente necesita, ayudarle a tomar decisiones y aconsejarle qué opción tomar. Ha de pensar tanto en el cliente como en el equipo de producción, controlar calendarios, realizar reuniones de seguimiento y es el centro neurálgico de la producción. Para que un proyecto llegue a cabo en tiempo y en la calidad acordada, hace falta una buena gestión de la producción.

Normalmente, el propio gestor de proyecto es el experto en metodología, pero a veces no es así o el proyecto requiere de una figura específica.

Análisis/Experto en metodología. Es la persona que decide cómo se ha de virtualizar un contenido, en formato, tecnología y procesos. No es lo mismo virtualizar un curso de leyes, que uno de ventas o de idiomas. Cada curso tienen unas necesidades de comunicación e interacción y por tanto, requerirá de unos recursos diferentes y un formato ad-hoc. Un experto podrá aconsejar al cliente que realice un caso práctico que se resuelva a lo largo del curso, que reformule el contenido para hacer un juego o que proponga utilizar otros medios para desarrollar la acción formativa, por ejemplo, usar una red social para realizar la formación. Esta figura (ya sea combinada con el gestor o por separado) es clave en la primera fase de trabajo, ya que determina cómo se han de producir los contenidos.

Hay que matizar que un curso on-line normalmente tiene detrás una gestión de la formación, una tutorización, una metodología que vincula el contenido con el tutor y con el aula on-line. Esta parte es tan importante como el propio contenido y es el experto y el gestor, que conocen al cliente, sus necesidades y recursos, es quien ayuda a definirla.

Diseño y programación de la maqueta/Programadores y diseñador. Por maqueta entendemos la interface general (botones de navegación, menús, seguimiento SCORM). Puede ser que tengamos una maqueta o que haya que desarrollar una nueva. En cualquier caso, en esta fase necesitaremos un diseñador gráfico, un programador de SCORM y un programador web. Es conveniente además, que el diseñador tenga unos fuertes conocimientos de usabilidad.

Revisión material/Tratamiento didáctico/Pedagogo. El cliente normalmente facilita unos materiales pensados para imprimir o que se utilizan en presentaciones. Estos contenidos se han de leer, revisar y se redactan pensando en una navegación por pantalla. Esta figura se encarga de definir esquemas, crear animaciones, cuestionarios, buscar recursos adicionales y organizar la información que luego se tendrá que virtualizar.

Virtualización/Maquetadores, ilustradores, animadores. Los contenidos se han de pasar del formato editado en la fase anterior a la maqueta interactiva. Hay que crear los gráficos y esquemas, así como las animaciones. En algunos casos, es necesario buscar fotos de catálogos, realizar ilustraciones o digitalizar vídeos.

En esta fase se revisa el material en los diferentes navegadores que se hayan definido previamente en el proyecto.

Calidad y testeos. El contenido antes de enviar a cliente, es revisado tanto por el experto en metodología como por una figura externa al proceso que garantice una visión objetiva. Una vez testeado, se envía el contenido al cliente y lo habitual es entrar en al menos 1 ronda de cambios menores.

Cierre y documentación. Una vez cerrado el proyecto y entregado al cliente, es conveniente hacer la documentación del mismo y un informe ejecutivo.

En otros proyectos, necesitaremos gestionar o formar autores, analistas de sistemas, productores de vídeo, animadores 3D, locutores, actores, ilustradores, creación de campus de formación, tutores… También hay que contar un tiempo para manuales y gestión de los materiales. Además el equipo ha de contar con una metodología de trabajo y protocolos claros de comunicación y gestión de la producción (control de versiones, herramientas de intercambio y gestión de tickets…)

Conclusiones

Está claro, que para conseguir el producto deseado, necesitamos estos perfiles, estas fases y el tiempo asociado. Es fácil imaginar que aunque sean 7 u 8 horas por fase (en realidad son bastantes más), al final suman un número elevado. Y que si aplicamos un precio/hora convencional, obtenemos el valor esperado del proyecto. En este punto, lo que acostumbra a suceder es que el cliente, lo considera un gasto excesivo (al final lo barato se paga caro), y para poder acometer el proyecto, se reducen perfiles, se unifican funciones o se ajustan los tiempos, abaratando el proyecto, pero perdiendo calidad.

Pero hay clientes que conocen el modelo, que saben el esfuerzo que hay detrás, que te ayudan y colaboran en la creación de su proceso de formación, que valoran y te facilitan el trabajo. Esos clientes pagan por crear un curso e-learning, no por una conversión automática de un word.

En este caso si que se trata de un espacio creado en Drupal que nos permite tener localizados los datos, claves de acceso y referencias de Proyectos/Clientes/Proveedores, dejando para el otro gestor la información de seguimiento.

Todavía está en fase de “pulido”. Lo siguiente es comunicarse con el gestor de horas y seguimiento para que la información de Clientes y Proveedores la capture directamente desde Drupal.

Estamos incorporando un centro de coste (ID) a todos los proyectos, de manera que podemos desarrollar canales de comunicación de datos entre los diferentes gestores (horas/información) y con otras herramientas (DocuWiki, Blog o Trac)…

Ante la necesidad de profesionalizar la gestión de interna de proyectos y no encontrando una alternativa en el mercado que solucione nuestras necesidades (muchos se acercan pero ninguno se ajusta), hemos decidido desarrollar una herramienta para tal fin. Nuestro principal interés era detectar que proyectos tienen desviaciones importantes para conocer las causas de estas desviaciones y ayudarnos a ajustar futuros desarrollos.

La herramienta que hemos implementado es un Gestor de proyectos clásico, como DotProject y permite el registro de una serie de proyectos, vinculados a clientes y una serie de recursos que modelan los diferentes trabajadores de la empresa con sus perfiles. Los gestores de proyecto pueden elaborar presupuestos y planificar la producción de los mismos, asignando planificaciones temporales a éstos recursos en función de los perfiles disponibles.

El sistema permite, a su vez, dar de alta proveedores y contabilizar las facturas emitidas a dichos proveedores.

Los trabajadores de la empresa accederán al sistema para consultar cual es su planificación actual, los hitos de los proyectos a los que están vinculados y el calendario de festivos de la empresa. Para que la herramienta funcione correctamente, deberán actualizar una parrilla de gestión de horas con las horas que han dedicado a cada uno de los proyectos. El sistema además permite asignar a cada recurso un horario laboral predefinido, que permite conocer posibles desviaciones horarias en los diferentes recursos.

Ésta parrilla de horas imputadas a cada proyecto nos permite, juntamente con las facturas emitidas a proveedores, establecer un preciso control presupuestario y de márgenes. De esta manera, podremos determinar los costes internos, costes externos, margenes y desviaciones con respecto al presupuesto original y diagnosticar de manera fiable cual ha sido la fuente de ésta desviación.

En un futuro, nuestra intención es ampliar esta herramienta para incorporar detalles de facturación y otras funcionalidades que consideremos que puedan resultar de interés para una gestión integral de la producción de la empresa.

Tampoco descartamos ofrecer esta herramienta a nuestros clientes, dentro de nuestro catálogo de productos actual.

Hay ya muchos textos escritos sobre Subversion, pero hoy no hablaré de sus características, de lo que puede hacer ni de cómo lo hace. Hoy me centraré en qué es lo que le encontramos interesante para utilizarlo como herramienta en una empresa. En otras palabras: por qué lo utilizamos.

• Ha llamado un cliente. Dice que tiene un problema con la versión j29rc20. ¿Alguien sabe de dónde puedo conseguir esa versión para hacer unas pruebas?

• Uffff… j29rc20 significa “jueves 29, versión que estaba en el discoduro de Ricardo Cano a las 2:00”. ¡A saber dónde estará esa versión ya ahora!

Subversion guarda todas las versiones que pasan por sus manos. Además, permite dar un nombre (etiquetas, en nomenclatura SVN) a cualquiera de esas versiones. Así, si j29rc20 fuese una etiqueta SVN, obtener esa versión seria trivial.

• ¡Ostras! ¡He copiado esta versión encima de la antigua pensando que no tenía nada importante y me he cargado todo mi trabajo de la última semana!

En un repositorio SVN, la incorporación y mezcla de los cambios hechos por los diferentes usuarios (o incluso de copias de trabajo distintas de una misma persona) se realiza de manera automática, garantizando que nadie sobreescribe el trabajo de otro. Y si has borrado un archivo que no debías o has hecho cambios que no son correctos, siempre puedes recuperar cualquiera de las versiones anteriores que hay guardadas.

• ¿Cuando corregimos la alineación de las imágenes para IE6 lo hicimos mediante CSS o JS?

Subversion permite comparar fácilmente cualquier par de versiones de cualquier archivo. Si unimos a esto la posibilidad de explicar en los comentarios qué es lo que hemos modificado en cada versión, responder a esta pregunta es tan fácil cómo ojear la lista de comentarios e inspeccionar las diferencias de la versión relevante con la anterior. Además, nos vendrá de regalo la información sobre quién hizo ese cambio y cuándo.

• Queremos implementar una funcionalidad experimental que va a afectar la estabilidad del proyecto pero incluirla en la siguiente versión sólo si está ya suficientemente estable. Nos arriesgamos a ir haciendo los cambios o cómo lo hacemos?

En el mundo SVN la respuesta es única: mediante una rama. En cada rama que creemos podremos tener una evolución independiente del mismo código, de manera que no se interfieran entre ellas. Crea una rama nueva para implementar allí la funcionalidad experimental. Cuando el código esté maduro podrás integrar fácilmente los cambios en la rama principal antes de hacer la nueva versión. Si esa integración de cambios no llega a tiempo, la rama principal incorporará otros cambios no desestabilizadores pero nada de la rama experimental.

• Tenemos un directorio JS que es común a todos estos proyectos, pero ahora ha llegado una versión nueva del JS. ¿Tenemos que copiarlo a todos los proyectos uno por uno?

En SVN, no. Separa el directorio JS en un apartado del repositorio y vincúlalo al resto de proyectos. De esta manera, los cambios de cualquiera de los proyectos se trasladarán al JS común y de ahí a todos los demás proyectos. Modifica el JS común o la copia vinculada a cualquiera de los proyectos y todos los demás sitios se actualizarán por arte de magia. Todo lo que dijimos antes sobre la seguridad de no sobreescribir cambios de otros y las versiones se aplica aquí también, por supuesto.

Pero no todo es de color de rosa…

Subversion al fin y al cabo es sólo una herramienta. Que resulte beneficiosa o nociva depende del uso que se le dé. Hay algunos problemas muy comunes:

Subversion permite tener todos los archivos de un proyecto muy bien ordenados e indentificados. Pero no obliga a ello. De hecho, con etiquetas, ramas, vínculos y una estructura de directorios mal definida SVN puede llevarnos a un nuevo nivel de caos desconocido hasta la fecha.

Por otro lado, como cualquier otra tecnología, requiere un aprendizaje. Trabajar con una copia de trabajo en SVN es muy similar a trabajar con archivos normales. Demasiado parecido. Pero quienes acostumbren a copiar proyectos (o partes de ellos) de un directorio a otro se encontrarán con unas cuantas sorpresas desagradables al intentar sincronizar su trabajo con SVN, sin ir más lejos. También hay que aprender a crear archivos nuevos, borrarlos o incluyo renombrarlos o cambiarlos de sitio cuando residen en un proyecto SVN. Es igual de sencillo que hacer esas operaciones sobre archivos normales, pero hay que recordar que la manera concreta de hacerlo cambia.

Por último, para aprovechar los proyectos organizados que nos posibilita un repositorio de código lo mejor es tener una gestión organizada. Una gestión que establezca claramente las entregas, las versiones, los objetivos de cada una de ellas, las iteraciones de testeo y corrección de errores, etc…

Pero todo esto es ya material para otro post (sí: es una amenaza).