Antes de configurar Drupal: Discovery y planificación de un proyecto

Una buena implementación de Drupal no debería comenzar creando tipos de contenido, campos, taxonomías o instalando módulos.

La configuración de Drupal debería ser la consecuencia de una serie de decisiones previamente tomadas sobre el negocio, los usuarios, el contenido y los procesos que el sitio debe soportar.

Antes de preguntarnos cómo configurar Drupal, debemos entender qué problema estamos intentando resolver.

Este artículo presenta un proceso de alto nivel para analizar un proyecto antes de comenzar su configuración. Posteriormente podremos extender esta metodología a proyectos más específicos, como Drupal Commerce.

1. Entender el negocio

La primera etapa consiste en comprender el contexto del cliente y los objetivos reales del proyecto.

En este punto todavía no necesitamos pensar en Drupal.

Algunas preguntas importantes son:

• ¿Cuál es el objetivo principal del sitio?
• ¿Qué problema debe resolver?
• ¿Qué proceso actual queremos mejorar o reemplazar?
• ¿Quién utilizará el sistema?
• ¿Qué acciones queremos que realicen los usuarios?
• ¿Cómo medirá el cliente si el proyecto ha tenido éxito?

El resultado debería ser una definición sencilla de los objetivos del negocio.

Ejemplo: el sitio debe permitir que arquitectos encuentren productos técnicos, consulten su documentación y contacten al distribuidor correspondiente.

Aunque esta definición parece sencilla, posteriormente tendrá consecuencias sobre la arquitectura de contenido, la navegación, la búsqueda, los formularios y las integraciones del sistema.

2. Identificar las audiencias y tipos de usuario

El siguiente paso consiste en identificar quién utilizará el sitio.

Es importante no confundir todavía estos perfiles con los roles de Drupal. Primero estamos describiendo usuarios del negocio.

Por ejemplo:

• Visitante anónimo
• Cliente particular
• Cliente profesional
• Distribuidor
• Editor de contenido
• Responsable comercial
• Administrador

Para cada perfil deberíamos intentar responder:

• ¿Qué necesita?
• ¿Qué intenta conseguir?
• ¿Qué información necesita?
• ¿Qué acciones debe poder realizar?
• ¿Qué restricciones tiene?

Más adelante podremos traducir estas necesidades a roles, permisos, workflows y mecanismos de acceso en Drupal.

3. Definir los principales User Journeys

Una vez sabemos quiénes son nuestros usuarios, debemos entender cómo interactuarán con el sistema.

Un User Journey describe el camino que sigue un usuario para alcanzar un objetivo.

Por ejemplo:

Google
  ↓
Landing page
  ↓
Producto o servicio
  ↓
Información técnica
  ↓
Formulario de contacto

Otro posible recorrido:

Visitante
  ↓
Buscador
  ↓
Producto
  ↓
Documento técnico
  ↓
Descarga

Estos recorridos empiezan a mostrarnos funcionalidades que probablemente necesitaremos:

• Búsqueda
• Filtros
• Formularios
• Media
• Relaciones entre contenidos
• Permisos
• Integraciones

Sin embargo, todavía estamos describiendo necesidades funcionales y no soluciones concretas de Drupal.

4. Identificar las entidades del negocio

Esta es una de las etapas más importantes de la planificación.

Debemos identificar qué tipos de información existen dentro del dominio del cliente.

Por ejemplo:

Producto
Categoría
Marca
Documento
Proyecto
Persona
Ubicación
Noticia
Servicio

También debemos entender cómo se relacionan entre sí.

Categoría
   │
   └── Producto
          │
          ├── Documentos técnicos
          ├── Imágenes
          └── Productos relacionados

En esta etapa estamos realizando una forma sencilla de modelado del dominio.

Solamente después deberíamos decidir cómo representar estas entidades dentro de Drupal.

Una entidad del negocio podría convertirse en:

• Content Type
• Taxonomy Vocabulary
• Media Type
• Custom Entity
• Paragraph Type
• Commerce Product

