Universidad Nacional Autónoma de México
Dirección General de Servicios de Cómputo Académico
Año 7 Núm. 74, Publicación Mensual, 27 de Noviembre de 2008

ARTÍCULOS

 

Año 6, Número 55, Enero de 2007

WBS, herramienta práctica para presentar la documentación de un proyecto de TI

Cristina Múzquiz Fragoso

 

Para quienes nos dedicamos a los sistemas de información, resulta familiar encontrarnos con una serie de problemas al momento de planear, elaborar y presentar la documentación.

Normalmente, una de las causas es que los gerentes de proyecto no otorgan la importancia necesaria tanto para su administración y control, mediante un repositorio y buenas prácticas, como para asegurar un buen producto. Una opción práctica para llevar a cabo el proceso de documentación es mediante una herramienta llamada WBS.

Algunos de los problemas comunes de la documentación de un proyecto de tecnologías de información (TI) se derivan de los siguientes escenarios:

  1. Es poco claro el objetivo específico de la documentación.
  2. Se definió como entregable al cliente, pero no se acotaron sus alcances.
  3. Careció de un orden claro en su generación, lo que se refleja en documentación duplicada o insuficiente.
  4. La tarea de documentar se delegó a un “documentador”, con poco o nulo conocimiento del desarrollo del proyecto de TI que se está documentando.
  5. Falta de consistencia, con procesos altamente documentados y otros con nula o poca documentación.

Lo anterior, suele traer como consecuencia que la documentación, evidentemente, sea poca y pobre, por lo cual no se aprovecha ni percibe como un producto de valor, y en muchos casos, aunque presente un contenido completo y detallado. Por lo general, los usuarios no acceden a ella porque se ignora cuál de todos los documentos tiene lo que requieren; es como buscar una dirección en una guía roji, pero sin claves ni orden.

Para mitigar la probabilidad de ocurrencia de estos problemas, se puede emplear un WBS (Work Breakdown Structure, es decir, estructura desglosada del trabajo), herramienta para definir el trabajo de manera jerárquica, que describe los entregables y tareas que deben realizarse para un proyecto dado. Para el WBS, se hace una de descomposición de tareas, mientras para su representación gráfica se utiliza un diagrama tipo organigrama, pero en lugar de roles, se esquematizan paquetes de trabajo. Hacerlo, implica tener lápiz y papel o, Power Point o, un software para hacer diagramas como por ejemplo, Visio.

Cada caja es un “paquete de trabajo”, es decir, un grupo de actividades en común.

Mismos niveles y paquetes de trabajo que en el WBS

Es importante mencionar que el WBS es un proceso de pensamiento, mediante el cual se pretende organizar el proyecto; en primera instancia, se requieren organizar las ideas de lo que se pretende hacer y las metas que se desean cumplir. Para iniciar un WBS, se tienen que definir las grandes áreas de trabajo en que puede ser dividido el proyecto, lo que constituirá los paquetes de trabajo a desarrollar para lograr la meta. Posteriormente, cada uno de esos paquetes de trabajo se debe dividir en otros más pequeños hasta lograr el desglose necesario. El nivel de desglose requerido por el proyecto, estará determinado en función de la complejidad y tamaño del proyecto. Se recomienda que los paquetes de trabajo, en cualquier nivel, sean independientes unos de otros y que se refleje un producto o servicio tangible, para poder medir los avances reales.

Con esta representación se tendrá un entendimiento claro de los conceptos, sin necesidad de explicar complicadas teorías. Aunque su representación gráfica es sencilla, la realidad es que el poner de acuerdo a todo el grupo de trabajo es un proceso complejo, pero brinda la oportunidad de lograr un mayor grado de integración, además de tener beneficios durante el desarrollo del proyecto de TI y, por ende, en su documentación.

Para muchos, el WBS es una herramienta tan sencilla, aparentemente, que se menosprecia su elaboración y prefieren ir directamente a la obtención de los estimados de costo y tiempo, frecuentemente, con estructuras diferentes que lo único que garantizan son confusión y conflictos.

