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.

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.

El Ciclo de Vida: Fase de Elaboración

La fase de elaboración es la encargada de determinar la solución técnica del proyecto. Así como durante la fase de inicio se determino el qué, ahora es necesario el como. Es esta fase durante la cual elaboramos los requisitos al nivel del diseño y por tanto, nos pone en posición de saber si el proyecto es técnicamente viable así como conocer la tecnología que vamos a utilizar durante la construcción.

El foco de la fase de elaboración se encuentra en las disciplinas de Diseño y Análisis; ya que estas son las encargadas de dar con la solución técnica. Aunque también hay un importante papel para la Gerencia del Proyecto, dado que en la fase de Elaboración es el punto donde debemos haber disminuidos y controlados los riesgos principales que pudieran dar al traste con el proyecto.

Es también la Fase de Elaboración el punto de no retorno para el proyecto. Una vez que dejemos atrás a esta fase y entremos en la construcción, los gastos serán tan elevados que se tendrá que tener muy en claro el alcance de la apuesta económica; es mejor detener un proyecto aquí, cuando se ha ejecutado menos del 25% del presupuesto que más adelante, donde los gastos son mucho mayores.

Típicos objetivos para esta fase son:

• Documento de Arquitectura del Sistema revisado y aceptado.
• Prueba de Concepto exitosa de todas las tecnologías novedosas a utilizar.
• Prototipo de la Arquitectura del sistema.
• Plan de Riesgos con los riesgos principales identificados y controlados.

El objetivo central es solo uno: responder si el proyecto es técnicamente viable con la solución o diseño propuesto.

Entonces, ahora como para el glosario:

Fase de Elaboración: Establece el como del proyecto; es decir: determina la solución técnica del sistema y la demuestra a nivel de pruebas de concepto. La Fase de Elaboración también es el punto donde se deben de haber controlado los riesgos principales del proyecto.

Finalmente, en cuanto a su duración, considero como sano una fase de elaboración de dos o tres iteraciones. Esto debido a la necesidad de realizar y probar el diseño, lo que genera una carga de documentación y de programación sensiblemente mayores a las que teníamos durante la fase de concepción. Por otra parte, en un proyecto típico, el gasto realizado es de aproximadamente el 20% del total del costo del proyecto; por lo que la ejecución del presupuesto si contamos también a la fase de concepción rondará el 25%.

Guiado por Requisitos y Riesgos

Idealmente todo Proceso Definido tendría una declaración de los principios detrás de las decisiones que se tomaron durante su diseño y puesta en punto. Esta declaración de principios resumiría en unas pocas frases todo el cuerpo metodológico del proceso.

En nuestro caso, tomamos la frase “Guiado por Requisitos y Riesgos” del Proceso Unificado de Desarrollo de Software, más conocido por las siglas UP.

Ser guiado por algo, significa que ese algo se tomará en cuenta en cada reunión de avance, para que las acciones siguientes estén moldeadas a la luz de este concepto guía. Tal como cabría esperar, el proceso UP define que su avance será planificado según los requisitos del proyecto y se cuidará siempre de los riesgos identificados.

Poniendo esto en forma más clara, tendríamos dos puntos:

Primero: UP es guiado por requisitos, lo cual quiere decir que es según estos como se expresa tanto la división del proyecto en subproyectos, como la planificación de las tareas a abarcar en una iteración dada. Si tenemos un Paquete de Requisitos con una organización racional, veremos que UP recomienda basarse en esta división para ir cubriendo los requisitos en una forma ordenada y sistemática, atendiendo sus dependencias y maximizando en todo momento el valor de negocio entregado por las actividades.

Segundo: UP es guiado por riesgos, lo cual en forma análoga a la anterior, significa que en cada iteración se incluirán actividades y tareas que busquen atacar los riesgos, según orden el de importancia con que se registraron estos en el Plan de Riegos del proyecto.

Existen dos principios más enunciados por UP como ideas centrales del proceso, pero las dejaremos para otro día. Por ahora, cuando planifique los próximos pasos de sus proyectos, cuide siempre que estas estén diseñadas tanto para satisfacer los requisitos por orden del valor de negocio que generan como para que ataquen los riesgos más importantes, todo según lo que se identifico en los documentos y demás artefactos relacionados con el manejo de requisitos y riesgos.

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.

Definimos Riesgo como…

Entenderemos por riesgo cualquier situación posible que de ocurrir perjudique al proyecto en alguna forma. Un riesgo puede ser desde que un avión se caiga hasta que las líneas de crédito del proyecto no sean aprobadas por el banco. Todo lo que pueda ocurrir, si es malo, es un riesgo.

Riesgo hace referencia a toda situación posible que de verificarse, hace daño al proyecto o incide negativamente sobre el desempeño del mismo.

Cualquier administrador de proyectos hace bien en identificar una lista de riesgos y en evaluar si estos son más o menos inminentes. Dicha revisión conviene hacerla en cada oportunidad que se tenga, sobre todo, en las reuniones de avance del proyecto. Es buena practica mantener un documento que liste los riesgos identificados, junto con su probabilidad de aparecer, y el costo o magnitud del daño que harían en tal caso.

En este caso, a la hora de identificar riesgos conviene trabajar un poco de más y tener una enumeración más larga de la necesaria. Eso es mucho mejor que dejarse sorprender por una situación negativa.