Gestión de Proyectos

Todo diseño de proyecto requiere de una coordinación satisfactoria. Dentro de este escenario, girará lo que concierne al tiempo de desarrollo, los personajes que intervendrán en el diseño, los costes, etc. Por tanto, las preguntas que nos debemos hacer inicialmente son las siguientes:

• ¿Qué es?
• ¿Quién lo hace?
• ¿Por qué es tan importante?
• ¿Cuáles son los pasos?
• ¿Cuál es el producto obtenido?
• ¿Cómo puedo estar seguro de que lo he hecho correctamente?

Muchos son los temas en que gira este proceso. En el terreno de lo personal, podemos citar los tan discutidos y promulgados expertos y la madurez de la capacidad de gestión humana. Ello hace énfasis en los expertos del software y como motivar a que estos produzcan lo mejor de si y el mejor software posible. Además de esto, la organización y la búsqueda de desarrolladores o ingenieros con dotes de capacidad y talento, etc.

Luego, aparece el producto como punto de partida del desarrollo. Esta fase resulta ser tan crucial cuando el desarrollador y el cliente se sientan a conversar y a trazar el objetivo general en base a la necesidad del cliente y las pautas que este impone en dicho escenario.

La fase del proceso, que emerge de las trazas de los objetivos y donde se planifica la mecánica operacional del desarrollo que contempla lasa actividades, los hitos, los requisitos del proyecto, las mediciones, la calidad del software, etc.

Por último, hablamos del proyecto en los se sumergen las planificaciones y que son controlados por la razón principal. Esto se practica a los efectos de evitar desviaciones durante las fases evolutivas del proyecto. El secreto y el éxito de producir software con bajos márgenes de errores, quizá, dependerá de tener presente tanto los objetivos, los datos de relevamiento lo más fidedignos posibles y los improvistos controlados. Todo esto mejorará la calidad productiva de la construcción y guía del proyecto en general.

El Personal

El capital más poderoso, creativo e incidente del éxito de una empresa resulta ser la calidad de sus profesionales y sus empleados en una compañía. Así mismo, para el caso del desarrollo de software esta regla es similar. El personal es clave en el éxito del desarrollo del software.

Ahora bien, para lograr que esta sinergia de personas realice sus actividades de forma eficiente y eficaz se requiere de una basta estrategia de organización. Por tanto, la coordinación y la organización serán claves en el desarrollo exitoso del software. Es por ello que la organización debe ser coordinada por un gestor que administre competencias humanas más que competencias técnicas y es allí donde surge la brecha entre organizadores humanos y técnicos. En consecuencia, lo que se debe preconizar es la administración humana y como lograr el mejor éxito coordinado de las mismas para que estas produzcan en el terreno de la creatividad y el esfuerzo técnico.

El ingeniero Mantei considera que un equipo puede administrarse mediante tres pilares básicos y ellos son:

• Descentralizado Democrático DD – Este equipo no tiene un jefe permanente. Se nombran coordinadores a coro plazo y se sustituyen por otras diferentes tareas. Se utiliza el consenso como poder comunicativo, es decir, se trata de una comunicación horizontal.
• Descentralizado Controlado DC – Este equipo posee un jefe de cabeza y otros por debajo de este. Se mantiene el grupo pero la implementación de soluciones se reparte e subgrupos por el jefe del equipo. La comunicación entre subgrupo e individuos es horizontal y vertical a lo largo de la jerarquía de control.
• Centralizado Controlado – El jefe se encarga de la resolución de los problemas a alto nivel y la coordinación interna del equipo. La comunicación entre el jefe y el equipo es vertical.

Además de estas características, el ingeniero Mantei ha descripto esta tarea de coordinación en siete etapas, las cuales, le pueden ayudar a replantear la organización de equipos de producción de proyectos y estos son los siguientes:

• Dificultad del Problema a Resolver
• El Tamaño del Programa – Resultante en líneas de código o puntos de función
• El Tiempo que el Equipo Permanecerá Unido – Tiempo de vida del equipo
• El Grado del Problema puede ser Modularizado
• Calidad y Fiabilidad del Sistema a Construir
• Rigidez de Fecha de Entrega
• Grados de Sociabilidad – Comunicación requerida para el proyecto

