Entrevistamos a Manuel de la Peña, QA Team Lead en Liferay Cloud y organizador de los meetups del GDG Toledo.

Con Manuel tratamos algunos aspectos del Producto Digital desde la perspectiva más técnica.

Entrevista a Manuel de la Peña de Liferay

Cuéntanos sobre tu experiencia laboral

Actualmente soy el Team Lead de Quality Assurance en Liferay Cloud, la división cloud de Liferay Inc, una empresa norteamericana con sede en Los Ángeles para la que trabajo desde hace 7 años y medio. En este empresa desarrollamos varios productos desde el ámbito Open Source, ofreciendo servicios profesionales sobre tales productos. Mis responsabilidades actualmente consisten en verificar que el proceso para el desarrollo del software que hacemos en esta división dispone de la mayor calidad posible, tanto a nivel de producto, como a nivel de proceso para construir el producto, y para ello me baso en la definición de métricas de aceptación con los diferentes equipos, por las cuales ellos definen qué es suficientemente bueno para entregar. Para verificar dichas métricas de una manera rápida y eficaz, hacemos uso extensivo de automatización de tareas, como por ejemplo la ejecución de pruebas del código, integración continua del mismo, y despliegue continuo de los artefactos generados en entornos internos de verificación, de modo que los diferentes equipos pueden consultar los estados mediantes dashboards específicos para cada tipo de verificación.

Desde el 2011, año en que me incorporé a Liferay Inc, he participado del desarrollo del producto Liferay Portal, realizando desarrollo de nuevas funcionalidades, así como corrección de errores en el producto, escritura de pruebas unitarias y de integración para el mismo, y creación de herramientas de apoyo a los equipos para mejorar su productividad.

Anteriormente a Liferay Inc, he compaginado mi vida profesional como asalariado con mi vida como freelance. Por un lado trabajando 4 años como consultor, para Indra y VASS, moviéndome por diferentes proyectos y clientes, siempre realizando labores de desarrollador de aplicaciones web, con el lenguaje Java como referencia, y por el otro, el de freelance, desarrollando pequeñas aplicaciones en la zona de Toledo, donde vivo, páginas web, y mantenimientos de redes informáticas y sistemas.

Antes de la consultoría aprobé una plaza de personal laboral en una entidad de derecho público de la Junta de Castilla-La Mancha como administrativo de informática, en la que estoy en excedencia desde 2007, realizando tareas de mantenimiento informática, soporte a usuarios y desarrollo de aplicaciones de gestión corporativas.

¿Cómo fue tu primera toma de contacto con un producto digital?

Pues a pesar de haber trabajado en el pasado con productos destinados a la creación de sitios web, como Wordpress o Joomla, no he sido consciente de todo lo que conlleva la definición de producto digital hasta no haber trabajado en Liferay Inc, donde nuestros productos tienen un impacto muy considerable tanto en el mundo empresarial como en el mundo open source.

El hecho de desarrollar un producto me hizo ver que whatsapp, facebook, spotify etc. no son apps que te instalas y simplemente envías un mensaje, haces un like o le das al play, es mucho más. Hay equipos detrás desarrollando funcionalidades, otros equipos resolviendo problemas a usuarios, otros equipos haciendo márketing…

En definitiva, creo que el ser parte creadora y no consumidora (en exclusiva) me hizo ver lo que es un producto digital, más tarde de lo esperado.

¿Qué es para ti un producto digital?

Relacionado con lo anterior, respecto a la parte empresarial del producto, ha sido muy importante para mí entender cómo los clientes usan tu producto, qué experiencias (positivas, negativas, neutras) tienen con él, qué echan de menos en la funcionalidad, qué les gusta, etc.

He de decir que trabajé durante un tiempo en el equipo de soporte de Liferay Inc, y es ahí donde de verdad te das cuenta de por lo que pasa un cliente al usar tu producto. Por ello, para mí, un producto digital es aquél que resuelve problemas reales de clientes por medio de la tecnología.

