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 la generan, 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 tener una documentación muy bien estructurada y extensa, si después el verdadero interesado no sabe comprenderla.

2. ¿En qué momento del proyecto nos dedicamos a documentar?
Otro de los errores más comunes es considerar la documentación como una tarea a realizar en la última fase del proyecto, antes de la reunión de cierre. Totalmente erróneo, puesto que se debe redactar durante la propia ejecución del mismo, puesto que cualquiera que haya desarrollado cualquier proyecto IT, sabe que en la última fase siempre pueden aparecer diferentes imprevistos que quitan la mayor parte del tiempo que estaba planificado para realizar la documentación. 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í. Y tanto que 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 se lo explicarás a aquella persona/s.

  • ¿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. Pero antes, vuelve a pensar de nuevo el objetivo, la persona a la cuál va dirigida, el motivo, las formas verbales, lenguaje, vocabulario, etc.

Y ahora, empieza a escribir. 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, y más en el momento actual que nos encontramos. 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 especialmente en mejorar el trabajo colaborativo, que 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 nuestra documentación, ya sea en la rapidez de compartirla  con cualquier compañero para obtener feedback, clasificarla mediante el uso de tags o categorías, o mejorarla 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 es Confluence de Atlassian, por su precio competitivo y la calidad de los resultados obtenidos.

5. Todo lo que has explicado está genial pero… ¿Qué se documenta en un proyecto de Business Intelligence con QlikView?
Existen muchos aspectos dentro de un proyecto realizado con QlikView 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 con QlikView 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 acesso y reducción de datos.

 ———————–

En definitiva: desarrollar la documentación de 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 realizas la documentación de todos tus proyectos?