Soporte documental y gestión

  • Ramon G. Sedó

  • Laura Benítez García

  • Eugènia de Vilar Font

PID_00214570
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico, químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita de los titulares del copyright.

Introducción

La gestión de proyectos requiere la existencia de un soporte documental en el que esté toda la información necesaria tanto para la correcta gestión del proyecto como para su desarrollo. A su vez, tan importante es generar esta documentación como crear un sistema de archivo simple y eficaz que permita que los miembros del equipo de trabajo y el cliente puedan acceder de forma rápida a la documentación que necesitan.
Para que el soporte documental sea realmente útil, debe haber un responsable de coordinar el repositorio documental. El coordinador será el responsable de definir los tipos de documentos que se elaborarán durante la vida del proyecto, de establecer una codificación concreta para el proyecto y de proporcionar plantillas para los distintos tipos de documento. Sin esta coordinación, es fácil que, aunque se genere documentación, acabe apareciendo información duplicada o que la documentación generada sea incompleta.
En este módulo se facilitan plantillas de muchos de los principales tipos de documentos que forman parte del soporte documental de un proyecto (la descripción de proyecto, la matriz de responsabilidades, la descripción de actividad, etc.) y se dan pautas de elaboración, explicando para qué es útil cada tipo de documento.
Se describe también en el módulo cómo desarrollar correctamente la memoria de un proyecto interactivo multimedia, aportando los puntos principales que se deben desarrollar, y se presentan dos alternativas distintas para facilitar la gestión compartida del soporte documental de un proyecto: los sitios de proyecto (project sites), sitios web en los que se organiza la información de un proyecto, y los softwares de grupo (groupwares), softwares de gestión compartida de proyectos con muchas herramientas que facilitan la comunicación asíncrona entre los miembros del proyecto.

1.La importancia del soporte documental

Cualquier actividad mercantil genera, por su propia naturaleza, una documentación propia, como pueden ser contratos, presupuestos, facturas, etc. Un proyecto multimedia, como actividad mercantil que es, también genera todo este tipo de documentación relacionada con las actividades económicas de prestación de servicios. Pero, además, la correcta gestión de un proyecto multimedia requiere otro tipo de soporte documental relacionado estrictamente con el proyecto, y no tanto con la actividad económica que supone.
En los proyectos multimedia se trabaja sobre un concepto abstracto que los miembros del equipo del proyecto van haciendo realidad. Este concepto abstracto debe conceptualizarse de alguna forma, sea mediante guiones o con documentos como la descripción de proyecto o la memoria. Este soporte documental posibilita que todos los miembros del equipo de desarrollo de un proyecto tengan la misma idea en la cabeza y caminen hacia los mismos objetivos orientando todo el diseño al mismo usuario.
Por otra parte, para la correcta gestión de un proyecto es necesario realizar documentos que informen de qué trabajo debe realizar cada miembro del equipo o dejar constancia escrita de las decisiones y las modificaciones importantes.
Además de toda la documentación que se genera a lo largo del desarrollo de un proyecto y que es de uso interno del equipo de trabajo o del jefe de proyecto, también hay una parte documental que se lleva a cabo para informar al cliente: al principio del proyecto para saber que está de acuerdo con lo que se va a realizar, a lo largo de su desarrollo para ir informándole del avance del proyecto y, al final, para que el cliente sepa cómo manejar el producto multimedia entregado y, en el caso de que sea un desarrollo (software) que deberá mantener, la información relacionada sobre la tecnología empleada y cómo ha sido aplicada esa tecnología al proyecto o producto entregado.

1.1.Documentación

76529_m3_01.gif
Como vemos en el esquema, en un proyecto vamos a generar diversa documentación que se necesita para gestionarlo correctamente. Pero si esta documentación no está correctamente archivada será difícil de localizar y, por lo tanto, no tendrá utilidad. Es tan importante generar correctamente los documentos, como codificarlos y ordenarlos correctamente.
Los miembros del equipo de trabajo deben tener la posibilidad de acceder de forma fácil y rápida a la documentación que necesiten o que deban rellenar. Para ello es imprescindible crear un espacio (físico o virtual) en el que esté toda la documentación del proyecto correctamente organizada, sea por carpetas, por base de datos, por índice o por el sistema que cada equipo y cada jefe de proyecto desee.

1.2.Documentar

A menudo, cuando se les habla de gestión de proyectos o de project managament, las personas se quejan porque piensan que dirigir un proyecto siguiendo esta metodología conlleva una gran carga administrativa, por la cantidad de "papeleo" que se genera. En efecto, si el soporte documental de la gestión de un proyecto no se realiza adecuadamente, puede llegar a ser una carga y una gran pérdida de tiempo. Algunas empresas que quieren aplicar una gestión de proyectos muy estricta creen que el proyecto estará mejor gestionado cuanta más documentación se genere, y esto no es así. Se debe generar sólo la documentación que se necesite según el proyecto. Aparte, como se ha visto en el apartado anterior, es tan importante crear la documentación como tenerla bien archivada para no perder tiempo cuando se busque.
Pero en la gestión de proyectos no todo es blanco o negro. Entre generar una gran cantidad de documentación mal organizada y no generar ningún documento, hay una gran escala de grises que depende de cada metodología de trabajo, del proyecto en concreto y de la cantidad de información que nos pida el cliente.
La metodología de la gestión de proyectos (project management) requiere un conjunto de documentos que den soporte a la toma de decisiones que se van generando a lo largo del proyecto. Por ejemplo, un documento estrictamente necesario es el de la descripción de proyecto. Todos los miembros del equipo de trabajo, además del cliente, deben tener clara esta descripción y han de poder acceder a ella en cualquier momento de duda. El hecho de crear un documento que contenga esta información es una herramienta, una ayuda. En ningún momento la documentación debe ser un fin. Generamos un documento porque va a ser útil a lo largo de la vida del proyecto y porque formalizar una información por escrito es el método más fácil que tenemos para que quede todo claro y para que, a la vez, puedan acceder a ella todos los que necesitarán la información concreta que pongamos en el documento.
La documentación es un soporte y una herramienta de la gestión de proyectos, no un fin.

