La estimación del riesgo

Los tres ejes

El jefe de proyecto algunas veces se queda perplejo frente al número de elementos que debe gestionar. ¿En qué dirección empezar?, ¿por dónde empezar y cómo continuar?

Para responder a estas preguntas, hay que representar en primer lugar los procesos del proyecto, tal y como los hemos descrito en el capítulo Un proyecto informático. En esta ocasión, elegimos un espacio estructurado en tres ejes, tiempo (ciclo de vida), análisis y control.

Cada dimensión de este espacio corresponde a un método más o menos estándar, que dará lugar a un proceso que el jefe de proyecto tendrá que seguir.

El primer eje (en la abscisa, horizontal) describe las fases del proyecto, tal y como podemos imaginarlas. El esquema anterior ofrece un modelo de desarrollo bastante estándar. Empieza expresando las necesidades y evoluciona hasta la entrega (producción) y mantenimiento del proyecto. Siendo rigurosos, deberíamos introducir la finalización del proyecto, ya que sabemos que la cobertura de soporte no es infinita. Más adelante veremos otros modelos de desarrollo existentes, propuestos por diferentes organizaciones.

A continuación viene el eje de análisis (en la ordenada, vertical). Indica el nivel de abstracción del proyecto. Cuanto mayor sea la ordenada, mayor es la abstracción. De manera inversa, una ordenada...

El modelo de desarrollo

El modelo de desarrollo es una de las primeras elecciones que debe hacer el jefe de proyecto. Da forma de manera explícita a la organización temporal del proyecto e influye mucho en el resultado final.

No hay buenos o malos modelos, al menos entre las grandes clases que se enumeran a continuación. Sin embargo, cada proyecto tiene características que hacen que la aplicación de un modelo acertado o el contrario no sea eficaz.

1. El modelo en cascada

También se llama modelo lineal o modelo nominal. Es el modelo más simple, aunque no hay que dejarlo de lado.

En este modelo, cada etapa sigue a la anterior, sin que sea necesario nada más que "esperar" su resultado; cuando termina la expresión de las necesidades, se escriben las especificaciones. Cuando termina esta fase, se hace el desarrollo hasta su finalización. Se encadenan las pruebas unitarias y así sucesivamente.

Antes de explicar la denominación "en cascada", nos fijamos en las diferentes etapas previstas para este modelo.

Idea-puesta en marcha	Es el punto de partida del proyecto, el momento en el que se establecen las condiciones de hardware y se comparte la visión del proyecto con el equipo.
Expresión de las necesidades	Después de tomar la decisión de participar en un proyecto, se recogen las necesidades funcionales de manera detallada, consultando a los usuarios. Estas consultas se detallan en un documento de trabajo (papel u hoja de cálculo), se identifican y finalmente se reagrupan o se cruzan entre ellas.
Especificaciones	El conjunto de consultas se toma en consideración, siguiendo diferentes enfoques fijados por el modelo de análisis: importancia, prioridad, dificultad técnica, riesgos... De las especificaciones se desprende la separación técnico-funcional de la aplicación.
Desarrollo	Las especificaciones se traducen a código, proyectando la división modular (componentes), en la plataforma elegida por el arquitecto.
Pruebas unitarias	Cada componente se prueba de manera independiente los unos de los otros. Su comportamiento se debe ajustar a las especificaciones, dentro de la franja de funcionamiento previsto.
Pruebas de integración	Los componentes por lo general se ensamblan en una plataforma técnicamente heterogénea. La lectura de registros SQL desde código...

El modelo de análisis

Este modelo administra el estudio del futuro sistema. La mayor parte de los métodos (modelos) empiezan por identificar los límites del sistema para evitar concentrarse en los detalles externos. Después, el sistema se estudia bajo un prisma de usuario y a continuación se formaliza. Evidentemente, toda la dificultad se centra en la no existencia concreta de esos sistemas.

