Luego de haber identificado la problemática a tratar, de haber definido el alcance del proyecto, de haber realizado la planeación del proyecto y después de su ejecución se presentan solicitudes de cambios. Estos cambios afectan de varias formas el proyecto y es función del Gerente de Proyectos hacerse cargo de la gestión de cambios del conjunto de prestaciones previamente definidas.
Un proyecto siempre va a tener solicitudes de cambios al conjunto de prestaciones, por lo tanto el manejo de estas situaciones debe estar contemplada. en muchos casos significa hacer muchas cosas en su estado “re”. ( redefinir, replanear, etc) y sobre todo llegar nuevamente a acuerdos con “stakeholders” relevantes. Luego socializar cada compromiso nuevo con el equipo de trabajo y lograr su compromiso para el cumplimiento de las nuevas condiciones.
Hay que recordar también que siempre algo se debe afectar para poder cumplir con las nuevas prestaciones, o mayores recursos o mayores tiempos o reducir prestaciones de otros componentes.
Los proyectos de software son realizados según las especificaciones y deseos de los clientes. Sin embargo, lograr plasmar en código lo que el cliente está pensando y quiere obtener al contratar a un grupo de desarrolladores es una tarea difícil. Para esto, existen varios métodos para obtener los requerimientos del software que el cliente desea. Una vez se tengan todos los requerimientos, y que el cliente los haya aprobado, se procede a la codificación.
Sin embargo, es común que los requerimientos cambien, ya sea porque al cliente se le ocurrió añadir una nueva funcionalidad al software en mitad de camino, o porque salió a la venta un nuevo software de la competencia que tiene aspectos que no se habían tenido en cuenta.
Esto ultimo fue lo que ocurrió con Square-Calc 4.0, en el cual la competencia sacó a la venta un software superior a éste en varios aspectos, por lo que se debieron replantear las prestaciones del software y por lo tanto los requerimientos.
Cuando se modifican los requerimientos de un producto de software, la consecuencia más común es un atraso en varios meses de la entrega final del producto y un sobre costo en la producción. Esto se debe a que al ingresar nuevos requerimientos y modificaciones al producto, la probabilidad de que sea necesario modificar las partes ya codificadas del software aumente considerablemente y haya necesidad casi de reescribirlo.
De acuerdo a lo anterior, al momento de realizar cambios en los requerimientos, es necesario hacer un estudio del impacto que éstos generan en el costo y tiempos de entrega del producto final. Tal como se aprecia en la lectura, primero se realizó una lista de prestaciones que deben ser modificadas, luego se estudió cuanto tiempo tardarían, y al final solo se escogieron las que eran mas relevantes y no tomaran mucho tiempo en ser establecidas.
Los cambios en los requerimientos son el común denominador en el desarrollo de software. Sin embargo, no se debe tener una actitud negativa frente a los cambios. Existen métodos para estimar los costos en tiempo y dinero de los cambios, y dependiendo de esto se pueden implementar o no.
GPTI – Capítulo 14
El control de cambios es un factor muy importante en cualquier desarrollo de software. Es común ver en casos donde clientes adicionan requerimientos al sistema de forma acelerada, sin pensar en el retraso y en los cambios en el resto del sistema que pueden generar. Otro caso es el que se presenta en Square-Calc 4.0, donde es la competencia de un producto de similares características quien define esos nuevos requerimientos adicionados.
La adición y posterior redefinición debe ser tratada con cautela. El trabajo en equipo es esencial en este caso. Todas las partes involucradas en el desarrollo deben dar un informe de retrasos y posibles inconvenientes y riesgos que pueden traer los cambios. Es importante darle prioridad a este proceso, dado que está en juego recursos y tiempo futuro que no estarán disponibles; además, en casos donde se esté haciendo un desarrollo a la medida, es clave darle a entender al cliente que estos cambios traerán un retraso y aún más importante es decirles de cuánto será el retraso.
Dependiendo del tamaño y la complejidad del proyecto, hay diferentes formas de llevarlo a cabo con el fin de tener un desarrollo rápido y ordenado:
• En proyectos de pequeña escala, es muy importante tener en cuenta que se deben hacer con un mínimo de tiempo. No es necesaria una especificación detallada de requerimientos y para facilitar futuros cambios; es conveniente trabajar un desarrollo evolutivo.
• En proyectos a mediana escala, es importante documentar muy bien todo lo que se desarrolle, se cambie y se sugiera; en estos desarrollos muchas personas intervienen en los diferentes procesos y es necesario llevar un control minucioso de los cambios que se van a realizar y se han realizado.
• En proyectos a gran escala, es importante controlar los tiempos. Un pequeño cambio puede hacer repercusión en un gran número de puntos funcionales o requerimientos. En más conveniente socializar en el equipo de desarrollo el cambio y en un tiempo prudente pensarlo, que tratar de hacer las estimaciones de forma acelerada sin tener en cuenta el efecto de los cambios en las entregas y en el sistema total.
Cuando el proyecto que se desarrolla es de escala comercial, se corre el riesgo de enfrentar una competencia que ofrezca servicios adicionales a la funcionalidad común de la aplicación.
El control de la influencia de ideas y conceptos en el proyecto de desarrollo por parte de terceras aplicaciones es muy importante de manejar, debido a que éstas provocan cambios que retrasan el proyecto al tener que modificarse los requerimientos, pruebas, documentación, entre otros. Si se presenta el caso en que muchos proyectos coinciden con el que se trabaja (Aplicaciones asesinas), puede suceder que se retrase tanto el lanzamiento que, al momento de hacerlo, éste ya es obsoleto. Aunque sea importante añadir dichos nuevos servicios, se debe analizar el impacto del cambio en todas las áreas que participan en la elaboración del proyecto, ya que de esta manera se conoce si es relevante y si se pueden incluir los nuevos servicios en la aplicación actual o de lo contrario se añadirán en una versión posterior.
Aspecto que controlaron bien en el proyecto de Square-Calc 4.0, debido a que contaban con un grupo de control de cambios conformado por representantes de cada una de las áreas que contribuyen al desarrollo del producto. Grupo con el que es importante contar a la hora de incluir cambios en las prestaciones, ya que es el encargado de analizar el impacto de éstas. Este hizo un correcto análisis de los cambios propuestos desde el punto de vista de los costos, planificación y prestaciones del producto, decidiendo incluir cambios importantes con poco impacto sobre la aplicación en general y su tiempo de lanzamiento.
Cabe aclarar que las aplicaciones asesinas: Son aplicaciones de la competencia que retrasan el lanzamiento de la aplicación local a través de prestaciones que se comienzan a añadir al conocerse los servicios adicionales que ofrece el otro producto.
Teniendo en cuenta el ejemplo 14.1 y su correspondiente situación, consideramos que la labor que llevó a cabo el equipo de control de cambios fue acertada.
Esto se debe a que se realizó un análisis de impacto a nivel de proyecto, es decir, se analizó el impacto sobre documentación, producto, plan de pruebas y clientes. Un aspecto a resaltar en el estudio de impacto es que se tuvo en cuenta el exterior del proyecto, es decir, los clientes –Los cuales son en última instancia los que adquieren el producto-. Esto fue decisivo en la decisión abordada debido a que el proyecto se encontraba a punto de terminar, lo cual implicaba que no se contaba con el tiempo apropiado para realizar la totalidad de los cambios propuestos para el producto final; además, existía un alto riesgo de afectar los factores anteriormente mencionados (documentación, producto, etc.) lo cual podría desencadenar un crecimiento exponencial en el tiempo y presupuesto de desarrollo del proyecto.
Es de admirar también la capacidad que tuvo el equipo para establecer las prioridades de aquellas prestaciones en cuyos cambios planteados se verían afectados otros equipos del proceso. Gracias a dicha priorización, se logró perpetuar un proceso de recorte de prestaciones el cual se realizó debido al estado de avance en el cual se encontraba el proyecto (a punto de terminar). Este recorte de prestaciones dio como resultado una lista donde se dejó en claro cuáles iban a ser las prestaciones que iban a ser implementadas. Y no sólo eso, también se logró llevar a cabo un análisis que permitió llegar a un pronóstico acertado del tiempo que dichas modificaciones proporcionarían en la fecha de entrega del producto final.
Otro de los puntos que favoreció el proceso que se llevó a cabo, es el hecho de que al final del estudio de los cambios, se realizó una notificación a todos las personas implicadas en el desarrollo del producto. Esto permitió que todas las partes estuvieran informadas sobre los procesos subsecuentes y sus implicaciones permitiéndoles no solo prepararse para estos sino empezar a trabajar en los cambios respectivos.
Control del Conjunto de Prestaciones
Por: Andres Felipe Montoya
Jaime H Arismendi
Todo desarrollo de software es susceptible a cambios durante su proceso de desarrollo, esto se puede dar por varios factores entre los cuales podemos destacar:
*Los cambios generados por el avance del proyecto, a medida que se avanza con el desarrollo del software se van teniendo más claros los requerimientos dando lugar a posibles cambios.
*Por otra parte están los cambios impulsados por los clientes finales, ya que hay ocasiones en que ellos desean realizar variaciones o adiciones inesperadas en los requerimientos para mejorar la funcionalidad del software en desarrollo, para ello se deben de hacer cambios en la marcha del proyecto lo que genera un impacto sobre los diferentes grupos del proyecto.
*Otro cambio encontrado regularmente en los desarrollos de software está arraigado en las innovaciones, cambios y nuevos productos lanzados por las competencias, pues no estar a la vanguardia del mercado puede dar pie al fracaso del software.
Este último factor citado es el caso presentado en el Ejemplo 14.1 del libro “Desarrollo y Gestión de Proyectos Informáticos”, en donde a pocas semanas de la entrega del desarrollo hecho por Square-Calc 4.0, se enteran que la competencia lanzo una nueva versión con mejoras que ellos no tenían previsto para la entrega de su producto final. De allí surge la necesidad de gestionar cambios en el desarrollo, teniendo en cuenta que “los productos con un mayor éxito son a menudo aquellos que han incorporado la mayoría de sus cambios al final del ciclo de desarrollo”, seguramente no tendrían ninguna oportunidad de éxito si no se implementaran algunos cambios que permitieran estar a un nivel igual o superior que el producto entregado por la competencia.
De esta manera podemos afirmar que los cambios no son del todo malos e intentar detenerlos puede ser un error, los cambios se deben ver como una oportunidad de éxito y su correcta gestión es la clave para lograr que el impacto de estos en lugar de ser perjudicial sea beneficioso. Para ello hay una serie de objetivos comunes que se deben buscar con la implementación de un plan de gestión de cambios y estos son: “Permitir cambios que ayuden a obtener el mejor producto posible en el tiempo disponible. Permitir que todas las partes afectadas por un cambio estimen los impactos del cambio en la planificación, los recursos y el producto. Notificar cada cambio propuesto a los miembros del entorno del proyecto, indicando su impacto estimado y si ha sido aceptado o rechazado. Mantener un registro de las decisiones relacionadas con el contenido del producto.”
Ahora bien, volviendo al Ejemplo 14.1, podemos apreciar como allí se hace una correcta gestión de los cambios, se realiza un estudio detallado de las implicaciones que tienen los cambios en el costo, tiempo y el producto, para así poder tomar las decisiones correctas que representan un mayor beneficio para todos los implicados en el proyecto y para la compañía.
Los proyectos de software que hemos desarrollado han tenido cambios en el conjunto de prestaciones que, de forma inconsciente, hemos tratado de sobrellevar sin tener un método claro o conocimientos sobre cómo realizar este control. En varias ocasiones al final del proyecto cuando no tenemos tiempo para terminar de implementar todas las prestaciones debemos recurrir a recortarlas. Fallos en la planificación, desarrollo de prestaciones innecesarias, introducción de nuevas prestaciones, falta de experiencia en la negociación y no tener clara la magnitud del proyecto entre otras cosas; son algunas de las causas que nos han impedido entregar un producto terminado y de calidad.
En la vida todo cambia y el software no es la excepción, bien desde que pensamos un proyecto personal y a mitad de camino queremos añadirle nuevas funcionalidades o mejorar las actuales, o cuando un cliente descubre una nueva necesidad y quiere agregarla, el cambio existe y debemos convivir con él. Tal vez existan proyectos donde no necesitamos cambiar nada, pero son contadas las excepciones y al menos que hayamos hecho un buen análisis, seguramente la falta de cambios indica que estamos dejando de lado algo.
El primer paso para evitar traumas con los cambios de requerimientos, es realizar un análisis de requerimientos global, para ello debemos tener muy claro cuál es el objetivo del software y sobretodo que problema planta solucionar el cliente. A primera vista parece fácil, “un software para manejo de inventario”, pero esta definición tan simple tiene implicaciones muy diferentes en cada negocio e incluso dentro de una misma empresa las personas lo pueden interpretar diferente, ¿acaso el software debe hacer seguimiento vía RFID?, o debe tener soporte para múltiples bodegas, ¿es importante enviar notificaciones vía SMS? Todas estas características y cientos más pueden ajustarse al negocio o pueden que no, y es parte de la labor identificarlas y poder estar preparado para desarrollarlas si así se requiere.
Es importante hacer control de cambios al inicio, durante y al finalizar. La especificación mínima nos acerca a no dejar errar en los detalles, ya sea por acción o por omisión, y conocer el por qué se dan los cambios nos prepara para las situaciones indeseables.
Muchas veces la experiencia permite identificar una necesidad que el cliente no tiene clara, pero que seguramente necesitara en el futuro, es ahí donde la detección temprana puede ser vital a la hora de realizar o no el cambio.
Un ejemplo claro, se puede observara a la hora de diseñar una base de datos, en una ocasión fuimos contratados para realizar un sencillo programa de facturación, al preguntar sobre la manera de hacer los descuentos, la respuesta fue “Aquí casi no damos descuentos y si mucho damos un 10% descuento por pago de contado”, de esta manera cuando diseñamos la base de datos incluimos en una tabla factura una columna llamada descuento con un valor entre 0 y 100, de esta manera el programa permitía agregar un solo descuento al precio final de la factura. Tiempo después la junta directiva creyó que una buena estrategia podía ser agregar descuentos en cascada (descuentos sobre descuentos ya aplicados a la factura) para motivar los pagos antes de 30 días y las ventas por volumen, cuando nos llamaron, explicamos todos los inconvenientes que este cambio podía ocasionar, no solo teníamos que modificar la forma de facturar, si no que debíamos cambiar la base de datos y con ello, la información que ya se había guardado durante el tiempo de operación. Si en esa ocasión hubiéramos previsto ese tipo de cosas, por encima de la necesidad inmediata del cliente, tal vez, desde el diseño abríamos pensado en múltiples descuentos y el cambio no hubiera sido tan traumático, es cierto que cumplimos con un requerimiento inicial pero no fuimos capaces de adaptarnos a las necesidades de nuestro cliente.
Francisco Martinez
Daniel Amariles