¿Cuál es el principal error que cometen las empresas a la hora de diseñar un producto digital?

Hoy día veo tres fuentes de problemas principales:

  1. No pensar en el cliente
  2. No utilizar los datos
  3. Reinventar la rueda.

Si no piensas en el cliente, en sus necesidades, en sus problemas (los cuales quieres resolver) el producto que hagas puede estar muy bien, pero si al cliente al que está destinado no le resuelve un problema que tiene difícilmente te lo va a comprar.

En cuanto a los datos, es vital medir. Se dice eso de que “no puedes mejorar lo que no puedes medir” y es totalmente cierto. Toma métricas de lo que consideres importante, síguelas e intenta realizar acciones correctivas, y utiliza esos datos para crear feedback. Y si lo haces de una manera desatendida, ya tienes mucho trabajo hecho.

Y respecto a la reinvención de la rueda, el hecho de construir sobre librerías/frameworks o proyectos que funcionan te permite ir mucho más rápido sin reinventar la rueda, lo cual te hace perder el tiempo al principio, cuando quieres salir rápido al mercado.

¿Que crees que se necesitaría en España para que se convirtiera en un referente internacional en creación de producto digital?

Veo muy importante que no se centralice todo el “business” en Madrid o Barcelona, sino que se permita la creación e innovación en diferentes áreas del país, porque hay gente con mucho talento desperdigada por ahí y que no tiene por qué irse a vivir a Madrid.

Personalmente vivo en Toledo, y trabajo de manera remota con Los Ángeles. Esta flexibilidad me permite disfrutar más de mi familia, conciliando de verdad, y por tanto estando mucho más motivado para contribuir al proyecto que desarrollamos, ¡incluso trabajo más horas de las que debería!.

Y este cambio hacia la flexibilidad horaria, entre otros, pasa por cambiar la cultura “tradicional” de la típica empresa española: jefes autoritarios, horarios larguísimos, presentismo, trabajo por horas en lugar de por tareas u objetivos, la no utilización de metodologías Ágiles…

Al final, y siempre desde mi punto de vista, todo circula alrededor del talento: si la persona empleada está contenta, rendirá más y se sentirá mucho más vinculada al proyecto/producto/negocio, por tanto ese sentimiento de pertenencia marcará la diferencia.

Product Hackers Awards Candidaturas

¿En qué aspectos os fijáis a la hora de decidir un stack tecnológico sobre el que desarrollar un producto concreto?

Dos cosas: el conocimiento del equipo, y el soporte del stack. Si mi equipo es experto en NodeJS, ¿por qué empeñarme en meter Java, o al revés?

Y en cuanto al soporte, miro la actividad del proyecto Open Source (si no recibe commits desde hace meses/años, si no hay actividad en los comentarios, si está bien documentado, etc.).

Al menos en las primeras fases del producto veo clave el utilizar tus mejores recursos sin reinventar la rueda, usando cosas (librerías, frameworks, proyectos Open Source) que funcionan y están bien probadas por otros, con una comunidad de usuarios detrás que los mantengan, para salir pronto y empezar a rodar. Incluso valoro el hecho de usar productos comerciales que aporten valor a tu stack. Luego habrá tiempo para cambiarlo si hiciera falta.

¿Cómo conseguís balancear el uso de tecnologías más modernas y que puedan atraer más talento técnico con la deuda técnica que va adquiriendo el producto?

Veo importante que el equipo se recicle, y no me refiero a que cada año se asista a un curso, o a dos.

Prefiero en cambio que se utilicen unas semanales a I+D (por ejemplo 4 horas para leer blogs/libros, aprender una tecnología, hacer un prototipo de algo que pueda -o no- ser aprovechado en el proyecto). Esto hacíamos en mi anterior equipo y me parece fundamental para el crecimiento individual de cada uno de los miembros del equipo.

