Antes o después, casi todos los proyectos de Drupal cambian de manos: termina un contrato, un concurso trae un nuevo proveedor, o un cliente que ha mantenido el sitio con su propio equipo, decide que necesita ayuda externa. El traspaso es un momento delicado. El cliente espera ver avances pronto, mientras que el conocimiento que necesita el nuevo equipo está disperso, sin documentar o se ha ido con el equipo anterior. Las primeras decisiones se toman sobre una plataforma que nadie del nuevo equipo entiende del todo todavía, y las promesas que se hicieron antes de conocer el estado real del código ahora tienen fecha de entrega.
Esta sesión trata sobre ese momento: cómo reunir todo el conocimiento posible, cómo recuperar el resto a partir del propio proyecto y cómo convertir un traspaso en una responsabilidad real sobre el proyecto, medida con datos y no con impresiones.
Qué cubre la sesión
1. Sacar el máximo partido al traspaso. Qué pedir: acceso a todos los entornos y sistemas, repositorios, el proceso de despliegue, integraciones, incidencias abiertas y la documentación existente. También cómo preparar sesiones de preguntas concretas con el equipo saliente, y por qué preguntarles qué arreglarían primero es una de las preguntas más útiles de todo el proceso.
2. Arqueología de proyecto. Cuando no hay nadie a quien preguntar o la información es insuficiente, la fuente es el propio proyecto. Eso significa leer el código y, si existe, el historial de Git. Los hallazgos suelen repetirse:
- paquetes sin mantenimiento o muy desactualizados, algunos con problemas de seguridad conocidos
- código escrito con hábitos de otros frameworks o previas versiones de Drupal
- ausencia de tests
- código a medida cuyo propósito no está claro, o que ya cubre un módulo contrib existente
- decisiones tempranas que desencadenaron una bola de nieve de problemas, que a menudo se resuelven corrigiendo la causa raíz (cuando la identificas)
Se trata de entender, no de juzgar, para poder dar el mejor servicio. A toro pasado, todo está más claro. Todos somos conscientes del sector y de la presión de plazos, cambios de última hora que forzaron la arquitectura y nunca se refactorizaron, y otros problemas que condicionan la calidad final de un proyecto.
3. Una visión compartida del proyecto. Consolidar lo que aprende el equipo en una documentación del proyecto que todos lean de la misma manera y la cobertura de tests de forma progresiva a modo de red de seguridad.
4. Métricas antes que opiniones. Todo traspaso empieza con una auditoría inicial, planteada como un proceso que abarca seguridad y estado técnico, calidad del código y buenas prácticas de Drupal, arquitectura, rendimiento, infraestructura, accesibilidad, SEO y cumplimiento del RGPD. Establece la línea base y ordena los hallazgos por criticidad. Después, las auditorías periódicas muestran el progreso tanto al equipo como a los responsables de negocio del cliente.
5. Múltiples líneas de trabajo en paralelo. Corregir lo que ha identificado la auditoría a la vez que se atienden las nuevas peticiones, de modo que ninguna línea bloquee a la otra y el trabajo de corrección siga siendo visible bajo el backlog de nuevas funcionalidades.
A quién va dirigida: jefes de proyecto, tech leads y responsables de producto.
Sobre el ponente: Jorge Tutor es CIO de Metadrop, agencia especializada en Drupal. La sesión se basa en el proceso de traspaso y auditoría que sigue Metadrop en plataformas de grandes organizaciones de las que se ha hecho cargo.