Un elefante se come bocado a bocado

O cómo desarrollar software en arquitecturas complejas.

En Despegar tenemos hace muchos años una arquitectura de microservicios que con el tiempo fue evolucionando hasta llegar a varios cientos de aplicaciones. Sin extendernos demasiado, porque haría perder el foco de este tema, la gran ventaja que nos dio fue la de escalar en tamaño del equipo, permitiendo que haya muchas manos trabajando en diferentes aspectos del mismo problema y aumentar nuestro poder de fuego para dar respuesta a los requerimientos de un negocio tan exigente como es el turismo.

La otra cara de esta moneda, es que muchas veces este tipo de arquitecturas presentan problemas de management, involucrando una coordinación no trivial cross a todo el stack, barriendo varios equipos y gerencias, con diferentes realidades y prioridades.

A lo largo de los años es una tarea que hemos repetido innumerables veces, por lo que creo interesante contar algunos tips, y lecciones aprendidas producto de estas experiencias.

Kickoff

Es clave poner a todos en la misma página, contar el objetivo que queremos conseguir con este desarrollo, entender prioridades, deadlines, levantar warnings que haya que considerar.

En mi experiencia no hay una forma mejor que otra, todo depende del tamaño y relevancia del proyecto. En proyectos muy grandes lo que más me ha funcionado es una reunión corta, y una minuta por mail que se pueda compartir con personas que no asistieron. Lo importante es que exista esta instancia.

Focal points

¿Y quiénes deberían participar del kickoff?

Algo que nos ha dado muy buen resultado es que siempre haya alguien del lado del equipo de tecnología como responsable del proyecto. Dentro de sus responsabilidades está la de contactarse previamente con todas las áreas/gerencias/grupos de personas que considere que van a participar de forma activa en el proyecto y pedir que haya a su vez un responsable de ese sector que sirva como punto focal.

El objetivo es sencillo, trabajar de esta forma logra que quien está a cargo del proyecto no tenga que lidiar con las particularidades arquitecturales de cada área, ni contactar uno a uno a los equipos dueños de cada aplicación donde será necesario un desarrollo.

Las personas designadas como puntos focales, tienen la responsabilidad de llevar el management del proyecto en su sector particular, coordinando hacia adentro e interfaceando hacia afuera en pos de que el proyecto se desarrolle con normalidad.

Como punto adicional del que espero podamos hablar otro día, el rol de focal point es una gran oportunidad para crecer, aprender, desafiar y permitir que se expongan personas con menor seniority.

Algo interesante es que si recurrentemente los mismos equipos son aquellos que nos olvidamos de incluir o entran tarde al proyecto, podríamos estar escondiendo un problema de arquitectura y deberíamos preguntarnos si nos parece bien que esos proyectos los afecten y de qué forma lo hacen.

No empieces algo que no sepas cómo terminar

Es un error que he visto más de lo que me gustaría, que nos lancemos a construir software, por largos periodos de tiempo, con un gran esfuerzo de parte de los equipos, y que una vez concluida esta tarea nos encontremos en una situación en la cual no sabemos cómo seguir, o no consideramos aspectos completamente críticos en el proceso de desarrollo como ser la etapa de testing y el proceso de rollout.

Como ingenieros, una parte importante de nuestro trabajo es intentar minimizar los saltos de fe. Aquellos momentos donde tomamos un riesgo de que algo salga mal y genere un problema para nuestros equipos y la compañía.

Algunas preguntas que deberíamos hacernos de forma temprana:

• ¿Cómo voy a probar la solución de punta a punta?
• ¿Necesito un ambiente especial para realizar las pruebas?
• ¿Tengo que probar en producción? ¿Puedo hacerlo sin abrir el desarrollo a usuarios finales?
• ¿Cómo será el proceso de rollout?
• ¿Tengo forma de exponer solo un grupo limitado de usuarios o escenarios a mi nueva funcionalidad y liberarla de forma paulatina?
• ¿Cómo va a ser el orden de subida de las diferentes aplicaciones involucradas?
• ¿Cuál va a ser la aplicación encargada de prender la funcionalidad? ¿Cómo lo va a hacer? Con un deploy, con configuración, etc.
• En caso de tener que hacer rollback (¡esperemos que no!), ¿qué problemas puedo tener? ¿Qué tan costoso puede ser ir y volver?
• ¿Qué quiero medir? ¿Tengo cómo y dónde hacerlo? ¿Quién va a ser responsable por el monitoreo? Ya sea a nivel salud de la app o métricas de negocio.