Partiendo del supuesto que se tiene de un WBS como un producto de la planeación del proyecto, veamos cuál es su utilidad en la documentación de un proyecto en TI, para contrarrestar las causas usuales de problemas en la documentación.

  1. Es poco claro el objetivo específico de la documentación. Regularmente, en un proyecto se consideran los documentos de análisis, diseño, desarrollo y manuales de usuario y técnicos. Pero cuando el proyecto de TI es más complejo, con varios subproyectos como, por ejemplo, la prestación de un servicio con varios sistemas, puesta a punto de sitios de operación, capacitación y soporte, entre otros, se deberá especificar y acordar claramente cuál es el objetivo de la documentación entregada al cliente. Al desarrollar el WBS del proyecto, se deben definir por cada paquete de trabajo sus objetivos con respecto a la documentación, de manera que éstos deberán estar alineados con el objetivo general del proyecto.
  2. Se definió como entregable al cliente, pero no se acotaron sus alcances. Se recomienda que desde el contrato, convenio o cotización se definan cuáles serán los documentos que se realizarán, y así brindar una breve descripción de cada uno de ellos. En forma ideal, se sugiere considerar características objetivas para que el cliente pueda verificar que la documentación cumple con lo establecido. En el WBS se deberán de plasmar los esfuerzos en tiempo y costo para cumplir con el alcance acordado, y los entregables específicos que se desean tener en este rubro.
  3. Careció de un orden claro en su generación, lo que se refleja en documentación duplicada o insuficiente. El WBS no deberá ser sólo una gráfica obtenida al inicio del proyecto para generar un documento de planeación; el WBS tendrá que ser un eje en la forma de trabajo durante todo el proyecto. De esta forma, el plan de trabajo también tendrá que estar alineado con el WBS, y manejar los mismos niveles de agrupación de trabajo.

Mismos niveles y paquetes de trabajo que en el WBS

Posteriormente, con base en el objetivo y alcances de la documentación, se sugiere hacer una matriz, como la siguiente:

Donde se consideren sólo los paquetes de trabajo que nos interesan y se acordaron documentar. De esta forma, se puede tener una visión clara, sobre el avance y las debilidades en la documentación. Cuando se continúa con un proyecto de TI, anteriormente desarrollado por otras personas, esta matriz también suele ser muy útil, para identificar las ausencias de documentación.

4. La importante tarea de documentar se delegó a un “documentador” que tiene poco o nulo conocimiento del desarrollo del proyecto de TI documentado. Este problema suele agudizarse cuando es un proyecto de TI complejo, porque el documentador suele ser alguien que no participa en el desarrollo de las actividades. Con apoyo del WBS se identifica y sensibiliza más a los colaboradores de la importancia de que ellos sean los que intervengan directamente en la documentación del proyecto, por su conocimiento profundo de los procesos. Además, este escenario tiene el valor de que el líder del proyecto puede planear mejor las horas de trabajo requeridas.

5. Falta de consistencia, con procesos altamente documentados y otros con nula o poca documentación. Con apoyo del WBS y su relación directa con la documentación de cada “paquete de trabajo” se puede lograr un mayor equilibrio, porque se identifican cuáles son las áreas que presentan poca o nula documentación y, por lo tanto, serán las que requieren de mayor apoyo.

Presentación de la documentación

Se sugiere un índice general, con objeto de localizar fácilmente los documentos; incluso, se puede utilizar el mismo WBS como un índice, donde cada paquete de trabajo (cajita), sea un hipervínculo a un documento.

El WBS es una herramienta tecnológica que ayuda en gran manera para hacer las cosas con orden y como diría Pitágoras “Con orden y tiempo se encuentra el secreto de hacerlo todo, y de hacerlo bien”. De esta forma, podremos tener no sólo documentos aislados, sino una estructura sólida de documentación, con mayores probabilidades de proporcionar un valor agregado al proyecto.

Para mayor información:

http://www.cenidet.edu.mx/misc/ cursoadmon/wbs.htm

http://www.proyectics.com/index. php?mod=contenido2&id=1579&seccion=Art%C3%ADculos&idcategoria=11

Inicio | Contacto |