Y en cuanto a la atracción de talento, usando tecnologías bien probadas, como comentaba antes, hace que sea mucho más fácil encontrar personas muy aptas con un tiempo mucho más bajo para empezar a producir.

En vuestro caso, ¿tenéis equipos separados de desarrollo de producto y de soporte o se cubren ambos aspectos desde el mismo equipo?

En Liferay Inc. existen equipos separados de desarrollo de producto y de soporte, pero es cierto que este equipo (el de la oficina de España, que es el que mejor conozco) es super técnico y excelente en su trabajo, siendo capaz de contribuir tanto fixes como funcionalidades al producto.

Mi equipo ideal es en el que no hay distinción, y así la responsabilidad sobre la propiedad del código recae en un único equipo, que se asegurará de sacar productos con la mejor calidad para luego no tener que darles soporte.

Es una hipótesis muy idealizada, porque bugs van a existir siempre, pero de esta manera se consiguen dos cosas:

  1. no desmotivar al antiguo equipo de soporte, puesto que “sólo” arregla o notifica bugs de los clientes
  2. se vincula aún más al antiguo equipo de desarrollo en la búsqueda de la calidad.

Es cierto que desde el punto de vista del business, éste quiere que el equipo de desarrollo tire hacia adelante aportando valor. Yo al menos no lo veo incompatible.Hay un equipo de desarrollo y otro de soporte, pero el de desarrollo hace de soporte cuando el de soporte no alcanza a solucionar el problema en cuestión.

¿Cuáles son los principales stoppers que os encontráis en el día a día en cuanto al desarrollo de producto y cómo los solucionáis?

Un stopper que considero importante, y que veo a demasiado a menudo, es la dependencia en los tests de aceptación basados en el interfaz de usuario. Estos tests, que simulan la navegación de un usuario por la aplicación (clicks, relleno de inputs, submits, paginación, etc) tienen tres problemas fundamentalmente:

  1. les gusta mucho a los gestores, puesto que prueba toda la aplicación
  2. por esto mismo son extremadamente lentos, porque necesitan levantar toda la aplicación (junto con todas sus dependencias: sistema de archivos, bases de datos, cachés, servicios dependientes, etc.) para reproducir el entorno a probar, y el uso del navegador para ello es muy lento. De este modo, añadir más tests implica añadir tiempo del orden de minutos con cada test, lo cual no escala
  3. son muy propensos a errores, siendo especialmente muy frágiles en un entorno de continuous integration (continuous testing): puesto que el equipo de desarrollo está cambiando el interfaz de usuario muy rápido, los tests no suelen ser mantenidos por el mismo equipo, por tanto hay un retraso en la actualización que pilla en medio de las pruebas automatizadas, generado multitud de falsos positivos.

Por ello me gusta dejar este tipo pruebas para los caminos críticos de la aplicación, haciendo otro tipo de pruebas para cubrir más casos.

Otro stopper que suelo percibir es la dificultad de alinear lo que demanda el mercado, con lo que al final se desarrolla. Por ello veo muy importante la figura del Product Owner (PO), el cual está en contacto con el mercado y con los clientes, y ayuda al equipo a priorizar los siguientes pasos a realizar. Haciendo al PO partícipe de las reuniones de seguimiento del equipo es puede dar feedback de una manera más fluida sobre la dirección del producto.

Para los que estén leyendo esta entrevista, ¿por qué crees que deberían participar en los Product Hackers Awards si tienen algún producto digital?

Product Hackers es un escaparate impresionante de cara a posicionar un producto. Simplemente el hecho de compararte con otros productazos existentes en España es todo un lujo. Y recibir la valoración de algunas o muchas de las personas que están como jurado es algo que de otra manera no sería posible conseguir. La mía no, que soy nuevo en esto de ser jurado :)

Product Hackers Awards Candidaturas