Entradas etiquetadas como Riesgos

Líneas Base

Una línea base es el compromiso, negociado y aceptado, que se alcanza con el cliente para que este comprenda que hemos de poner un alto en la captación de necesidades con miras a enfocarnos por unos días, en construir aquello nos ha pedido hasta el día de hoy.

Como estrategia de organización del proyecto, su principal virtud es la de permitir la gestión de requerimientos, al introducir pausas regulares en las exigencias del cliente, con miras a ver primero el logro de las primeras ideas, antes de introducir nuevas variaciones.

Al contar con las líneas base como estrategia de gestión de requisitos, es posible disminuir el riesgo que representan para los proyectos las especificaciones incompletas: simplemente no vamos a aspirar a tener todas las cartas en la mano, vamos a trabajar con lo que tenemos hasta un punto y luego, alcanzados los primeros objetivos, volver a recoger lo que se nos haya escapado la primera vez.

Por lo mismo, es posible también reducir el riesgo de desorden en los requisitos del proyecto. Hay una disciplina en el equipo del trabajo, que se le puede explicar al cliente. Dicho de otra forma, es una forma educada de pedirle paciencia.

Anuncios

, , , , , , , ,

Deja un comentario

Definimos Terminos de Referencia como…

De tanto en tanto nos vamos a encontrar con que la organización que requiere el desarrollo elabora para nosotros un documento de requisitos, en formato libre, al que llaman no sin cierto orgullo “Términos de Referencia”. La práctica viene de otras áreas de la ingeniería donde una petición simple de parte del cliente puede ser analizada y convertida en un trabajo completo, con un razonable nivel de calidad.

Sin embargo, en Ingeniería del Software los términos de referencia no pueden ser utilizados con buenos resultados. Típicamente son documentos incompletos, que mezclan requisitos con análisis e incluso con diseño, cuya existencia es señal de acceso limitado a los stakeholders por parte de la organización de desarrollo. En otras palabras: si nos dan Términos de Referencia tendremos problemas más adelante.

El acto de especificar un sistema de software a demostrado repetidamente ser difícil. Es necesario indicar un gran número de aspectos distintos, mantener la diferencia entre requisito y solución, actuar primero a lo ancho, capturar valor de negocio, entre otros puntos que son propios de nuestra profesión y que resultan incompatibles con las premisas detrás de un documento de términos de referencia.

Veamos algunos de estos puntos en detalle. Comencemos por la definición:

Términos de Referencia: Documento elaborado por el cliente con indicaciones de las especificaciones requeridas al sistema de software por desarrollar.

En otras palabras: en un documento de Términos de Referencia el cliente ha querido ahorrarnos a nosotros el trabajo de especificación. Muy amable de su parte, pero si la organización de desarrollo no interviene en la especificación entonces nos enfrentamos a varios problemas:

  • Se ha asumido un modelo de ciclo de vida en cascada. Los modelos actuales son iterativos, repitiendo múltiples veces el paso de especificación. Un esquema más rígido, como el cascada, suele incrementar el riesgo de fracaso del proyecto.
  • Si el cliente siente que ya ha desarrollado los requisitos a satisfacción puede verse renuente a dedicar esfuerzos nuevos en este asunto. Tendríamos entonces problemas al presupuestar horas para actividades de elicitación de requisitos.
  • El documento en si mismo es un problema. Su estructura es necesariamente ad-hoc, independiente de la metodología que se vaya a seguir en el desarrollo. Puede ser difícil de analizar y haber dejado puntos importantes por fuera.

Si solo fuera para tener una idea del proyecto, básicamente cualquier documento o carta es bueno. Sin embargo los términos de referencia vienen con intenciones más amplias: sustituir la especificación profesional por un único documento, valido para el desarrollo así como para el cálculo de la oferta económica. No importa como lo vea, los términos de referencia son un problema.

Sin embargo, los Términos de Referencia son también un hecho. En algunas situaciones incluso son lógicos: en las licitaciones se distribuyen especificaciones para acto seguido requerir ofertas de costo cerrado. Si esto funciona bien en tantos sectores distintos, el cliente puede pensar que ha de valer también para sus proyectos de software.

Por lo anterior será inevitable que nos topemos con estos documentos. Tendremos que desarrollar entonces alguna técnica para sacar el mayor provecho de los mismos, sin importar cuan diferentes sean de caso en caso y de cliente en cliente. A fin de cuentas ellos son el cliente, y uno no puede ser tan descortez de desachar los resultados de su trabajo.