Por este motivo, una pregunta como:

¿Qué tipos de contenido debemos crear?

debería ser precedida por una pregunta más importante:

¿Qué entidades existen realmente en el dominio del cliente?

5. Definir las funcionalidades necesarias

Una vez entendido el negocio y el modelo de información podemos comenzar a identificar las funcionalidades que necesitará el sistema.

Por ejemplo:

• Búsqueda
• Filtros
• Formularios
• Registro de usuarios
• Perfiles
• Newsletter
• SEO
• Sitemap
• Redirecciones
• Workflows editoriales
• Contenido privado
• Multilenguaje
• Integración con CRM
• APIs
• Analytics

También resulta útil clasificar los requisitos según su prioridad.

Must have
Should have
Nice to have
Future

Esta clasificación ayuda a controlar el alcance del proyecto y evita introducir complejidad innecesaria durante la primera implementación.

6. Analizar los requisitos de contenido

En un proyecto Drupal, el contenido merece una sección específica.

Debemos comprender no solamente qué contenido existe, sino también cómo se crea, publica y mantiene.

Algunas preguntas importantes son:

• ¿Quién crea el contenido?
• ¿Quién puede modificarlo?
• ¿Quién lo revisa?
• ¿Quién puede publicarlo?
• ¿Existen diferentes idiomas?
• ¿El contenido debe traducirse?
• ¿Qué contenido debe ser reutilizable?
• ¿Qué taxonomías existen?
• ¿Qué tipos de imágenes, documentos o vídeos se gestionarán?
• ¿Necesitamos revisiones?
• ¿Existen procesos de aprobación?
• ¿Hay contenido con fecha de publicación o expiración?

Estas respuestas posteriormente definirán elementos como:

Content Types
Fields
Taxonomies
Media Types
Workflows
Permissions
Content Moderation
Translations

7. Definir requisitos técnicos y no funcionales

No todos los requisitos están relacionados directamente con funcionalidades visibles para el usuario.

También debemos analizar los requisitos técnicos y operativos del sistema.

Performance

• Volumen de tráfico esperado
• Volumen de contenido
• Estrategia de caché
• CDN
• Requisitos de tiempo de respuesta

Seguridad

• Datos personales
• Autenticación
• Permisos
• Auditoría
• Políticas de acceso

SEO

• URLs
• Metadata
• Canonical URLs
• Structured Data
• Sitemaps
• Redirecciones

Accesibilidad

• Nivel WCAG esperado
• Navegación mediante teclado
• Contraste
• Semántica del contenido

Localización

• Idiomas
• Países
• Formatos de fecha
• Formatos numéricos

Operaciones

• Backups
• Entornos de desarrollo, staging y producción
• Deployment
• Logging
• Monitoring
• Mantenimiento

8. Identificar integraciones externas

Drupal normalmente forma parte de un ecosistema más amplio.

Por ello debemos identificar todos los sistemas externos con los que tendrá que comunicarse.

              CRM
               ↑
               │
ERP ←────── Drupal ──────→ Newsletter
               │
               ↓
           Analytics

Algunas integraciones habituales son:

• ERP
• CRM
• PIM
• DAM
• Servicios de newsletter
• Servicios de autenticación
• Buscadores externos
• Analytics
• Sistemas de facturación
• APIs de terceros

Estas integraciones pueden tener un impacto muy importante sobre la arquitectura del proyecto.

9. Identificar restricciones

Todo proyecto tiene restricciones que condicionan las decisiones técnicas.

Por ejemplo:

• Presupuesto
• Fecha de lanzamiento
• Hosting disponible
• Tecnologías obligatorias
• Sistemas legacy
• Dependencias de terceros
• Tamaño del equipo
• Capacidad de mantenimiento

Es importante documentarlas explícitamente porque muchas decisiones arquitectónicas estarán determinadas por estas limitaciones.

10. Traducir los requisitos a una arquitectura Drupal

Solamente después de completar las etapas anteriores deberíamos comenzar a diseñar la implementación dentro de Drupal.