1.3.Coordinación de la base de conocimiento

Se denomina base de conocimiento del proyecto al repositorio en el que están almacenados todos los documentos del proyecto: los documentos internos, los documentos para entregar al cliente, los diagramas, los mapas, las minutas, los cronogramas, los planes, las buenas prácticas, las lecciones aprendidas, etc.
En todo proyecto debe existir un rol de coordinador de la base de conocimiento. En proyectos pequeños este rol lo adopta el jefe de proyecto; en proyectos grandes puede que haya una persona específica dedicada a ello.
Éstas son las responsabilidades del coordinador de la base de conocimiento:

  • Determina qué porción de la base de conocimiento de otros proyectos es relevante en el proyecto actual. Cuando el proyecto está a punto de empezar, extrae información relevante de otros proyectos para usarla en el proyecto actual. La base de conocimiento no comienza vacía, sino que se usan plantillas y otros documentos históricos.

  • Desarrolla e implementa con el gerente de proyecto y el equipo cómo se administrarán los documentos en el proyecto. Impone disciplina para manejar los documentos, define la nomenclatura de los mismos, controla quién carga documentos en la base de conocimiento...

  • Publica, revisa los documentos publicados y hace cumplir en el proyecto los estándares definidos para el mismo o procedentes de la organización. Produce un documento que describe los estándares y las reglas de la base de conocimiento para cualquier involucrado en el proyecto.

  • Supervisa y controla el acceso y las actualizaciones a la base de conocimiento. Es el guardián de los documentos, define seguridad y accesos a la base de conocimiento, pide a los miembros del equipo que la enriquezcan, piensa en función de proyectos futuros, etc.

1.4.Procedimiento de codificación de un proyecto

Para una correcta organización de la documentación de un proyecto, es muy útil, en primer lugar, codificar el proyecto, y en segundo lugar, hacer que el nombre del proyecto y su código estén presentes en cualquier documento. Se debe tener en cuenta que normalmente las empresas no trabajan en un solo proyecto. Si titulamos a un documento "descripcion.doc" y en su interior sólo ponemos el título "Descripción de proyecto" o si el documento no está debidamente organizado se pueden producir confusiones, ya que no se sabrá a qué proyecto corresponde esta descripción.
En los documentos importantes, también es útil poner siempre la fecha, quién es el autor y, si procede, quién lo ha aprobado. Si hay alguna duda concreta sobre una información que se lee en un documento, siempre sabremos a quién debemos acudir (porque ha redactado el documento) o si este documento en cuestión está aprobado o pendiente de aprobación por el jefe de proyecto, el cliente o el responsable de área.
Para la identificación de los documentos relacionados con un proyecto, es muy útil contar con una codificación clara. Así se formaliza la documentación que se obtiene de cada proyecto.
Ejemplo
Un ejemplo de codificación de los documentos puede ser el siguiente:
Código de proyecto. Nombre o identificador asociado al proyecto.
Código de documento. Nombre o identificador del tipo de documento:

  • DDP. Documento de descripción del proyecto

  • DJP. Documento de definición del jefe de proyecto

  • DAP. Documento de alcance del proyecto

  • DMR. Documento de matriz de responsabilidades

  • DPT. Documento de plan del trabajo

  • DCR. Documento de cuadro de recursos

  • DAC. Documento de actividades del proyecto

  • DIA. Documento de informe de avance

  • DAR. Documento de acta de reunión

  • DIR. Documento de informe final

Codificación de la versión. Número que indica la versión del documento en cuestión.
Codificación de la fecha. Formato de codificación de la fecha: "aaaammdd".
Así, ejemplos de nombres de documentos codificados podrían ser los siguientes:
Código de proyecto. Web promocional Acme, WPA

  • WPA-DDP-v0-20100123. Versión inicial del documento de definición del proyecto WPA

  • WPA-DDP-v3-20100202. Versión 3 del documento de definición del proyecto WPA

  • WPA-DAR-v0-20100123. Versión 0 de un acta de reunión del proyecto WPA

  • WPA-DIA-v1-20100123. Versión 1 de un informe de avance del proyecto WPA

1.5.La comunicación en el proyecto

La documentación en un proyecto es la base sobre la que debe sostenerse la comunicación dentro del mismo. La documentación es el medio por el que se mantienen las relaciones entre los distintos miembros del equipo del proyecto y entre el cliente, los proveedores, los patrocinadores, etc.
Para que la comunicación con todas las personas e instituciones involucradas en el proyecto sea exitosa, se debe determinar, desde el inicio del proyecto, quién requerirá información sobre el avance y el desarrollo del proyecto.
Una vez identificados los consumidores de esta información, es necesario definir qué datos requerirá cada uno y si los requerirá de forma regular, esporádica o eventual. Para ello se debe analizar cuál es la relación entre el involucrado y el proyecto. Aquellas personas o instituciones directamente involucradas en la ejecución del proyecto requerirán información detallada de forma regular. El resto requerirá información menos detallada y de forma esporádica.
La planificación de las comunicaciones de un proyecto consiste en definir lo siguiente:

  • ¿Quién requerirá información sobre el proyecto?

  • ¿Qué información?

  • ¿Con qué frecuencia?

  • ¿Cómo se recogerá esta información?

  • ¿Cómo se procesará y se almacenará?

  • ¿Cómo se distribuirá?

