Tiempo de lectura: 5 minutos

Llevo más de 15 años en el mundo del desarrollo de software, esto me ha permitido compartir experiencias en varios equipos y con cada salto aprendo algo del proceso de adaptación, aquí os relataré algunos trucos para mejorar al máximo vuestra entrada. 

Por mucho que os parezca extraño, nuestros primeros pasos no serán con objetivos técnicos, sino mucho más humanos. 

El mejor enfoque en todo este proceso es que, al principio, escuchemos mucho y mejor opinemos poco de entrada ya que nos faltará aún mucho contexto sobre las decisiones tomadas anteriormente. Podemos apuntar todos los puntos de mejora que veamos de manera constructiva, podemos sugerir poco a poco y ver la reacción, y luego iterar como mejora continua. Además, podemos ayudar a documentar y/o a revisar la documentación que tenga el equipo.

El proceso consta de 6 partes: empezaremos con una presentación; luego, en paralelo, por un lado debemos hacer un pequeño discovery del estado del equipo (producto, dinámicas y tecnología) y al mismo tiempo tenemos que alinear expectativas con cada una de ellas. Una vez estemos listas, será el momento de tocar código.

 

Una presentación honesta y transparente. Aunque os conozcan, puede que no hayan interactuado nunca tanto con vosotras cómo va a ser a partir de ahora. Por ejemplo: 

Hola, soy Ramon, me considero muy directo, transparente, me define muy bien mi DISC: Rojo: impaciente, enfocado a resultados. Lo que menos me gusta es estar en una reunión a la que no puedo aportar o que me parezca que no aporta a la corporación como, por ejemplo, una reunión sin un objetivo claro o outcome esperado. Amarillo: No me gustan nada las rutinas y me cuesta acabar las cosas. En cambio, mi verde y azul están muy bajos: me importan poco los procesos y me cuesta mucho la escucha activa (algo en lo que trabajo para mejorar).A todo esto, me gusta recibir feedback y mejorar constantemente. Me gusta que, cuando piensan en mí, vean reflejada la imágen de un buen profesional, alguien con mucha energía y ganas de ayudar.

A todo esto, me gusta recibir feedback y mejorar constantemente. Me gusta que, cuando piensan en mí, vean reflejada la imágen de un buen profesional, alguien con mucha energía y ganas de ayudar.

Para hacer algo así necesitas conocerte muy bien y ayudará mucho a vuestro equipo para que empatice con vosotros. Será genial si el equipo hace lo mismo y se presenta de la misma forma. Os puede ayudar usar herramientas como el DISC o Eneatipos para buscar adjetivos en los que os veáis reflejados.

El siguiente paso será conocer el producto que existe alrededor del equipo. Aquí tendrá un gran papel la persona que tenga el rol de producto. Algunas preguntas que os pueden funcionar son:

• ¿Cuál es el cliente que usa el producto? ¿Interno o externo?
• ¿Qué pasaría en la empresa si no existiera este equipo? 
• ¿Qué objetivos hay a medio/largo plazo?
• ¿Cómo recibimos feedback del cliente?
• ¿Cuál es el “dolor” del cliente?
• ¿Qué componentes definen el producto? ¿Qué intentan mitigar?
• ¿Cuál es la visión del producto?
• ¿Quiénes son los stakeholders?
• ¿Cómo son nuestras US? ¿Tenemos DoD, DoR?
• ¿Cómo puntuamos las US?¿Hay alguna plantilla?
• ¿Cuál es el roadmap del producto?
• ¿Cómo ve el área de negocio el producto?

Tendremos más información del contexto del equipo entendiendo más sus expectativas y necesidades del producto.

Ahora nos podemos interesar más por los rituales o dinámicas que tenga el equipo: dailies, weeklies, retros…  De esta manera tendremos una idea general de todos aquellos momentos que comparte el equipo. Podemos preguntar sobre cada sesión: 

• ¿Usamos algún framework agile? ¿Scrum o Kanban?
• ¿Qué propósito tiene?
• ¿Qué roles colaboran?
• ¿Son periódicas o bajo demanda?
• ¿Cómo es la dinámica? 
• ¿De qué partes se compone?
• ¿Usamos algún patrón de toma de decisiones?
• ¿Quién la lidera?