Antes de describir las grandes líneas de los métodos más utilizados, Merise y UML, vamos a descubrir qué se debe hacer para establecer los modulos de los sistemas informáticos.

1. El principio de modelización del análisis

La modelización es una abstracción de la realidad. Describir una situación en un documento es una abstracción. ¿Qué objetivos buscamos? En principio se trata de describir, con un mínimo de formalismo, el sistema que buscamos. A este respecto, Merise habla de subconjunto representativo (SER). Esta "simplificación" es primordial para quien desee participar en las especificaciones de un proyecto, sin tener el producto final a mano. La modelización también es una técnica para definir las prioridades en un proyecto. Algunos detalles que residen en los objetos de los usuarios no tienen ningún sentido real, mientras que otros son de una importancia vital.

Para el jefe de proyecto, la modelización es un proceso que, recordemos, le permitirá tratar lo mejor posible su objetivo, favoreciendo la reutilización y la generalidad. A continuación se explica cómo actuar.

La modelización se lleva a cabo en tres fases: abstracción, instanciación y verificación.

La abstracción es la etapa más delicada. Se trata de analizar lo que existe para extraer lo fundamental, sin introducir sesgos. La trampa reservada habitualmente a los programadores principiantes, consiste en introducir de manera no apropiada detalles que serán ignorados y esfuerzos en vano en el resultado final. En nuestro ejemplo, la dirección del jugador, sus exclamaciones y el color del balón, no tienen ninguna importancia.

La abstracción proporciona modelos que serán una representación formalizada y subjetiva de la realidad.

A continuación viene la instanciación. Normalmente se obtiene usando...

El modelo de control

Conocemos el dicho "gestionar es prever" y nos podríamos preguntar si aplica a la gestión de proyectos. El objetivo del control es precisamente prever la supervisión de peligros y anticipar los cambios críticos del proceso de proyecto.

Ahí reside la diferencia principal entre la asociación del desarrollo y el análisis con el control. Los dos primeros modelos están anidados y son las partes constitutivas del proceso de proyecto. El control controla el proceso con una visión exterior, más sistemática; el proyecto, como proceso, forma parte de un conjunto de flujos de trabajo que caracteriza la actividad de la empresa. Esta actividad no solo se aplica hacia el interior, sino que relaciona la empresa con sus socios, clientes, proveedores y subcontratistas.

El control de un proyecto es una técnica para controlar el proyecto (un proceso "local"), a escala de la empresa; lo que significa que el comité de control sólo implica a una parte del equipo de proyecto (normalmente el jefe de proyecto) y a los representantes del comité de dirección de la empresa, junto a sus homólogos de las empresas asociadas en el proyecto (socios y clientes).

Como muchas de las actividades que se tratan en este nivel, la visión no se basa en el detalle, sino en la agregación de la información elemental, lo que llamamos indicadores clave de rendimiento (KPI). Gracias a estos indicadores, el comité de control aporta orientaciones nuevas y modifica las prioridades.

El riesgo se evalúa permanentemente y será el comité de control el que, en última instancia, decidirá sobre el resultado del proyecto en caso de agravamiento significativo del riesgo o si aparecen peligros con consecuencias negativas.

Tener en cuenta el contexto del negocio y de los procesos, es otra tarea del comité de control. Hay que evitar a toda costa que ningún especialista técnico...

Estimación de los riesgos

Estudio del riesgo para el proyecto de CRM

La consultora Plus ha solicitado que Guillermo, que es informático, ayude a Ana, que es responsable de marketing y que también pasa a ser jefa de proyecto. Los dos identifican los riesgos aplicables a su proyecto de implantación de un CRM. El producto de su reflexión tendrá un doble impacto. En primer lugar, el nivel de riesgo se actualizará en cada comité de dirección, de manera que se anticipe los periodos en los que se debe prestar una atención especial a los aspectos particulares del proyecto. Por otro lado, la evaluación del perfil de riesgo va a guiar la elección de un proveedor, que va a desplegar la solución siguiendo una metodología adaptada.