Partiendo de las preguntas mencionadas anteriormente y de estas características se debe elaborar el plan de comunicación del proyecto.
Además, en la distribución de los documentos debemos plantearnos las distintas características del medio empleado.
Sobre la base de las preguntas anteriormente mencionadas y de estas características, debe elaborarse el plan de comunicación del proyecto.
Actualmente hay una gran cantidad de herramientas en línea que permiten la comunicación entre los miembros del equipo de una manera síncrona o asíncrona. Estas herramientas también se denominan software colaborativo.
Aquí os ofrecemos enlaces a artículos adicionales que tratan sobre el uso de algunas de estas herramientas disponibles en línea:
Herramientas de trabajo colaborativo

  • Google Apps. Herramientas gratuitas de correo electrónico y de colaboración para el ámbito personal, profesional, educativo e institucional. Es un conjunto de programas basados en web para crear documentos en línea con la posibilidad de colaborar en grupo. Incluye correo electrónico, procesador de textos, hoja de cálculo, programa de presentación básico y un editor de formularios destinados a encuestas: Gmail, Calendar, Drive/Docs, Grupos, Sites...

    http://www.google.com

  • eGroupWare. Solución de trabajo en grupo vía web, de código abierto. Incluye un calendario, una libreta de direcciones, un gestor de contactos, un cliente de correo electrónico IMAP, 1 InfoLog, funciones de CRM, un gestor de proyectos, un gestor de recursos, un gestor de ficheros, una plantilla de tiempos, una wiki, una base de conocimiento y un motor de flujos de trabajo.

    http://www.egroupware.org

  • TalkAndWrite. Software interactivo en tiempo real que simula la interacción de dos personas que trabajan una junto a otra en un documento en común.

    http://www.talkandwrite.com

  • Open Atrium. Dispone de calendario, gestor de incidencias, documentos organizados en libros, blogs, un escritorio e incluso un tipo de muro estilo Facebook para compartir enlaces, trucos y pensamientos.

    http://openatrium.com

Comunicación personal, videoconferencia y mensajería instantánea
Otras herramientas de interés

  • Glinkr. Herramienta para hacer mapas mentales en línea.

    http://www.glinkr.net/

  • Bubbl.us. Integra la lluvia de ideas de un equipo de trabajo para hacer en línea un mapa mental.

    https://bubbl.us

  • Sneffel. Permite que varios miembros de un equipo dibujen al mismo tiempo en un papel o pizarra virtual en las pantallas de los ordenadores.

    http://www.sneffel.com/

  • Edistorm. Decenas de post-it juntos en un mismo lugar para permitir la visualización de las ideas escritas por cada uno de los miembros del equipo y elegir las mejores para iniciar un trabajo o proyecto.

    http://www.edistorm.com/

  • Zoho. Herramienta para administrar las tareas de un equipo de trabajo.

    http://www.zoho.com/

  • Mind42. Plataforma para poder elaborar mapas mentales en línea de una manera sencilla entre varios miembros de un equipo.

    http://mind42.com/

2.Documentos de soporte a la gestión de proyectos

La gestión de proyectos genera y requiere, como hemos dicho anteriormente, un soporte documental. Algunas profesiones, como por ejemplo la arquitectura, tienen un colegio profesional que marca unos estándares de documentación para entregar en un proyecto (memoria, pliego de condiciones, etc.). El mercado multimedia es tan joven y tan dinámico que aún no se han creado estándares de este tipo, por lo que las plantillas de documentos que aquí se presentan se facilitan a modo de orientación, y deben adaptarse para cada proyecto a la metodología de trabajo que corresponda. Algunas organizaciones, sobre todo administraciones públicas y empresas de consultoría de proyectos, tiene sus propias definiciones para la documentación que se debe generar para cada proyecto. En otros casos será el jefe de proyecto el que defina la metodología que hay que seguir en función de sus conocimientos metodológicos y del proyecto en cuestión.
El tamaño del proyecto condiciona enormemente el soporte documental que se genera. Un proyecto pequeño con un grupo de trabajo también reducido necesitará poco soporte documental. Un proyecto grande, en cambio, requerirá que se genere más documentación, ya que habrá más información compleja que se necesitará formalizar en un documento y, además, habrá mucha gente que necesitará poder acceder a esa información del proyecto de forma ágil. La documentación generada para un proyecto de un mes con dos personas trabajando en él no puede ser la misma que la generada en un proyecto que tenga una duración estimada de seis meses e involucre a un equipo de trabajo de unas diez personas.

2.1.Descripción de proyecto

