El jueves pasado fue la última reunión del grupo Meetup Management 3.0 – Peopleware – Agile Management (grupo que, por cierto, cumple ya un año, supongo que ya sabes de qué va, sino leete antes este post Grupo en Madrid sobre Liderazgo Técnico – Management 3.0 – Peopleware).
La charla, muy interesante, y muy bien expuesta, fue impartida por Pedro Sebastián Mingo. Y más allá del propio contenido de la misma, que trataba de las cualificaciones de los tester en un entorno ágil, la charla, más el posterior debate al que conllevó, volvieron a escenificar la situación de indeterminación, crisis de identidad, ser o no ser, que en nuestros tiempos vive uno de los perfiles tecnológicos más emblemáticos: el tester.
Hace ya casi 2 años de aquel post de probable futuro del desarrollo software y consejos para orientar tu profesión, desde mucho antes, en aquel post, y ahora siempre que puedo, no me canso de decir que aquel “viejo” perfil de Tester al que nadie hacía caso, que estaba porque no se podía ir a los clientes diciendo que “no teníamos testing”, que se pasaba el día haciendo papeles, casos de prueba, que nunca se llegaban a pasar, que en la mayoría de las ocasiones no tenía ninguna cualificación técnica, aquellos tiempos en se buscaba la fuerza bruta más que la inteligencia y la técnica, aquel testing… se acabó, es pasado. Y quien continue hoy en ese testing… es porque también es pasado.
Tampoco es que yo sea un visionario, ni mucho menos, es que es de perogrullo, vamos, que lo ve hasta un gato de yeso. Si la agilidad ha llegado a muchas empresas por la necesidad que se ha creado en su negocio de entregar más y más rápido valor, de manera fiable, en forma de software, a sus clientes, si eso lleva a cuestionarse todo lo que sea un freno para ello, como las relaciones con operaciones, en referencia a pasos a producción, hablo de DevOps, y si testing está en medio de todo como garante de que no se pasan “bombas nucleares” en forma de código y aplicaciones basura… estaba claro que el cambio del Testing, y los tester, tenía que acabar llegando a las empresas, y que aquellas cosas de cómo hacer bien y buen software, y las pruebas, que se llevaban diciendo desde hace muchos años (acuérdate de aquello de “Utilizamos la novedosa técnica de TDD”… ¿Cómo? ¿Novedosa? ¿Seguro?)… acabarían llegando.
Claro que todo cambio llega con dolor para algunos, miedos, inseguridades, rechazos y crisis de identidad. Aunque estos nuevos tiempos hayan traído aire fresco a una de las profesiones clave en tecnología, la están saneando, devolviéndole su pureza, en el nuevo reparto de “cartas”, hay quienes no saben dónde está su lugar.
Es por ello que si en estos tiempo asistes a un debate sobre Testing, verás como la mayoría de las inquietudes giran entorno a cómo encajar los nuevos tiempos en los viejos esquemas, escucharas cosas como…
-Pero, en esta nueva manera de trabajar… ¿El tester está dentro del equipo de desarrollo o está fuera? Porqué nosotros es que trabajamos con una fábrica de testing, caja negra, no sabemos ni quien prueba.
-Pero, en esta nueva manera de trabajar… ¿El tester es un desarrollador, con conocimientos técnicos, pero que prueba o no debe saber de desarrollo? Porqué nosotros es que tenemos tester funcionales que no saben nada de tecnología.
-Pero, en esta nueva manera de trabajar… ¿el operaciones es el que hace las pruebas de carga? ¿Quién hace pruebas de carga? ¿El tester funcional? Uff.
Quizá deberíamos ya empezar a romper con el pasado, quizá así nos sería más fácil entenderlo, ver la foto global, quizá así sea más fácil que intentar estar encajonando el futuro, digo el presente, en nuestros esquemas del pasado, con sus roles, estructuras empresariales y formativas.
Y démonos prisa, porque ahí fuera hay otros que ni se plantean tales cuestiones, quizá nunca conocieron esa antigua manera de trabajar, y que mientras pensamos en cómo meter el presente en el pasado ellos están sacando cada día, a toda velocidad, valor en forma de software a los que aún son tus clientes.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Te leo porque tu blog es de esas pocas cosas que hacen que no me corte las venas por haberme metido en esta profesión. Y digo esto en un momento de inflexión en el que sé que a este mercado laboral en nuestro país no quiero volver…
Penas aparte. Para mí la única forma de construir un equipo ágil es asimilarlo a los equipos de alto rendimiento. El problema está en cómo construyes ese equipo con mil «empleados de gerencia» entre los que incluyo a los jefes de proyecto que ejercen de figura florero, que cobran una pasta por hacerte trabajar prácticamente de autónomo pagándote menos que a un empleado de supermercado (así está el patio) y que en vez de agradecerte la labor, aunque sea con un trato de respeto, que lo que nuestras cabezas sacan no lo sacan las suyas ni comprándose una nueva, te lo pagan con gritos y hasta insultos (verídico).
El símil más parecido al de nuestra profesión aquí es la relación entre el matón de escuela y el empoyón. Está profesión se ha convertido en un aparentar que uno sabe algo y al que sabe le tienen de esclavo y le echan las culpas de todo, incluso con ataques de índole personal. De vergüenza es poco.
Y sí, un tester funcional no tiene por qué ser, y me atrevo a decir que no debería ser, un perfil técnico sino, como su nombre indica, un perfil funcional. Un tester con perfil técnico tiene que hacer pruebas de rendimiento.
Cómo metes a un tester en un equipo ágil? Pues igual que metes a un desarrollador o a un analista. Si de lo que se debería tratar es de hacer el trabajo y terminarlo bien y a tiempo.
Llevas al analista funcional y a un arquitecto al cliente, qué es lo que quiere hacer el cliente y de qué infraestructura disponen? Qué presupuesto tienen? Porque lo mismo quieren un viaje a la luna y solo pueden pagar un bono de ave.
La otra pregunta es, somos nosotros capaces de cubrir sus necesidades? Porque si he detectado que no, eso de externalizar está muy bien, pero si ese proveedor tuyo es ad hoc, amigo mío, puedes estar cruzando la fina línea de estafar a tu cliente.
Una vez que tenemos claro el proyecto de partida empezamos a trabajar agilmente: analistas, desarrolladores y testers. Y pasa en la propuesta el precio de los cambios de última hora, que ninguno comemos del aire.
Problema para el cambio? Ni hay gente preparada, ni los que están preparados regalan un trabajo de calidad, ni los que estamos en la senda de querer pertenecer al grupo anterior estamos por la labor de aguantar insultos de quien cobra su sueldo y parte del que nos corresponde a nosotros.
Conclusión? Apaga y vámonos a la vendimia francesa porque el panorama que nos han dejado está para mear y no echar gota.
Y yo que no vine a la profesión a hacerme de oro, sino a vivir dignamente de hacer lo que me gusta…
Lo dicho. Un placer leerte. Oasis en el desierto vamos.
Ánimo eh 🙂 y gracias!
Gracias las que hay que darte por defender la profesión y luchar por ella. Yo definitivamente hago lo que un colega tuyo que comentaste: lo dejo. De cualquier forma se te seguirá leyendo, que es interesante lo que cuentas y esa forma de trabajar que vas describiendo (en mi humilde opinión, muy bien, poco a poco, ni profundo ni somero y dando en el clavo de muchos problemas sin ofender ni imponer, ilustrando para el que quiera entender, muy pedagógico).
Si admites despojados y públicas fechas… Tendremos que colarnos en alguna conferencia.
Ánimo y gracias 😉
Yo no tengo problemas de identidad, soy un Tester Funcional. Ahora bien, si los gerentes, no saben en dónde ubicarme, entonces el problema de identidad lo tienen ellos, que no saben cómo encarar un proyecto y qué tipo de tester poner en el proyecto.
Con respecto al sueldo, no sé por qué un Tester Técnico (tareas de automatización y performance), está mejor pago que un Tester Funcional (esto pasa en Argentina que es donde vivo). Me llegan propuestas, les digo una pretensión salarial, y me dice que lo que pretendo es para un Técnico, que el Funcional tienen un rango inferior para pagar. No entiendo. Cuando leo las stories hago mucho análisis funcional. Muchas veces el tester técnico desarrolla algo sin pensar en la parte funcional. Cuando se implementa, no es lo pedido por el cliente.
No se puede automatizar todo, por una simple razón: somos humanos, no siempre hacemos las mismas cosas.
Saludos!!!!