Ingenieria de Sistemas aplicada a la Libertad Financiera III: Requisitos

Siguiendo con la idea de aplicar ideas del trabajo a la Libertad Financiera (ver parte I: Introduccion y parte II: Ciclo de Vida), tras estudiar el ciclo de vida de un proyecto, traemos hoy el tema de los “requisitos” en los proyectos.

He de decir antes de nada que la palabra “requisitos” no me suena bien. Siempre hemos escuchado decir requirements. De hecho, me pregunto si estas cosas se traducen o simplemente se toma la palabra inglesa para evitar errores. Si algún lector lo sabe, que lo comente más abajo.

Dos niveles de requisitos

Hay dos niveles de requisitos, los requisitos de usuario (user requirements) y los requisitos de sistema (system requirements).

Requisitos de Usuario

Todo proyecto empieza tomando nota de las necesidades de los futuros usuarios. Así que en reuniones muy sesudas se toma nota de sus deseos y se escribe el [EURD] (End User Requirement Document).

Este documento está compuesto por una lista de requisitos de alto nivel, indicados con unos identificadores únicos, desde el punto de vista del usuario final.

A este nivel no nos preocupa la implementación, eso vendrá después.

Ejemplo de la Libertad Financiera

De una manera informal, hemos comentado en casa que tenemos los siguientes deseos (el equivalente al [EURD]).

  • El objetivo de este proyecto es alcanzar la Libertad Financiera. La Libertad Financiera se define como la obtención de ingresos pasivos en una cantidad tal que nos permita cubrir nuestros gastos.
  • La Libertad Financiera será alcanzada por la vía del ahorro y la inversión.
  • Todo dentro de la legalidad vigente, nada de experimentos offshore y trucos extraños.
  • Si algún momento recibiéramos una pensión pública, sería bienvenida, pero no contamos con ella.
  • El proceso de ahorro e inversión no puede modificar en gran medida la vida cotidiana de los usuarios.
  • La fase de ahorro e inversión ha de estar terminada no después de que los usuarios lleguen a la edad de jubilación estatal.

Requisitos de Sistema

Una vez que tenemos la lista de requisitos de los usuarios, entonces vamos a crear los requisitos nuestros, internos. Van a ser los requisitos de sistema, y van a quedar documentados en el [SRD] (System Requirement Document).

Como norma general, por cada requisito en [EURD] va a haber al menos un requisito en [SRD].

Ejemplo de la Libertad Financiera

La implementación ya se ha decidido. Va a ser invertir de manera pasiva, en una cartera diversificada, utilizando fondos de inversión, siguiendo una filosofía Bogleheads.

Para evitar caer en prácticas de inversión inapropiadas (como el por ejemplo hacer market timing), es norma de buena costumbre escribir un “manifiesto inversionista” (equivalente al [SRD]). Este manifiesto inversionista se crea a partir de las ideas recogidas en las conversaciones previas (el [EURD]).

  1. El objetivo de este proyecto es invertir de manera pasiva según la filosofía 60%/40% Bogleheads.
  2. La cartera estará compuesta por los siguientes ETFs: VWRL (Vanguard All-World) y EUNH (iShares core eur government bond).
  3. Todos los meses se comprarán los fondos de inversión indicados en punto 2.
  4. Los ingresos vendrán de aplicar la regla del 4% al total del patrimonio.
  5. Los ETFs distribuyen dividendos. Lo que falte hasta completar el 4% se obtendrá vendiendo activos.
  6. El porcentaje de ahorro de los ingresos mensuales será variable. Porcentajes mayores del 30% serán opcionales pero no obligatorios.
  7. El proyecto tomará en consideración 20 años como tiempo máximo para la fase de ahorro.

Cambios

Bueno, pues ya tenemos la documentación ([EURD] y [SRD]), y todo va viento en popa. Pero esto no puede durar mucho, en todo proyecto surge la necesidad de cambiar los requisitos ¿Qué hacer en este caso?

Uno quiere pensar que los requerimientos sean perfectos, pero a la hora de la verdad siempre hay que retocarlos. Esto es normal, porque el conocimiento se va obteniendo poco a poco, cuando los requerimientos se definen realmente se sabe muy poco de cómo será el sistema ya desarrollado.