El documento de descripción de proyecto es uno de los más importantes del soporte documental a la gestión de proyectos. Es el punto de partida a partir del cual todos los miembros del equipo de trabajo empiezan sus diseños. Debe ser muy claro y conciso, y el registro que usemos en su redacción no debe ser excesivamente técnico, ya que este documento lo deben entender el cliente, el jefe de proyectos y todos los miembros del equipo, los de las áreas de contenidos, artística y técnica.
La descripción de proyecto ha de resumir toda la información básica del proyecto. Después de leer este documento, cualquier persona debe saber en qué consiste el proyecto, cuáles son sus objetivos y con qué coste aproximado y en qué tiempo debe realizarse.
En el caso de que se haya obtenido una "Definición de proyecto aportada por el cliente" o un briefing elaborado por el equipo de desarrollo del proyecto pero aprobado por el cliente, la descripción de proyecto se hará a partir de la información proporcionada o aprobada por el cliente y de los conocimientos del equipo de desarrollo del proyecto.
Este documento se puede ir ampliando a lo largo del proyecto, de manera que acabe convirtiéndose finalmente en la memoria del proyecto.
El documento de descripción de proyecto se crea en la fase inicial del proyecto y normalmente lo escriben sus máximos responsables.
A continuación, se propone una plantilla de descripción de proyecto basada en la propuesta por Jaime Pereña en su libro Dirección y gestión de proyectos.
Fuente: Jaime Pereña Brand (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.
Fuente: Jaime Pereña Brand (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.

2.2.Definición de jefe de proyecto

El jefe de proyecto suele ser el responsable de generar y de definir la documentación del proyecto, pero no todas las empresas dan la misma autonomía a los jefes de proyecto. En ocasiones los jefes de proyecto sólo ejercen una actividad de coordinación, y en otras, en cambio, tienen mucha autonomía en la toma de decisiones.
Por este motivo, el documento de definición de jefe de proyecto es muy útil como base de referencia para saber hasta dónde puede decidir de forma autónoma el jefe de proyecto y a partir de dónde ya no.
Independientemente del formato que se le dé, las informaciones básicas que este documento debe contener son las siguientes:

  • Qué función principal tiene el jefe de proyecto en relación con la empresa o con el proyecto.

  • Dónde está dentro de la estructura organizativa de la empresa y del proyecto.

  • Qué actividades debe realizar.

  • De qué medios propios dispone (humanos y materiales).

  • Qué libertad de decisión tiene (en qué aspectos puede decidir él sólo y en cuáles no).

En el libro de Pereña antes citado, tenemos el siguiente ejemplo de documento de definición de jefe de proyecto:
Fuente: Jaime Pereña Brand (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.
Fuente: Jaime Pereña Brand (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.

2.3.Matriz de responsabilidades

Para saber quién puede decidir qué (lo que lamentablemente es uno de los grandes misterios de muchas empresas grandes con un gran equipo directivo), existe otro documento muy útil: el de matriz de responsabilidades.
El documento denominado matriz de responsabilidades puede realizarse para decidir las responsabilidades de la empresa en general o para formalizar quién debe realizar qué en un proyecto. Lo importante es que en un eje se coloquen las decisiones que se deben tomar o las actividades que se han de realizar, y en el otro eje de la matriz se indiquen las personas. Se puede crear un código propio, como por ejemplo que el número 1 sea quien lo realiza, el número 2 sea quien lo aprueba y el número 3 sea el destinatario del documento.
En resumen, la matriz de responsabilidades es útil para identificar qué personas deben intervenir en un proyecto y a quién incumbe cada decisión de las que se han de tomar. Es un documento que puede ser útil para diferentes proyectos parecidos, ya que es muy fácil de adaptar a nuevos proyectos. Normalmente lo realizan los directivos de la empresa o del proyecto.
A continuación, se puede ver una matriz de responsabilidades de un proyecto, que sirve para ver quién realiza cada actividad en el proyecto y quién aprueba las distintas fases.
Fuente: Jaime Pereña Brand (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.
Fuente: Jaime Pereña Brand (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.

2.4.Plan de trabajo

Cuando el jefe de proyecto planifica todo el trabajo que se deberá realizar a lo largo del proyecto, normalmente genera un documento que resume el conjunto de actividades que hay que desarrollar debidamente ordenadas según su orden previsto de ejecución. A menudo, esta información se formaliza gráficamente en un diagrama de Gantt, diagrama que muestra el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo del tiempo total del proyecto.
El diagrama de Gantt, desarrollado por Henry Laurence Gantt, es un método gráfico de planificación y control en el que un proyecto se divide en diferentes actividades y se hacen estimaciones sobre cuánto tiempo requiere cada una, así como sobre el total de tiempo necesario para acabar el proyecto por completo.
Henry Laurence Gantt refinó el concepto de utilizar un gráfico de barras para controlar las medidas pertinentes para el proceso de la construcción naval. Durante el siglo xx, la parte esencial de su diagrama del proceso se aplicó a los proyectos que no tenían nada que ver con la construcción de barcos. Hoy en día, el diagrama de Gantt se utiliza para establecer una red de precedencia que determina el nivel de prioridad de cada tarea asociada con el proyecto.
Adjuntamos diferentes enlaces con información adicional sobre esta herramienta y su creador:
Aparte de Microsoft Project, existen otras herramientas que permiten generar diagramas de Gantt (véase el apartado 2.2 del módulo 2).
A continuación, a modo de ejemplo, podemos observar un diagrama de Gantt.
76529_m3_05.gif

2.5.Histograma de recursos

Otro documento que se acostumbra a realizar cuando se diseña el plan de trabajo es el cuadro o histograma de recursos. En él se especifica quién va a estar trabajando en el proyecto cada día. Se organiza en dos ejes: el vertical, con los recursos, y el horizontal, con el tiempo (distribuido en días o en la unidad de tiempo que sea más cómoda).
Este documento es útil para que el jefe de proyecto sepa cuánta gente está trabajando cada día, para comprobar que, por ejemplo, no haya planificado más recursos humanos que ordenadores hay para trabajar, etc.
A modo de ejemplo, a continuación se proponen dos gráficos de recursos:
76529_m3_06.gif

2.6.Diario de actividad

En las actividades importantes es muy útil que el responsable de la actividad o la persona que esté inmediatamente por encima de él en la toma de decisiones lleve un control de dichas actividades. En este documento, que se puede llamar diario de actividad, se recogen todos los hechos o las incidencias verdaderamente significativos de forma muy resumida. La elaboración de este documento es útil para, si ha habido un retraso significativo en una actividad, ver qué incidencias han ocurrido y así no volver a cometer el mismo error en proyectos o planificaciones futuros.
Obligatoriedad del diario de actividad
En algunas profesiones es obligatorio llevar un diario de actividad. Los arquitectos, por ejemplo, deben llevar al día un cuaderno de seguimiento de las obras en el que anotan los hechos más importantes de cada visita de obra que realizan. El Colegio de Arquitectos obliga legalmente a que estos profesionales lleven este control, un control que finalmente sellará el citado colegio. En la actividad multimedia no es obligatorio llevar este control desde el punto de vista legal, pero es muy recomendable hacerlo si el proyecto es grande.
A continuación, se propone la plantilla de diario de actividad que Jaime Pereña recomienda:
Fuente: Jaime Pereña Brand (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.
Fuente: Jaime Pereña Brand (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.

2.7.Informe de avance

En proyectos muy grandes y que tengan un tiempo estimado de ejecución de muchos meses, a menudo se pacta con el cliente el envío sistemático de informes de avance del proyecto. La periodicidad de estos informes depende de lo pactado, pero acostumbran a ser o semanales o mensuales.
En este documento se deben concretar los avances realizados desde el último informe, así como los posibles desvíos respecto a la planificación temporal y de costes. También se debe informar sobre si en el último período ha habido alguna incidencia, así como de las medidas correctoras que se han tomado. Por último, es importante detallar todos los anexos que se adjuntan al informe de avance, como pueden ser bocetos, maquetas, etc.
Normalmente el informe de avance lo redacta el jefe de proyecto.
A continuación, se propone una plantilla de informe de avance:
Fuente: Jaime Pereña Brand (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.
Fuente: Jaime Pereña Brand (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.

2.8.Modificación

El carácter dinámico de los proyectos multimedia provoca que a menudo, durante su curso, surjan propuestas de modificación del proyecto, sea porque lo pide el jefe de proyecto (por ejemplo, porque después de realizar un análisis de alternativas tecnológicas completo se ve que la solución prevista no es la óptima) o bien porque sea el mismo cliente quien lo pide.
Estas modificaciones se deben formalizar en un documento de propuesta de modificación cuando su aplicación afectaría a:

  • La fecha de entrega del proyecto.

  • Los objetivos del proyecto.

  • El coste del proyecto.

En el documento se debe explicar cuál es la modificación que se propone y por qué, así como la resolución que finalmente se adopta, una vez que la persona encargada de aprobar o no la modificación tome una decisión.
A continuación, se puede observar una plantilla de propuesta de modificación:
Fuente: Jaime Pereña Brand (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.
Fuente: Jaime Pereña Brand (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.

2.9.Acta de reunión

Mucha gente piensa que hacer actas de las reuniones es una tontería y que es perder el tiempo, y cuando va a una reunión pide una hoja en blanco y se apunta los puntos más importantes de la reunión en la hoja. A menudo es la misma gente que, cuando busca la hoja donde apuntó esa información que se pactó en la reunión (por ejemplo, el presupuesto), no la encuentra y tiene que enviar un correo electrónico o llamar para que se lo digan, lo que sí que es, posiblemente, perder el tiempo.
Naturalmente, no es necesario levantar acta de todas las reuniones que se realizan en el curso de un proyecto (que son muchísimas), pero en los proyectos grandes es importante hacer un documento de acta de reunión en aquellas reuniones en las que se sepa que se van a tomar decisiones importantes relacionadas con la evolución del proyecto. Si no, es muy probable que haya olvidos o incomprensiones.
Las actas de reunión no deben ser largas. No interesa recoger todo lo que se dice en la reunión, sino sólo las decisiones que se han tomado y las personas que están involucradas en esas decisiones.
Este documento lo puede redactar alguno de los asistentes a la reunión o bien un secretario.
Pereña recomienda la siguiente plantilla de acta de reunión:
Fuente: Jaime Pereña Brand (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.
Fuente: Jaime Pereña Brand (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.

2.10.Informe final

Cuando se entrega un proyecto finalizado al cliente, es muy recomendable adjuntar un informe final. Este documento sirve para demostrar al cliente que hemos realizado lo pactado y, en caso de que haya alguna ligera desviación respecto a lo previsto, justificarla. Además, es útil tanto para el cliente como para el mismo equipo de trabajo, ya que sirve de valoración global de todo el proyecto.
En este documento se deben recoger los objetivos iniciales del proyecto y ver si se han cumplido, así como recordar la necesidad inicial que tenía el cliente y que lo llevó a encargar el proyecto, para comprobar si realmente lo que se ha desarrollado da respuesta a esa necesidad.
También se debe añadir toda la información relativa a pruebas que tengamos, así como consideraciones futuras para mejorar o ampliar el proyecto.
Normalmente, el informe final lo redacta el jefe de proyecto una vez finalizado el proyecto.
A continuación, se propone una plantilla de informe final:
Fuente: Jaime Pereña Brand (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.
Fuente: Jaime Pereña Brand (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.

3.La memoria de un proyecto

La memoria de un proyecto es un documento muy habitual en algunas profesiones liberales en las que se realizan proyectos, como la arquitectura o algunas ingenierías. Esta memoria se entrega junto con todos los planos antes de entrar en la fase de ejecución del proyecto, y los respectivos colegios profesionales deben dar el visto bueno tanto de los planos como de la memoria, que sigue un esquema estándar.
En el caso de los proyectos multimedia no es obligatorio realizar la memoria, pero sí que es muy importante disponer del briefing del proyecto. En proyectos de gran envergadura, se acostumbra a llevar a cabo una memoria que se termina antes de entrar en la fase de desarrollo del proyecto y que sirve de referencia a todo el equipo que realizará las actividades de esta etapa. Junto a la memoria se anexan los guiones y toda la información relacionada con el proyecto.
A pesar de que no existe un estándar de memoria para los proyectos multimedia, hay unos puntos que no se pueden obviar.
En este apartado pretendemos hacer un recorrido por todos los puntos de la memoria, explicando qué tipo de información debe haber en cada apartado. Naturalmente, estos puntos son una guía, y el jefe de proyecto debe adaptarlos a cada proyecto.

3.1.Descripción

La primera parte de una memoria es la descripción de proyecto (1) . Lo importante es que este apartado de la memoria debe resumir sintéticamente el proyecto. Su finalidad es que cualquier persona, sólo con leer esta información, sepa en qué consiste el proyecto y cuál es el resultado final que se espera. Por ello es muy importante que estén bien explicados, como mínimo, los puntos siguientes:

  • Objetivos y justificación

    Aquí se describen los objetivos del proyecto y la necesidad del cliente o del mercado que reside en el origen del proyecto. Si es necesario podemos distinguir entre los objetivos propios del proyecto (por ejemplo, diseñar y desarrollar un sitio web accesible a personas con poca visión) y los objetivos internos del equipo de desarrollo (por ejemplo, investigar sobre la accesibilidad en Internet).

  • Descripción

    Aquí debe explicarse en qué consiste exactamente el proyecto, si el soporte será un sitio web, una aplicación para dispositivos móviles..., si se trata de un producto estático o dinámico, etc.

  • Usuarios

    En este punto especificaremos a qué público objetivo se dirige el producto, la aplicación o el sitio web que hay que desarrollar en el proyecto. Es muy importante definir correctamente al público objetivo. Si en este punto no concretamos bien el tipo de usuario que esperamos que use nuestra aplicación, las personas que realicen el diseño pueden orientarlo mal y provocar que el proyecto fracase.

En la descripción de los usuarios debemos concretar al máximo las características exógenas (edad, sexo, demografía, etc.) y las características endógenas (motivación, uso que se hará de la aplicación, aptitud y actitud ante la tecnología, etc.) de los usuarios hacia los que se debe orientar el producto.

3.2.Cuerpo de la memoria

En principio, la idea de la memoria es que el equipo de trabajo pueda leerla y, sólo con la información que contiene, pueda desarrollar el proyecto. Si otro equipo tomara la misma memoria, debería desarrollar un proyecto prácticamente igual. Debe ser una descripción clara y concisa de todo lo que habrá en el proyecto. No debe tener contenido de relleno, pero debe ser exhaustiva.
A continuación, se presentan ejemplos de los contenidos que hay que describir en el cuerpo de la memoria de un producto multimedia:
1) Análisis de contenidos
a) Objetivos generales

  • Diseñar un sitio web para enseñar a leer a los niños de tres a cinco años.

b) Objetivos específicos

  • Mantener la atención de los niños/usuarios por medio de una historia que sirva como hilo conductor en el proceso de aprendizaje.

  • Intentar que los niños se acostumbren a interactuar con una aplicación multimedia interactiva mediante una narración lineal con estructura de libro interactivo.

  • Despertar la curiosidad de los niños/usuarios con la introducción de objetos visuales interactivos, como preguntas realizadas para que los niños escojan una entre varias soluciones propuestas, mediante dibujos o animaciones.

2) Análisis formal
a) Estilo artístico. Describe la parte visual de la aplicación.

  • Estilo genérico. Se debe especificar el estilo, que puede ser sobrio, atrevido, infantil..., y la justificación por la que se ha escogido ese estilo.

  • Aspectos artísticos. Se ha de determinar la tipografía, los colores, el logo, el tratamiento de los media, etc.

  • Esbozos o maquetas. Si ya existen esbozos o maquetas del producto, es importante anexarlos como complemento en este apartado.

b) Tipología de los media
Aquí explicaremos brevemente qué tipos de media utilizaremos (texto, imágenes y formato, vídeo, fotografía, ilustraciones...) y su integración con la interfaz.
Es de gran utilidad adjuntar capturas de pantalla de muestra de la integración con la interfaz.
Formas de interacción. Describiremos qué tipos de interacción ofrecerá la aplicación o producto:

  • Interacción del ratón. Puede ser con clic, con efecto rollover, con el efecto de arrastre de objetos...

  • Tipos de menús. Pueden ser desplegables, textuales, icónicos... Describiremos dónde están, por qué, cómo se interactúa con ellos, qué tipo de actuaciones comportan y cómo se indica si están en estado pasivo, habilitados, deshabilitados, activos, etc.

  • Dispositivos especiales de interacción. Pueden ser pantallas táctiles, software de reconocimiento de voz, etc.

c) Navegación
Describe cómo se ha solucionado la navegación dentro de la aplicación o producto desde los puntos de vista conceptual y visual.
d) Estructura de página
Define la estructura de las páginas y su composición (el espacio reservado para la navegación, la cabecera y el pie de página...), así como dónde se encuentran los menús de primer nivel de contenidos, dónde situamos los servicios, etc.
e) Dimensión de la aplicación
En este punto de la memoria daremos la información necesaria para que cualquiera que la lea se haga una idea de la dimensión del proyecto. Así, por ejemplo, si es una web estática especificaremos el número de páginas previstas; si es dinámica, el número de páginas plantilla, el tamaño de la base de datos, etc. También cuantificaremos los media: fotografías, vídeos, audios, animaciones...
3) Análisis tecnológico
a) Solución tecnológica. En este apartado describiremos la tecnología que se va a usar en el proyecto.
b) Requerimientos de producción. Son las necesidades de hardware, software u otros aparatos (cámara de vídeo, software de edición de texto, vídeo, etc.).
c) Requerimientos de usuario. Son las necesidades de hardware o software del usuario para usar el producto (conexión a Internet, navegador, conectores –plug-ins–, etc.).
4) Necesidades de mantenimiento
En el caso de que sea un producto dinámico, se plantearán alternativas de actualización de contenidos y de la aplicación. En el caso de que haya soporte técnico posterior a la entrega del proyecto, esto también se detallará en este apartado.
5) Calendarios y plazos
Se explica brevemente el calendario de trabajo, concretando fechas de inicio, de fin y de los principales hitos intermedios.
Este apartado puede remitir al anexo de planificación del proyecto si se quiere ampliar información.
6) Presupuesto
En este punto se indica el presupuesto del proyecto. Puede ir desglosado, indicar sólo la cantidad o se puede mostrar por etapas, por equipos, etc. en función de las características del proyecto y del criterio de la empresa desarrolladora. Deberá especificarse si se trata de un presupuesto cerrado o de una bolsa de horas que se han de consumir.

