mejoramiento de la gestión de requisitos en proyectos de …€¦ · la mejora, además,...

Universidad Técnica Federico Santa María

Departamento de Informática

Magíster en Tecnologías de la Información

1

Mejoramiento de la Gestión de Requisitos en Proyectos de Implementación de Infraestructura TI

Eduardo Fiol Mujica

[email protected]

Resumen. Un Requisito es toda característica observable de una solución que el Interesado desea esté presente en ésta. La Gestión de Requisitos consiste en manejar estas características en un proyecto, reduciendo el Riesgo de implementación de éste y aumentando la probabilidad de éxito. La manera en que se gestionan los requisitos en ECITI genera retrasos y mayores costos por rediseño y retrabajo. Se propone mejorar la Gestión de Requisitos en tres ejes: Organizacional, Metodológico y Económico. Se establece como Objetivo fortalecer los roles, seguir estándares y mejores prácticas, guiarse por metodologías y apoyarse en herramientas, para que contribuyan al negocio eficaz y eficientemente, lo cual traerá como Beneficio un mejor nivel de cumplimiento ante clientes y una mayor rentabilidad. La mejora, además, impactará positivamente la imagen de la empresa ante los clientes y el clima interno. Se desarrolla un Caso donde se aplica a un proyecto previo en modalidad ingeniería reversa y se obtiene una reducción del 54% del sobrecosto en HH asociado a errores y omisiones en la gestión Comercial-Arquitectónica, lo cual casi duplica las estimaciones. Es fundamental que la Empresa se prepare para un salto evolutivo hacia una Arquitectura de Soluciones Complejas, incorporando paulatinamente este enfoque y sus componentes.

Palabras Clave: Infraestructura TI, Gestión de Requisitos, Gestión de Proyectos, Mejora de Procesos, PDCA, PMBoK, ITIL.

1 Introducción

La Gestión de Proyectos TI es diferente de la gestión de otros tipos de proyecto, porque las necesidades cambian permanentemente, por la (in)compatibilidad entre distintos componentes de hardware y software, por las amenazas de seguridad, por las restricciones de ancho de banda en las redes, etc. [07].

La Gestión de Proyectos TI, como negocio, tiene bastantes años y el número de empresas cuyo rubro es ejecutar proyectos de esta naturaleza para terceros es grande (y creciente), lo cual constituye un mercado relevante.

Las empresas no inician un proyecto porque es bien visto o porque quieren estar en la frontera tecnológica, debe haber una justificación económica y financiera para ello. En este contexto, el Jefe de Proyecto debe pensar más como un gerente, pues no se trata de tecnología por tecnología puramente. Un nuevo servidor de bases de datos con multiprocesador, muchos GB de RAM y switches ultra rápidos suena interesante, pero si no justifica la inversión es sólo un juguete caro.

Al definir las metas y objetivos del negocio, se define el resultado final de lo que creará el proyecto. Para un proyecto TI, lo más común es [07]:

• Mejorar la satisfacción del cliente y usuarios. • Ser más eficiente (disminuir costos y/o aumentar ingresos). • Asegurar los activos de la organización. • Cumplir las normas y regulaciones.

1.1. Contexto

1.1.1. Antecedentes generales de la Empresa

ECITI (acrónimo de Empresa Consultora en Infraestructura TI , nombre de fantasía a utilizar en este trabajo) es una empresa –mediana según el número de empleados y grande según la facturación– que provee soluciones




2

para asegurar eficacia, eficiencia, calidad y continuidad de negocio a sus clientes, a través de proyectos de implementación (generalmente de integración), que son parte importante del core del negocio. Lleva 28 años en el mercado y tiene una cartera de clientes amplia y heterogénea en giro, tamaño y ámbito.

Sus clientes poseen múltiples sistemas, de diferentes fabricantes y aplicativos –propios o de terceros–, en un ambiente dinámico, donde se les presentan problemas de administración, de acceso a la información y costos relacionados con dicha infraestructura. La implementación de infraestructura TI es la base del trabajo de ECITI y, entre las soluciones ofrecidas a los clientes, están:

• Infraestructura. Arquitectura e implementación de proyectos de infraestructura tecnológica. • Virtualización. Tecnologías que permiten hacer uso de plataformas, sistemas operativos, almacenamiento y

redes en un ambiente virtual. • Almacenamiento y Respaldo. Plataformas que permiten almacenar información de manera eficiente y

recuperarla ante una pérdida total o parcial. • Continuidad del negocio. Procesos críticos disponibles para usuarios con máximo up time (Planes de

Contingencia, Planes de Recuperación y Continuidad Operacional) • Seguridad. Con un SOC (Security Operations Center) que presta servicios a los clientes. • Datacenter. Con 600 m2 certificados en Tier II en Operación y Tier III en Infraestructura (Uptime Institute,

2016), salas de explotación y comunicaciones, con servicios de housing, hosting, manos remotas, respaldo, restauración y monitoreo, además de un NOC (Network Operations Center) que presta servicios a clientes.

• Adicionales. Integración TI, Cloud, Gestión, Seguridad, Analytics, Soporte y Servicios.

El personal operativo involucrado en los temas recién descritos, son: 20 personas en el área Comercial, 3 en Jefatura de Proyectos, 20 en Servicios y 22 en Datacenter.

Organizacionalmente [06] (figura 1), la Empresa nació, como la gran mayoría, pequeña (menos de 10 personas), con una estructura simple y todas las actividades bajo Supervisión Directa del dueño y gerente general (Ápice Estratégico). A medida que fue más exitosa, creció y su estructura se profundizó, con la aparición y extensión de la Línea Media, la aparición del Staff de Apoyo y el aumento y la especialización del Núcleo Operativo.

Figura 1. Partes de la Organización. Fuente [06].

Hoy tiene más de 100 empleados, tiene una estructura Funcional y la Supervisión Directa como Mecanismo de Control se mantiene hasta el presente, lo cual genera problemas (ver 3.4).

1.1.2. Unidades Organizacionales afectadas

ECITI está organizada en cuatro Gerencias: Comercial, de Servicios, de Datacenter y Administración.

Las áreas de ECITI afectadas por el proyecto son la Gerencia Comercial y la Gerencia de Servicios.

Los Interesados de estas áreas, desempeñan los siguientes roles:

Ápice Estratégico

Líne

a M

ed

ia

Núcleo Operativo

Ideología




3

Ejecutivo Comercial. Pertenece a la Gerencia Comercial. Es el primer contacto con el cliente. Conoce al cliente (a veces de mucho tiempo). Puede recoger los primeros requisitos, sobre todo los de tipo organizacional y de gestión. Desarrolla la Propuesta Económica consecuente con la Propuesta Técnica y negocia el precio con el cliente y los proveedores. Aprueba Controles de Cambio.

Arquitecto . Pertenece a la Gerencia Comercial. Hace el Levantamiento Inicial de Requisitos y desarrolla la Propuesta Técnica. Negocia aspectos técnicos de la solución con el cliente y los proveedores. Aprueba Controles de Cambio.

Jefe de Proyecto. Pertenece a la Gerencia de Servicios. Gestiona el proyecto de principio a fin (Inicio, Planificación, Ejecución, Control y Cierre). Tiene contacto permanente con la contraparte del cliente, con el equipo de implementación y los proveedores. Participa en todas las reuniones del proyecto. Negocia aspectos técnicos y de gestión del proyecto con el cliente. Propone Controles de Cambio. Genera toda la documentación de gestión y parte de la técnica.

Especialista. Pertenece a la Gerencia de Servicios. Desarrolla el Diseño Detallado y el Documento de Implementación de la solución completa y parte de los Planes de Trabajo. Participa en las reuniones de análisis. Realiza la implementación propiamente tal y la documenta.

1.1.3. Funcionalidades afectadas

Funcionalmente hablando, previo al inicio del proyecto, se realizan las actividades descritas en el Anexo 1.

En este contexto, la tarea a destacar es el desarrollo de la Propuesta Técnica.

Desarrollo de la Propuesta Técnica

El Ejecutivo Comercial, basado en una necesidad de parte del cliente, la cual puede ser comunicada formal (bases técnicas, llamada a licitación o correo) o informalmente (conversación o llamada telefónica), realiza la primera aproximación. A partir de ahí, mediante correos y llamadas, elabora un primer esbozo, el cual presenta al Gerente Comercial, con quien analiza si continuar; de ser así, se crea un borrador (draft). La manera en que el cliente expresa sus necesidades es variable, desde vagos deseos hasta especificaciones concretas y precisas.

Luego, se incorpora el Arquitecto, quien se entrevista con el cliente y toma los requisitos técnicos, proceso que dependiendo del tamaño y complejidad de la necesidad puede ser realizado en varias iteraciones. Con base en la información recopilada (contexto, situación actual, solicitudes, plataforma del cliente, restricciones presupuestarias, plazos, etc), el Arquitecto elabora la Propuesta Técnica, en dos líneas principales:

1. Configuración de Hardware y Software. Se desglosa la solución en los dos grupos de componentes mayores –Hardware y Software–, la cual se detalla en Archivos de Configuración, cuyo formato es específico de cada marca (IBM, Dell, EMC, etc). Según el tipo de componente (servidor, storage, etc), las partes y piezas se especifican según su número de parte. Accediendo a sitios web de los proveedores, se obtienen los precios unitarios y los descuentos. El Arquitecto verifica que la solución cumple los requisitos mediante dimensionamiento (sizing) y matrices de compatibilidad (para componentes de la misma marca) y de interoperabilidad (para componentes de distintas marcas).

2. Cuantificación de los Servicios. Primero, se define la Estructura de Desglose del Trabajo (EDT) y, basado en ésta, se genera la Planilla de Costeo de Servicios (PCS) donde, a partir de las HH (Hora Hombre) y el costo unitario por rol y tipo de HH, se calcula el costo por actividad y del proyecto.

Ítem Descripción Tiempo N° de HH para realizar la actividad Recursos N° de personas que ejecutarán la actividad Cantidad N° de componentes involucrados en la actividad

El producto (multiplicación) de estos tres ítems corresponde al Esfuerzo (HH).

Por ejemplo, rackear 1 switch requiere que 1 persona trabaje 0,5 HH; por lo tanto, rackear 6 switches corresponde a 0,5 x 1 x 6 = 3 HH, según se detalla a continuación:

Actividad Tiempo Recursos Cantidad Esfuerzo Rackear Switch 0,5 1 6 3,0




4

Este es un proceso iterativo que, como se estipula en la figura 1, está sujeto a la aprobación del cliente.

Una vez que el cliente da el visto bueno, con toda la información anterior se conforma la Nota de Venta, que es el documento oficial (además, incluye aspectos financieros), el cual se registra en SAP.

Una vez aprobado el proyecto, se da inicio formal a éste y se sigue el flujo de trabajo de acuerdo al PMBoK [09], descrito en el Anexo 2.

En una visión crítica del proceso recién descrito, hay algunos puntos a poner atención. Lo principal es que en la fase Comercial hay poca formalidad, no se incorporan aspectos de negocio, organizacionales ni de riesgo del cliente en los documentos que se elaboran. En oportunidades se modifican las estimaciones del Arquitecto para ajustarse al presupuesto del cliente y ganar la propuesta. La principal excusa es que se corre contra el tiempo, pero los sobrecostos y sobretiempos incurridos indican que esto no se debe desestimar.

1.2. Planteamiento y Definición del Problema

La manera en que se gestionan los requisitos en la organización genera retrasos y mayores costos, por rediseño y/o retrabajo. Esta debilidad involucra toda la línea de trabajo interno: Comercial, Proyectos y Servicios.

