¿Cómo definir el scope de los proyectos?

Desde el comienzo de mi camino en el desarrollo de software, aprendí que determinar el alcance de los proyectos y sus cronogramas (en inglés “scoping”), es una de las cosas más difíciles de hacer bien.

Desafortunadamente, los programas de las carreras de informática en las universidades no enseñan a hacer esto. Así que aquí está mi intento de consolidar lo que he aprendido sobre este tema.

El scoping no es algo que se pueda hacer en un día y nunca más tocarlo en todo el proyecto. De hecho, para determinar el scope de un proyecto con precisión, hay que prestar atención especialmente en las siguientes fases:

• La fase de planificación: las primeras etapas de la definición del proyecto y sus objetivos.
• La fase de determinación del alcance o scoping: aquí es donde se intenta enumerar el trabajo que debe realizarse dados los objetivos del proyecto y estimar cuánto tiempo se requerirá para realizarlos.
• La fase de ejecución: cuando realmente está en proceso de implementación.

La fase de planificación:

Una de las cosas más importantes que se deben hacer durante este tiempo es definir objetivos muy específicos para el proyecto. Por ejemplo, en lugar de “mejorar X para que sea más escalable y eficiente”, un objetivo mejor y más específico podría ser “mejorar X agregando pruebas unitarias, admitiendo 20.000 consultas por segundo y reduciendo la media limitada de latencia del usuario a <= 200 ms . “

Tener objetivos de esta manera permite eliminar sin piedad cualquier cosa que no contribuya a estos, para que no sufran alteraciones de sus funcionalidades. En este sentido, también se podría considerar definir explícitamente los anti-objetivos y separar lo que serían los nice-to-have.

La fase de determinación del alcance o scoping:

• Solo los desarrolladores, en conjunto a los Project y Functional managers, deberían ser los que definan el scope de las tareas. Ni sus gerentes, ni los stakeholders claves del proyecto (Ya sea cliente o PO).
• Dividir el proyecto en pequeñas tareas, cada una de las cuales tomen dos días o menos. Cuando se tienen tareas que tienen un alcance de “aproximadamente 1 semana”, suelen terminar tomando más tiempo porque no se enumeraron todas las subtareas que se precisaban realizar.
• Definir hitos medibles para alcanzar la meta. Programar cada uno con una fecha específica de objetivo. Estos deberán tener responsables.
• Agregar un colchón de tiempo: es importante poder también dejar una reserva de tiempo considerando reuniones de trabajo, feriados, imprevistos, etc. Se suele multiplicar el tiempo requerido por desde 1,25 a 1,5.
• Tener en mente que 2X el número de personas no significa 1/2X el tiempo de desarrollo, como resultado del tiempo de ramp-up, integración de equipos, etc.

La fase de ejecución:

El scope se debe ajustar durante la ejecución del proyecto. Para cada tarea, hay que hacer un seguimiento de cuánto tiempo se estimó y finalmente cuanto se tardo en completarla.

Si el scope está desviado en un 50% para los primeros hitos, es probable que también lo esté en un 50% para el resto del proyecto.

Utilizar los hitos para entender cómo va el proyecto: es tentador responder “va a estar listo la semana que viene” o “a fin de mes”. Pero este tipo de respuestas vagas tienden a crear proyectos que siempre están a 2 semanas de estar terminados. En su lugar, usar los hitos (re-scopeados) para dar una respuesta concreta basada en cuánto trabajo queda por hacer.

Por último, siendo honesto, de ninguna manera soy un experto en el scoping y todavía en Orbit, cometemos errores con regularidad, como por ejemplo, no seguir algunas de las mejores prácticas mencionadas en el artículo. Simplemente pensé que documentaría mis aprendizajes hasta ahora para poder referirme a esto en el futuro.

Si te gusto este post, te invito a que puedas ver mas contenido Orbit.com.ar y conozcas como trabajamos.