Podemos visualizar el proceso de esta manera:

BUSINESS
   ↓
Users
   ↓
User Journeys
   ↓
Domain Model
   ↓
Functional Requirements
   ↓
Content Requirements
   ↓
Technical Requirements
   ↓
────────────────────────
     DRUPAL ARCHITECTURE
────────────────────────
   ↓
Entities
Bundles
Fields
Taxonomies
Media
Views
Roles
Permissions
Workflows
Modules
Configuration

Ahora sí podemos responder preguntas como:

• ¿Qué entidades debemos utilizar?
• ¿Qué tipos de contenido necesitamos?
• ¿Qué campos tendrá cada entidad?
• ¿Qué taxonomías necesitamos?
• ¿Qué Media Types debemos crear?
• ¿Qué roles existirán?
• ¿Qué permisos tendrá cada rol?
• ¿Qué workflows editoriales necesitamos?
• ¿Qué Views debemos construir?
• ¿Qué módulos contribuidos necesitamos?
• ¿Necesitamos desarrollar módulos personalizados?

Configuración como consecuencia del diseño

Una de las ideas fundamentales de esta metodología es separar claramente dos etapas:

Discovery y diseño
        ↓
Arquitectura
        ↓
Configuración Drupal

No deberíamos descubrir la arquitectura del sistema mientras creamos campos desde la interfaz administrativa.

La interfaz de Drupal es el lugar donde implementamos decisiones previamente tomadas.

Esto permite obtener sitios:

• Más coherentes
• Más fáciles de mantener
• Más sencillos de evolucionar
• Con menos módulos innecesarios
• Con modelos de contenido más claros
• Con permisos mejor definidos

El siguiente paso: Drupal Commerce

Esta misma metodología puede extenderse a un proyecto de comercio electrónico.

Drupal Commerce introduce un nuevo conjunto de conceptos que debemos analizar antes de comenzar su configuración:

Drupal Project Discovery
        │
        ├── Business
        ├── Users
        ├── Content
        ├── Features
        └── Integrations
                │
                ▼
       Commerce Discovery
                │
        ├── Products
        ├── Product Variations
        ├── Pricing
        ├── Customers
        ├── Stores
        ├── Markets
        ├── Currencies
        ├── Taxes
        ├── Promotions
        ├── Checkout
        ├── Payments
        ├── Shipping
        ├── Orders
        ├── Fulfillment
        └── ERP / CRM / Accounting

Por ejemplo, un cliente puede decir simplemente:

Vendemos puertas.

Pero antes de configurar Drupal Commerce debemos descubrir qué significa exactamente una puerta vendible.

Podríamos tener:

Producto
Door Model X

Variaciones:
├── 80 × 200 / Blanco / Izquierda
├── 80 × 200 / Blanco / Derecha
├── 90 × 200 / Blanco / Izquierda
└── 90 × 200 / Blanco / Derecha

O quizás el precio dependa de diferentes variables:

Tamaño
+ Material
+ Acabado
+ Grupo de clientes
+ País
+ Cantidad

Cada una de estas decisiones puede modificar significativamente la arquitectura de Drupal Commerce.

Conclusión

Aprender Drupal no debería limitarse a conocer dónde se encuentra cada opción dentro de la interfaz administrativa.

Un buen arquitecto o configurador de Drupal debe ser capaz de transformar necesidades reales del negocio en una arquitectura coherente de entidades, contenido, usuarios, permisos, workflows e integraciones.

El proceso puede resumirse así:

Entender el negocio
        ↓
Entender los usuarios
        ↓
Entender los procesos
        ↓
Modelar la información
        ↓
Definir requisitos
        ↓
Diseñar la arquitectura
        ↓
Configurar Drupal

En el siguiente paso extenderemos este mismo proceso específicamente para Drupal Commerce, creando una metodología para descubrir y documentar productos, variaciones, precios, impuestos, pagos, envíos, checkout, pedidos e integraciones antes de comenzar su configuración.