La raíz de estos problemas y debilidades se concentra en dos ámbitos:

• Gestión del Conocimiento. Las personas tienen el conocimiento necesario en su mayoría, pero no suficientemente organizado y sistematizado. Los actores aprovechan poco el conocimiento acumulado sobre clientes y proyectos anteriores, por lo que parte importante del esfuerzo de diseño y gestión del proyecto deba dedicarse a recrear y/o reescribir cosas ya hechas, siendo heterogénea la manera en que cada actor participa y gestiona la información.

• Metodología. No se evalúa cómo el entorno del requisito lo afecta ni cómo éste afecta a su entorno, no se distingue entre requisito del negocio, del interesado, de la solución, de la transición, del proyecto o de la calidad, muchas veces no se priorizan, no tienen trazabilidad y no se aclaran todas las suposiciones.

En diversos trabajos publicados, donde se analizan las causas de cancelación de proyectos, hay un consenso que alrededor del 30% afecta directamente a la eficacia y el 20% a la eficiencia.

En este mismo sentido, con el objetivo de cuantificar el problema internamente, en 2016 ECITI hizo una revisión de 19 proyectos que tuvieron dificultades en los dos años anteriores (detalle en Anexo 3), de los cuales se analizaron dos factores clave: la fuente del problema y la fase en que éste fue detectado (Tabla 1). De ahí, se desprende que la fuente principal de los problemas (14/19 = 74%) está al inicio de la cadena (Comercial) y que la fase en que éstos se detectan mayoritariamente (9/19 = 47%) está casi al final (Ejecución).

Tabla 1. Número de problemas detectados en proyectos.

Fase de Detección Fuente Inicio Planificación Ejecución Cierre Total Comercial 5 2 7 14 Proveedor 2 1 3 J. Proyecto 1 1 Logística 1 1 Total 6 4 9 0 19

La principal explicación del problema recién descrito es que, al comienzo de un proyecto, la incertidumbre y el riesgo son mucho mayor. Esto va aparejado con que el costo de corregir un error aumenta a medida que el proyecto avanza (ver figura 2).




5

Figura 2 Grado de Riesgo y Costo de reparar errores. Fuente. Gráfico 2-9. Impacto en las variables en función del tiempo del proyecto [09].

1.3. Motivación y Justificación

Los problemas detallados anteriormente no son evidentes para la mayoría, pero las consecuencias si lo son:

• Mayor esfuerzo (más trabajo, expresado en HH) de Planificación, Ejecución y/o Control. • Necesidad de rediseño de la solución o de cambio o compra de componentes no considerados o

incorrectamente considerados. • Esfuerzo de gestionar más Controles de Cambio.

Para el cliente, ECITI debería minimizar estos problemas (al menos sus consecuencias), y desde el punto de vista interno, se debe mejorar la performance económica para que sean más rentables. Esto ha sido tomado por la Gerencia General como una oportunidad de mejora, dando inicio a un proceso de Mejora Continua .

1.4. Solución Propuesta

La Hipótesis propuesta es que, al realizar una Gestión de Requisitos que sea eficaz, eficiente (provee los resultados deseados, a un menor costo y tiempo) y pertinente al rubro, tamaño y complejidad de ECITI, de sus clientes y sus proyectos; entonces, habrá un mayor nivel de cumplimiento ante los clientes (en alcance, plazo y calidad) y una mayor rentabilidad de los proyectos (en HH y costos).

El Objetivo del presente trabajo es definir y fortalecer el rol de todos y cada uno de los actores, definir un flujo de trabajo que adhiera a los estándares y las mejores prácticas, que esté guiado por metodologías y se apoye en herramientas, para que así ellos desarrollen su trabajo y contribuyan al negocio más eficaz y eficientemente.

El cumplimiento de este objetivo generará los siguientes Beneficios:

• Eficacia. Un mejor nivel de cumplimiento ante los clientes (especialmente en alcance y calidad). • Eficiencia. Ahorros (especialmente en tiempo y costo) y, por tanto, mayor rentabilidad de los proyectos.

1.5. Alcances

El presente trabajo se enmarca en los siguientes Alcances:

• Organizacional, se circunscribe a las Gerencias Comercial y de Servicios. El resto de la organización actúa como apoyo o receptor del servicio.

Baj

o

Gra

do

A

lto

Riesgo e Incertidumbre

Costo del cambio

Tiempo




6

• Funcional, se circunscribe a los Proyectos de Implementación de Infraestructura TI. No incluye otros tipos de negocio y/o proyectos que ECITI realiza para sus clientes.

• Operacional, se refiere a la modalidad de implementación y puesta en marcha. Todos los proyectos se implementan de la misma manera, siguiendo los preceptos básicos del PMBoK, adaptados al tamaño y complejidad del proyecto, pudiendo omitir algunos pasos y/o documentos para los más pequeños y simples.

1.6. Organización del Documento

El presente trabajo se estructura de la siguiente manera: se describe el Marco Teórico y Estado del Arte, en 4 aspectos: el Ciclo PDCA, la Gestión de Proyectos, ITIL y la Gestión de Requisitos. Posteriormente, se presentan la Metodología de Validación de la Hipótesis. A continuación, se describe la Propuesta de Solución y su estrategia de implantación. Luego, se aplica a un Caso, se realiza el Análisis de Resultados y termina con las Conclusiones y Recomendaciones.

2 Marco Teórico y Estado del Arte

2.1. Ciclo PDCA y Modelo de Mejora Continua

Tal como se indica en 1.3, la fuera impulsora del presente trabajo es la Mejora Continua.

El ciclo de Mejora Continua o Ciclo PDCA (del inglés Plan-Do-Check-Act, Figura 3), es una estrategia de mejora continua de la calidad, muy utilizada por los Sistemas de Gestión de la Calidad (SGC) y los Sistemas de Gestión de la Seguridad de la Información (SGSI), aun cuando es aplicable a prácticamente cualquier área.

Figura 3. Ciclo PDCA. Fuentes: Imai, 1986 e Ishikawa, 1985.

Lo anterior, permite a las empresas una mejora en su competitividad, de sus productos y servicios, incrementando la calidad, reduciendo los costos, optimizando la productividad y, a consecuencia de esto, aumentar su rentabilidad.

2.2. Gestión de Proyectos

El enfoque “madre” de esta Tesina es la Gestión de Proyectos [09], la cual provee mejores prácticas, procesos, herramientas y documentos y actúa como paraguas para el resto.

Los procesos afectados están en los Grupos de Proceso de Inicio y Planificación y de las Áreas de Conocimiento de Integración y Alcance (ver Figura 4 y Anexo 4), donde se distinguen 6 procesos y 10 documentos.

La Gestión de Requisitos es, principalmente, un problema de Gestión de Alcance, siendo éste, probablemente, el dominio más descuidado de la Gestión de Proyectos. Hasta hace poco, la mayoría de los textos de Gestión de Proyectos establecía algo así como “una vez que se le comunica el Alcance del Producto al Jefe de Proyecto, éste puede embarcarse en la creación de la Estructura de Desglose del Trabajo, con el apoyo de su equipo” [07].




7

Figura 4. Flujo de la Gestión de Requisitos.

Fuente. [09] Síntesis de figuras 4-3, 4-5, 5-3, 5-5, 5-9 y 5-11.

2.3. ITIL

ITIL (Biblioteca de Infraestructura de Tecnologías de la Información o Information Technology Infrastructure Library) es un compendio de publicaciones que describe de manera sistemática un conjunto de buenas prácticas para la Gestión de Servicios de Tecnología de la Información (TI).

Fue originalmente desarrollada en 1989 por la Oficina de Comercio Británico (OGC) y desde 2013 es patrocinada por AXELOS, un joint venture entre Capita y la OGC y es de libre utilización.

La versión actual data de 2007, denominada ITIL v3 , agrupa los elementos principales de ITIL en 5 volúmenes, conformando el Ciclo de Vida ITIL:

1. Estrategia de Servicios (Service Strategy o SS). 2. Diseño de Servicios (Service Design o SD). 3. Operación de Servicios (Service Operation o SO). 4. Mejora Continua de Servicios (Continual Service Improvement o CSI). 5. Transición de Servicios (Service Transition o ST).

La estructuración de éstos se muestra en el diagrama del Anexo 8.

1. Estrategia de Servicios

Diseña el plan de acción que permitirá desarrollar una estrategia TI en la Organización, en varias áreas: Estrategia general, competitividad y posicionamiento de mercado, tipos de proveedores de servicio, gestión del servicio como un factor estratégico, diseño organizacional y estratégico, procesos y actividades clave, gestión financiera, dossier de servicios, gestión de la demanda, y responsabilidades y responsabilidades clave en la estrategia de servicios.

Inicio Planificación

Desarrollar Acta de Constitución

Desarrollar Plan de Gestión del Proyecto

Planificar Gestión del Alcance

Recopilar Requisitos

Definir Alcance

Crear EDT

Inte

grac

ión

Alc

ance

Caso de NegocioEnunciado del Trabajo

Plan de Gestióndel Proyecto

Acta deConstitución

Plan de Gestiónde Requisitos

Plan de Gestióndel Alcance

Documentode Requisitos

Matriz de Trazabilidad

Enunciado del Alcance

Línea Base del Alcance




8

Este volumen se relaciona con:

- Gestión del Cambio. - Gestión de los Niveles de Servicio. - Gestión del Catálogo de Servicios. - Gestión de la Cartera de Servicios.

2. Diseño de Servicios

Desarrolla lo relativo al diseño de Servicios TI, como arquitecturas, procesos, políticas, documentación. Se adentra además en la Gestión de niveles de servicio, diseño para gestión de capacidad, continuidad en los servicios TI, gestión de proveedores y responsabilidades clave en diseño de servicios.

3. Operación de Servicios

Expone las mejores prácticas para ofrecer un nivel de servicio de la Organización acorde a los requisitos y necesidades de los Clientes (Acuerdo de Nivel de Servicio, SLA o Service Level Agreement). Incluye objetivos de productividad/beneficios, gestión de eventos, de incidentes, de activos y de las aplicaciones; caso de cumplimiento, servicios de help desk y técnica, así como las principales funciones y responsabilidades para el personal de servicios que llevan a cabo los procesos operativos.

4. Mejora Continua de Servicios

Explica la necesidad de mejora continua como fuente de desarrollo y crecimiento en el Nivel de Servicio de TI, tanto interno como externo, para que la organización esté en constante análisis de sus procesos de negocio y actúe una vez detectadas las necesidades, de manera que éstas respondan a los objetivos, la estrategia, la competitividad y la gestión de la estructura de las organizaciones con infraestructura TI, para estar al tanto de los cambios en el mercado y las nuevas necesidades de TI.

5. Transición de Servicios

Define los cambios en la provisión de servicios comunes (trabajo diario) en la empresa. Aspectos tales como la gestión de la configuración y servicio de activos, la planificación de la transición y de apoyo, gestión y despliegue de los Servicios TI, Gestión del Cambio, Gestión del Conocimiento, y por último las responsabilidades y las funciones de las personas que participen en el Cambio o Transición de Servicios.

2.4. Gestión de Requisitos

2.4.1. Características y Atributos de los Requisitos

Un Requisito es toda característica observable de una solución que todo Interesado desea que esté presente en dicha solución, el cual puede ser técnico (de la solución misma) o de negocio (del proyecto) [03].