3.3.Anexos

En la memoria de un proyecto los anexos son muy importantes, ya que en ellos detallamos todos los esquemas y los guiones que utilizará el equipo de desarrollo.
Según cada proyecto, los anexos serán totalmente distintos.
Por este motivo, la parte de los anexos es la que más varía en las memorias.
A pesar de ello, hay una tipología de información que es muy útil poner en los anexos de la memoria de cualquier proyecto, el plan de trabajo o los guiones.

4.El acceso al soporte documental

Como se ha comentado, en la gestión de proyectos es tan importante generar un buen soporte documental (el justo, no excesivo) como poder acceder a él con facilidad y agilidad. Para ello hay varios sistemas. Si todo el equipo de trabajo trabaja en el mismo sitio, una opción puede ser organizar un disco de red compartido con toda la información de interés. Pero esta situación idílica casi nunca ocurre. Por este motivo, hay varios sistemas que nos permiten que todos los implicados en un proyecto (desde el equipo de trabajo hasta el cliente) puedan acceder a la principal documentación del proyecto desde cualquier lugar y en cualquier momento.
Naturalmente, debe entenderse que estos sistemas de acceso a la información no están reñidos con otros sistemas de comunicación, como el teléfono o el correo electrónico. Sencillamente, tienen objetivos diferentes y es útil trabajar con todos ellos a la vez.
En este apartado se presentan dos de estos sistemas de gestión compartida de la documentación de un proyecto: el sitio de proyecto (project site) y los softwares de grupo (groupwares).

