archivo

Archivos diarios: septiembre 13, 2011

Todavía hay muchos (aunque cada vez menos) que muestran un rechazo a los sistemas de información y al software en general en el ámbito laboral. Es cierto que a nivel porcentual es posible que no sea una cifra muy significativa, sin embargo en un mundo donde la tecnología avanza a una velocidad de vértigo, este porcentaje aún pequeño pesa cada vez más.

Se han puesto medios para disminuir esa brecha digital de muchas personas que comenzaron con su trayectoria profesional con anterioridad a la explosión de las TICs, sin embargo, en muchos casos estos medios no han llegado a todo el mundo y en otros son las personas las que no han querido hacer el esfuerzo de adaptarse.

Los medios tradicionales para realizar determinados tipos de trabajo han funcionado durante muchos años, han cumplido su cometido, sin embargo en la actualidad no contar u obviar las nuevas tecnologías supone una pérdida de productividad individual y, en general, de la organización en la que desarrollan sus servicios profesionales.

El desarrollador libanés Joseph Abou Nader realizó una reflexión interesante en la que pone en una balanza el software y su ausencia: “No temo al software, temo su falta”.

Si no existe comunicación dentro del equipo de proyecto o la misma no fluye de manera adecuada tendrá consecuencias en el resultado final del producto que se obtiene, esto es así porque no hay que dar por sentado que todos los integrantes del equipo de proyecto tienen la misma percepción del sistema o producto que hay realizar, de qué es lo realmente prioritario y cuál no, de cómo se va a organizar el trabajo, de cuáles son los plazos y de cuál es el nivel de calidad exigido en el proyecto.

Es necesario armonizar en lo posible la visión de los distintos integrantes del equipo de proyecto para la cual la existencia de comunicación, dando información precisa y adecuada, resulta fundamental para ello.

La comunicación no debe entenderse de manera exclusiva de arriba hacia abajo, sino que también debe ser fluida a nivel horizontal, para poder coordinar de manera adecuada los trabajos que se realizan, para consultar cualquier tipo de duda o para solicitar ayuda y de abajo hacia arriba para que se puede conocer en cada momento el estado real del proyecto y, además, puedan llegar las inquietudes del equipo hacia los niveles superiores.

Richard E. Fairley realiza una reflexión que refleja la importancia de una buena comunicación dentro de un equipo de proyecto: “La estructura de un sistema software refleja la estructura de comunicación del equipo que lo ha desarrollado”.

Este área de proceso del nivel 2 de CMMI resulta complementaria de la Planificación del Proyecto, es lógico, si se planifica es para sentar unas bases que sirvan de referencia para la posterior ejecución del proyecto (como comentaré más adelante el plan de proyecto debe entenderse como el mapa inicial, debiéndose ajustar cuando existen causas que motivan ese cambio).

Aquí es donde nos encontramos con uno de los problemas de la gestión de proyectos de muchas organizaciones, ya que si bien se puede llegar a planificar de manera razonable unos mínimos: estimación de costes, cronograma del proyecto, relación de entregables, etc…, en muchos casos la gestión se centra en aspectos meramente contables, ¿cuánto llevamos gastado?.

La gestión y el control del proyecto debe ir más allá de eso y entrar en una monitorización continua y/o periódica de los hitos establecidos en la planificación: esfuerzo/coste, cronograma, compromisos, riesgos, participación de los actores implicados en el proyecto y obtener información lo más precisa posible sobre el avance real del proyecto y sobre el estado de los entregables pactados.

¿Todo esto para qué? Pues para tomar decisiones que permitan solucionar problemas, corregir desviaciones (en lo posible), etc… Monitorizar y medir permite llevar a cabo acciones correctoras si fuera preciso.

Es importante tener en cuenta que el objetivo es gestionar, controlar y actuar (a tiempo) por encima de intentar cumplir las especificaciones del plan de proyecto. Esto no en una incongruencia, salvo que dichas especificaciones sean inamovibles, algo que en la realidad sucede en pocos proyectos sobre todo porque resulta contraproducente intentar cumplir con objetivos que después resultan poco realistas, ya sea porque se partía de una situación inicial donde la información recibida no era correcta o insuficiente y/o porque en el propio desarrollo del proyecto se han producido contingencias que afectan al plan del proyecto.