¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
  1. Libros
  2. Gestión de proyectos informáticos
  3. Evaluar el riesgo
Extrait - Gestión de proyectos informáticos Desarrollo, análisis y control (4ª edición)
Extractos del libro
Gestión de proyectos informáticos Desarrollo, análisis y control (4ª edición) Volver a la página de compra del libro

Evaluar el riesgo

Los tres ejes

Es normal que a veces el director de proyectos esté desconcertado debido a la cantidad de elementos que debe organizar para tener éxito. ¿En qué dirección ir? ¿Por dónde empezar y cómo continuar?

Para responder a estas preguntas, en primer lugar se debe imaginar el proceso del proyecto como se describe en el capítulo Iniciar un proyecto informático. En esta ocasión, elegimos un espacio estructurado por tres ejes, tiempo (ciclo de vida), análisis y control.

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

images/cap3_pag1.png

El primer eje (abscisa horizontal) es el que describe las fases del proyecto, tal y como las podemos preconfigurar. El diagrama anterior propone un modelo de desarrollo bastante estándar, a partir de la expresión de necesidades, evolucionando hasta la entrega (producción) y el mantenimiento del proyecto. Estrictamente hablando, deberíamos introducir el final del ciclo de vida del proyecto, porque sabemos que el marco de soporte no es infinito. Como veremos más adelante, existen otros modelos de desarrollo que proponen diferentes organizaciones.

A continuación, nos encontramos con el eje de análisis (ordenadas, verticales). Este representa el nivel de abstracción del proyecto....

El modelo de desarrollo

El modelo de desarrollo es una de las primeras elecciones que debe tomar el director de proyectos. Da forma explícita a la organización temporal del proyecto y tiene una gran influencia en el resultado final.

No existe un modelo correcto o incorrecto, al menos entre las grandes clases enumeradas a continuación. Sin embargo, cada proyecto tiene características que hacen que la aplicación de un modelo sea adecuada o, por el contrario, ineficaz. 

1. El modelo en cascada

También se llama modelo lineal o modelo nominal. Sin lugar a dudas se trata del modelo más sencillo, aunque no por ello deja de tener éxito.

images/cap3_pag6.png

En este modelo, cada etapa sigue a la anterior, sin necesidad de "esperar" su resultado. Tan pronto como se completa la expresión de las necesidades o requisitos, se escriben las especificaciones. Al final de este trabajo, se lleva a cabo el desarrollo hasta su finalización. Las pruebas unitarias se suceden entre sí, y así sucesivamente.

Antes de explicar por qué se llama en cascada, veamos las diferentes etapas previstas por este modelo.

Idea - inicio

Este es el punto de partida del proyecto, el momento en que se cumplen las condiciones de hardware y materiales y el equipo comparte la visión del proyecto.

Expresión de las necesidades

Tras tomar la decisión de comenzar un proyecto, volvemos a recopilar información de los usuarios para obtener más detalles. Estas peticiones se registran en un documento (papel u hoja de cálculo), se identifican y, finalmente, se agrupan y se buscan sinergias entre ellas.

Especificaciones

Todas las peticiones se consideran en función de los diferentes enfoques dictados por el modelo de análisis: importancia, prioridad, dificultad técnica, riesgos, etc. Las especificaciones muestran un desglose técnico-funcional de la aplicación.

Desarrollo

Las especificaciones se traducen en código, proyectando la segmentación modular (componentes) en la plataforma elegida por el arquitecto.

Pruebas unitarias

Cada componente se prueba independientemente del resto. Su comportamiento debe cumplir con las especificaciones, dentro del rango de operativo y de funcionamiento previsto.

Pruebas de integración

Los componentes se ensamblan con mayor frecuencia en una plataforma técnicamente heterogénea....

El modelo de análisis