4.1.Los sitios de proyecto (project sites)

En un proyecto es muy útil tener toda la documentación principal del proyecto correctamente ordenada de forma que todos los miembros del equipo de trabajo y el cliente puedan acceder a ella. Para que esto se pueda hacer desde cualquier parte, debemos tener esta documentación accesible desde Internet.
A este espacio de Internet de acceso restringido muchos autores lo llaman project site. Se trata de un sitio web en el que se publica toda la documentación, un centro virtual de comunicación entre el cliente y el equipo de trabajo y, a la vez, dentro del mismo equipo de trabajo.
Los sitios de proyecto se protegen con contraseña para que sólo puedan acceder a ellos las personas involucradas en el proyecto en cuestión.
Normalmente el encargado de organizar y actualizar el sitio de proyecto es el jefe de proyecto (o su ayudante, si tiene). Aunque hay quien pueda pensar que es una pérdida de tiempo, en unas pocas horas dedicadas a la actualización del sitio de proyecto se ahorrará muchas horas a los miembros del equipo y, por lo tanto, al proyecto en general.
4.1.1.Estructura
No hay una estructura fija que seguir cuando creamos el sitio de proyecto. Cada jefe de proyecto organizará la información y el acceso a ella como mejor considere. No obstante, esta podría ser una estructura básica:

  • Página 1. Es la página de acceso (se pide el login y la contraseña).

  • Página 2. Es una página con un apartado para el menú de navegación y otro para los contenidos. A la izquierda situamos el menú con los principales apartados según los tipos de contenidos que podemos encontrar. A la derecha se cargará la lista de documentación que hay en cada apartado.

  • Página 3. Es el documento en concreto que se busca. (Se puede cargar en el mismo apartado de contenido de la derecha o se puede abrir una ventana emergente o pop-up con el documento.)