Dar visibilidad, siempre

En este tipo de proyectos grandes, es fácil perder la noción de los tiempos y el avance.

Lo que a mí me ha dado buen resultado es poner checkpoints periódicos, ser claros con objetivos y expectativas y ante la primera señal de un desvío poner a toda parte interesada en el proyecto al tanto, y dar las explicaciones correspondientes.

No olvidarse nunca, como ya hemos hablado, que nosotros trabajamos con mejores estimaciones posibles y que es natural y aceptable que no sean 100% precisas. Lo que no es aceptable es no dar visibilidad temprana y explicar los motivos de los cambios de fechas. Una vez más: Ningún proyecto se atrasa un mes el último día.

Colaboración, trabajo en equipo

Es imposible llevar un proyecto de un tamaño relativamente grande sin acompañamiento. Es importante apelar al trabajo en equipo y a la responsabilidad de las personas que llevan adelante cada parte del proyecto. En este sentido, el rol del manager es ser un facilitador, aceitar las comunicaciones entre partes, llevar visibilidad sobre el resto del proyecto a cada equipo involucrado y tener siempre presente la big picture. Puede ser útil generar un grupo de “mesa chica” del proyecto, donde estén no más de 4 personas clave, con comunicación diaria para levantar y solucionar problemas que puedan aparecer.

¿Cómo sabemos si el proyecto funcionó como esperábamos o no?

Si bien es una pregunta que podría tornarse filosófica, es tan sencilla como entender cuáles son los indicadores que queremos mover con este desarrollo (ya sean técnicos o de negocio), qué es lo que le vamos a pedir al proyecto una vez esté en producción y teniendo eso claro, pensar cómo lo vamos a medir, dónde, quién será el responsable, y si contamos con las herramientas correspondientes para hacerlo o tenemos que desarrollarlas.

Así como no pensar en el testing y rollout; no puedo ni recordar la cantidad de proyectos que he visto subir a producción sin tener esto en claro. Las consecuencias de no realizar estos planteos en una etapa temprana son pérdida de tiempo, no saber cómo iterar una historia y sobre todo no poder capitalizar el costo del proyecto, no poder explicar cuánto valor hemos generado, o realmente tener que convivir con la incertidumbre de si lo que hemos desarrollado hizo que las cosas funcionaran mejor o peor.

Aprender, aprender, aprender

Una vez que podemos dar el proyecto, o por lo menos una etapa importante del mismo, por concluído, tenemos que aprovechar para capitalizar todo lo que aprendimos y llevarlo a algo concreto. Para esto las mejores herramientas que he tenido vienen en forma de retro / postmortem. Es muy fácil skipear esta etapa y no ver el valor, que seguramente no se dará en el corto plazo, pero probablemente ayude al círculo virtuoso de que los proyectos salgan cada vez mejor.

Los proyectos pueden ser exitosos o no a nivel negocio; lo que no podemos permitir es no aprender y extender ese conocimiento para ser aplicado en los próximos.

Conclusión

Llevar adelante un proyecto de gran tamaño en un contexto con tantas aplicaciones y equipos no es rocket science, sin embargo hay que tener varias cosas en cuenta. Dejar de lado cualquiera de estos aspectos, probablemente ocasionará dolores de cabeza y una experiencia no del todo feliz para quienes llevan adelante el proyecto, para quienes esperan sus resultados, y sobre todo para la organización.

Se me ocurren varias frases para representar lo que escribí en este post, pero hay una en particular que habla de nuestro rol de ingenieros y de ponerle cabeza a las cosas. No importa que después salgan bien o mal, lo importante es que tomemos las decisiones y no nos movamos por inercia, o dejándolas libradas al azar. Planificar lo que queremos que pase y los escenarios de contingencia es algo clave.

A goal without a plan, is just a wish