En una visión evolutiva, los requisitos van siendo capturados en forma progresiva, a medida que los distintos actores entran en escena y desempeñan su rol. Mientras se avanza, la naturaleza de los requisitos va variando, de organizacionales a técnicos y de generales a específicos, todo lo cual impone un tratamiento diferenciado.

Todo requisito de Interesado, Sistema o Componente deberá poseer las siguientes características ([05] 5.2.5):

• Necesario. Define una capacidad, atributo, restricción o factor de calidad esencial. • Libre de la Implementación. No establece restricciones innecesarias al diseño. • No ambiguo. Es establece de manera que sea interpretado de una sola forma. • Consistente. Está libre de conflictos con otros requisitos. • Completo. Está descrito en forma suficiente y necesaria. No necesita amplificación. • Singular. Está planteado como un requisito único, sin conjunción con otro.




9

• Factible. Es técnicamente alcanzable, cumple las restricciones con riesgo aceptable. • Trazable. Se le puede hacer seguimiento hasta los documentos fuente. • Verificable. Posee los medios para demostrar que el sistema solución lo satisface.

Para apoyar el Análisis, los requisitos deben exhibir atributos que ayuden a entenderlos y gestionarlos.

Los atributos más importantes incluyen ([05] 5.2.8):

• Identificación. Debe ser identificable de manera única, para reflejar sus relaciones. • Prioridad. Los interesados consensuan una prioridad para cada requisito. • Dependencia. Las dependencias entre requisitos deben ser definidas y registradas. • Riesgo. Se debe determinar una escala de riesgo para los requisitos del Sistema. • Fuente. Cada requisito debe incluir un atributo que indique su origen. • Justificación. Establecer un requisito necesita una razón de existencia. • Dificultad. Provee contexto para el análisis. • Tipo. Ayuda en la recolección y agrupamiento para el análisis.

2.4.2. Gestión de Requisitos

El objetivo de gestionar los requisitos es reducir el Riesgo de Implementación de un proyecto, en dos ejes:

• Eficacia. Riesgo de hacer algo que el cliente no solicitó. • Eficiencia. Riesgo de sub (o sobre) estimar recursos y/o tiempo.

En cuanto a los proyectos, según sus resultados, éstos se clasifican en ([07]):

• Exitoso. Cumple todos los requisitos del cliente y es entregado a tiempo y dentro del presupuesto. • Cuestionado. Cumple la mayoría de los requisitos del cliente e incurre en sobrecostos y/o retrasos. • Fracasado. Cancelado porque no entregó lo esperado e incurrió en severos sobrecostos y/o retrasos.

Un importante estudio (Standish Group, CHAOS Reports 1994-2009) muestra que la tasa de éxito o fracaso depende del tamaño del proyecto (Tabla 3) y que en el período 1994-2009 hay un aumento de los exitosos y una disminución de los fracasados, así como también una disminución en el rendimiento [07].

Tabla 3. Tasa de éxito/fracaso según tamaño del proyecto (%).

Exitoso Cuestionado Fracasado Grande 9,0 61,5 29,5 Mediano 16,2 46,7 37,1 Pequeño 28,0 50,4 21,6

Al investigar las causas de los cuestionados y fracasados, las 5 más importantes son:

1. Requisitos incompletos 2. Falta de involucramiento del usuario 3. Expectativas poco realistas de los clientes 4. Requisitos y especificaciones cambiantes 5. Cliente no necesita las características provistas

Al hacer una investigación más profunda sobre la causa 1 (requisitos incompletos), se descubrió que:

N° Causa Raíz Frecuencia 1 Están basados en hechos incorrectos 49 % 2 Fueron omitidos 29 % 3 Son inconsistentes 13 % 4 Son ambiguos 5 % 5 Están errados o fuera de lugar 2 % 6 Otros 2 %




10

Adicionalmente, se descubrió que, de todos los requisitos inicialmente solicitados por el cliente, sólo el 52% queda en la solución. Más aún, el retrabajo necesario para corregir los errores en los requisitos puede alcanzar el 50% del costo total del proyecto, lo cual es reforzado por dos estudios (Boehm 1981 y Hooks 1995) y reflejado en la figura 5 (una cuantificación de la figura 2), que muestra el costo promedio de corregir un error, a medida que avanza el proyecto. Esto se contrapone con el principio de calidad que indica que un defecto debe ser detectado y corregido lo antes posible.

Figura 5. Costo promedio de corregir un error v/s etapa de la corrección. Fuente [07] Figura 1.6, página 12.

Típicamente, en TI y desarrollo de software los requisitos se desarrollan de manera jerárquica , donde éstos se van obteniendo en un nivel de detalle creciente, con una granularidad asociada ([07] Tabla 4.1, página 57):

Granularidad Tipo Muy Alto Nivel Requisito de Negocio (Problema, Objetivo) Alto Nivel Característica Nivel Detallado Requisito Funcional / No Funcional Otro Regla de Negocio / Restricción

Al seguir este enfoque, un Objetivo es descrito a través de varias Características y, a su vez, cada una de éstas es lograda a través de varios Requisitos (Funcional / No Funcional).

Complementariamente, en una aproximación psicológica al cliente, los requisitos pueden ser agrupados en [07]:

• Consciente. Están en la mente de los interesados y son mencionados de inmediato. Son los más fáciles de obtener. Por ejemplo, un cliente que quiere un sitio web para incrementar sus ventas incluirá un catálogo de productos, una canasta y el pago con tarjeta de crédito.

• Inconsciente. Son tan comunes y familiares para los interesados que éstos no los mencionan, suponiendo que todos los conocen. Son los más difíciles de obtener. Por ejemplo, el IVA de la venta seguramente será omitido por el interesado y, si el desarrollador no sabe contabilidad, el cálculo quedará fuera de la solución.

• Ni soñado. Serían de gran utilidad para los interesados, pero ellos no son conscientes de su existencia. Por ejemplo, la encriptación de los datos de la tarjeta de crédito para transacciones en línea, si no se le informa al interesado seguramente no quedará en la solución.

Los requisitos, una vez recopilados, deben ser priorizados. En una categorización simple, se pueden clasificar en: deben, deberían y podrían estar presentes ([07], pág 139). Esto es muy importante, dados los resultados del estudio que indica que, de todos los requisitos inicialmente solicitados, sólo el 52% queda en la solución.

Según [09] “los interesados participan en el descubrimiento y descomposición de necesidades en requisitos y en determinar, documentar y gestionar los requisitos del producto. Los requisitos incluyen condiciones o




11

capacidades que deben estar presentes en el producto. Incluyen necesidades y expectativas cuantificadas y documentadas de los interesados, que deben recopilarse, analizarse y registrarse con un nivel de detalle suficiente. El desarrollo de los requisitos comienza con un análisis del Acta de Constitución del Proyecto, del Registro de Interesados y del Plan de Gestión de los Interesados. Los requisitos constituyen la base de la EDT, que a su vez es la base para la Planificación del Costo, del Cronograma y de la Calidad”.

Al clasificar los requisitos, éstos generalmente son de tipo [03]:

1. Funcional. Enuncian los servicios o prestaciones que debe proveer la solución, de cómo cada componente debería comportarse en situaciones específicas.

2. No Funcional. Son limitaciones o restricciones impuestas por los estándares y el entorno del cliente. Se aplican a la solución como un todo, más que a componentes individuales.

Los requisitos se desarrollan a través de un Proceso de Adquisición y Análisis [03], cuyas actividades son:

1. Descubrimiento. Se interactúa con los interesados para descubrir sus requisitos e intereses. 2. Clasificación y organización. Los requisitos se agrupan y organizan en grupos coherentes, usando un

modelo arquitectónico, identificando subsistemas y asociando los requisitos con éstos. 3. Priorización y negociación. Al haber varios interesados, los requisitos estarán en conflicto. Aquí,

priorizan los requisitos y resuelven los conflictos mediante negociación, acuerdos y compromisos. 4. Especificación. Se genera un documento de Especificación de Requisitos, comprensible por el cliente,

que después sea útil para los implementadores.

En este proceso, se usan los documentos de la figura 4 –detallados en Anexo 4–, entre los que destacan:

1. Caso de Negocio

La inversión en TIC, aún con el uso de las mejores prácticas de Project Management, por sí solo, no garantiza que se logren los objetivos del negocio.

El Caso de Negocio es un documento que proporciona información necesaria desde la perspectiva comercial para determinar si el proyecto vale o no la inversión requerida.

Para este trabajo, los elementos relevantes de un caso de negocio son:

• Situación Actual: ¿Cuál es el problema?, ¿Por qué es un problema? • Propuesta: ¿Qué se propone?, ¿Cómo soluciona el problema? • Precio: ¿Cuánto está dispuesto a pagar el cliente?

2. Matriz de Trazabilidad de Requisitos

Permite vincular los requisitos del producto desde su origen hasta los entregables que los satisfacen. Ayuda a asegurar que cada requisito agrega valor al negocio, al vincularlo con los objetivos del negocio y del proyecto. Permite realizar seguimiento de los requisitos a lo largo del ciclo de vida del proyecto, lo cual contribuye a asegurar que, al final, se provean los entregables acordados.

La Matriz de Trazabilidad de Requisitos debe contener, al menos, las siguientes columnas:

Id Identificador, puede ser un número secuencial o un código Nombre Nombre oficial del requisito Tipo Del negocio, del interesado, de la solución, de la transición, del proyecto o de calidad Fuente Documento fuente de referencia que lo detalla Entregable Entregable(s) asociado(s) (Id en la EDT)

A lo largo del proceso, se debería usar un Repositorio para mantener consistencia y hacer seguimiento.

2.4.3. Estructura de Desglose del Producto y del Trabajo

Por años, la orientación de la gestión de proyectos fue a la fase, pero el interés del cliente ha sido siempre el entregable, por lo que dicha orientación ha cambiado, acogiendo el interés del cliente.




12

Por otro lado, la mayoría de los enfoques ponen más énfasis en el cómo (proyecto) que en el qué (producto), dando por sentadas muchas particularidades de este último, lo cual es un error, pues lo primordial es definir el alcance del producto correcta y completamente antes que el alcance del proyecto.

La descomposición es una técnica utilizada para dividir y subdividir el alcance del proyecto y los entregables del proyecto en partes más pequeñas y manejables [09].

Todo proyecto, incluso de software, tiene resultados (entregables) que se manifiestan de manera física, donde el alcance del proyecto corresponde a la sumatoria de todos los entregables.

La Estructura de Desglose del Producto (EDP o Product Breakdown Structure –PBS–) es una estructura jerárquica utilizada para descomponer el producto en sus partes constituyentes, como una lista de materiales.

Ésta ayuda a identificar los distintos componentes necesarios para producir los entregables y para estimar costos y presupuestos.

A pesar de la importancia de la EDP en la gestión de un proyecto, el PMBoK [09] no ha incorporado este concepto, lo cual es una debilidad, por lo que ésta debe ser suplementada.

El uso de la EDP proporciona las siguientes ventajas [08]:

• Brinda un enfoque general de los entregables del proyecto, sin incluir los paquetes de trabajo. • Ayuda a identificar todos los entregables del proyecto para completar el producto total. • Representa los componentes más altos de una EDT. • Facilita la transferencia de datos entre los miembros del equipo del proyecto.

Una forma de caracterizar la EDP es que sus elementos son sustantivos.

Varios autores han incorporado la EDP, como complemento en la Definición del Alcance:

• NASA ([08] 4.2.1.2.2). Mediante la EDP se va detallando el producto en una jerarquía, proveyendo un marco de trabajo que da una visión global y detallada de cómo los componentes se ensamblan en la solución. Los requisitos asignados a la EDP pueden ser funcionales, de rendimiento y de interfaz. Luego, se construye la EDT (el alcance del proyecto), agregando a la EDP los elementos de servicio necesarios. El principal beneficio de usar EDP es que el foco está en desarrollar la solución (el qué) y el equipo puede concentrarse en el producto, sus características y riesgos, para luego emprender el proyecto (el cómo).

• Prince2 [02]. Define el Producto del Proyecto, que es el resultado esperado, desde el punto de vista del cliente, utilizando primero la EDP para identificar exactamente lo que hay que producir y, a partir de ésta, definir el trabajo a realizar a través de una EDT, describiendo finalmente los paquetes de trabajo necesarios, debiendo garantizar su trazabilidad (qué productos se incluyen en cada paquete de trabajo y viceversa).

• Miller [01]. Establece un proceso incremental e iterativo de 8 pasos, tal como se muestra en la figura 6. Aquí, la EDT se va construyendo en forma incremental, donde los tres primeros pasos de la figura son relevantes para este trabajo. Primero, se hace un listado de los entregables, basándose en los sustantivos encontrados en los documentos donde el cliente expresa sus necesidades.

Luego, se desarrolla la EDP (en versión inicial y completa) para proveer una buena representación de los entregables, que son la base de las actividades. El producto es la EDT, la cual es una extensión de la EDP (ver figura 7 con un ejemplo simple). Hay más de una manera de estructurarlo; por ejemplo, el Sistema Operativo, que es un componente de Servidores, podría ser un Entregable separado, dada su naturaleza.




13

Figura 6. Proceso de 8 pasos de Miller. Fuente [01] Figura 13.1, página 144.

Figura 7. Ejemplo simple de integración EDP-EDT.

Análoga a la EDP, la Estructura de Desglose del Trabajo (EDT o Work Breakdown Structure –WBS–) es una estructura jerárquica utilizada para descomponer el trabajo necesario para generar el producto como un todo y en sus partes constituyentes [09]. La unidad fundamental son los paquetes de trabajo, los cuales son descritos mediante verbos.

3 Metodología y Análisis

3.1. Metodología de Validación

La Hipótesis propuesta en 1.4 debe ser validada.

Como base de comparación, para medir la efectividad del cambio, se utiliza el esfuerzo de ejecución de algunos proyectos. En el Anexo 5 se detalla el esfuerzo (en HH) de 14 proyectos con problemas (subconjunto de los descritos en la tabla 1). Para hacer las HH comparables (tienen un costo unitario distinto) se convierten a UF y se calcula la diferencia, con el siguiente resultado:

Encontrar Entregables del Proyecto

Desarrollar EDP completa

Desarrollar y revisar la EDP inicial

Establecer las Actividades

Desarrollar la Red

Estimar las Duraciones

Verificar el Itinerario del Proyecto

Asignar los Recursos




14

Normal Extra Jefe Proyecto Total Planificadas (UF) 2.507 1.593 618 4.718 Ejecutadas (UF) 3.221 2.382 650 6.553 Diferencia (UF) -714 -789 -332 -1.835 Diferencia (%) -28% -50% -54% -39%

Cabe destacar respecto de esta información que la mayor diferencia (54%) está en los Jefes de Proyecto, lo cual refuerza lo comentado en 1.2.

Estas desviaciones serán tomadas como base de comparación para medir la efectividad del cambio.

3.2. Estructuración de la Solución

Enmarcado en el Ciclo PDCA, el trabajo se estructura en 4 fases:

1. Planificar .

Desarrollar un compendio de la terminología pertinente a la gestión de requisitos y áreas conexas. Un requisito tiene una componente fundamental de Comunicación; éste es comprendido de manera distinta por un Ejecutivo Comercial y por un Ingeniero Implementador; por lo tanto, hay que unificar conceptos dentro de la organización.

Definir clara y consistentemente los roles, en su conjunto y en forma individual. Cada profesional juega un rol distinto –y complementario– en la gestión de requisitos.

Definir las variables a medir y los criterios de aceptación que permitan concluir que la mejora es efectiva.

Desarrollar un flujo de trabajo basado en documentos estándar, el cual cada actor debe aprender a completar y usar correctamente para tomar decisiones. Cada grupo de interés será entrenado con este propósito y ello implica, entre otras cosas, cambiar algunos hábitos.

Para lo anterior, se utilizará el método de Modelación Visual Participativa.

Socializar el proyecto es fundamental para involucrar y lograr la colaboración de todos.

2. Ejecutar.

Una vez definido el enfoque, se comienza a usar en forma amplia por todos los actores.

El suscrito efectuará una labor de acompañamiento a los actores durante esta fase y la siguiente.

Las variables definidas se medirán y reportarán periódicamente para análisis.

3. Monitorear .

Mensualmente, al comienzo, y semestralmente después, se hará un seguimiento de la efectividad y eficiencia del uso del enfoque.

4. Corregir .

Introducir modificaciones y/o mejoras en los aspectos que lo ameriten.

Para efectos de esta tesina, se ejecutará un ciclo completo. Para esta primera vez, se define una marcha blanca, donde se aplique completamente el nuevo enfoque y se monitoree cercana y continuamente. La capacidad de trabajo del suscrito será de un proyecto, al ser ésta una actividad adicional a sus obligaciones normales.

3.3. Implementación

A continuación, se detalla un conjunto de medidas y acciones que permitan mejorar la Gestión de Requisitos, todas enmarcadas en el flujo presentado en la figura 4.




15

3.3.1. Estrategia

Dadas las características del problema, donde el 74% de los errores se origina al inicio del proyecto (tabla 1) y el costo promedio de corregir un error es mayor a medida que avanza el proyecto (figura 4), como estrategia se aplicará el nuevo enfoque sólo en la etapa previa al proyecto (descrita en 1.1.3 y anexo 1), lo cual es más eficaz y eficiente, y en un primer período será sobre proyectos grandes y complejos; después se incluirán los demás.

Además, para aislar el efecto de la aplicación del nuevo enfoque, y que los resultados sean comparables, la gestión del Jefe de Proyecto se realizará de la misma manera que se hacía anteriormente (ceteris paribus).

3.3.2. Caso de Negocio

El Ejecutivo Comercial, principal responsable del llenado de este documento, debe pesquisar los puntos fundamentales en las primeras aproximaciones con el cliente y con la lectura de los documentos entregados por éste. También debe detectar riesgos inherentes al cliente y al entorno administrativo.

3.3.3. Propuesta Técnica

Hoy en día las Propuestas Técnicas que llegan desde Arquitectura son bastante heterogéneas, dependiendo de quién la elaboró, del cliente, del tema, etc, lo cual dificulta su traducción al diseño. Esto se mejora mediante un Documento de Arquitectura de Soluciones Técnicas, el cual se describe en el Anexo 6, para alinear conceptos y homogeneizar la manera en que se elabora la Propuesta Técnica, con una estructura estándar para esta última también. Cabe destacar que la Propuesta Técnica y el Documento de Arquitectura de Soluciones Técnicas tienen cierta superposición, pues el último contiene aspectos que no son entregados al cliente, ya que está orientado a los especialistas al interior de la empresa, y vice-versa. Lo anterior tiene su correspondencia con los documentos Definición de Requisitos, orientado al cliente, y Especificación de Requisitos, orientado al desarrollador, ambos provenientes del ámbito del Desarrollo de Software ([03] 4.2), perfectamente trasladables a TI.

Adicionalmente, el Arquitecto puede detectar riesgos inherentes al entorno tecnológico y al proyecto.

En 3.3.4 se dan indicaciones a seguir, en cuanto a los términos a (no) utilizar.

Se debe utilizar minutas de reunión para refrendar los acuerdos tomados y los cambios acordados.

3.3.4. Especificar Requisitos

Una especificación de requisitos debe ser breve y precisa, enfocada al qué (producto) y no el cómo (proyecto), sin dar lugar a la interpretación. Una regla es registrar un requisito con un verbo y que la forma sea consistente en todo el documento, no alternar entre “debe” (obligatorio), “debería” (opcional) y “podría” (deseable) [07].

Hay varias palabras potencialmente problemáticas, que no conviene usar en una especificación de requisitos.

Para los Requisitos Funcionales ([07] Tabla 6.8, página 145):

Palabra Qué hacer Ejemplo (antes / después) Aceptable Definir “aceptable” y que los interesados decidan

qué es aceptable y qué no lo es Espacio en disco aceptable / Espacio en disco entre 3,8 y 4,5 TB

Eficiente Explicar cuán eficientemente opera la solución Máquina eficiente / Máquina consume menos de 0,5 KVA Rápido Especificar velocidad mínima, máxima y deseada Línea rápida / Línea con tasa efectiva de 150 Mbps Continuo Traducir a características observables del

producto Integración continua del Sistema A con el B / No deberían perderse más del 0,5% de las transacciones de A al integrarlo con B

Muchos Proporcionar un número específico o parámetros aceptables para cada valor

La solución tendrá muchas interfaces / La solución tendrá entre 10 y 12 interfaces

Suficiente ¿Cuánto es “suficiente”? Crear un número suficiente de cuentas / Crear cuentas para todos los empleados de contabilidad

Amigable Traducir a características observables del producto

El sitio web será amigable / El diseño del sitio web se ajustará a los estándares actuales de interfaces usuarias de la empresa




16

Para los Requisitos No Funcionales ([07] Tabla 7.6, página 161):

Requisito Explicación Ejemplo (incorrecto / correcto) Aspecto Estilo previsto del aspecto del producto.

Especifica la intención y no el diseño. El producto debe verse atractivo / El producto debe cumplir los estándares corporativos de marca.

Usabilidad Hace que el producto se ajuste a las habilidades del usuario y no del desarrollador.

El sitio debe ser fácil de usar / El 75% de los usuarios debe poder comprar un producto hasta 20 min después de entrar al sitio.

Rendimiento El producto debe operar en cierto tiempo El producto debe tener tales capacidades

La página se carga a una velocidad adecuada / La página se carga en menos de 5 seg.

Disponibilidad El producto debe estar disponible y operativo. Conocido por uptime.

El sistema está disponible todo el tiempo / El sistema está disponible el 99% de lunes a viernes, de 9 a 17.

Robustez Grado en el cual un sistema continúa operando tras fallas en componentes.

El sistema es difícil de romper / Si el editor falla antes de salvar el archivo, el sistema recuperará todos los cambios previos.

Seguridad Los datos almacenados o transferidos por el producto están protegidos de accesos no autorizados.

El sistema provee seguridad adecuada / La información de la tarjeta de crédito del cliente está encriptada por el sistema mediante PGP.

3.3.5. Estructura de Desglose del Producto y Estructura de Desglose del Trabajo

Lo descrito en 2.3.3 necesita ser operacionalizado.

La mejor fuente para definir los entregables es un documento escrito con las propias palabras el cliente, donde éste expresa sus objetivos, deseos y expectativas. Se aconseja usar las propias palabras del cliente, no hacer “traducciones”, pues éstas tienen un significado específico para éste.

Los entregables definidos con el cliente son lo que hay, no agregar más porque “al cliente se le olvidaron”.

Los entregables deben ser expresados mediante un sustantivo. Esta es la guía principal para buscar en el documento del cliente los entregables potenciales. Si tiene un modificador (adjetivo), también considerarlo. No todos los sustantivos representan entregables (por ejemplo, nombres propios).

La creación de la EDP es un proceso iterativo (número de pasos determinado por la complejidad), donde en cada iteración se desglosan aquellas partes que aún no están suficientemente completas o claras.

