El pasado 1 de Julio, tras pasar cuatro años como parte de la familia Amazon Business, cambié de organización para empezar una nueva aventura como miembro del equipo de ingeniería de Kindle.
Cambiar de organización a nivel corporativo es algo suficientemente complejo que “casi” equivale a cambiar de empresa, con lo cual había expectativas que fijar, información que transferir, tareas que cerrar y procesos que documentar.
En este artículo veremos algunos elementos a tener en cuenta cuando cambiamos de equipos desde el punto de vista del técnico individual, algunos estos elementos serán aplicables también a cuando cambiamos de empresa.
Expectativas
Lo primero, una vez aclaramos con nuestro jefe de nuestra intención para cambiar de destino, es necesario fijar plazos para cerrar frentes abiertos y proyectos en curso.
Si estamos cambiando de empresa, lo habitual es que tengamos un plazo mínimo de notificación estipulado en el contrato, mientras que si estamos cambiando de equipo podemos ser más flexibles.
En general, basándome en mi experiencia, entre tres semanas y un mes debería ser tiempo suficiente para cerrar frentes abiertos y hacer transferencia de conocimientos, lo que nos lleva a…
Listar frentes abiertos
El siguiente paso es abrir una hoja de Excel, Google Spreadsheets, o un fichero de texto y comenzar a escribir una tabla con la información siguiente para todo lo que tengamos en la cabeza:
- Área (o proyecto)
- Tarea
- Estado a fecha de hoy
- Personas involucradas (aparte de nosotros)
- Fecha tope
- Estará completo antes de que dejemos el equipo?
- Quién se puede hacer cargo cuando no estemos?
- Qué necesitamos para que esté completo?
Aunque tengamos un equipo perfectamente conexionado con todas las tareas en Jira, TFS, GitLab, Github, Trello, etc. siempre habrá tareas que tenemos en la cabeza, ideas y frentes abiertos que no viven en el sistema de gestión de tareas.
Para aquellas tareas que estén asignadas a nosotros en el sistema, podemos repetir el ejercicio documentando el estado actual y el estado esperado cuando ya no estemos.
Es importante dejar a una persona o punto de contacto a cargo de estas tareas, para ello podemos sugerir alguien en nuestro equipo que tenga especial contexto sobre las mismas, de manera que el seguimiento no se interrumpa.
Notificar a personas involucradas
Tras listar los frentes abiertos y detectar las personas involucradas, es importante notificar a otras personas que trabajan con nosotros que no seguiremos en el equipo, especialmente si somos la persona de contacto de una o más iniciativas, y hacer las conexiones necesarias entre otros equipos y los nuevos interlocutores.
De esta manera nos aseguraremos que los proyectos sigan adelante y estableceremos expectativas claras para las personas que están fuera de nuestro equipo aunque colaboren con nosotros.
Documentar progreso
El siguiente paso, una vez aclarado qué vamos a poder poder terminar y qué no, es dedicar tiempo a documentar, especialmente los proyectos que hemos entregado más recientemente y aquellos que se van a mantener en curso cuando no estemos.
Como ejemplo de elementos que podemos documentar, tenemos:
- Decisiones técnicas tomadas y por qué las hemos tomado.
- Puesta en marcha en pruebas y producción de nuestros servicios.
- Detalles sobre scripts y pequeñas automatizaciones que hayamos hecho.
Transferir conocimiento
Además de la documentación, es muy útil tener una o varias sesiones de transferencia de conocimiento con otros miembros del equipo que vayan a heredar nuestras responsabilidades.
Estas sesiones pueden cubrir, entre otros aspectos:
- Visión general de los diferentes servicios que componen nuestro sistema
- Ciclo de vida de peticiones (especialmente útil en una arquitectura de microservicios)
- Tickets cerrados recientemente, especialmente aquellos de alta prioridad, y causas más comunes.
Estas sesiones, además, podemos grabarlas en vídeo de manera que queden como “documentación” para que otros miembros del equipo puedan recurrir a ellas en caso necesario.
Limpiar
Cambiar de equipo suele ser una buena oportunidad para hacer “borrón y cuenta nueva”, así que podemos aprovechar para renovar equipamiento si es posible.
En cualquier caso es una buena oportunidad para hacer copia de seguridad, y borrar repositorios locales de proyectos antiguos, siempre y cuando dejemos copias de nuestras ramas en repositorios remotos.
Re-asignar cuentas, permisos, credenciales, listas de correos…
Dependiendo del grado de automatización que tengamos, nuestro usuario puede ser administrador o dueño de ciertos recursos, por tanto será necesario re-asignar dichos recursos así como rotar claves en caso de que no tengamos un sistema automatizado. En caso contrario se podría perder información cuando nuestra salida se haga efectiva.
Es posible que tengamos acceso a sistemas específicos única y exclusivamente por pertenecer a ciertos equipos, y es importante asegurarnos que este acceso será revocado, ya que puede ser un vector de ataque desde nuestra cuenta del que nos olvidemos en el futuro.
De manera adicional, es importante dejar listas de distribución o canales de slack que dejen de ser relevantes para nosotros, ya que solamente agregaremos ruido y podemos dar la falsa impresión de que seguimos en el equipo.
Seamos accesibles
Incluso tras meses de trasferencia de conocimientos habrá cosas que no seamos capaz de transmitir, o problemas que surjan cuando no estemos, y para ello es importante mantenernos accesibles.
Si seguimos dentro de la empresa, habrá ocasiones en que alguien de nuestro antiguo equipo contactará con nosotros con dudas o preguntas, especialmente en las primeras semanas o meses, y es una oportunidad para seguir ayudando y apoyando al equipo.
Conclusiones
Los cambios siempre traen incertidumbre, cuando nosotros propiciamos un cambio generamos incertidumbre en la gente a nuestro alrededor pero también en nosotros mismos.
Construir un plan de transición nos ayudará a reducir y limitar esta incertidumbre tanto para nosotros como para nuestros compañeros.
Dejando claras las expectativas, los frentes abiertos, habiendo transferido el conocimiento, documentando proyectos, dejando los recursos con sus nuevos dueños y manteniéndonos accesibles, podremos enfrentar los nuevos retos que nos esperan tras cerrar una etapa profesional, hagámoslo bien.
Un comentario en “Offboarding”