Finalmente me gustaría recordar que todos sin excepción hemos luchado con los términos de referencia de nuestros profesores y preparadores. ¿Cuantas veces en nuestros estudios tuvimos que llevar a cabo un proyecto a partir de un breve enunciado carente de toda norma de calidad? Así como entonces fue difícil producir un programa autenticamente útil a partir de dichas especifiones, aquí nos va a costar mucho trabajo en conseguir satisfacer el cliente si nos atenemos unicamente a lo dicho en los malvados, digo, en los variables Términos de Referencia.

, , , , , , , ,

3 comentarios

Tareas: Construir Lista de Riesgos

La lista de riesgos es el enunciado de todas las posibles situaciones que pueden perjudicar el proyecto. Es elaborada con ayuda de los stakeholders y del personal de la empresa de desarrollo, considerando la visión del sistema para poder prever, ya desde el principio del proyecto, cuales son esos riesgos posibles.

La identificación por si sola no es suficiente para tener control de los riesgos, sin embargo no se puede mitigar aquello que no se tiene identificado, por lo que toda la gestión de riesgos debe comenzar por construir la lista de riesgos principales. Tarea que debe ser revisada de tanto en tanto, probablemente luego de cada iteración o cierre de fase. Con todo, es meta del ciclo de vida para la fase de elaboración, que para entonces ya hayamos tomado medidas contra los principales riesgos con miras a que estos no molesten durante la fase de construcción.

El siguiente diagrama SPEM ilustra la tarea:

Fig. 1 – Diagrama SPEM de la tarea Construir Lista de Riesgos

Para cuando la lista de riesgos se va a crear por primera vez, se puede considerar seguir los siguiente pasos:

  1. Convocar a los trabajadores y stakeholders relevantes.
  2. Iniciar la reunión con una inducción de los tipos de riesgos comunes.
  3. Dar a los asistentes unos minutos para que realicen individualmente una primera lista de riesgos.
  4. Pedir a los asistentes que ordenen sus riesgos identificados por orden de importancia.
  5. Tomar los tres o cinco primeros riesgos de cada lista.
  6. Identificar los riesgos más nombrados, estos son los que más preocupación causan.
  7. Enriquecer la lista común con sugerencias y ampliaciones.
  8. Clasificar y ordenar los riesgos de la lista común según los criterios pertinentes.
  9. Presentar la lista de riesgos en la forma de un documento.

Por otra parte, si la lista ya está realizada, se puede entonces la tarea se vuelve un trabajo de revisión y actualización, algo definitivamente más simple, que bien puede no necesitar de una reunión expresa para el punto.

Por ultimo comento que es típico que el rol de analista de riesgos sea asumido por el Jefe de Proyecto. No hay buena razón para tener a alguien dedicado exclusivamente a esto y de todos modos, el Jefe de Proyecto es de seguro, uno de los invitados a la reunión de identificación de riesgos.

, , , , , ,

1 comentario

Como combatir los riesgos

Existen tres formas básicas de combatir los riesgos: eliminación, cobertura y diversificación. Estas estrategias son sencillas y de aplicación universal, en cuanto valen como posibles alternativas ante cualquier tipo de riesgo. Veremos si las podemos explicar con ayuda de un ejemplo deportivo.

Digamos que hay dos equipos de fútbol en la liga, que tienen mucha competencia entre ellos. Nosotros estamos en posición de apostar… y como perder es algo que no queremos entonces estamos frente a nuestro riesgo ya definido: “perder nuestra apuesta”.

Como tal, este riesgo tiene una probabilidad de ocurrencia del 50%… estadística que bien puede variar en función de los equipos en cuestión. Este porcentaje es la probabilidad de ocurrencia del evento.  50% significa que el asunto es como tirar una moneda: puede que se gane, puede que se pierda.

Vamos a trabajar este riesgo con la primera alternativa. La Eliminación de Riesgos es el acto de tomar decisiones que los hacen imposibles de ocurrir. En nuestro caso: decidir no apostar.

En cuanto a la segunda alternativa, si apostamos no a uno solo sino a los dos equipos… pues uno de ellos necesariamente ganará… cierto? A esta estrategia la llamamos Cobertura de Riesgos. Ante un riesgo dado, su cobertura será un evento necesariamente opuesto que ocurre al presentarte el problema y que hemos dispuesto que nos compense por el daño recibido.

Finalmente tenemos La Diversificación de Riesgos. Esta es simplemente no apostar tan solo en el partido de nuestro ejemplo, sino que también vamos a atrevernos a apostar en otros. De esta forma, perderemos en algunos y ganaremos en otros. A la larga, una buena política de diversificación puede hacernos ganar incluso si hemos perdido una fracción importante de los encuentros.

Los riesgos son parte de la vida… así que hay que prepararse contra ellos y para cada uno escoger una de las políticas básicas: Eliminación, Cobertura y Diversificación.

, , , , , ,

6 comentarios