Inicialmente, la técnica básica es destacar en el documento del cliente los sustantivos que se considere darán origen a un entregable. Posteriormente, con base en las respuestas del cliente a preguntas sobre la versión anterior del documento, se detectarán nuevos entregables y/o se desglosarán los existentes.

Cada entregable debe ser nombrado y su fuente establecida desde el inicio, para hacerle seguimiento. Las fuentes iniciales de entregables pueden ser: contratos, SOW, acuerdos y especificaciones.

El proceso va generando una estructura descendente (como la parte superior de la figura 7), la cual conforma el esqueleto de la EDP, al cual se le agrega más detalle.

Operacionalmente hablando, esta tarea puede desarrollarse manualmente o apoyada por computador; para las etapas iniciales se recomienda lo primero, cuando el proceso es desordenado y hay muchas vueltas atrás, por lo que la eficiencia de usar computador es baja; pueden ocuparse post-it de diferentes colores y tamaños en una pizarra y unidos por líneas dibujadas en ésta, los cuales son fotografiados y registrados, conformando las sucesivas versiones (consensuadas), hasta que el tamaño y la complejidad hacen aconsejable automatizar.

Inicialmente, la estructura es plana, pero al avanzar el proceso ésta va incrementando su amplitud y su profundidad (número de niveles). Generalmente, la estructura no es balanceada (cada rama tiene distinto número de niveles comparada con el resto), lo cual no necesariamente es negativo, simplemente puede significar que el cliente tiene más interés en unas partes que en otras.

Cuando el tamaño y la complejidad lo justifican, la actual versión de la EDP debe ser traspasada a un software de gestión de estructuras tipo árbol (se usará WBS Chart Pro, hoy WBS Schedule Pro, de criticaltools.com, que tiene interfaz con Project), el cual provee la consistencia y durabilidad que le faltan a la forma manual.

En cada iteración debe hacerse un análisis, pues los documentos fuente incorporados pueden no revelar todos los entregables considerados por el cliente, usualmente hay más. Para resolver esto, se deben hacer reuniones




17

de revisión y análisis sin y con el cliente; en las últimas, es fundamental que el cliente indique entendimiento y acuerdo; éste debe involucrarse, no puede ver la EDP como “de los analistas”, sino como “nuestra”.

La importancia de los entregables es que, además, permiten monitorear el avance del proyecto, lo cual debe ser explicitado al cliente. Una manera práctica es dibujar la EDP en una hoja grande, a la vista de todos los interesados, a la cual se le van tarjando los casilleros (entregables) a medida que éstos van siendo completados.

A la EDP de la figura 7 (parte superior) se le van agregando los entregables de cliente descubiertos tardíamente y, también, más nivel de detalle, el cual se puede obtener de documentos, plantillas estandarizadas y/o lecciones aprendidas de proyectos anteriores. A partir de dicha estructura se va conformando la EDT, la cual aparece como una prolongación de la EDP (parte inferior de la figura).

La EDT contiene, además de los Entregables del Cliente (finales), los Entregables del Proyecto (intermedios) [07]. Esto incluye la Gestión del Proyecto y los documentos internos (técnicos y de gestión); sin esto, no se podría hacer el trabajo ni generar los entregables finales, pueden llegar a ser el 25% del trabajo total. Se deben incorporar en la EDP formando una rama separada de los entregables del cliente. Esto agrega valor al proyecto para el cliente y, en muchos casos, es positivo mostrarlos. Se deben agregar como una rama de ésta.

Al aplicar la descomposición sucesiva, se debe tener cuidado de mantener una granularidad (tamaño de la actividad) más o menos homogénea y que sean manejables. Se exceptúan los entregables subcontratados.

La EDP debe ser elaborada por completo por el Arquitecto y la EDT debe ser elaborada en conjunto entre el Arquitecto, el Jefe de Proyecto y el equipo del proyecto.

Toda actividad debe ser descrita (nombrada) mediante un verbo y un sustantivo. El sustantivo proviene del entregable del cliente, el verbo es definido por el Arquitecto o el Jefe de Proyecto. Hay verbos más genéricos y otros más específicos. Al definir un verbo se debe pensar que éste quedará registrado en el plan de proyecto y en la Gantt, que después debe monitorearse y reportarse su avance. El verbo puede llevar un modificador (adjetivo). Por ejemplo, “Desarrollar el Documento de Requisitos” se compone del verbo (desarrollar), el sustantivo (documento) y el modificador (requisitos), donde el sujeto es el entregable de la acción.

3.3.6. Matriz de Trazabilidad de Requisitos

Los requisitos evolucionan, por lo que es necesario registrarlos y asociarlos con los entregables que les dan respuesta. Para esto, se utilizará la matriz definida en 2.3.2, la cual será completada durante las sucesivas iteraciones, inicialmente por el Arquitecto y luego por el Jefe de Proyecto.

3.3.7. Redefinición y Seguimiento del Proceso

Las Variables a medir son las HH de Especialista y de Jefe de Proyecto empleadas en la consecución del proyecto (traducidas a UF). Esto se compara con la línea base definida en 3.1.

Para socializar y retroalimentar el proyecto, se programaron reuniones con la Gerencia Comercial, con Ejecutivos Comerciales y con Arquitectos.

Para resolver lo descrito en 1.2, en cuanto a gestión del conocimiento, se define un nuevo Flujo de Proyecto, más simple, estructurado y automatizado, que lleve un registro y permita hacer seguimiento más eficaz y eficiente de las variables fundamentales del proyecto. El flujo se presenta en el Anexo 7 y la diferencia principal respecto del actual (descrito en Anexo 2), es que incorpora un sistema informático basado en web que se establece como la columna vertebral para gestionar el flujo, al cual acceden todos los interesados, incluyendo el cliente. Se pretende incorporarlo en la segunda o tercera iteración del PDCA.

Para cuantificar lo antes descrito, se procederá a medir las variables definidas y reportar.

Finalmente, se procederá a evaluar e introducir mejoras, completando la primera iteración del ciclo PDCA.

3.4. Factores Críticos de Éxito

Al investigar la Situación Actual (ver 1.1.1), se confirma que el problema es metodológico y también cultural.




18

En ECITI, a pesar de sus 27 años de existencia y sus más de 100 empleados, la Supervisión Directa como Mecanismo de Control se mantiene hasta el presente. Esta constatación es importante para explicar parte sustancial de las debilidades y falencias, pues cuando el poder total está concentrado en el Ápice Estratégico, la empresa tiene dificultades para evolucionar hacia la Profesionalización (unidades fuertes y autónomas), la que incluye, entre otros, la adopción de estándares y mejores prácticas. Una manifestación patente de ello es que, para desarrollar correctamente la Gestión de Proyectos, la empresa debería tener una estructura Matricial [09], pero los actores principales de ello (los Jefes de Proyecto) están desempoderados y muchas veces son meros coordinadores. Según [06], la empresa debería ser una mezcla equilibrada de los tipos Innovadora, Profesional y Máquina, lo que le daría suficiente flexibilidad (orientación a proyectos), gestión del conocimiento y formalidad (institucionalidad). El cambiar este aspecto es muy importante para posibilitar el éxito de este proyecto en el mediano y largo plazo (ver figura 1).

4 Aplicación en un Caso

4.1. Caso Ejemplo

4.1.1. Descripción del Cliente y del Proyecto

El enfoque propuesto se aplica sobre un caso particular, el cual es un proyecto anteriormente ejecutado, donde hubo varios errores y omisiones, los cuales tuvieron como consecuencia una sobreutilización de los recursos. Se desarrolla nuevamente la fase comercial-arquitectónica tomando en cuenta aquellos errores y omisiones, re-planificando el esfuerzo y comparándolo con los costos reales y viendo las mejoras producidas.

Este proyecto se desarrolló en 2015 para una Corredora de Bolsa (empresa chilena tradicional), recién adquirida por un banco internacional (el verdadero cliente), comprendió infraestructura (servidores, storage, respaldo, comunicaciones, telefonía, virtualización y seguridad) y servicios (Implementación: de la plataforma, las comunicaciones y la seguridad, migración de datos, migración de correos y reestructuración del dominio). Todo esto en dos dependencias o sites: en ECITI (primario o productivo) y oficina del cliente (secundario o de contingencia). De todos los ámbitos mencionados, ECITI debió subcontratar: telefonía, parte de la seguridad y migración de correos.

Este proyecto está incluido en el estudio descrito en 1.2 y la Ficha de Análisis desarrollada para éste es:

Cronograma Inicio: 17-02-2015 – Término: 25-04-2015 Área Origen Comercial – Arquitectura Detectado en Planificación Tipificación Subestimación de requisitos y esfuerzo Descripción El cliente está fuertemente orientado a ITIL y su requerimiento fue hecho en ese contexto.

Los servicios propuestos por ECITI no acogieron dicho énfasis y se subestimó el esfuerzo para darles cumplimiento, tanto en la implementación como en la posterior operación. Ello contribuyó a excederse en las Horas, con un sobrecosto del 25%.

Recomendación Escuchar bien al cliente cuando expresa los requisitos, sobre todo en proyectos complejos como éste.

Balance de Horas

UF/ Planificado Ejecutado Diferencia Tipo de HH HH HH UF HH UF HH UF Porc Especialista / Normal 0,87 562 489 455 396 107 93 19% Especialista / Extra 1,30 118 153 287 373 -169 -220 -144% Jefe de Proyecto 0,99 124 123 186 184 -62 -61 -50% Total 765 953 -188 -25%

Aquí pueden apreciarse las consecuencias de manera cuantitativa respecto de las HH; sin embargo, hubo otros costos por cambio de componentes.




19

Las principales diferencias de HH se deben a:

• Cliente exigió cumplir fecha de puesta en marcha, se debió implementar plataforma transitoria. • Se debió realizar tareas de Administrador de Sistema no consideradas. • Se debió configurar VPN ECITI con Miami no considerada. • Se debió reconfigurar el Servicio de Directorio de la Red en 24 hrs, lo cual impactó el cronograma.

Las causas fundamentales de los errores y omisiones cometidos son:

• El verdadero cliente era el Banco Internacional y no la Corredora. Esta simple confusión provocó un retraso no menor en comprender cabalmente los requisitos.

• La implantación bajo enfoque ITIL era la piedra angular del proyecto, el RFP (Request For Proposal) estaba estructurado así (además de estar escrito en inglés).

• El cambio no era sólo tecnológico, sino también cultural, pues pasaron de ser una empresa tradicional (estilo familiar, relajada) a una altamente estructurada y regulada y el personal de la Corredora no estaba preparado para ello, lo cual generó sobrecarga para el equipo de proyecto de ECITI.

• El representante del cliente (la contraparte de ECITI) venía de EEUU (Miami) semana por medio (cuando no estaba se hacían conferencias vía teléfono) y sólo hablaba idioma inglés.

• La migración de los correos de los corredores (traders) con el registro de las transacciones realizadas en el pasado era una actividad clave; sin embargo, el requisito era difuso y no fue bien dimensionado, además que, al ser subcontratado, se perdió parte del control sobre éste (ver 3.3.5).

• Los componentes fueron comprados y los proveedores fueron contratados antes que asumiera el Jefe de Proyecto, cuando los requisitos y restricciones aun no estaban del todo claros.

A partir del RFP, se generó la Propuesta Técnica respectiva, la cual fue poco clara y contenía ambigüedades y omisiones, una consecuencia importante de ello fue que el cliente cambió los requisitos más de una vez, entre ellos exigió migrar la plataforma de PCs en modalidad big bang (80 estaciones de trabajo en un fin de semana, lo que incluyó, además, el redireccionamiento de la salida a internet). La principal razón que el cliente aceptara la propuesta, así como estaba, es que hubo confianza de parte de éste desde el comienzo de las negociaciones con el Ejecutivo Comercial.