En consecuencia, la organización de los grupos depende del tipo de proyecto y su envergadura. Resulta interesante saber, que según las recomendaciones del ingeniero Mantei, que el manejo de soluciones sencillas conviene que las administre equipos tanto DC o CC. Sin embargo, cuando los problemas no resultan ser sencillos, resulta recomendable pensar en un equipo DD.

El Producto

Quizá uno de los pasos más complejos es la de determinar los costes y los valores cuantitativos del producto. La complejidad de un proyecto y la difícil situación de ponderar componentes y personas, surge de la necesidad de encontrar un punto que determina la forma en cómo obtener el beneficio del coste de forma segura. Algunos tienden a aplicar la ley de Maquiavelo, “divide y vencerás”. De hecho suele ser una estrategia interesante. Un problema muy complejo puede ser dividido en problemas más pequeños o atomizados. Si esto es posible, Ud., puede cuantificar mejor los costes de desarrollo de cada área y juntarlos para obtener el coste global. Sin embargo, no resulta en una tarea sencilla. Peor aún, puede que sus costes se vayan distorsionando con el correr del avance del proyecto dado que la inconsistencia de los recursos se hace notar en estas etapas. Es por ello que la cuantificación de los costes se establezca con un meditado plan de desarrollo que contemple estas y otras desviaciones posibles de la presupuestación.

El gran problema que se tiene de entrada es que no se puede determinar con precisión la calidad del software. Lamentablemente, la calidad se podrá notar cuanto el modelo empírico y de prueba inicie sus primeras horas de vida. Es por ello que crear prototipos demo no resulta en una locura después de todo. Yo diría que el prototipo podría ser un generador de cuantificaciones que pueden servir para obtener los costes finales o, al menos, contar con un tanteo del coste del producto a simple vista. En resumen, la clave está en la coordinación, los objetivos y el desarrollo evolutivo del proyecto más el prototipo de muestra y evaluación.

El Proceso

Ha de estudiarse con mucho cuidado el proceso que se aplicará para el desarrollo del proceso. Si bien se ha estudiado que existen varias formas de practicar esta fase, la clave del proceso erradica en aplicar el método adecuado. Pasamos a recordarlos a continuación:

• Modelo Secuencial
• Modelo de Prototipo
• Modelo DRA (Desarrollo Rápido de Aplicaciones)
• Modelo Incremental
• Modelo Espiral y Espiral WINWIN
• Modelo de Desarrollo de Ensamblaje y Componentes
• Modelo de Desarrollo Concurrente
• Modelo de Métodos Formales
• Modelos de Técnicas de Cuarta Generación

Por tanto, toda planificación comienza con un proceso de maduración del desarrollo. Esta fase de maduración permite establecer las siguientes pautas evolutivas del proyecto:

• Comunicación con el Cliente – Tareas requeridas para establecer la obtención de requisitos eficiente entre el desarrollador y el cliente.
• Planificación – Tareas requeridas para definir los recursos, la planificación temporal del proyecto y cualquier información relativa a él.
• Análisis del Riesgo – Tareas requeridas para valorar los riesgos técnicos y de gestión.
• Ingeniería – Tareas requeridas para construir una o más representaciones de la aplicación.
• Construcción y Entrega – Tareas requeridas para construir, probar, instalar y proporcionar asistencia al usuario (por ejemplo: documentación y formación)
• Evaluación del Cliente – Tareas del cliente basadas en la evaluación de las representaciones de software creadas durante la fase de ingeniería e implementadas durante la fase de instalación.

La descomposición de los procesos resulta una tarea muy importante y, como hace mención el ingeniero Mantei en sus observaciones, resulta importante considerar el modo ECP (Estructura Común de Procesos). Por ejemplo, para un pequeño proyecto se tiene los siguientes pasos:

1. Desarrollar una lista de aspectos que se han de clarificar
2. Reunirse con el cliente para resolver los aspectos que se han de clarificar
3. Desarrollar conjuntamente una exposición del ámbito del proyecto
4. Revisar al alcance del proyecto con todos los implicados
5. Modificar el alcance del proyecto cuando se requiera