Este modelo gobierna el estudio del sistema en formación. La mayoría de los métodos (modelos) empiezan dibujando los límites de este sistema para evitar centrarse en detalles externos. Seguidamente, el sistema se estudia desde el ángulo de los estímulos del usuario y luego se formaliza. Obviamente, toda la dificultad del ejercicio radica en la ausencia de una existencia concreta del sistema.

Antes de describir las líneas principales de los métodos más utilizados, Merise y UML, descubriremos cómo proceder para modelar sistemas informáticos.

1. El principio del modelado en análisis

El modelado es una abstracción de la realidad. Simplemente plasmar una situación en un documento constituye una abstracción. ¿Cuáles son los objetivos que perseguimos? En primer lugar, se trata de describir el sistema objetivo con un mínimo de formalismo. A ese respecto, Merise habla de un subconjunto representativo (SER). Esta "simplificación" es esencial para aquellos que quieren participar en las especificaciones de un proyecto sin disponer del producto final. El modelado también es una técnica para definir prioridades en un proyecto. Algunos detalles que se encuentran en las piezas del usuario no tienen un significado real, mientras que otros resultarán ser extremadamente importantes.

Para el director de proyectos, el modelado es un proceso que, recordemos, le permitirá tratar mejor su asunto priorizando la reutilización y la genericidad. A continuación, indicamos cómo.

El modelado se realiza en tres pasos: abstracción, instanciación y verificación.

images/cap3_pag17.png

La abstracción es el paso más complicado. Se trata de analizar aquello que existe para identificar lo esencial sin introducir sesgos. El obstáculo principal con el que se encuentran los programadores novatos es introducir de manera poco apropiada detalles que se pueden traducir en sesgos y esfuerzos inútiles en el resultado final. En nuestro ejemplo, la equipación del jugador de fútbol, su forma de celebrar los goles y el color de la pelota no importan.

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

Posteriormente, viene la instanciación. Por lo general, se obtiene...

El modelo de control

Conocemos la máxima "dirigir significa prever" y podríamos preguntarnos si se puede aplicar a la gestión de proyectos. Este es precisamente el propósito del control, es decir, prever la aparición de peligros y anticipar cambios críticos en el proceso del proyecto.

Ahí radica la principal diferencia entre la asociación del desarrollo y el análisis con el control. Los dos primeros modelos están anidados y son los que conforman el proceso del proyecto. El control gestiona el proceso con una visión externa, más sistémica. El proyecto, como proceso, forma parte de un conjunto de flujos de trabajo que caracteriza la actividad de la empresa. Esta actividad no solo es introspectiva, sino que conecta a la empresa con socios, clientes, proveedores y subcontratistas.

Por lo tanto, la gestión o control de un proyecto es una técnica de control del proyecto (un proceso "local") a nivel de empresa. Esto significa que el comité de control involucra solo a una parte del equipo del proyecto (generalmente el director del proyecto) y también a representantes del comité de dirección de la empresa, así como a sus homólogos que son miembros de las organizaciones asociadas al proyecto (socios, clientes, etc.).

Al igual que muchas actividades que se tratan en este nivel, la visión no se basa en detalles, sino en agregados de información básica llamados indicadores clave de rendimiento (Key Performance Indicator o KPI). Con estos indicadores, el comité de control proporciona nuevas direcciones y cambia las prioridades.

images/cap3_pag32.png

El riesgo se evalúa continuamente y, en última instancia, corresponderá al comité de control decidir sobre el resultado del proyecto, en caso de un aumento significativo en el nivel de riesgo o la aparición de peligros con consecuencias adversas.

Tener en cuenta el contexto de negocio y de los procesos, es otra de las ocupaciones del comité de control. Es necesario evitar a toda costa que especialistas técnicos...

Tener en cuenta el riesgo

1. Análisis del riesgo