No obstante lo anterior, se debe consignar que hubo dos hechos importantes que significaron sobreutilización de HH, los cuales no pueden ser achacados a la gestión del Ejecutivo Comercial o del Arquitecto:

• El despacho de los componentes de hardware de servidores (5 servidores, 2 storage y 1 unidad de respaldo) no fue bien gestionado por el proveedor, lo que significó un retraso de 45 días. Por ello, se debió implementar una plataforma transitoria sobre equipamiento propiedad de ECITI alojado en el sitio principal, a costo de ECITI, con una sobreutilización de 48 HH extra (3 personas debieron trabajar juntas un fin de semana). Con esto, se logró reducir el retraso a 25 días, lo cual fue considerado insuficiente por el cliente.

• Para aplacar los reclamos por el retraso antes descrito, el Jefe de Proyecto debió permanecer en la oficina del cliente el fin de semana que se implementó la plataforma de PCs, trabajando junto con los especialistas y los proveedores, con una sobreutilización de 16 HH.

Por lo anterior, el diferencial efectivo de HH que puede atribuirse a la gestión comercial y de arquitectura es el que se muestra a continuación:


Es decir, la comparación de las mejoras debería hacerse contra esta tabla (ver 3.1 –Línea Base– y 3.3.1 –cómo aislar el efecto de la aplicación del nuevo enfoque–).




20

4.1.2. Desarrollo

Dados estos antecedentes, a continuación, se desarrollan los elementos que estuvieron ausentes o incompletos en la propuesta original tal como deberían ser:

a) Caso de Negocio b) Propuesta Técnica c) Lista de Requisitos d) Matriz de Trazabilidad de Requisitos e) Estructura de Desglose del Producto f) Estructura de Desglose del Trabajo

En cada una se destaca lo agregado (amarillo) o modificado (verde); cuando es completo se indica textualmente.

a) Caso de Negocio

El caso de Negocio se agrega completo, no existía de esta forma en la propuesta original.

Aquí, las siguientes preguntas deben ser respondidas:

• Situación Actual o ¿Cuál es el problema? La Corredora de Bolsa ha sido adquirida por un Banco Internacional y su

plataforma digital debe ser transformada, para nivelarla con la de éste y adoptar los estándares de la industria bancaria.

o ¿Por qué es un problema? El contexto es lo que se denomina compliance, el Banco tiene normas y políticas internas y está sujeto a normas nacionales e internacionales muy estrictas, en cuanto a seguridad y confidencialidad de la información y uso de información privilegiada (en la Corredora el ambiente era mucho más relajado en este aspecto). Esto incluye a los empleados de la Corredora, quienes pasaron a ser empleados del Banco, debiendo cumplir el código de ética de éste.

• Propuesta o ¿Qué se propone? Una solución tecnológica de apoyo al corretaje de acciones (securities) confiable y

segura, que cumpla todas las normativas del Banco y de los organismos reguladores, que opere en dos sitios (principal y secundario, intercomunicados y en alta disponibilidad). Esta solución incluye hardware (servidores, almacenamiento, estaciones de trabajo, sistema de comunicaciones y telefonía), software (Servicio de Directorio de la Red, virtualización, sistemas operativos, administrador de bases de datos, antivirus/antispam, filtro de contenidos, administrador de correos con archiving y encriptación, Prevención de Pérdida de Datos, plataforma de colaboración, respaldo y restauración de datos, grabación de llamadas) y servicios (implementación de la plataforma de servidores y estaciones de trabajo, migración de servicios, datos y correos).

o ¿Cómo soluciona el problema? Al establecer un ambiente operativo basado en ITIL, el Banco estará haciendo la gestión de TI bajo la modalidad exigida por los organismos reguladores, resguardando así la integridad y confidencialidad de la información de sus clientes.

• Precio o ¿Cuánto está dispuesto a pagar el cliente? US$ 550.000

b) Propuesta Técnica

En el RFP del cliente se lee: “Provider shall follow the ITIL standards processes and procedures with a Single Point of Contact. In order to ensure that the required level of service needed to run the Private Bank business is in place, IT best practices and policies are mandatory. Provider shall have IT Change, Problem and Incident Management processes in place”.

Este párrafo no fue considerado a cabalidad, lo cual cambiaría el énfasis de la Propuesta Técnica respectiva.

Situación Actual y Requerimiento

Actualmente, el cliente tiene una instalación física en sus oficinas de la comuna de Las Condes, donde se encuentra localizada una Sala de Servidores y Comunicaciones, la cual no cuenta con las características mínimas de robustez y seguridad que permitan continuidad operativa, además que es un sitio único (no hay alta disponibilidad en sentido alguno). Las transacciones realizadas por los agentes están respaldadas mediante




21

correos en Gmail y las estaciones de trabajo que utilizan no operan bajo criterios de riesgo y seguridad. La tecnología de la plataforma computacional está obsoleta, además de ser lenta e insuficiente. La planta telefónica, si bien es digital, no está integrada a la plataforma computacional ni tiene posibilidad de grabar llamadas.

El Cliente requiere contar con un Servicio Integral externalizado que aborde dos alcances principales:

• Implementación de nueva Plataforma de servidores, almacenamiento, respaldo, estaciones de trabajo y telefonía, en cuanto a hardware, software y servicios de implementación en dos sitios

• Migración de datos y correos

Los Interesados relevantes definidos en este proyecto son:

Por parte del Cliente:

• Gerente de Administración y Finanzas (es el Patrocinador, está en Chile) • Jefe de Proyecto principal (viene de EEUU) • Jefe de Proyecto secundario (está en Chile)

Terceras Partes:

• Proveedores de hardware: Servidores, Almacenamiento, Respaldo, Estaciones de Trabajo, Redes y Comunicaciones, Telefonía IP y Filtro de Contenido

• Proveedores de software: de sistemas para Servidores, de seguridad y gestión de Correos, de Virtualización y de Respaldo y Telefonía IP.

• Proveedores de servicio: de renovación de Estaciones de Trabajo y de Migración de Correos y Telefonía IP.

• Proveedor del Enlace de Comunicaciones • Bolsa de Comercio de Santiago • NIC Chile

Por ECITI:

• Gerente de Datacenter • Arquitecto • Ejecutivo Comercial • Equipo Implementador • Jefe de Proyecto

c) Lista de Requisitos

Con base en los puntos descritos en el párrafo anterior, utilizando las recomendaciones descritas en 3.3.4, se desarrolla la Lista de Requisitos.

1. Renovación de Plataforma de Servidores del Sitio Principal 2. Nueva Plataforma de Servidores en Sitio Secundario (no existe en la situación actual) 3. Cambio de sitio, el Primario original pasa a ser Secundario y el nuevo, Primario 4. Renovación de Estaciones de Trabajo del Sitio Secundario 5. Generación de Esquema de Contingencia ante falla de Sitio Principal 6. Cambio de Core de Comunicaciones y Seguridad 7. Migración de Servidores y sus datos a nueva plataforma 8. Migración y Conversión de correos a nueva plataforma

Desde el punto de vista psicológico del cliente, todos los requisitos son de tipo Consciente (ver 2.3.2).

Las marcas y modelos de los componentes y los nombres de proveedores han sido omitidos.

d) Matriz de Trazabilidad de Requisitos

Este elemento es nuevo, no hay una estructura que permita trazabilidad en la propuesta original.

De acuerdo a las recomendaciones descritas en 3.3.6 y 4.2.2, se desarrolla la Matriz de Trazabilidad de Requisitos, basada en la Lista de Requisitos recopilada en el párrafo anterior.




22

Id Nombre Tipo Fuente Entregable 1 Renovación Sitio Principal Del Negocio RFP Sitio Principal Implementado 2 Nuevo Sitio Secundario Del Negocio RFP Sitio Secundario Implementado 3 Cambio de sitio principal Del Negocio RFP Sitio Principal Cambiado 4 Renovación Estaciones de Trabajo Del Negocio RFP Estaciones de Trabajo Implementadas 5 Generación Esquema Contingencia Del Negocio RFP Esquema de Contingencia Creado 6 Cambio Core de Comunicaciones Del Negocio RFP Core Cambiado 7 Migración de Servidores De la Solución RFP Servidores Migrados 8 Migración de Correos De la Solución RFP Correos Migrados

e) Estructura de Desglose del Producto

Este elemento es nuevo, no existe en la propuesta original.

A partir de la Lista de Entregables se genera la Estructura de Desglose del Producto (ver Figura 8), siguiendo las reglas y recomendaciones descritas en 3.3.5.

En los dos primeros entregables (Sitio Principal y Secundario) salvo 1 y 4, los componentes son iguales.

f) Estructura de Desglose del Trabajo

A partir de la Estructura de Desglose del Producto descrita en e), se genera la Estructura de Desglose del Trabajo (ver Figura 9), siguiendo las reglas y recomendaciones descritas en 3.3.5.

El último elemento a la derecha (entregable) contiene la Gestión, la cual incluye los Entregables del Proyecto.

El proyecto y los entregables (primer nivel) se heredan de la EDP y están enmarcados en azul.

Por motivos de espacio, se realizan los siguientes cambios respecto de la EDP:

• Las actividades comunes entre ambos sitios se consignan una sola vez en una rama separada. • Se condensan todos los elementos de cada entregable de la EDP como un solo entregable denominado

“EDP” (enmarcado en rojo) y se agregan los correspondientes a la EDT bajo éste.

Con la información descrita en a) – f) se está en condiciones de Planificar y Ejecutar el proyecto. A partir de las HH planificadas, se estima (en forma conservadora) una reducción del 30% de sobreutilización.

4.2. Resultados y principales hallazgos

En los días inmediatamente a continuación del big bang ocurrieron dos hechos relevantes:

• En la PCS original no se incluyeron HH para realizar las Pruebas previas al paso a producción, las cuales fueron igualmente ejecutadas entre el equipo de implementación y los usuarios finales, con un sobreconsumo de 16 HH normales, 8 HH extra y 8 HH de JP para ECITI.

• En ITIL, la Transición de Servicios (Implementación) incluye el Control de Cambio [10]. En esta ocasión no fue así, pues en la planificación original del proyecto no se incluyeron dichas HH. Como la plataforma de usuarios se implementó en modo big bang, el proceso no pasó por los controles especificados en ITIL y tuvo un sobreconsumo de 2 HH Normal, 1 HH Extra y 1 HH de JP por 5 días (ver ítem “Tareas de Administrador de Sistema no consideradas” en Balance de Horas de 4.1).

Al incorporar estos dos puntos en la tabla de la página 19, se tiene:


Es decir, el déficit se reduce un 54% (de 110 UF a 57 UF), monto significativamente mayor a lo esperado.




23

Cabe destacar que, al no aplicarse la metodología, se debieron ejecutar tareas adicionales casi sin planificar, lo cual aumentó aún más el consumo de recursos.

Figura 8. Estructura de Desglose del Producto.




24

Figura 9. Estructura de Desglose del Trabajo.




25

5 Conclusiones y Recomendaciones

La reducción del déficit de HH en un 54% es bastante significativa y, al menos en este caso, indica que, al considerar los elementos detallados en el capítulo 3 de la presente tesina, la metodología produce mejoras. Habría que explorar más casos y analizar si se comportan de manera homogénea o, al menos, consistente.

