Principio del proyecto
Los recursos básicos del proyecto se organizan en una fase inicial que se denomina Principio del proyecto.
En este tema
Reunión de planeación
Desarrollo iterativo
¿Es este un proyecto controlado por ámbito o por fecha?
Planear los recursos del proyecto
Definir los roles y las responsabilidades
Definir un plan de comunicación
Identificar las partes interesadas
Esbozar el plan del proyecto
Revisar el plan del proyecto
Obtener los compromisos del proyecto
Reunión de planeación
En una fase temprana del proyecto, las partes interesadas y los expertos en la materia deben reunirse para analizar el proyecto y crear el plan del producto. Las partes interesadas se deben elegir en función de la naturaleza y la complejidad del proyecto y la entrega del producto.
Dependiendo del tamaño del proyecto y de su complejidad, la reunión puede durar varios días o varias semanas.
Desarrollo iterativo
Una técnica importante en la administración de riesgos es la planeación del proyecto en iteraciones, normalmente de cuatro a seis semanas. Un plan de iteración es una lista de características que el equipo del proyecto desarrollará y probará. Cada característica especifica una tarea o una variante mejorada de una tarea que el usuario podrá realizar utilizando el producto. Al final de cada iteración, se muestran las características planeadas. A la terminación de algunas iteraciones, el producto parcialmente completado se lanza para la realización de pruebas por parte de un conjunto limitado de usuarios.
Los comentarios de esas demostraciones y pruebas se utilizan para revisar el plan.
El plan del producto se organiza de manera que los principales escenarios de usuario y los componentes principales del sistema se utilicen en una fase temprana, aunque solo sea de forma simplificada.
Uno de los riesgos más significativos en la mayoría de los proyectos es la interpretación incorrecta de los requisitos. Esta interpretación incorrecta de los requisitos puede darse no solo en el equipo de desarrollo sino también en las partes interesadas y los usuarios finales. Es posible que tengan dificultades para prever cómo la instalación del nuevo sistema afectará a las actividades comerciales.
Además, el contexto comercial puede cambiar durante el tiempo de vida del proyecto, dando lugar a un cambio en los requisitos del producto.
Un proceso iterativo proporciona la garantía de que cualquier ajuste en los requisitos derivado de la demostración del producto puede incluirse antes de que finalice el proyecto, evitándose los gastos que generaría una revisión sustancial.
Otro riesgo significativo es una estimación incorrecta de los costos de desarrollo. Los desarrolladores que trabajan en una nueva área, y quizás en una nueva plataforma, pueden tener dificultades a la hora de realizar estimaciones precisas de los costos de desarrollo antes de abordar el proyecto. En algunos casos, es posible que sea difícil determinar si una estrategia de implementación determinada se realizará suficientemente bien. Pero mediante la revisión del plan al final de cada iteración, el equipo puede aprovechar la experiencia de las iteraciones anteriores. Este es uno de los motivos por los que un buen plan del producto programa el trabajo en cada componente principal en una fase temprana.
¿Es este un proyecto controlado por ámbito o por fecha?
Algunos proyectos requieren que todos los requisitos funcionen antes de la entrega. Estos tipos de proyectos no son habituales en un contexto de software. Un ejemplo real podría ser la construcción de un puente. Un tramo sin finalizar no es útil. Sin embargo, un proyecto de software no completado pero correctamente planeado puede ser objeto de implementación y uso por parte de un conjunto limitado de usuarios. Posteriormente, se puede completar de forma progresiva en el transcurso de varias actualizaciones.
Lo primero es determinar si se trata realmente de un proyecto controlado por ámbito. En caso afirmativo, se debe esperar a tener estimaciones detalladas y un plan detallado para determinar una fecha de finalización. Pero esto tiene un precio. Aumentará la sobrecarga de planeación, y la contención de la programación como una contingencia frente a una estimación deficiente retrasará la fecha de entrega, con el consiguiente incremento de costos. Por lo tanto, antes de decidir que el proyecto sea controlado por ámbito, hay que estar totalmente seguro de ello. Esto es más probable en un entorno complejo de ingeniería de sistemas que en un producto exclusivamente de software o un escenario de servicios.
La mayoría de los proyectos de software son proyectos controlados por fecha porque se pueden entregar de forma progresiva. Por ejemplo, si se desea lanzar un juego informático en el período de vacaciones en los Estados Unidos, debe estar listo en octubre. El incumplimiento de la entrega en octubre afectará negativamente a las ventas entre Halloween y Navidad y, si la programación se retrasa dos meses, se puede perder la ocasión totalmente.
Planear los recursos del proyecto
A un proyecto se le debe asignar el personal necesario para ser entregado en la fecha deseada. Deben utilizarse los datos históricos de proyectos anteriores para promover un debate acerca de si se dispone de recursos suficientes.
Una vez conocidos los requisitos de personal, se debe crear un organigrama del proyecto que identifique claramente la estructura del equipo del proyecto, los niveles de dotación de recursos y la distribución geográfica, si es necesario. Guarde toda la información de asignación de personal en el portal del proyecto.
Definir los roles y las responsabilidades
Describa cada rol del proyecto y sus responsabilidades, y publíquelos en el plan del proyecto. Cada persona que se una al proyecto debe conocer su rol y sus responsabilidades en el proyecto.
Definir un plan de comunicación
Es importante definir un plan de comunicación para el proyecto. Las rutas de comunicación ayudan a administrar los costos de coordinación del proyecto. También es importante definir quién debe asistir a las reuniones, con qué frecuencia deben celebrarse estas, las rutas de comunicación y la forma de dirigir a una instancia superior los problemas que no pueden ser resueltos por los asistentes habituales de las reuniones.
El objetivo de un plan de comunicación excelente es asegurarse de que las actividades de coordinación del proyecto se ejecuten con la mayor fluidez posible y evitar derrochar esfuerzos for falta de comunicación.
El plan de comunicación se debe publicar en el portal del proyecto y mantenerse el tiempo que sea necesario. Un plan de comunicación es una herramienta útil para todo el personal, especialmente para los nuevos miembros. Les ayuda a conocer la forma de trabajar de un equipo de mayor tamaño y cómo se pueden realizar acciones mediante una comunicación apropiada de diferentes maneras, con diferentes miembros del equipo y para fines diferentes.
Identificar las partes interesadas
Identifique todas las partes interesadas relevantes del proyecto. Además de los miembros básicos del equipo, la lista debe incluir el personal técnico y comercial que tenga una incidencia notable en la implementación correcta del proyecto o en el efecto que el producto puede tener después de su entrada en servicio. Estas partes interesadas pueden estar en una fase anterior o posterior a la actividad de ingeniería del software.
Esbozar el plan del proyecto
Cree una versión esquemática del primer plan del proyecto que se pueda revisar cuando empiece el desarrollo. La finalidad de esta versión es ayudar a analizar los recursos y las escalas de tiempo con los patrocinadores del proyecto. Se deben describir las características principales y las fechas de entrega estimadas. Para obtener más información, vea Planear el proyecto (CMMI).
Revisar el plan del proyecto
Publique el esquema del plan del proyecto en el portal del proyecto. Aunque el plan requiere una gran cantidad de trabajo, sigue siendo un plan de alto nivel que aplaza muchas decisiones de programación detalladas. Esto tiene su porqué. Un nivel de detalle demasiado profundo en esta fase previa no se aprovechará posteriormente.
Cuando no se conocen a ciencia cierta los requisitos, solo deben planearse de forma general y los detalles deben aplazarse hasta que se disponga de más información. Cree un plan para obtener esa información.
Programe una reunión de revisión con todas las partes interesadas. Las reuniones cara a cara siempre son mejores para este tipo de actividad. Asegúrese de que haya tiempo suficiente para que se pueda realizar una revisión completa y se puedan oír y atender las opiniones discrepantes.
Obtener los compromisos del proyecto
Una vez acordado el plan del proyecto con las partes interesadas, obtenga de cada una los compromisos debidos para aprobar el plan del proyecto.
Recoja los compromisos y almacene los detalles en el portal del proyecto.
Recursos adicionales
Para obtener más información, vea los recursos web siguientes:
A Practical Guide to Feature Driven Development, Stephen R. Palmer y John Malcolm Felsing; Prentice Hall PTR, 2002.
The IT Measurement Compendium: Estimating and Benchmarking Success with Functional Size Measurement, Manfred Bundschuh and Carol Dekkers; Springer, 2008.