Ciclos

En Unagi solemos encarar nuestros desarrollos en ciclos, tomando como referencia las metodologías ágiles. Un ciclo es un concepto que tiene 3 partes:

• un conjunto de requerimientos,
• un equipo,
• y un deadline

Creemos que todo desarrollo se puede trabajar en módulos con una duración de X semanas. Incluso, aunque se trate de un mantenimiento con múltiples tareas, podríamos tratar de ver todos como un conjunto e intentar establecer un ciclo con todas esas tareas en él. El deadline puede variar levemente pero usualmente los ciclos tienen 3 semanas.

Tiempo fijo y alcance variable

Lo normal es pensar en un conjunto de requerimientos y determinar cuánto tiempo estimo necesario para lograr completarlos. Solemos preguntarnos, ¿cuánto vamos a tardar en hacer todo esto? y estimar. Si fallé en la estimación, voy modificando el tiempo para lograr incluir todo. En otras palabras, se suele definir un alcance fijo y un tiempo variable.

Nosotros le damos una vuelta de tuerca y tratamos de cambiar nuestra forma de pensar los ciclos y requerimientos. Cada vez que vayamos a iniciar un módulo, la pregunta no debe ser “¿cuánto vamos a tardar en hacerlo?” sino “¿qué es lo mejor que puedo hacer en 3 semanas para resolver el problema?”. Ambos hablan de tiempo pero son muy diferentes. El primero tiene un alcance fijo y un tiempo variable, el segundo un tiempo fijo y un alcance variable.

En caso de ver que no vamos a llegar con un deadline, no vamos a extender el ciclo, sino que vamos a achicar (o modificar) el alcance para cumplir con el deadline.

¿Pero esto no va en detrimento de la calidad de nuestras soluciones? Si manejamos ciclos de 3 semanas puede ser que no lleguemos a tener la versión ideal, ¿no? La respuesta es “Depende”.

¿Cuál es la versión ideal de algo? Si tengo hambre, siempre voy a elegir un asado frente a un pancho. Pero si solo tengo 5 minutos, un pancho va a ser el ideal.

Acá buscamos lo mismo. Sabemos que siempre va a haber cosas para mejorar y propuestas mejores. Pero nosotros queremos lograr soluciones buenas, que le agreguen valor al cliente en tiempos razonables. Por ello, será fundamental mejorar nuestros análisis, usando herramientas y técnicas que nos permitan cambiar rápidamente, priorizando aquellas soluciones que solucionen problemas y, por ende, aporten valor.

¿Por qué 3 semanas?

La respuesta es tan simple como “porque es un número que nos ha funcionado”. Probamos con diferentes rangos y vimos que, en 3 semanas de trabajo, se puede armar algo lo suficientemente grande como para generarle valor al cliente y solucionar uno o más problemas, y lo suficientemente chico como para poder ver el final parados en el comienzo del ciclo. Atrás quedaron esos ciclos eternos donde el foco se va cambiando todo el tiempo y el final parece alejarse cada vez más.

Inicio de ciclo (aka Kickoff)

En todo equipo va a haber uno o varios integrantes (aka Pitchers) que van a ser los encargados de escribir los requerimientos del ciclo (Pitch).

Los requerimientos deben tratar de ser lo suficientemente claros, por lo que hay que especificar:

• el problema a resolver,
• solución planteada (sin necesidad de ir tan a bajo nivel),
• cosas que podrían entrar pero no son necesarias,
• posibles dependencias y problemas que, a priori, podrían aparecer.

Los Pitchers deben dedicar mucho tiempo de análisis para que no se escape nada. Si no se dedica este tiempo, el deadline va a ser una fecha sin sentido. Además, se deben incluir imágenes, bocetos y videos tratando de que el problema y solución queden lo más claro posible.

¿Cuándo se va a hacer esto? Mientras los equipos están trabajando en un ciclo, los pitchers van a estar analizando el siguiente.

Equipos

El equipo al que aspiramos en cada proyecto es uno heterogéneo:

• un UX o UI,
• uno o más desarrolladores,
• un pitcher
• un QA

Muchas veces, esto no es necesario o no es viable porque el ciclo es muy corto o el cliente es muy pequeño. En esto casos, la composición del equipo variará. Cuando se dan estas situaciones, el ciclo-motor tomará un rol más activo para que no caiga toda la responsabilidad en el desarrollador.

Algo importante: Nunca nadie va a trabajar solo/a.

Deadlines

Al momento de presentar un ciclo, es importante aclarar cuál es el deadline estipulado. Los clientes deben estar al tanto de dicha fecha y de que, mientras estemos transitando un ciclo, todo lo que pidan quedará para después de finalizar el ciclo actual (a excepción de un error grave).

El deadline de cada ciclo tiene que ser inamovible. Lógicamente, pueden surgir cuestiones no tenidas en cuenta durante la planificación que hacen que nos demoremos más pero, en estos casos, se modificará el alcance y se comunicará al cliente la situación.

Esto nos beneficia por 2 motivos:

1. De cara a los clientes: por una cuestión de respeto, debemos entregar el trabajo a los clientes cuando le dijimos que lo iban a tener. Hay clientes muy ansiosos que, si no les entregás algo cuando ellos lo esperan, se ponen un poco intensos. Aunque lo que se entregue es algo con un alcance menor, sirve para calmar las aguas.
2. A nivel interno: para lograr un compromiso de parte del equipo a cargo del módulo y, además, para poder planificar próximas tareas/módulos sabiendo cuándo una persona estará disponible nuevamente.