Lidiando con un “Scope Creep” en proyectos de desarrollo de software
Por Linda Russell [ Acerca de la autora ]
 Un Scope Creep es un riesgo significativo en proyectos de desarrollo de software. Ahora veremos por qué sucede y cómo evitar o mitigarlo.
¿Qué es un Scope Creep?
El desarrollo de un nuevo software surge generalmente como resultado de la identificación de una necesidad de un cliente, quien puede ser interno o externo a una organización. El paso siguiente es especificar cómo el software cumplirá con esa necesidad, específicamente, qué funcionalidad será desarrollada.
Lo anterior es el “scope” o alcance del proyecto. En esta fase los planes del proyecto están preparados y basados en la estimación para el desarrollo y entrega de una funcionalidad determinada, por lo que una fecha de finalización es acordada.
Pero, puede ocurrir que cuando comienza el desarrollo y parece que el proyecto está progresando de manera adecuada, el cliente se da cuenta que hay requerimientos adicionales que olvidó mencionarlos o elementos extras de funcionalidad que necesita. Frecuentemente, añadiendo estos suplementos generará que la duración de proyecto sea ampliada, omitiendo los plazos límites e incrementando los gastos; conduciendo al menoscabo del margen en el proyecto y potencialmente a la insatisfacción del cliente y pérdida de la credibilidad generada por una entrega tardía.
¿Cómo lidiar con un Scope Creep?
Es importante que una especificación funcional esté producida desde el principio, escrita en términos que el cliente pueda entenderla. Por ejemplo, un paseo por el proceso donde el software apoyará, tal vez ilustrado con una simulación a través de diapositivas, lo que ayudará a clarificar cómo trabajará el nuevo sistema desde el punto de vista del usuario.
La especificación funcional debe ser acordada y firmada por el cliente y debería incluir una Definición de Alcance. Esto expresa que solamente la funcionalidad, la cual está explícitamente descrita en la especificación está incluida en el alcance del proyecto y que algo no descrito está “fuera de alcance”.
Cuando posteriormente el cliente identifica elementos adicionales, dicha referencia es hecha en la especificación: ¿La funcionalidad requerida es descrita o aludida a:?. Si no lo es, el nuevo desarrollo está fuera de alcance.
El próximo paso es elaborar el impacto del desarrollo de la nueva funcionalidad: ¿Qué esfuerzo extra será requerido?, ¿Qué efecto tendrá sobre la totalidad de duración del proyecto?, ¿En qué costos adicionales se incurrirá y cómo afectará esto al margen del proyecto?.
Si el impacto es insignificante, puede ser acordado para incluir la nueva funcionalidad en el proyecto existente, pero lo ideal debería ser la realización de la definición por escrito de una especificación revisada. El peligro aquí es que el cliente creerá que se ha sentado un precedente, por lo que puede pensar que futuras revisiones serán realizadas de la misma forma; por eso es importante comunicar las razones para permitir la revisión en esta instancia.
Es más probable que el desarrollo adicional genere retraso y/o costos extras. El cliente necesita estar conciente de las implicaciones de la revisión en términos del impacto de éstas sobre las escalas de tiempo y costos; y una especificación de las adiciones y cambios deberían escribirse (con la propia Definición de Alcance). Entonces será el cliente quien decidirá si está dispuesto a pagar más y si acepta la fecha final revisada del proyecto. Si está de acuerdo, la nueva especificación debería ser firmada como antes.
¿Realmente necesitamos una Definición de Alcance?
Uno puede pensar que escribir una especificación lo suficientemente detallada puede generar que la realización de la Definición de Alcance conlleve más tiempo (y costo) del que está garantizado por el valor del proyecto como un todo. Por ejemplo, si se tiene previsto que todo el proyecto tome únicamente unas pocas semanas y toma cinco días escribir una especificación detallada, un análisis costo/beneficio mostraría que no vale la pena hacerlo.
Si es el caso, hay que evaluar la probabilidad del riesgo (basándonos en el conocimiento del cliente y qué tan seguro se está de todos los requerimientos que han sido identificados) y el posible impacto del aumento en contingencia suficiente en las estimaciones de tiempo y costos para cubrir todo excepto la mayor parte de las revisiones principales a la especificación.
Temas relacionados:
 Certificación en Administración de Proyectos de Software
|
Soy Novato