Estos son aspectos que pueden resolver pequeños problemas y establecer un lineamiento de fases bastante fáciles de seguir y con resultados satisfactorios a corto plazo. Sin embargo, en un proyecto más complejo surgen otras variantes que pueden complicar este tipo de lineamientos. Por ejemplo, para el caso de un proyecto cuyas fases muestren un escenario más amplio, las fases evolutivas del proceso podrían ser las siguientes:

1. Revisar la petición del cliente
2. Planificar y programar una reunión formal con el cliente
3. Realizar una investigación para definir soluciones propuestas y enfoques existentes
4. Preparar un documento de trabajo y una agenda para la reunión formal
5. Realizar la reunión
6. Desarrollar conjuntamente mini-especificaciones que reflejen la información, función y características de comportamiento del software
7. Revisar todas las mini-especificaciones para comprobar su corrección, su consistencia, la ausencia de ambigüedades
8. Ensamblar mini-especificaciones un documento de alcance del proyecto
9. Revisar ese documento general con todo lo que pueda afectar
10. Modificar el documento de alcance del proyecto cuando se requiera

El Proyecto

Cuando se establece el seguimiento de un proyecto, la mayor preocupación estriba en la desviación y en que las cosas puedan ir yendo en un sentido inadecuado. Si esta desviación se nota en las fases del proyecto, deberá de inmediato, tomarse decisiones acertadas. Existen las famosas reglas de señales de peligro definidas por el ingeniero John Reel en el que ha elaborado una tabla de notaciones negativas de la evolución de un proyecto que tiene una tendencia al desvío de los objetivos. Estas reglas son las siguientes:

1. La gente del software no comprende las necesidades de los clientes
2. El ámbito del producto está definido pobremente
3. Los cambios están mal realizados
4. La tecnología elegida cambia
5. Las necesidades del negocio cambian o están mal definidas
6. Las fechas de entrega no son realistas
7. Los usuarios se resisten
8. Se pierden los patrocinantes o nunca se obtuvieron adecuadamente
9. El equipo del proyecto carece del personal con habilidades propias
10. Los gestores y los desarrolladores, evitan buenas prácticas y sabias lecciones

Bien, para conducir el proyecto bajo un carril adecuado, el ingeniero John Reel establece el llamado “sentido común” y lo ha especificado en cinco reglas básicas y estas son las siguientes:

• Empezar con el pie derecho – Esta tarea se realiza trabajando duro, pero muy duro, para comprender el problema a solucionar y estableciendo entonces objetivos y expectativas realistas para que cualquiera que vaya a estar involucrado en el proyecto. Se refuerza construyendo el equipo adecuado y dando al equipo la autonomía, autoridad y la tecnología necesaria para realizar el trabajo.
• Mantenerse – Muchos proyectos no realizan un buen comienzo y entonces se desintegran lentamente. Para mantenerse, el gestor del proyecto debe proporcionar incentivos para conseguir una rotación del personal mínimo, el equipo debería destacar la calidad en todas las tareas que desarrolle y los gestores veteranos deberían hacer todo lo posible por permanecer fuera de la forma de trabajo del equipo.
• Seguimiento del Progreso – Para un proyecto de software, el progreso se sigue mientras se realizan los productos del trabajo (por ejemplo, especificaciones, código fuente, conjunto de casos de prueba) y se aprueban (utilizando revisiones técnicas formales) como parte de una actividad de garantía de calidad. Además, el proceso del software y las medidas del proyecto pueden ser reunidas y utilizadas para evaluar el progreso frente a promedios desarrollados por la organización de desarrollo de software.
• Tomar Decisiones Inteligentes – En esencia, las decisiones del gestor del proyecto y del equipo de software deberían “seguir siendo sencillas”. Siempre que sea posible, utilice software del mismo comercial o componentes de software existentes. Evite personalizar interfaces cuando estén disponibles aproximaciones estándar. Identifique y elimine entonces riesgos obvios. Asigne más tiempo del que pensaba necesitar para tareas arriesgadas o complejas (necesitará cada minuto).
• Realizar Análisis Postmorten, después de finalizar el proyecto – Establecer un mecanismo consistente para extraer sabias lecciones de cada proyecto. Evaluar la planificación real y la prevista, reunir y analizar métricas del proyecto de software y realimentar con datos de los miembros del equipo y de los clientes y guardar los datos obtenidos en formato escrito.

Autor: Wagner, Ariel Alejandro.