El infierno de los tickets
Problema
Si solo tenés un martillo todos los problemas se parecen a un clavo
¿Por qué comienzo con esta conocida frase?, primero quiero dar un poco de historia y luego voy a explicar por qué la menciono.
En los equipos de infraestructura en el cual llevo trabajando y liderando algunos años tuve la gran fortuna de cruzarme con Juanjo. Desde el minuto cero le escuché decir, promover y defender a capa y espada:
- Nunca caigamos en un equipo de infraestructura que trabaje mediante pedidos por tickets
Posicionamiento
¿Cuál es el racional detrás de esta posición firme?
- Se tiene que tener una cultura extremadamente fuerte de punta a punta para poder determinar que ticket es mas importante que otro.
- El equipo de infraestructura inherentemente tiene que crecer si el equipo de tecnología y producto se expande a nuevas funcionalidades.
- Es extremadamente difícil mantener al equipo de infraestructura motivado.
- Es imposible innovar desde el equipo de infraestructura.
Existen varios motivos más, pero en este momento me parecen los mas destacables y avanzo en explicar cada uno de ellos.
1. Cultura extremadamente fuerte
Tanto a los equipos de infraestructura como a los de QA no se los suele involucrar en el armado de roadmap y sprint de tecnología y producto. En caso de que pase, se lo hace al final de la milla “cuando ya todo está cocinado”.
¿A dónde apunto con esto?, que si al responsable de infraestructura le llegan dos tickets y tiene que priorizar por cuestiones de capacidad de ejecución, la pregunta obvia:
¿que ticket priorizo?
Buena suerte cuando estés ahí, porque para los clientes lo de ellos es lo más importante del mundo mundial y es lo más importante por sobre cualquier cosa.
2. Crecimiento sin sentido
Supongamos que el punto anterior esta resuelto, de este punto que voy a explicar a continuación no se zafa.
¿Por qué decimos que el equipo de infraestructura inherentemente tiene que crecer?
Si caemos en tickets que solo resuelve el equipo de infraestructura a más productos y funcionalidades que tenga la empresa más personas se necesitan del equipo de infraestructura para atacar la demanda de tickets.
Felicitaciones, creaste un embudo de ejecución.
¿Solución?, contratar más talento para el equipo de infraestructura.
3. Motivación
Supongamos que el punto 1 y el 2 están resueltos.
¿Los integrantes del equipo de infraestructura son humanos verdad?
Digo esto porque es difícil mantener la motivación si —en un trabajo que es altamente impulsado por la creatividad— acotamos a los integrantes del equipo a “cerrar tickets” sin ningún lugar para la discusión o la doble pregunta.
¿Qué puede pasar?, rotación alta en el equipo de infra y un malestar en los equipos de tecnología que, si son tóxicos, pueden acusar de bloqueantes o mala experiencia en la gestión de infraestructura al equipo de infra.
De esto último ¿qué puede decirte?, Keep Calm y te dejo un gran abrazo.
4. Innovación
Por último si tenemos resueltos los anteriores 3 puntos es imposible innovar, lisa y llanamente.
¿Por qué?, un equipo que trabaja simplemente cerrando tickets, abocado solo a participar en un proyecto creando infraestructura, es imposible que pueda innovar.
Volvamos al inicio
Si solo tenés un martillo todos los problemas se parecen a un clavo
A lo largo de post expliqué el racional y los puntos mas importantes en los que va a impactar una metodología de tickets para gestión de infraestructura.
Y quiero dejar en claro que no está mal trabajar por tickets en un equipo de infraestructura, lo que si está definitivamente mal es que la gestión de infraestructura se haga por tickets.
¿Y qué tiene que ver la frase del martillo?, que se implementó mal una metodología ágil en muchas empresas con los equipos de infraestructura y “debemos parar la pelota” para reflexionar por qué no están funcionando bien las cosas en muchos lugares.
¿Y cómo podemos evitarlo?
Debemos inyectar una mentalidad de producto a los equipos de infraestructura, ofrecer abstracciones con experiencias de primer nivel del caos de la plataforma subyacente para que los equipos de tecnología de producto sean autosuficientes en la gestión del software y la infraestructura asociada.
Espero que mi experiencia te haga repensar como formar cultura y procesos de trabajo para los equipos de infraestructura en la empresa si tenés dudas o necesitas discutir algo de lo que escribí estoy encantado de conocerte :)
¡Hasta pronto! 👋🏽