La Empresa debería exigir mayor rigurosidad en la fase previa al inicio de un proyecto, sobre todo en los de mayor tamaño y complejidad, donde el riesgo de obtener un margen negativo es más alto.

La Empresa, en general, y los Arquitectos, en particular, deben prepararse para un salto evolutivo hacia una Arquitectura de Soluciones Complejas, que acoja de mejor manera las necesidades de los clientes. Ellos juegan un rol clave en el desarrollo de la solución. Como apoyo a lo anterior, las Propuestas Técnicas deben ser reestructuradas, de manera que faciliten su traducción al diseño y la trazabilidad de los requisitos y entregables. Este aspecto se mejoraría mediante el Documento descrito en el Anexo 6.

La simulación en modalidad ingeniería reversa del desarrollo de la Propuesta Técnica para un proyecto real ya ejecutado permite evidenciar las debilidades de la situación actual con mayor detalle, como por ejemplo la no planificación de las pruebas y la subestimación en la cubicación de HH, que son la consecuencia de una gestión inadecuada de los requisitos.

Ésta es la primera “vuelta” del ciclo PDCA. En las siguientes se irán incorporando y/o modificando otras mejoras propuestas en la presente tesina. Se piensa que el Documento de Arquitectura descrito en el Anexo 6 es el próximo y, posteriormente, el sistema de apoyo graficado en el Anexo 7.

Complementariamente, se recomienda que el Jefe de Proyecto sea informado más tempranamente en el desarrollo de las propuestas técnicas y se realice un traspaso de información más completo.

Finalmente, hay algunos puntos negativos presentes en este trabajo que se deben a debilidades de la disciplina (Gestión de Proyectos en Infraestructura TI) y no de la metodología propuesta en la tesina. Uno importante es la falta de indicadores para medir y comparar.

6 Referencias Bibliográficas

[1] D. Miller, Building a Project Work Breakdown Structure, CRC Press, 2009. [2] F. Turley An Introduction to PRINCE2, Axelos, Ver 1.5, 2013. [3] I. Sommerville, Software Engineering, Addison-Wesley, 10th Ed, 2015. [4] IEEE Computer Society, Guide to the Systems Engineering Body of Knowledge, BKCASE, ver 1.8, 2017. [5] ISO/IEC/IEEE, 29148:2011 Systems and Software Requirements Engineering, IEEE, 1st Ed, 2011. [6] J. Lampel, H. Mintzberg, J.B. Quinn & S. Ghoshal, Strategy Process, Pearson, 5th Ed, 2014. [7] J. Moustafaev, Project Scope Management, CRC Press, 2014. [8] NASA, Systems Engineering Handbook, NASA, Rev 2, 2016. [9] PMI, A Guide to the Project Management Body of Knowledge (PMBoK), PMI Press, Ver 6, 2017. [10] The Stationery Office, ITIL 2011 Service Transition, TSO, 2011.




26

7 Anexos

1. Actividades previas al inicio de un proyecto (Actual)

Gerencia Comercial Gerencia de ServiciosCliente

Desarrollar / Modificar Propuesta

Cliente Acepta

Presentar Propuesta a

Cliente

Revisar Documentación

(Preliminar)INICIO

Solicita Evaluar Proyecto

Define y Contextualiza

Proyecto

NO

Documentación Completa?

Clasificar Proyecto y Asignar JP

SI

SI

NO

EnviarDocumentación

CompletarDocumentación

Documentación

Requisitos Preliminares e

Información del Cliente

Propuesta

Realizar Levantamiento

FIN

JP asignado

Aceptación e Inicio Formal del Proyecto




27

2. Flujo del Proyecto (Actual)

Arquitectura-Comercial PMO Ingeniería-Soporte EmpresaCliente Equipo de Proyecto

Ph

ase

Asignar Recursos

Conformar Equipo de Trabajo e Informar

Revisar Documentación

Proyecto

Presentar JP y Equipo de Trabajo al Cliente

INICIO

Solicitar Recursos

Enviar Documentación Proyecto

Realizar Kick-off Interno (aclarar dudas)

Desarrollar ppt resumida

Planificar

HayDesviaciones de la

PT?

Evaluar Desviaciones

SI

Kick-off con cliente

Ingeniería de DetallePlanes de TrabajoCondiciones y Logística

Recabar Información Relevante del Proyecto

en sitio del Cliente

NO

(*) Documentos Pertinentes según Tamaño y Complejidad del Proyecto

Requisitos Detallados

Riesgos

Generar Plan del Proyecto y Documentación Subsidiaria

pertinente (*)

Documento de RequisitosDocumento de AlcanceEDTCarta GanttRoles y responsabilidadesRiesgos y mitigación

(* )

Ejecutar Plan de Trabajo (Generar

Entregable)

Generar Documentación de

Entregable(s)

Implementar Cambios Aprobados

Reuniones de Control y Seguimiento

Generar Acta de Aceptación de

Entregable

Hay Desviaciones del Plan?

Evaluar Desviaciones

SI

Documentación Técnica asociada a

Entregable

Entregable

Acta de Aceptación de

Entregable

Minuta de Reunión

NO

Requisitos de Implementación

Avisar Hito de Pago

Entregar Documentación del Proyecto

Archivar Documentación del Proyecto

Entregar felicitaciones al Equipo de Trabajo

Comunicar Cierre de proyecto a la empresa

Incorporar Lecciones Aprendidas

Acta de Término y Cierre del Proyecto

Encuesta

FINRetroalimentación

Inic

iar

Pla

nifi

car

Eje

cuta

r y

Co

ntr

ola

rC

err

ar

ppt resumida

ppt detallada

Acta de Constitución y Alcance del Proyecto Desarrollar Acta de

Constitución y Alcance del Proyecto

Crea Ticket Proyecto

Avisar Hito de Pago

Acta firmadaFirma Acta

Hito de pagoFacturar

Solicitud Semanal Horas Recursos

Asignación Semanal Horas Recursos

Asignar Horas Recursos

Trabajocompleto?

SI

NO

Documentación del Proyecto

Firma Acta Acta firmada

Maximo

Maximo

Ticket

QuemarHH

MaximoQuemar

HH

MaximoQuemar

HH

Hito de pagoFacturar

MaximoQuemar

HH

Maximo

QuemarHH

MaximoQuemar

HH

EDT

Maximo

Control de Cambio




28

3. Detalle de proyectos problemáticos

Proyecto Área Origen Fase Detección Problema 1 Arquitectura / Comercial Inicio Falta conocer Expectativas del Cliente 2 Arquitectura / Comercial Inicio Omisión de información 3 Arquitectura / Comercial Inicio Falta dimensionar Rack y se subestiman HH 4 Arquitectura / Comercial Inicio Falta revisar componentes antes de despachar 5 Arquitectura / Comercial Inicio Versión incorrecta de Propuesta Técnica 6 Arquitectura / Comercial Planificación Subestimación de HH 7 Arquitectura / Comercial Planificación Subestimación de requisitos y su énfasis 8 Arquitectura / Comercial Ejecución Falta levantamiento y dimensionamiento de HW 9 Arquitectura / Comercial Ejecución Falta validar matriz de compatibilidad de HW 10 Arquitectura / Comercial Ejecución Falta dimensionamiento de HW 11 Arquitectura / Comercial Ejecución Falta levantamiento de información 12 Arquitectura / Comercial Ejecución Incompatibilidad de Hardware 13 Arquitectura / Comercial Ejecución Falta de hardware para completar actividad 14 Arquitectura / Comercial Ejecución Licencias pendientes 15 Arquitectura / Proveedor Planificación Requisitos mal especificados 16 Jefatura de Proyecto Ejecución Falta validar funcionalidades del storage 17 Logística Inicio Falta validar compatibilidad de hardware 18 Proveedor de site Ejecución Excesiva demora en cumplir requisitos 19 Tercer proveedor Planificación Información no declarada oportunamente

4. Detalle de los Procesos y Documentos contenidos en la figura 3

Proceso Descripción Entradas Herramientas y Técnicas Salidas Desarrollar Acta de Constitución

Desarrollar documento que autoriza formalmente la existencia del proyecto y confiere al Jefe de Proyecto la autoridad para aplicar los recursos de la organización a las actividades de éste.

Enunciado del Trabajo Caso de Negocio Acuerdos Factores Ambientales Activos de Procesos

Juicio Experto Técnicas de Facilitación

Acta de Constitución del Proyecto

Desarrollar Plan de Gestión del Proyecto

Definir, preparar y coordinar todos los planes subsidiarios e incorporarlos en un plan integral para la gestión del proyecto.

Acta de Constitución del Proyecto Factores Ambientales Activos de Procesos

Juicio Experto Técnicas de Facilitación

Plan de Gestión del Proyecto

Planificar Gestión del Alcance

Crear un plan que documente cómo el alcance del proyecto será definido, validado y controlado.

Plan de Gestión del Proyecto Acta de Constitución del Proyecto Factores Ambientales Activos de Procesos

Juicio Experto Reuniones

Plan de Gestión del Alcance Plan de Gestión de Requisitos

Recopilar Requisitos

Determinar, documentar y gestionar necesidades y requisitos de interesados para cumplir con los objetivos del proyecto.

Plan de Gestión del Alcance Plan de Gestión de Requisitos Plan de Gestión de Interesados Acta de Constitución del Proyecto Registro de Interesados

Entrevistas Grupos focales Talleres facilitados Técnicas de creatividad Técnicas de toma de decisiones Cuestionarios y encuestas Observaciones Prototipos Estudios comparativos Diagramas de contexto Análisis de documentos

Documento de Requisitos Matriz de Trazabilidad

Definir Alcance

Desarrollar una descripción detallada del proyecto y del producto.

Acta de Constitución del Proyecto Plan de Gestión del Alcance Documento de Requisitos Activos de Procesos

Juicio Experto Análisis de producto Generación de alternativas Talleres facilitados

Enunciado del Alcance Documentos de proyecto actualizados

Crear EDT Subdividir los entregables y el trabajo del proyecto en componentes más pequeños y manejables.

Plan de Gestión del Alcance Enunciado del Alcance Documento de Requisitos Factores Ambientales Activos de Procesos

Descomposición Juicio Experto

Línea Base del Alcance Documentos de proyecto actualizados




29

Documento Descripción Caso de Negocio Proporciona información necesaria desde una perspectiva de negocio para determinar si el proyecto es

viable o no, en términos de los beneficios versus la inversión requerida. Enunciado del Trabajo Descripción narrativa de los productos y servicios a ser entregados por el proyecto. Acta de Constitución del Proyecto

Autorización formal de la existencia de un proyecto, confiere al director de proyecto la autoridad para aplicar los recursos de la organización a las actividades de éste.

Plan de Gestión del Proyecto Describe el modo en que el proyecto será ejecutado, monitoreado y controlado. Plan de Gestión de Requisitos Describe cómo serán analizados, documentados y gestionados los requisitos. Plan de Gestión del Alcance Describe el modo en que el alcance será definido, desarrollado, monitoreado, controlado y verificado. Documento de Requisitos Describe el modo en que los requisitos individuales cumplen las necesidades de negocio. Enunciado del Alcance Describe el alcance, los entregables principales, los supuestos y las restricciones del proyecto. Matriz de Trazabilidad Vincula los requisitos del producto desde su origen hasta los entregables que los satisfacen. Ayuda a

asegurar que cada requisito agrega valor al negocio, al vincularlo con los objetivos del negocio y del proyecto. Permite realizar seguimiento de los requisitos a lo largo del ciclo de vida del proyecto, lo cual contribuye a asegurar que, al final, se provean los entregables acordados.

