Administración de riesgos y manejo del personal en proyectos de software
Enviado por Carlos Galindo González
La primera etapa de un proyecto de software implica redactar una propuesta para realizar ese proyecto. La propuesta describe los objetivos del proyecto y cómo se llevará a cabo. La misma incluye estimado de costo y calendarización. Justifica por qué el contrato del proyecto se le debe dar a una organización o a un equipo en particular. La planeación de proyectos se refiere a la identificación de actividades, hitos y entregas producidas por un proyecto. Por lo tanto se debe bosquejar un plan para guiar el desarrollo hacia las metas del proyecto. La estimación del costo es una actividad relacionada que se refiere al estimado de los recursos requeridos para llevar a cabo el plan del proyecto.
La supervisión del proyecto es una actividad continua. El administrador debe tener conocimiento del progreso del proyecto, y comparar los progresos y costos reales con los planeados. A parte de los mecanismos formales, la supervisión informal continua predice problemas importantes del proyecto y revela dificultades en su momento. Por ejemplo estas entrevistas informales diarias pueden exteriorizar un problema en una falla del software. Más que esperar un informe de atraso del proyecto, el administrador podría asignar un experto para resolver el problema o podría decidir si ese problema se vuelve a calendarizar.
La administración de software abarca la planeación, calendarización, administración de riegos, manejo del personal, estimación de los costos de software y la administración de calidad. En este artículo se cubre la administración de riesgos y el manejo del personal. Muchas son las causas para el fracaso de proyectos de software, se pueden mencionar: entrega tardía, no fiable, costo superior al estimado, características de ejecución pobres. Muchas veces la falla estaba en el enfoque de administración utilizado.
Administración de Riesgos
Una tarea muy importante del administrador de proyectos es anticipar los riesgos que podrían afectar la programación del proyecto o la calidad del software a desarrollar y emprender acciones para evitar esos riesgos. Los resultados de este análisis de riesgos se deben documentar a lo largo del plan del proyecto junto con el análisis de consecuencias cuando el riesgo ocurra. Identificar estos y crear planes para minimizar sus efectos en el proyecto se llama administración de riesgos. La metodología del Proceso Unificado de Desarrollo brinda una estructura que permite caracterizar un riesgo:
Nombre del Riesgo.
Magnitud.
Descripción.
Impacto.
Indicador.
Estrategia de Anulación.
Estrategia de Mitigación.
Plan de Contingencia.
Como se aprecia se define el nombre del riesgo, la magnitud representa su peligrosidad (Grave, Moderado o Leve), también existe una descripción del mismo, su impacto en el proyecto; el indicador que lo señala. Se cuenta con una estrategia de anulación que persigue reducir la probabilidad de que el riesgo surja; así como una estrategia de mitigación que significa reducir el impacto del mismo; en el caso que esta última no sea efectiva, se cuenta con un plan de contingencia.
De forma simple, se puede concebir un riesgo como una probabilidad que una circunstancia adversa ocurra. Los riesgos son una amenaza para el proyecto, para el software que se está desarrollando y para la organización. Estas categorías de riesgo se definen como se muestra a continuación:
Riesgos del proyecto: afectan la calendarización o los recursos del proyecto.
Riesgos del producto: afectan la calidad o desempeño del software que se está desarrollando.
Riesgos del negocio: afectan a la organización que desarrolla el software.
Por supuesto esta clasificación no es única, un riesgo puede abarcar varios puntos señalados anteriormente. Ejemplo de ello puede ser el riesgo: programador experto abandona el proyecto, es un riesgo para el proyecto pues puede retrazar la entrega del sistema; es un riesgo del producto debido a que un sustituto puede no ser tan experto y cometa muchos errores; y para el negocio porque esa experiencia puede no contribuir a negocios futuros.
Página siguiente |