Llegamos a lo que a todas las personas que trabajan en tecnología nos encanta: la tecnología. Para hacer un discovery inicial de la tecnología podemos usar herramientas que otras personas han creado y sabemos que funcionan. En este caso os puedo recomendar el Software Delivery Assessment de ClonfluxDigital que permite tener una visión general de varios puntos que conciernen al equipo. Puede que lleguéis a un equipo que haya hecho en el pasado algo similar, usémoslo para entender en qué estado está el equipo. Os puedo recomendar que os centréis en entender todo a alto nivel, pues intentar abarcarlo todo de golpe puede crear frustración y ser muy complejo para vuestro equipo.

Para complementar todo lo anterior, podéis preguntar:

• ¿Cuál es el ciclo de vida del código?
• ¿Qué entornos tenemos y qué utilidad tenemos?
• ¿Qué tests hacemos (nombre) y qué componentes incluyen?
• ¿Hay alguna guía de programación, de estilo o de diseño?
• ¿Qué lenguajes, frameworks y third parties importantes usamos?
• ¿Tenemos CI/CD?
• ¿Cómo desplegamos las aplicaciones?
• ¿Hay infraestructura como código?
• ¿Existe backlog de mejora tecnológica?
• ¿Tenemos ADRs?

Recordad que tenemos que alinear expectativas durante todo el proceso. Podemos revisar cómo funciona el equipo, cómo interacciona, qué retos tiene encima de la mesa y qué energía tiene. A su vez, tendremos que  saber cómo podemos impactar nosotras. De esta manera, conoceremos mucho mejor cuáles son las necesidades del equipo (tanto de producto como tecnológicas) y qué esperan que hagamos nosotras. Evitaremos así sorpresas a futuro del estilo: «Yo esperaba hacer bla, bla…». Para ello, es útil preguntar, por ejemplo: «¿Cómo creéis que os puedo ayudar?» o «¿Qué creéis que puedo mejorar?».

Ahora toca picar código, el momento esperado. Técnicas como el Pair Programming o el Mob Programming  y entrando nosotras en la dinámica con el rol de driver, pueden ayudarnos a obtener más contexto. Durante todo el proceso de entrada en el equipo con el código, será mejor que no juzguemos el mismo ni las decisiones tecnológicas de entrada, sino que, como decíamos, es mejor antes preguntar, ya que seguro que eso está de esa manera por algún motivo. Para dar un feedback a tus compañeras puedes preguntarte cosas como:

• ¿Qué parte del código te cuesta más entender?
• ¿Cómo de “doloroso” es ejecutar un proyecto en máquina local? ¿Y los tests?
• ¿Cómo de difícil es acceder a los diferentes entornos del equipo?
• ¿Cómo de difícil es entender el pipeline del CI?
• ¿Cómo de “doloroso” es tu primer deploy?

Por otro lado, recordad que las decisiones tecnológicas que ha tomado el equipo anteriormente son bajo el conocimiento de ese momento y dentro de un contexto puntual, o sea que puede que ahora no tengan sentido pero siguen siendo válidas.

…

Durante todo el proceso seguramente estaremos viendo puntos de mejora, por lo que os recomiendo que preguntéis antes de compartirlo. Seamos empáticos y altamente constructivos. Así, en vez de decir “Esto está mal…” o “Yo lo haría…”, sería más adecuado decir algo como “Podemos revisar este punto, posiblemente encontremos una mejora…”. Recordad que ese equipo posiblemente tenga un backlog de trabajo y puede que no se pueda absorber todo de golpe.

Cómo veis, el proceso de entrada en un equipo está lleno de preguntas. A partir de aquí intentaremos hacer 1on1, si no lo hemos hecho ya con todas las personas del equipo, para entender más sus necesidades y ver qué podemos aportar a cada persona de una manera diferente.

De aquí en adelante, la evolución en el equipo y la colaboración con nosotras debería producirse con ciclos de mejora continua, usando sesiones de feedback, espacios para reflexionar y revisitando esas expectativas.