Línea Base del Alcance Versión aprobada del alcance y la EDT, que sólo puede cambiarse vía Controles de Cambio.

5. HH ocupadas en proyectos problemáticos

A continuación, se detallan las HH de 14 proyectos que tuvieron problemas.

HH Planificadas HH Ejecutadas Diferencia Proyecto Normal Extra J.P. Normal Extra J.P. Normal Extra J.P.

a 12 54 14 167 31 36 -155 23 -22 b 13 64 16 61 54 14 -48 10 2 c 22 0 4 4,5 0 4 18 0 0 d 25 26 0 25 8 5 0 18 -5 e 59 56 35 38 0 15 21 56 22 f 70 0 14 114 0 25 -44 0 -11 g 90 0 26 130 9 25 -40 -9 1 h 140 41 37 188 41 53 -48 0 -16 i 144 40 18 163 54 58 -19 -14 -40 j 229 329 166 407 634 215 -178 -305 -49 k 329 9 43 307 95 73 22 -86 -30 l 361 54 46 283 32 60 78 22 -14 m 562 118 124 455 287 186 107 -169 -62 n 825 434 81 1360 587 191 -535 -153 -110

2.881 1.225 624 3.703 1.832 960 -821 -607 -334

6. Documento de Arquitectura de Soluciones Técnicas

Objetivo del Documento

El presente documento define la estructura y una guía de contenidos para la documentación que la Gerencia Comercial debe entregar a la Gerencia de Servicios al momento de solicitar el inicio de un proyecto y la designación de un Jefe de Proyecto.

Dependiendo del tipo de proyecto, algunas secciones pueden omitirse o abordarse superficialmente.

Sólo incluir productos y funcionalidades que son parte de la solución.

La estructura que debe tener el documento es la que se describe a continuación.

Resumen

Identificar el cliente, el nombre del proyecto y proveer información resumida del problema y de la solución acordada.

Problema

Describir la situación actual y el problema o necesidad del cliente. El uso de diagramas ayuda.




30

Situación Actual

Describir la Situación Actual, en todos los aspectos que sean pertinentes de cara al proyecto (Componentes de hardware y comunicaciones, sistemas operativos, versiones, etc).

Incluir un diagrama donde destaque: equipamiento, ubicación (site), conexiones (switch SAN y LAN), velocidad de los enlaces; si son 2 sites, entonces indicar si están unidos con LAN o SAN extendida.

Necesidad

Describir la Necesidad (problema) planteada por el cliente. En este contexto, se deberá además incluir:

• Énfasis (lo más importante para el cliente, qué exigencias hace) • Restricciones ($, fechas, personal, accesos, ventanas, logística) • Expectativas respecto de los resultados del proyecto

Requisitos

A partir de lo anterior, definir los Requisitos, cuya satisfacción resuelven el problema planteado:

• Funcionales • No funcionales (desempeño, fiabilidad, portabilidad, disponibilidad, escalabilidad, etc) • De gestión, Logísticos y otros que influyen en el resultado

Solución

Descripción General

La Arquitectura es la visión de alto nivel de una solución técnica, es la forma de ensamblar los elementos que la componen de la mejor manera posible, tal que satisfaga los Requisitos. Especificar de manera detallada la solución técnica propuesta, así como los factores relevantes para el desarrollo y uso, debe contemplar los servicios, los componentes y el Diagrama de Arquitectura.

Verificar que el Modelo de Arquitectura de la solución técnica propuesta esté alineado con las estrategias de TIC de las marcas. En esta sección se podrá hacer referencia a links o Redbook.

Delimitaciones o Alcance

Aquí se expresan los acuerdos de ECITI con el cliente respecto de qué está dentro y qué está fuera del Alcance (qué debe hacer ECITI y qué no), bien especificado y detallado.

Por ejemplo, cuántas VM a migrar, configurar, pruebas a realizar, quién provee ciertos insumos, etc.

Plazos, ventanas, Freezing. etc

Objetivos y Beneficios

Definir los objetivos (al lograrlos, se cumple con lo solicitado por el cliente) y los beneficios (lo que el cliente obtiene al lograrse los objetivos) del proyecto.

Componentes de la Solución

Detallar todo el Hardware que compone la solución.

Detallar todo el Software (licenciamiento incluido e información de la licencia vendida; por ejemplo, si es Essential, que aparezca el detalle de este tipo de licencia y no la de Enterprise) y versión a instalar.

Servicios Incluidos

Se debe incluir:

• Detalle de las Actividades • Documentación Técnica acordada (procedimientos, instalación de SO, BD, etc), de estar incluida • Pruebas a realizar (ejemplo, pruebas de clúster se hacen con cliente y se genera documento) • Documentación de Gestión acordada




31

Dependencias Externas

Describir quiénes son los Proveedores de los componentes y servicios (ej, enlaces, configuraciones de storage) y qué nivel de cumplimiento tienen, sobre todo en los tiempos de entrega.

Diagramas de Arquitectura

La solución se construirá según una Arquitectura establecida, en la que se especifica cómo los distintos componentes de la plataforma funcionan como un todo y se apoyan unos a otros.

Incluir un diagrama donde destaquen: equipamiento, ubicación (site), conexiones (switch SAN y LAN), velocidad de los enlaces; si son 2 sites, entonces indicar si están unidos con LAN o SAN extendida.

Requisitos Físicos

Listar detalladamente los requisitos específicos de la solución para ser considerados dentro de la arquitectura, tanto su funcionalidad, hardware y software, entre las cuales deben estar:

• Ocupación de rack (Us), consumo eléctrico y disipación calórica de los componentes • Configuraciones (ejemplo disk magic)

Criterios y Supuestos Técnicos y Restricciones

Listar y describir los criterios técnicos de evaluación de alternativas, tal como:

• Consideraciones de Ejecución. Describir elementos que influyan en la definición de actividades y de esfuerzos, como: ventanas horarias, cuantas máquinas en paralelo se pueden migrar, si se puede hacer migración remota o presencial, las características de los enlaces disponibles, etc.

• Criterios para definir qué actividades se desarrollarán en horario normal y cuáles no. • Principios de seguridad de la información e infraestructura, incluyendo comunicaciones, tales como:

confidencialidad, localización, disponibilidad, forma de acceso, protocolo, procesamiento, etc. • Matriz de Compatibilidad con plataforma actual (HW y licenciamiento del cliente). La transición a la

solución final puede estar limitada por restricciones o hándicaps de la actual. No es necesario incluir todas las matrices, lo que se espera es que el Consultor confirme que lo que se va a implementar no tenga problemas de compatibilidad con la plataforma del cliente y que alerte sobre las incompatibilidades.

Respaldo

Para proyectos que incluyan respaldo, detallar lo siguiente, de manera adicional a los ítems anteriores:

• Políticas de Respaldo • Sizing sobre las máquinas a respaldar • Expectativas de crecimientos sobre la plataforma de respaldos • Responsabilidad sobre medios magnéticos • Expectativas del cliente sobre tasas de deduplicación (VTL) y gestión de informes (Manual, web) • Capacidad de enlaces relacionados a servidores que se encuentren en regiones • SLA definidos por ambientes (SAP, Exchange, etc) • Definir si proyecto contempla Bare Metal (Tiempos relacionados)

Datacenter

Para proyectos que incluyan Datacenter, se deben definir los servicios que éste debe proveer al cliente (con indicadores expresados en SLAs), así como también las responsabilidades en la implementación. Cuando se utilice equipamiento compartido, especificar los componentes que participan de la solución.

Riesgos

Durante el levantamiento inicial y la elaboración de la Propuesta Técnica, el cliente puede advertir o transparentar algunos riesgos provenientes de su parte, los que deberán ser registrados.




32

Definiciones, Acrónimos y Abreviaturas

Esta sección provee las definiciones de todos los términos, acrónimos y abreviaturas utilizadas en este documento, requeridas para interpretarlo correctamente.

Referencias

Esta sección proporciona una lista completa de todos los documentos referenciados en cualquier punto del documento. Identificar cada documento por título, número de reporte si aplica, fecha y organización que lo publica. Especificar las fuentes de donde pueden obtenerse las referencias. Esta información puede ser proporcionada por referencia a un apéndice o a otro documento.

Documentación adicional

Informar en este punto los documentos de apoyo para generar la propuesta, ejemplo levantamiento de máquinas a migrar, respaldar, bases de licitación, entre otros.

Responsables

Responsables de la Elaboración, Revisión y Aprobación de la propuesta.




33

7. Flujo del Proyecto (Propuesto)

GestionarEspecialistas

Comercial Jefe de Proyecto Servicios SistemaCliente Especialista PMO RRHH

Plan de Trabajo

Documentación del Proyecto

Inicializar Proyecto 2 (Asignar Especialistas)

Inicializar Proyecto 5 (Presentar JP y Equipo de

Trabajo al Cliente)

INICIO

Autorizar y Registrar Proyecto 2 (Clasificar y

Asignar JP)

Inicializar Proyecto 4 (Kick-off Interno)

HayDesviaciones de

la PT?

GestionarControl de Cambio

SI

Planificar Proyecto 5 (Kick-off con cliente)

Planificar Proyecto 1 (Analizar Requisitos)

NO

Generar Entregable y Actualizar Actividad

Generar Documentación de Entregable

Implementar Cambios Aprobados

Seguimiento y Control 1 (Reunión de Avance)

Gestionar Aceptación de Entregable

Hay Desviaciones del

Plan?

GestionarControl de Cambio

SI

Documentación Técnica asociada a

Entregable

Entregable

Minuta de Reunión

NO

Cierre del Proyecto 1 (Gestionar Acta de

Cierre)

Cierre del Proyecto 3 (Retroalimentación y

Lecciones Aprendidas)

FIN

Retroalimentación

Inic

iar

Pla

nifi

car

Eje

cuta

r, M

onito

rea

r y

Con

trol

ar

Ce

rrar

Planificar Proyecto 4 (Acta de Constitución y

Alcance)

JP asignado

Acta firmadaFirma Acta

Trabajocompleto?

SI

NO

Firma Acta Acta firmada

Inicializar Proyecto 1 (Solicitar Especialistas)

Desarrollar Plan de Trabajo

Reportes Periódicos y Eventuales

Gestionar Pago Horas Extra

Autorizar y Registrar Proyecto 1 (Informac Cliente y Proyecto)

Especialista asignado

JP asignado

Inicializar Proyecto 3 (Revisar Documentac.)

Planificar Proyecto 2 (Definir Alcance)

Planificar Proyecto 3 (Definir y Registrar

Cronograma)

Cierre del Proyecto 2 (Cierre Administrativo)

Hito de Pago

Hito de Pago

Pago Horas Extra

Acta firmada

Establecer Restricciones

semanaAsignar

Especialista (semana)

Caso de Negocio

JP Asignado

Solicitud Especialistas

Especialistas Asignados

Minuta

Minuta

Documento de Requisitos + Matriz de Trazabilidad

EDT

Gantt

Control de Cambio

Acta de Constitución y Alcance

Acta Firmada

Plan de Trabajo

Restricciones Semana

Especialistas Asignados Semana

Horas Extra a Pago

Entregable TerminadoQuema de HH

Control de Cambio

Documentación Entregable

Reporte

Acta Aceptación Entregable firma

Minuta

Acta de Cierre firmada

Lecciones Aprendidas

Cierre Administrativo

Minuta

Minuta

Solicitud Especialistas

Alta de Servicio




34

8. Diagrama de Procesos ITIL

mejoramiento de la gestión de requisitos en proyectos de …€¦ · la mejora, además,...

Documents