Redescubriendo Drupal desde el lado de producto

Hacía tiempo que no abría Drupal. Esta vez lo abordo como Product Owner, y eso lo cambia todo. Ya no me pregunto cómo construir una funcionalidad, sino cuánto cuesta, quién la va a usar y qué puede romperse cuando la tocamos.

Aprender a hablar el mismo idioma

Al principio, Drupal da la impresión de ser una herramienta en la que todo es posible y nada es evidente. Tipos de contenido, vistas, taxonomías, permisos: son muchos conceptos. Mi primer impulso fue querer entenderlo todo antes de pedir nada. Mala idea. Lo que me ayudó fue entender cómo razona el equipo técnico, para formular mis necesidades en sus términos. Una petición bien planteada evita muchas idas y vueltas.

Administrar sin perderse

La administración del día a día es sobre todo disciplina. Módulos, actualizaciones de seguridad, permisos de los editores: nada espectacular, pero si se descuida, sale caro enseguida. Desde el lado de producto he aprendido a considerar la administración como parte del producto, y no como una tarea técnica aparte.

Desarrollo a medida y actualizaciones de versión

Ya viví las actualizaciones de versión como jefe de proyecto técnico. Gestionábamos el calendario, estimábamos los tickets y resolvíamos los imprevistos. Ahora miro el mismo tema desde el otro lado: soy yo quien decide qué construimos y qué dejamos fuera.

Cada desarrollo a medida es una deuda: hay que mantenerlo, probarlo en cada actualización mayor y explicarlo a la siguiente persona que llegue. Antes de aprobarlo, necesito poder responder a tres preguntas: qué problema de negocio resuelve, si una solución estándar bastaría y cuánto costará dentro de tres años.

En las actualizaciones de versión, mi papel ya no es fijar la fecha, sino arbitrar: qué funcionalidades mantenemos, cuáles eliminamos y qué nivel de riesgo aceptamos. También tengo que defender el tiempo de pruebas y correcciones en la hoja de ruta, porque si no, siempre acaba recortado.

Lo que me quedo: limitar el desarrollo a medida a las necesidades realmente específicas y documentar cada desviación respecto al estándar, con el motivo que la justificó. Dentro de tres años alguien tendrá que entender por qué las cosas están hechas como están, y ese documento suele ser la única traza de ese razonamiento.

El día a día: peticiones de contenido

Buena parte de mi trabajo son peticiones de creación o modificación de contenido. Parecen simples, pero enseguida revelan la distancia entre lo que la herramienta permite y lo que esperan los equipos. Lo que marca la diferencia es un planteamiento mínimo: quién lo pide, qué tipo de contenido es, qué plantilla usar y para cuándo. Parece obvio, pero suele ser lo que falta.

Lo que me ha enseñado

Pasar al lado de producto con Drupal me ha hecho ver que la tecnología no es el tema principal. Lo importante son las necesidades claras, un sitio que se pueda mantener en el tiempo y la conciencia del coste de cada decisión. Eso va mucho más allá de Drupal.