Ejemplo
David Siegel, en su libro Secrets of succesful web sites, recomienda la siguiente estructura de sitio de proyecto:
Anatomía de un sitio de proyecto propuesto por David Siegel
Anatomía de un sitio de proyecto propuesto por David Siegel
David Siegel parte de una página principal, en la que se pide la contraseña, para ir a la página de bienvenida, donde ya identifica al usuario con privilegios de entrada y lo sitúa corporativamente (con el logo) dentro de la empresa desarrolladora. Haciendo clic en esta página iríamos a la página propiamente de acceso a la información. En la parte izquierda, Siegel coloca los contenidos siguientes:

  • View section

    • Calendar (calendario)

    • Schedule (agenda)

    • Chronology (cronología)

  • Reference section

    • Contacts (contactos)

    • Resources (recursos)

    • Help (ayuda)

En la parte de la derecha de esta página 3, coloca todos los contenidos del apartado elegido en el menú de la izquierda. La página 4 es una ventana emergente que se abre con el contenido deseado.
A continuación, se detalla una propuesta de los contenidos útiles de incluir en el sitio de proyecto. En función del proyecto se añadirían o se sacarían algunos de estos contenidos.
76529_m3_14.gif
Una última recomendación en cuanto al sitio de proyecto es que es muy útil que desde la página web corporativa de la empresa de desarrollo se pueda acceder a él. Según dónde tengamos ubicado el sitio de proyecto, su URL puede ser difícil de recordar, tanto para el cliente como para los miembros del equipo de trabajo. En cambio, todos recuerdan la dirección de la página de la empresa, por lo que, en caso de olvido, siempre podrán acceder a ella y desde allí enlazar al sitio de proyecto.

4.2.Los softwares de grupo (groupwares)