¿Cuántos proyectos se han abandonado una vez empezados o incluso, en el momento de la entrega? Demasiados, eso es seguro. La informática algunas veces tiene una mala reputación: demasiado compleja, poco fiable y costosa. También lo son los equipos de proyecto: demasiado lentos, cautelosos o incapaces de adaptarse a las nuevas tecnologías. Por no hablar de los lenguajes de programación: orientación a objetos o no, demasiado reciente u obsoleto. Y después se critica a los proyectos por sus características más fundamentales: demasiado grandes, no lo suficientemente dotados, no lo suficientemente rentables como para permitir inversiones, etc.

Las críticas vienen de todas partes, antes, durante e incluso después. Aunque nunca sea agradable ser blanco de estas recriminaciones, incluso aunque algunas de ellas tengan fundamento, es más bien la forma en que se hace lo que sale mal. El análisis de riesgos es una actividad crucial de la gestión de proyectos. Su propósito es "consumir" todas las observaciones, alertas, críticas y objeciones planteadas antes y durante el proyecto, para llevar a cabo las operaciones hasta su conclusión en las mejores condiciones de previsión posibles.

a. Clases de riesgo

Siempre estamos interesados en los mismos temas. Las cuestiones aparentemente opuestas en realidad cubren el mismo tipo de riesgo. Supongamos el caso del lenguaje de programación. Para una persona dada, puede ser inconcebible desarrollar hoy en día sin un lenguaje que no responda a los paradigmas de orientación a objetos, mientras que para otra, por el contrario, introducir la orientación a objetos en un script es una fuente de complejidad o incluso de complicaciones innecesarias. ¿Quién tiene razón? Todo depende de las circunstancias. No podemos hacer una clasificación de las mejores tecnologías. Cada una de ellas está orientada a un determinado marco de aplicaciones en el que dará excelentes resultados. En un entorno diferente, puede obstaculizar drásticamente la realización del proyecto.

En otras palabras, no vamos a establecer una lista de los riesgos, sino los tipos de riesgos. La persona responsable del análisis de riesgos es la encargada de confrontar la realidad...

Estudio de riesgos para el proyecto CRM

La empresa consultora Plus encargó a Guillaume, informático, que ayudara a la dirección de marketing, en la que también se encuentra la directora de proyectos, Annie. Juntos, identifican los riesgos aplicables a su proyecto de implementación de CRM. El producto de su reflexión tendrá un doble impacto. En primer lugar, el nivel de riesgo se actualizará en cada comité de control, para que se puedan anticipar los períodos clave durante los cuales se debe prestar atención a aspectos particulares del proyecto. Por otro lado, la evaluación del perfil de riesgo guiará la elección de un proveedor y proveedor de servicios, para implementar la solución en función de una determinada metodología adaptada.

1. Análisis de riesgo

a. Viabilidad del proyecto

Los patrocinadores (sponsors) se tienen que asegurar de que el marco del proyecto sea compatible con los objetivos estratégicos. En otras palabras, no planteamos la duración del proyecto, la fecha de lanzamiento operativo (go live) ni la asignación presupuestaria.

El proyecto comienza en octubre, se prevén dos meses de selección de proveedores y seis meses de implementación. Por lo tanto, el go live se produciría al inicio del período estival del año siguiente, en el mejor de los casos. Probablemente este no sea un buen momento para lanzar una nueva aplicación, ya que la mayoría de los usuarios estarán de vacaciones. Guillaume sugiere a Annie que aproveche este período para hacer un lanzamiento "suave" (soft opening) con efectivos reducidos y asociados que estén más disponibles durante sus vacaciones. Annie está interesada en esta idea, pero también teme que los proveedores de servicios no estén realmente disponibles después de que termine el contrato. También espera que las negociaciones duren más de lo esperado por el DAF.

Annie tiene razón probablemente, porque la falta de identificación de un presupuesto preciso no pondrá a la compañía en una posición de fuerza para las negociaciones, que corren el riesgo de convertirse en arbitrajes dolorosos e ineficaces para, finalmente, apoyarse en el presupuesto de reserva. Entonces, Guillaume propone establecer...