Etiqueta: organización

Offboarding

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.

Cómo organizamos eventos en UAM.net, en 10 pasos

La experiencia de coordinador del dotnetclub y presidente de la asociación me ha permitido organizar un número ya considerable de charlas técnicas y eventos, y, tras casi 3 años al frente del club, van surgiendo ciertas consideraciones que, pese a no ser reglas de oro han ido funcionando.

1. Busca un buen equipo

La más importante de todas las que verás por aquí. Esto no se consigue en solitario ni de lejos, necesitas a gente que ayude, colabore y aporte ideas a las actividades, gente motivada y que se deje motivar, independientemente del tema de la charla. Estamos aquí todos para aprender, no lo olvides nunca, y de este trabajo en equipo, se aprende mucho.

2. Escoge un tema

Aunque pueda parecer trivial, la elección de un tema depende mucho del público, pero más aún de la época en la que estés. Si eres de una asociación de nueva creación, creo que puedes dejar la charla de Sharepoint para más adelante y empezar con algo más divertido como Robotics o Kinect.

3. El horario, ese gran desconocido

Asúmelo, alguien se va a quejar, y alguien no va a poder venir a la charla por la elección de la hora, eso siempre va a pasar. El problema es que cuando estás en una facultad (como nos pasa a nosotros) con 4 cursos diferentes de 2 planes de estudios, es muy difícil encontrar horarios que convenzan a todo el mundo. Prueba horarios diferentes, pivota, y sobre todo, pide feedback del público.

4. Cuidado con las fechas

La elección de una fecha es casi tan complicada como la de el tema en cuestión, ya que depende de: exámenes, entregas de prácticas, vacaciones, puentes, ganas de los alumnos… los mejores tiempos suelen ser justo después de una temporada cargada (fin de parciales o de finales de febrero, justo a la vuelta de semana santa, etc…). Otra cosa importante es intentar espaciar los eventos, es mejor tener un evento al mes durante 3 meses que tener 3 eventos en 1 mes y luego desaparecer.

5. Burocracia, ese proceso

Dependiendo de la universidad (y del estado de la asociación), para poder realizar una actividad necesitas autorización de junta de centro, delegación de alumnos, o similar. La solicitud de dicha autorización suele ir acompañada de una descripción (breve) de la charla que se va a impartir, información sobre el ponente y la persona responsable, así como la fecha y la hora. Esto puede tardar, así que hazlo lo antes posible.

6. Promoción, promoción, promoción

Una vez has pasado el «escollo» burocrático, es hora de empezar a promocionar la charla por tu cuenta, para conseguir que la gente se entere de la misma:

  • Si conoces alguien que sepa diseño gráfico, mételo en tu equipo!, e intenta conseguir que te haga un cartel para el evento.
  • Imprime los carteles y pégalos donde te dejen donde puedas.
  • Si tu facultad tiene lista de correo interna, úsala.
  • Crea/usa las cuentas de twitter, facebook, tuenti, la web de tu club, todo lo que tengas al alcance. Piensa que esta promoción es gratis.
  • Si conoces a profesores, intenta conseguir que se impliquen en la charla, que hablen de ella a los alumnos o incluso que vengan.
  • Promociona la charla por clases y laboratorios.

Poco a poco comenzarás a ver que el tiempo que le dediques a la promoción será menor conforme avanza el curso, porque los interesados seguirán viniendo a las charlas, aunque es importante que, al menos para los primeros eventos, la gente se entere.

7. El ponente

Lo normal cuando se empieza en un dotnetclub, es no saber nada de nada. Por suerte, la infraestructura nacional permite ponerse en contacto con alumnos de otras universidades, que vengan a contar sus experiencias, o con profesionales miembros del programa MVP, a los que puedes recurrir si necesitas que alguien que sabe mucho te cuente algo de un tema. Son gente muy cercana que están al alcance de un tweet.

Poco a poco y ganando algo de experiencia podrás empezar a dar charlas con el equipo interno, y entonces será mucho más divertido, pero es importante saber que podemos recurrir a compañeros de otras universidades o profesionales.

No está de más decir que es necesario mimar cuidar al ponente (botellín de agua mínimo) aunque sea compañero de la facultad, ten en cuenta que viene gratis ;) .

8. La hora de empezar

He de reconocer que en esta soy aún muy malo, pero siempre es importante presentar al ponente (tú eres una cara más o menos conocida, y puede que para el ponente sea su primera vez en tu facultad), presentarte y presentar a la asociación, ya que quieres que haya cierta continuidad tras el evento, que la gente se quede con vuestros nombres, y donde os puede localizar.

9. Durante la charla

En la charla el importante es el que la da, pero también es importante que el público se entere, se ve bien al final? se oye correctamente? la gente se está aburriendo?. También es importante anotar cuanta gente viene, de cara a estadísticas. Si tienes twitter, intenta comentar los puntos más importantes de la charla, ya que ayudará a que los que no han podido venir puedan tener algo de información del evento..

10. Reflexiones finales y estadísticas

Al finalizar la charla no olvides volver a agradecer la asistencia y tener en cuenta los comentarios que puedan surgir de los asistentes, si tienes previsto otra charla más adelante, es el mejor momento para promocionarla.

Además, puedes imprimir encuestas (que puedes hacer con cualquier editor de texto) para saber qué impacto ha tenido la charla de verdad, y contar con la opinión de la gente sobre la misma, tanto en aspectos técnicos como organizativos.

Conclusiones

Organizar eventos (aunque solamente sean de 1h) no es sencillo, pero es gratamente reconfortante cuando le sirve al menos a 1 sola persona (que puedes ser tú, por la experiencia de organizarlo). Si tienes más trucos o temas a tener en cuenta déjame un comentario.

Dedicado a Nacho, Moya y Carlos, por dejarse liar al principio de los tiempos, y a Álvaro, Jorge, Javi, Cris, Marina… por unirse a la fiesta ;)