SysEng_06_Requisitos
Los requisitos evolucionan según avanza el proyecto.

Si hay que cambiar algo, entonces nos encontramos ante un CR (Change Request). Este CR va a ser preparado con toda la información posible, con la sugerencia técnica, para ser aprobada por el management. CR se presenta en un CCB (Change Control Board), donde se acepta (o no) para ser implementado. En el caso de ser aceptado para ser implementado, el equipo técnico lleva a cabo los cambios.

El CCB es el punto central para coordinar cambios en la documentación y la configuración del sistema. A esta reunión acuden miembros de los diversos departamentos. El objetivo es que todos los departamentos estén informados de los cambios, y que todos ellos puedan aportar su punto de vista con respecto de los cambios.

¿Qué tipos de CRs nos encontramos? CCN, CN, RfD, y RfW.

CCN (Contract Change Notice). Se crean cuando tenemos que modificar un contrato. Esto necesita ser aprobado por management en CCB, tanto porque modificar el contrato va a implicar un incremento en el coste, como porque puede haber implicaciones adicionales que no han sido tenidas en cuenta por el equipo que ha preparado el CCN.

Ejemplo: Vino el otro día Fog y me dijo, “mira Willy, he decidido incluir una parte de oro en la cartera”. Fog por favor, ¿no habíamos dicho que en esta casa somos de Bogleheads? Vale, no pasa nada, pero prepárate los argumentos (CCN) y a la hora de la cena lo comentamos (CCB).

CN (Change Notice). Este es una modificación menor, que no afecta a los usuarios. El objetivo es hacerla pública, para que no exista ninguna posibilidad de que haya efectos del cambio no tenidos en cuenta. En el CCB habrá representantes de otros equipos, que podrán asegurar que no hay ningún impacto reseñable por este CN. Es un cambio en la implementación, hay que avisar al usuario pero no hace falta su aprobación.

Ejemplo: Resulta que el ETF que nos interesa no está disponible en el broker, ha sido eliminado. Ok, no hay problema, se escoge otro ETF que siga al mismo índice y listo. Se necesita un CN para documentarlo, y ya está.

RfD (Request for Deviation). Uno de los requisitos es demasiado estricto y no puede ser cumplido. Hay que relajar la condición, hacerla más fácil de cumplir. El RfD se envía al CCB para ser aprobado. Tal vez era una condición demasiado estricta, y el relajarla no tenga ningún impacto en el resto del proyecto. En este caso, el CCB aceptará el RfD.

Ejemplo: El ETF VUSA (S&P 500 de Vanguard) no está disponible, así que elegimos SXR8 (S&P 500 de iShares) en su lugar. Hay que modificar el requisito número 2 del “contrato inversionista”/[SRD], pero la diferencia es mínima, así que basta con crear un RfD y enviarlo al CCB para ser aprobado.

RfW (Request for Waiver). Uno de los requisitos es imposible de cumplir. Se solicita al CCB eliminar ese requisito. Si la eliminación de este requisito no tiene un impacto negativo en el resto del proyecto, el CCB aprobará el borrarlo.

Ejemplo: Si cambiásemos de idea y solo buscásemos complementar la pensión pública, podríamos ignorar el requisito número 7 del “contrato inversionista”. Ya no hace falta preocuparse por el plazo de 20 años, cuando nos jubilemos, los ingresos pasivos que obtengamos complementarán la pensión pública. Por lo tanto vamos a preparar un RfW que será confirmado durante una de nuestras cenas (CCB).

 

Ya hemos tenido la introducción a la ingeniería de sistemas, al ciclo de vida de los proyectos, a la gestión de los requisitos del proyecto. En el siguiente post pasaremos a preocuparnos por los posibles riesgos de que algo vaya mal ¿Cómo tener en cuenta estos riesgos?

Autor: willyfog

Turista laboral por la Unión Europea. Por favor que dure. Lo que veo, leo o me cuentan no lo suelo encontrar en español, así que me gusta escribirlo por aquí.

Un comentario en “Ingenieria de Sistemas aplicada a la Libertad Financiera III: Requisitos”

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s