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.
La supervisión de riesgos debe ser un proceso continuo y en cada revisión del progreso los riegos graves deben ser considerados por separado y discutidos por la audiencia.
Manejo del Personal
Por lo general, los administradores de proyectos tienen que seleccionar a las personas para trabajar en su proyecto. De forma ideal, estará disponible personal con habilidades y experiencia apropiada para trabajar en el proyecto.
Sin embargo, en muchos casos, los administradores tienen que establecer un equipo ideal mínimo para el proyecto. Las razones para esto son:
- El presupuesto del proyecto no cubre la contratación de personal con sueldos altos. Se tiene que contratar personal con menos experiencia y menos sueldo pero mejor aprovechados.
- El personal con experiencia apropiada no está disponible dentro o fuera de la organización. Es imposible reclutar nuevo personal para el proyecto. Dentro de la organización, las mejores personas ya se han asignado a otros proyectos.
- La organización desea desarrollar las habilidades de sus empleados. El personal inexperto puede ser asignado al proyecto para aprender y adquirir experiencia.
El administrador de software tiene que trabajar con estas restricciones al seleccionar al personal del proyecto. Sin embargo, todos estos problemas son probables a menos que exista un miembro del proyecto que cuente con algo de experiencia en el tipo de sistema a desarrollar. Sin esta experiencia, probablemente se cometerán muchos errores pequeños.
Se debe contar con un plan de desarrollo del personal que describa cómo de desarrollarán las habilidades y experiencia de los miembros del equipo del proyecto. El personal que trabaja en una organización de software es su activo más grande; representa el capital intelectual y se deja a los administradores del software asegurar que la organización obtenga los mejores beneficios posibles al invertir en las personas. Dichas personas deberán tener un nivel de responsabilidad y se les deberán asignar premios de acuerdos con sus capacidades. Los administradores de proyectos tienen que resolver problemas técnicos y no técnicos, motivar a la gente, planear y organizar su trabajo, asegurando que este se realice de manera adecuada. La administración pobre del personal es unos de los factores más importantes para el fracaso de los proyectos.
Uno de los papeles más importantes de los administradores de proyectos es motivar a las personas que trabajan con ellos. Maslow (1954) señaló que las personas se motivan al satisfacer sus necesidades y que esas necesidades se ordenan en una serie de niveles:
- Necesidades Fisiológicas.
- Necesidades de Seguridad.
- Necesidades Sociales.
- Necesidades de Estima.
Las personas que trabajan en las organizaciones de desarrollo de software por lo regular no están hambrientas o sedientas y por lo regular no se siente físicamente amenazadas por su entorno. Por lo tanto asegurar la satisfacción de las necesidades sociales, de estima y de autorrealización es más importante desde un punto de vista administrativo. Satisfacer las necesidades sociales significa permitir que la gente tenga tiempo de conocer a sus compañeros de trabajo y proveer lugares para que se conozcan. Canales de comunicación informales y fáciles de utilizar, como el correo electrónico, son muy importantes.
Para satisfacer las necesidades de estima se necesita mostrar a las personas que son de gran valor para la organización. El reconocimiento público de los logros es una forma sencilla pero efectiva de hacer esto. Obviamente, las personas también deben sentir que se les paga de acuerdo con el nivel que reflejan sus habilidades y experiencia.
Por otro lado, para satisfacer las necesidades de autorrealización se necesita dar a las personas responsabilidad en su propio trabajo, asignarle tareas demandantes (pero no imposibles) y proveerles un programa de capacitación donde puedan desarrollar sus habilidades. Las personas no sólo están motivadas por las necesidades personales sino también por las metas de estos grupos más amplios. Ser miembro de un grupo cohesivo es altamente motivante para muchas personas. Las personas que se sienten satisfechas con su trabajo a menudo les gusta trabajar debido a que se motivan por la gente que trabajan con ellas y por el trabajo que hacen.
Bibliografía
– Ian Sommerville, “Ingeniería de Software”, 6ta Edición. Pearson Educación, 2002.
– I. Archer Pupo, “Fases del Proceso Unificado de Desarrollo”. http://www.avatar.com.pe