Otro sistema de gestión compartida de documentación son los softwares de grupo o groupwares. Se trata de software que facilita la gestión de conocimiento de un grupo de trabajo en un proyecto.
Hay muchos softwares de grupo en el mercado, y no todos tienen las mismas funcionalidades. A pesar de ello, la mayoría acostumbran a ofrecer los servicios siguientes:

  • Correo electrónico (correo web –webmail–, no POP3)

    Aunque el correo electrónico POP3 es muy práctico, a menudo es muy cómodo usar un correo web (webmail) con los mensajes relacionados estrictamente con un proyecto. De esta forma, sabemos que toda la comunicación importante que se nos ha enviado relacionada con el proyecto está guardada y, lo más importante, que es accesible desde cualquier ordenador.

  • Espacio para documentación compartida

    Naturalmente, un software de grupo debe proporcionarnos, como mínimo, lo que nos daría un sitio de proyecto: un espacio donde colgar toda la documentación importante del proyecto, organizándola de la forma que nos parezca más lógica.

  • Espacio de foros

    La ventaja de usar foros en ciertas tomas de decisiones es que se deja una constancia escrita de la evolución de la comunicación, ya que los mensajes posteados quedan cronológicamente ordenados en el foro según su orden de emisión. Es muy útil que todos los usuarios del software de grupo puedan crear nuevos foros cuando quieran. Esto genera una dinamización de la investigación y de la voluntad de compartir conocimiento. Incluso, gracias a los foros, se pueden realizar tormentas de ideas (brainstormings) en línea, mientras cada uno de los integrantes está ubicado en un espacio diferente.

  • Mensajería instantánea

    La mensajería instantánea es útil cuando se quiere solucionar una duda de forma rápida y cuando la solución es fácil de comunicar. Cuando se trata de una cuestión compleja, es mejor usar otro tipo de sistema de comunicación.

  • Agenda

    Es muy útil tener una agenda compartida por todos en la que se fijen las fechas de reuniones y los calendarios de entregas.

  • Salas de chat

    El chat es una herramienta de comunicación útil en ciertos temas. A veces se pueden realizar reuniones en línea en un chat. De todas formas, a no ser que tengamos un control sobre el servidor que hospeda el chat, no tendremos la constancia escrita de todo lo que se haya dicho. Por lo tanto, se debe usar con moderación y sólo cuando sea estrictamente necesario.

  • Videoconferencia

    La videoconferencia se debe utilizar siguiendo los mismos criterios que el chat. Es útil para hacer reuniones a distancia, pero para otro tipo de comunicaciones es mejor usar otros sistemas. Por otra parte, la videoconferencia requiere una infraestructura y un ancho de banda considerable.

  • Pizarra virtual (para hacer esbozos en tiempo real y en línea)

    No muchos softwares de grupo disponen de esta herramienta, pero es realmente útil en determinados procesos del diseño. Permite que varias personas dibujen a la vez en dicha pizarra virtual.

  • Tareas (asignación y recepción)

    La herramienta de asignación de tareas es muy útil cuando está bien gestionada. Es realmente efectivo que el jefe de proyecto o los responsables de área puedan asignar tareas por medio de una herramienta de este tipo y que los miembros del equipo de trabajo, cuando entren, vean todas las tareas que tienen asignadas. De todas formas, esta herramienta debe servir de recordatorio, pero normalmente se debe completar con información detallada de la tarea, que se facilitará bien mediante el documento de descripción de actividad o bien con una explicación que se mandará por correo electrónico o se explicará en persona.

  • Diagrama de flujo de trabajo (workflow)

    Algunos softwares de grupo permiten crear diagramas de flujo de trabajo o bien del tipo diagrama de Gantt o diagrama PERT, que permiten ver el camino crítico de un proyecto. Estos diagramas los veremos en profundidad en el módulo "Técnicas de dirección de proyectos".

Un software de grupo puede funcionar por intranet o por extranet. En el segundo caso es muy importante la seguridad, por lo que debemos cerciorarnos de qué seguridad nos da la empresa que hospedará toda la información que colguemos por medio del software de grupo (en el caso de que no sea un servidor propio).
Aquí encontraréis enlaces con más información sobre las herramientas de trabajo colaborativo en la red:
Información complementaria sobre los project sites
Información complementaria sobre plataformas de creación de project sites

5.Manual de usuario

En el desarrollo de un producto interactivo multimedia, además del producto en sí, es posible que haya que elaborar un manual de uso del mismo.
Aunque el manual de usuario no forma parte del soporte documental de la gestión de proyectos, sino del producto en sí, en este apartado definimos y describimos cómo debe ser un manual de usuario, debido a la vital importancia que éste tiene dentro del marco del desarrollo del producto.
En el manual de usuario se explicarán todas las posibles opciones que puede llevar a cabo el usuario con esta aplicación de manera detallada.
Podemos distinguir varios tipos de manuales de usuario en función de cómo se plantee su uso. Es habitual elaborar un documento general que pueda ser consultado de modo independiente al uso del producto o mediante una opción del mismo que nos permita consultar la información de modo interactivo. En este último caso suele añadirse a la interactividad una opción de ayuda o información que acostumbra a ser contextual. La información contextual presenta la información relevante al uso de la parte de la aplicación interactiva que el usuario utilice en el momento de realizar la consulta.
Otro tipo de manuales de usuario cada vez más usados son las denominadas guías visuales. Estas guías son capturas de vídeo que nos muestran cómo realizar la interactividad con el producto añadiendo explicaciones de audio, texto o combinando ambos medios.
Sea cual sea el tipo de documento escogido, su destinatario es el usuario final, por lo que debe ser escrito de modo que cualquier persona pueda entenderlo con la menor dificultad posible.
El contenido del manual variará en función del producto final, pero hay ciertos elementos que siempre deben estar presentes:

  • El detalle de todos aquellos pasos que se llevan a cabo para usar el producto.

  • La especificación de los alcances y las limitaciones del producto.

  • La explicación de las posibilidades de configuración o personalización del producto.

  • La descripción de las acciones que derivan de cada interacción con el producto.

Si el documento es genérico y no contextual, además del detalle de la interacción paso a paso, suelen adjuntarse capturas de pantalla a modo de ejemplo.
Un apartado habitual en los manuales de usuario es el glosario de términos, en el que se definen los principales conceptos usados en el producto y relacionados con el ámbito al que éste se refiere.

Bibliografía

Concepción Suárez, R. (2007). Metodología de gestión de proyectos en las administraciones públicas según ISO 10.006. Oviedo: Ed. Universidad de Oviedo, Biblioteca Universitaria (Colección "Tesis Doctoral-TDR", n.° 24).
Gómez-Senent, E.; Capuz, S. (1999). El proyecto y su dirección y gestión. Valencia: Universidad Politécnica de Valencia, Servicio de Publicaciones.
Pereña Brand, J. (1996). Dirección y gestión de proyectos (2.ª ed.). Madrid: Ediciones Díaz de Santos, S. A.
Siegel, D. Secrets of succesful web sites.