Kill switches, rollback y hotfix en un rebrand como interim EM

Contexto

La empresa renovaba su marca y las apps tenían que estar a la altura. Un rebrand en una app no es cambiar el logo. Es tocar prácticamente todas las pantallas, en Android, en iOS y en las partes de React Native, con varios equipos entregando a la vez. Las apps habían estado un buen tiempo sin publicar mientras se construía todo, así que el lanzamiento tenía mucho acumulado.

En medio de eso, me tocó hacer de manager del equipo de experiencia de apps de forma interina, mientras seguía con mi trabajo técnico.

Problema

Dos problemas encadenados.

El primero era técnico. ¿Cómo sacás a producción una versión nueva de todo, sin red, para una app que ya usa mucha gente? Si algo sale mal, ¿volvés atrás? ¿Cómo?

El segundo era humano, un equipo con presión, con un backlog desordenado en Kanban y un calendario que no perdonaba.

Qué decidimos (y qué descartamos)

Decidimos lanzar primero una beta, a una porción controlada de usuarios, con la puerta de atrás abierta. Eran tres piezas, la estrategia de rollout, kill switches para apagar funcionalidad sin publicar, y un camino claro de rollback a la versión anterior.

Descartamos el lanzamiento “big bang”, el de una sola fecha, todos los usuarios y a ver qué pasa. También descartamos improvisar los hotfixes. Un hotfix es el peor momento para decidir cómo se hace un hotfix.

En lo humano, descartamos seguir con un Kanban suelto. Pasamos a Scrum.

Cómo lo hicimos

1. Escribimos el proceso antes de lanzar. Quién avisa a quién, cómo se corta la rama de la release candidate, qué entra después del code freeze y qué no, con qué justificación y con qué evidencia de estabilidad. Los cambios posteriores al freeze necesitaban un motivo y una aprobación.
2. Playbooks de hotfix y de rollback. Cómo se nombra la rama, cómo se publica, cómo se sincroniza de vuelta con main, y cómo se vuelve a la versión legacy en cada plataforma.
3. Kill switches. Para apagar una funcionalidad sin pasar por las tiendas. También probamos un aviso suave de actualización. Ayudó menos de lo que esperábamos, y esa es una buena noticia porque nos enseñó que los switches sirven para contener, no para forzar.
4. Tracking del rebrand. Una estrategia común de seguimiento para Android, iOS, React Native y checkout, y paneles para validar la app nueva. Esto fue clave para monitorear el lanzamiento con datos y no con intuiciones.
5. Equipo. Sprints cortos, planning, dailies y retros. Un tablero que se pueda leer. Hablar con los equipos y los stakeholders para alinear prioridades y desbloquear lo que estuviera trabado fuera del equipo.

Resultado

La beta salió en las dos plataformas. Cuando algo no estaba listo, la decisión de qué hacer ya estaba tomada, porque se había discutido en frío. Eso fue lo que más valor tuvo. Los equipos podían validar la app nueva con datos, y el seguimiento de las semanas siguientes fue ordenado, no heroico.

El equipo salió con un proceso mejor del que entró. Y yo salí con un respeto enorme por quien hace de manager todos los días.

Qué haría distinto

Empezaría a hablar de rollback desde la primera reunión de planificación, no cuando la fecha ya estaba cerca. Con un equipo agotado, “qué hacemos si sale mal” suena a pesimismo, y es lo más optimista que podés hacer.

Y protegería más mi propio tiempo técnico. Hacer de manager “interino” suena a favor temporal. Pero la gestión no es un extra de las tardes. Es otro trabajo.