# Antes de configurar Drupal: Discovery y planificación de un proyecto Enviado por [danieluxury](/es/user/1 "Ver perfil del usuario.") el Vie, 25 Sep 2026 - 11:19 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: ```plaintext Google ↓ Landing page ↓ Producto o servicio ↓ Información técnica ↓ Formulario de contacto ``` Otro posible recorrido: ```plaintext 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: ```plaintext Producto Categoría Marca Documento Proyecto Persona Ubicación Noticia Servicio ``` También debemos entender cómo se relacionan entre sí. ```plaintext 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. ```plaintext 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: ```plaintext 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. ```plaintext 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: ```plaintext 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: ```plaintext 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: ```plaintext 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: ```plaintext 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: ```plaintext 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í: ```plaintext 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. ## Course navigation: Drupal Commerce Chapter 1 of 11 - [ Siguiente → Antes de configurar Drupal Commerce: Discovery del negocio y del modelo comercial ](/es/antes-de-configurar-drupal-commerce-discovery-del-negocio-y-del-modelo-comercial) [↑ Course index](/es/node/43)