1. ¿Quién revisa y valida la documentación?

Uno de los principales errores es elegir correctamente qué persona se encargará de validar toda la documentación que generamos.

Normalmente son los propios desarrolladores quienes se encargan de documentar, validan y revisan. Grave error puesto que, como ocurre también en el mundo de la programación, siempre tendemos a pensar que todo lo que explicamos es perfecto o está redactado de la mejor manera posible, cuando NO es así.

La persona que se debe dedicar a revisar y validar será aquella la cual va utilizar/mantener aquello que se acaba de desarrollar. De nada sirve documentar de forma estructurada y extensa, si después el verdadero stakeholder no es capaz de comprenderla.

2. ¿En qué momento del proyecto nos dedicamos a documentar?

Otro de los errores más comunes es considerar la tarea de documentar como una última fase del proyecto, antes de la reunión de cierre.

Totalmente erróneo, puesto que se debe documentar durante la propia ejecución del mismo, puesto que cualquiera que haya desarrollado cualquier proyecto IT, es consciente que pueden aparecer imprevistos que quitan la parte del tiempo que estaba destinado a documentar. Es más bajo mi criterio, considero que tendría que ser un entregable dentro de cada una de las fases del proyecto.

3. Desarrollar la documentación es realmente aburrido. ¿Hay algún método para afrontarlo desde otro punto de vista?

Sí.

NO debemos tomar la documentación de un proyecto como una tarea aburrida, al contrario, se trata de una tarea compleja que debemos afrontarla como un verdadero reto personal: ¿Sería capaz de plasmar por escrito todo aquello desarrollado y que otro lo entendiera perfectamente sólo leyéndolo?

Antes de empezar, párate un momento. Piensa que es lo importante del proyecto y lo que no es. Diferencia entre lo que es necesario y no. Haz un borrador del contenido. Una vez que lo tengas, reflexiona cómo documentar:

  • ¿Se trata de un usuario final? ¿O de un técnico?
  • ¿Es una persona del equipo y podemos utilizar un lenguaje más informal? ¿O es un manager?
  • ¿Qué lenguaje emplearemos? ¿Utilizaremos formas reflexivas? ¿O pasivas?
  • ¿Qué estamos redactando exactamente? ¿Una documentación técnica? ¿Cómo acceder a la aplicación desarrollada? ¿Un HowTo? ¿Un manual de usuario?

Una vez hayas respondido todas estas preguntas y las que te vayan surgiendo, estarás preparado para empezar a documentar. Pero antes, vuelve a pensar de nuevo el objetivo, la persona a la cuál va dirigida, el motivo, las formas verbales, vocabulario, etc.

Y ahora, empieza a documentar. Sé claro y conciso, remarca todo aquello importante y ayúdate de capturas de pantalla e imágenes.

4. ¿Existe alguna herramienta para mejorar o clasificar todo lo que vamos documentando?

Por supuesto.

Sin ir más lejos, hace un par de días Microsoft anunció su nueva versión de Office 2016 la cual, entre sus numerosas novedad, se centra en mejorar el trabajo colaborativo. Esto permite a los usuarios acceder y editar los documentos de Office en tiempo real sin importar el entorno o dispositivo. Algo parecido a lo que ofrece Google Drive, por ejemplo.

Gracias a estas ventajas, podemos mejorar la tarea de documentar, ya sea en la rapidez de compartirla  con cualquier compañero para obtener feedback, clasificarla mediante el uso de tags o categorías, o mediante la inserción de gráficos.

Existen diferentes alternativas, dónde todo depende de la propia experiencia de cada uno. En mi caso, la herramienta que os puedo recomendar para documentar es Confluence de Atlassian, por su precio competitivo y la calidad de los resultados.

5. ¿Es necesario documentar en un proyecto de Business Intelligence?

Existen muchos aspectos dentro de un proyecto Business Intelligence que deben ser documentados.

De hecho, si tenemos un proyecto que realizamos hace un tiempo y tenemos que volver a desarrollar o mantener, la documentación se convierte en una herramienta/ayuda indispensable para entender todo aquello que se realizó.

Algunos temas que ha de abarcar la documentación de tu proyecto Business Intelligence son los siguientes:

  • Objetivo, alcance y requerimientos.
  • Orígenes, modelo de datos, tablas, campos.
  • Script ETL, transformaciones, relaciones, lógica y densidad de información.
  • Dimensiones agrupadas, métricas y KPI’s definidos.
  • Hojas, objetos, gráficos, función, propiedades y expresiones.
  • Usuarios, sección de acceso y reducción de datos (para QlikView o Qlik Sense).

En definitiva: documentar un proyecto es una tarea fundamental para garantizar el éxito del mismo una vez finalizado.

Nos ayudará a nosotros mismos y a cualquier otra persona, tanto a realizar un buen mantenimiento, como comprender lo que se desarrolló hace un tiempo.

Y tú, ¿También te encargas de documentar todos tus proyectos?