 |
| Imagen de: Picasa Web Albums |
En un entorno tan dinámico como el de los tiempos actuales, todo proyecto está expuesto a la posibilidad que ocurran cambios de alcance durante su desarrollo.
En proyectos de informática está prácticamente asegurado que una vez que el cliente vea el producto se requerirán “ajustes” respecto al diseño original, además, la necesidad del área de negocio podría variar desde el inicio del proyecto hasta su entrega.
En este artículo se discute los distintos tipos de cambios de alcance que puede enfrentar un proyecto de informática, los posibles impedimentos para negociarlos con el cliente y los peligros representados en los mismos.
Además se expresan una serie de pasos que se pueden seguir para gestionarlos con el cliente.
Independientemente de si se está aplicando un enfoque de desarrollo ágil o un enfoque predictivo tradicional, siempre existe la necesidad de manejar las expectativas del cliente en cuanto a los cambios que solicite.
Bajo un enfoque de desarrollo ágil, los cambios se manejan al final de la iteración, si el número de iteraciones es finito y se desea incluir nuevas funcionalidades o modificar las existentes es necesario reemplazarlas por otras de menor prioridad en la lista de funcionalidad por desarrollar (Backlog), si esto no es posible (el cliente necesita todo lo que está en el Backlog), es necesario agregar iteraciones adicionales, resultando en mayor tiempo y presupuesto.
En un enfoque predictivo tradicional, los cambios, luego de valorarse, deberán evaluarse en función de su impacto sobre el proyecto previamente definido, si implica mayor tiempo o costo esto deberá aprobarse y si no se cuenta con presupuesto (o no se puede mover el tiempo), deberá descartarse alguna otra funcionalidad del alcance.
Como se puede ver en ambos casos (Ágil o Tradicional predictivo), todo cambio siempre tendrá un impacto en alcance, tiempo o costo, y esta expectativa es necesario manejarla con el cliente.
> Ejemplos de estimación de costos de un proyecto de software
> Ejemplo de presupuesto de un proyecto de software
Los cambios que resultan de menor complejidad para negociar con el área usuaria son los de funcionalidad, pues está claro que se está solicitando algo adicional.
Pero cuidado, existen dos posiciones extremas que suelen adoptar los desarrolladores de software, una posición es la de aceptar y desarrollar absolutamente todo lo que el usuario les diga, resultando en inversión de mayor tiempo y costo. La otra posición extrema es solicitar cambios de alcance por todo, inclusive por cambios menores de configuración, textos en mensajes, entre otros.
En aras de preservar la buena relación entre el área de Tecnología de Información y el área de negocio es recomendable adoptar una posición no extremista respecto a este asunto, definiendo umbrales o niveles de tolerancia sobre cambios cuando el producto es sometido a revisión.
Otra alternativa para evitar los cambios y el retrabajo es someter el producto a revisiones continuas por parte del usuario, tal como lo establecen metodologías tradicionales de Prototipos o los nuevos enfoques de desarrollo ágil.
Es necesario definir esto desde el principio, para que el área usuaria tenga las expectativas claras en que, por ejemplo, puede solicitar cambios en los textos de mensajes, pero no puede solicitar un módulo adicional no identificado previamente en la fase de análisis.
Sin descargo de lo dicho anteriormente, debe tenerse cuidado con los ajustes menores al producto. Por ejemplo, en el caso de un mensaje de texto en una pantalla software, solicitar cambiar un texto de una pantalla parecería no tener mucho impacto, pero ¿Qué sucede si el usuario revisa los textos de las más de 300 pantallas de una aplicación y solicita cambios sobre todas?, ¿seguiría teniendo un impacto menor sobre el proyecto?, posiblemente no.
¿Y qué ocurriría si estos cambios no se solicitan todos en un mismo período?, sino a lo largo de varios meses, ¿Cuándo identificaríamos que tenemos un cambio de alcance?, ¿Podríamos negociar con el cliente un cambio de alcance al final del proyecto?, posiblemente no.
Como se mencionó anteriormente, lo mejor es definir niveles de tolerancia para estos cambios, que evalúen no solamente cada solicitud de cambio individual sino la agregación de las mismas, de esta forma se puede manejar con anticipación la expectativa del cliente, señalándole por ejemplo que si continúan solicitando los ajustes a la tasa actual, sería necesario solicitar un cambio de alcance en un tiempo dado.
Los cambios de alcance de naturaleza técnica son más difíciles de negociar con los usuarios finales que los cambios de funcionalidad.
Por ejemplo, que sucedería si somos un desarrollador externo y al principio del proyecto el área de TI nos dijo que existían una serie de servicios para acceder a una aplicación, realizamos nuestra estimación bajo ese supuesto, pero luego se descubre que los servicios no existen y deben desarrollarse.
Claramente es una funcionalidad adicional a desarrollar, pero, ¿es asignable el cambio de alcance al usuario?, no necesariamente. El usuario podría decir que es un aspecto técnico no relevante para ellos y el área de TI podría decir que es responsabilidad del proyecto identificar la totalidad del alcance técnico a desarrollar.
En el caso del alcance técnico, los cambios de alcance tienen mucha menor probabilidad de aceptación, por lo que lo mejor es la prevención, validando el diseño técnico de la solución en el sitio (por ejemplo inspeccionando y realizando pruebas sobre estos servicios), antes de comprometer la estimación.
Independientemente del enfoque de desarrollo de software aplicado (ágil o predictivo), es una buena práctica tener un procedimiento de revisión de cambios de alcance previamente acordado con los distintos involucrados en el proyecto, tanto del área usuaria como de otros interlocutores de áreas técnicas.
Dicho procedimiento debería contemplar como mínimo lo siguiente:
Para el caso de enfoques de desarrollo ágiles, este procedimiento está inmerso en el proceso, por lo general la solicitud se realiza durante la revisión del Producto, para luego valorar y aprobar (o rechazar) el cambio al inicio de la próxima iteración durante la fase de planificación de la misma. Para el caso de enfoques predictivos, puede adoptarse un procedimiento de control de cambios, como por ejemplo el establecido por el “Project Management Institute” (PMI) en el área de conocimiento de Gestión Integrada.
¿Qué ocurre en situaciones cuando el tiempo apremia porque la fecha de entrega esta próxima?, pues debe hacerse de forma expedita, posiblemente valorándolo el mismo día y discutiéndolo lo antes posible en una teleconferencia.
¿Y qué opinas tu?, ¿Qué recomendarías para gestionar los cambios en los proyectos?, ¿Cómo manejarías la negociación y relación con el cliente?. Te invitamos a participar en el foro de discusión del blog de “La Oficina de Proyectos de Informática” y a suscribirte por nuestros canales.
¿Buscas información de gerencia de proyectos?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y contenidos de Gerencia de Proyectos, entonces suscríbete a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
Artículos relacionados
En proyectos de informática está prácticamente asegurado que una vez que el cliente vea el producto se requerirán “ajustes” respecto al diseño original, además, la necesidad del área de negocio podría variar desde el inicio del proyecto hasta su entrega.
En este artículo se discute los distintos tipos de cambios de alcance que puede enfrentar un proyecto de informática, los posibles impedimentos para negociarlos con el cliente y los peligros representados en los mismos.
Además se expresan una serie de pasos que se pueden seguir para gestionarlos con el cliente.
Gestión de cambios de alcance independientemente del enfoque de desarrollo de software
Independientemente de si se está aplicando un enfoque de desarrollo ágil o un enfoque predictivo tradicional, siempre existe la necesidad de manejar las expectativas del cliente en cuanto a los cambios que solicite.
Bajo un enfoque de desarrollo ágil, los cambios se manejan al final de la iteración, si el número de iteraciones es finito y se desea incluir nuevas funcionalidades o modificar las existentes es necesario reemplazarlas por otras de menor prioridad en la lista de funcionalidad por desarrollar (Backlog), si esto no es posible (el cliente necesita todo lo que está en el Backlog), es necesario agregar iteraciones adicionales, resultando en mayor tiempo y presupuesto.
En un enfoque predictivo tradicional, los cambios, luego de valorarse, deberán evaluarse en función de su impacto sobre el proyecto previamente definido, si implica mayor tiempo o costo esto deberá aprobarse y si no se cuenta con presupuesto (o no se puede mover el tiempo), deberá descartarse alguna otra funcionalidad del alcance.
Como se puede ver en ambos casos (Ágil o Tradicional predictivo), todo cambio siempre tendrá un impacto en alcance, tiempo o costo, y esta expectativa es necesario manejarla con el cliente.
Un elemento importante al considerar un cambio de alcance o de otra indole, es el costo que este representa para el proyecto. ¿Te gustaría ver ejemplos de estimación de costos en proyectos de software? sigue los siguientes enlaces:
> Ejemplos de estimación de costos de un proyecto de software
> Ejemplo de presupuesto de un proyecto de software
Cambios en la funcionalidad
Los cambios que resultan de menor complejidad para negociar con el área usuaria son los de funcionalidad, pues está claro que se está solicitando algo adicional.
Pero cuidado, existen dos posiciones extremas que suelen adoptar los desarrolladores de software, una posición es la de aceptar y desarrollar absolutamente todo lo que el usuario les diga, resultando en inversión de mayor tiempo y costo. La otra posición extrema es solicitar cambios de alcance por todo, inclusive por cambios menores de configuración, textos en mensajes, entre otros.
En aras de preservar la buena relación entre el área de Tecnología de Información y el área de negocio es recomendable adoptar una posición no extremista respecto a este asunto, definiendo umbrales o niveles de tolerancia sobre cambios cuando el producto es sometido a revisión.
Otra alternativa para evitar los cambios y el retrabajo es someter el producto a revisiones continuas por parte del usuario, tal como lo establecen metodologías tradicionales de Prototipos o los nuevos enfoques de desarrollo ágil.
Es necesario definir esto desde el principio, para que el área usuaria tenga las expectativas claras en que, por ejemplo, puede solicitar cambios en los textos de mensajes, pero no puede solicitar un módulo adicional no identificado previamente en la fase de análisis.
Cuidado con el “Scope Creep”
Sin descargo de lo dicho anteriormente, debe tenerse cuidado con los ajustes menores al producto. Por ejemplo, en el caso de un mensaje de texto en una pantalla software, solicitar cambiar un texto de una pantalla parecería no tener mucho impacto, pero ¿Qué sucede si el usuario revisa los textos de las más de 300 pantallas de una aplicación y solicita cambios sobre todas?, ¿seguiría teniendo un impacto menor sobre el proyecto?, posiblemente no.
¿Y qué ocurriría si estos cambios no se solicitan todos en un mismo período?, sino a lo largo de varios meses, ¿Cuándo identificaríamos que tenemos un cambio de alcance?, ¿Podríamos negociar con el cliente un cambio de alcance al final del proyecto?, posiblemente no.
Como se mencionó anteriormente, lo mejor es definir niveles de tolerancia para estos cambios, que evalúen no solamente cada solicitud de cambio individual sino la agregación de las mismas, de esta forma se puede manejar con anticipación la expectativa del cliente, señalándole por ejemplo que si continúan solicitando los ajustes a la tasa actual, sería necesario solicitar un cambio de alcance en un tiempo dado.
Cambios técnicos
Los cambios de alcance de naturaleza técnica son más difíciles de negociar con los usuarios finales que los cambios de funcionalidad.
Por ejemplo, que sucedería si somos un desarrollador externo y al principio del proyecto el área de TI nos dijo que existían una serie de servicios para acceder a una aplicación, realizamos nuestra estimación bajo ese supuesto, pero luego se descubre que los servicios no existen y deben desarrollarse.
Claramente es una funcionalidad adicional a desarrollar, pero, ¿es asignable el cambio de alcance al usuario?, no necesariamente. El usuario podría decir que es un aspecto técnico no relevante para ellos y el área de TI podría decir que es responsabilidad del proyecto identificar la totalidad del alcance técnico a desarrollar.
En el caso del alcance técnico, los cambios de alcance tienen mucha menor probabilidad de aceptación, por lo que lo mejor es la prevención, validando el diseño técnico de la solución en el sitio (por ejemplo inspeccionando y realizando pruebas sobre estos servicios), antes de comprometer la estimación.
Establecer procedimientos de cambios de alcance
Independientemente del enfoque de desarrollo de software aplicado (ágil o predictivo), es una buena práctica tener un procedimiento de revisión de cambios de alcance previamente acordado con los distintos involucrados en el proyecto, tanto del área usuaria como de otros interlocutores de áreas técnicas.
Dicho procedimiento debería contemplar como mínimo lo siguiente:
- Solicitud de cambio: Establecer quien realiza solicitudes de cambio, cual es el canal de comunicación apropiado y bajo que formato. Es importante evitar que se hagan solicitudes directas a los desarrolladores (por ejemplo durante un Product Review) y que estos tengan que dar respuesta inmediata.
- Análisis y valoración: El equipo revisa la solicitud y determinar el esfuerzo (por ejemplo en horas) y la posible planificación (Fecha). Es importante revisar su impacto sobre duraciones y costos previamente establecidos.
- Determinar si es un cambio menor: Si el cambio está dentro de umbrales previamente establecidos, este puede ser aprobado de forma expresa, por ejemplo por el desarrollador en sitio o por el Gerente del Proyecto. Si por el contrario, el cambio excede un umbral, puede establecerse en el procedimiento que lo debe aprobar el comité.
- Comité de cambios: Un comité integrado por miembros del equipo, del usuario y otros involucrados debe revisar la solicitud ya valorada por el equipo. Aquí deben tomarse decisiones, se extiende el plazo (por ejemplo se agrega otra iteración), se incrementa el presupuesto para incorporar personal adicional, o se intercambia por otro componente del alcance no desarrollado aún que tenga el mismo valor. Este comité es quien aprueba los cambios.
- Ejecución del cambio: Sólo después que se han cumplida la aprobación, bien sea por vía expresa o por la vía de comité de cambio, se procede a desarrollar el cambio de alcance.
Para el caso de enfoques de desarrollo ágiles, este procedimiento está inmerso en el proceso, por lo general la solicitud se realiza durante la revisión del Producto, para luego valorar y aprobar (o rechazar) el cambio al inicio de la próxima iteración durante la fase de planificación de la misma. Para el caso de enfoques predictivos, puede adoptarse un procedimiento de control de cambios, como por ejemplo el establecido por el “Project Management Institute” (PMI) en el área de conocimiento de Gestión Integrada.
¿Qué ocurre en situaciones cuando el tiempo apremia porque la fecha de entrega esta próxima?, pues debe hacerse de forma expedita, posiblemente valorándolo el mismo día y discutiéndolo lo antes posible en una teleconferencia.
Conclusión
¿Y qué opinas tu?, ¿Qué recomendarías para gestionar los cambios en los proyectos?, ¿Cómo manejarías la negociación y relación con el cliente?. Te invitamos a participar en el foro de discusión del blog de “La Oficina de Proyectos de Informática” y a suscribirte por nuestros canales.
¿Buscas información de gerencia de proyectos?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y contenidos de Gerencia de Proyectos, entonces suscríbete a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
No hay comentarios :
Publicar un comentario