Purpose

Definir un estándar común para describir y validar el alcance de todos los proyectos de Website de /nk.

El objetivo es que, antes de marcar un proyecto como Ready, Sales y Delivery puedan responder sin ambigüedad:

Qué website estamos construyendo, qué cantidad de trabajo incluye, qué funcionalidades contempla y dónde termina el alcance vendido.

Este estándar complementa el Web Questionnaire, que sirve para obtener información del cliente durante Sales. El questionnaire releva contexto, necesidades, estructura, contenido, CMS, integraciones, infraestructura, SEO, analytics y otros requerimientos; este documento transforma esa información en un scope operativo y cuantificable.

Core Principle

Un Website no puede definirse únicamente mediante frases como:

“Redesign and development of the corporate website.”

o:

“New website with CMS.”

El scope debe expresarse mediante unidades concretas, cantidades y límites.

Un tercero que no participó de Sales debería poder leer el Project Definition y entender aproximadamente cuánto Website fue vendido.

1. Scope Model

Todo Website debe clasificarse antes del Readiness Gate según el modelo con el que será construido.

A. Component-based Website

El Website se construye mediante un sistema de componentes reutilizables, generalmente administrados desde un CMS.

El cliente puede posteriormente crear diferentes páginas combinando esos componentes sin que cada nueva página implique necesariamente nuevo diseño o desarrollo.

En este modelo, el scope se controla principalmente mediante:

Component Budget + complexity tiers + elementos estructurales + templates especiales + funcionalidades.

B. Fixed-structure Website

El Website se construye alrededor de un conjunto previamente definido de páginas o templates.

En este modelo, el scope se controla principalmente mediante:

cantidad de unique templates / páginas + funcionalidades + nivel de administración de contenido.

C. Hybrid Website

Un Website puede combinar ambos modelos.

Por ejemplo:

un sistema de componentes reutilizables para páginas institucionales junto con templates estructurados específicos para Blog, Careers, Resources o Product Detail.

En estos casos, cada parte debe cuantificarse utilizando el modelo correspondiente.

2. Component-based Website

Cuando el Website utiliza un sistema flexible de componentes, el alcance debe incluir un Component Budget.

Component Budget

El Component Budget representa la cantidad total de complejidad de componentes incluida dentro del proyecto.

Cada componente se clasifica en uno de cuatro tiers:

El Project Definition debe indicar como mínimo:

• Total Component Budget.
• Distribución estimada por tier.
• Cantidad máxima o estimada de componentes L.
• Componentes XL conocidos.
• Cualquier excepción relevante al modelo.

Ejemplo:

Component Budget: up to 120 points
Estimated distribution: 7 S / 9 M / 7 L / 4 XL
Known XL components: Interactive Hero, Advanced Form, Product Explorer, Locations Map.

La distribución inicial permite dimensionar el proyecto.

No obliga a que Discovery termine exactamente con esa combinación.

El límite principal es el Component Budget acordado, junto con las reglas del Component Complexity Standard — S / M / L / XL.

3. Component Budget Rules

El Component Budget permite que Discovery refine la solución sin tratar cada pequeño ajuste como un cambio comercial.

Como referencia:

1 XL = 2 L = 4 M = 12 S

Estas equivalencias funcionan como una unidad de control de scope.

No pretenden afirmar que el esfuerzo real de implementación sea matemáticamente idéntico en todos los casos.

S / M Components

Existe mayor flexibilidad para redistribuir componentes S y M durante Discovery mientras:

• se respete el Component Budget;
• no aparezcan funcionalidades nuevas;
• no aparezcan integraciones nuevas;
• no cambie materialmente la naturaleza del sistema.

L Components

Debe existir una distribución estimada y un límite razonable.

Si durante Discovery aumenta significativamente la cantidad de componentes L, deberá revisarse el impacto sobre el Component Budget.

XL Components

Los XL representan componentes de alta complejidad y riesgo.

Siempre que sea posible, deben estar identificados nominalmente antes del Readiness Gate.

Por ejemplo:

Interactive Product Explorer
Complex Form integrated with Salesforce
Interactive Hero with advanced motion

La aparición de un nuevo XL no contemplado requiere un Scope Review, incluso cuando existan puntos disponibles.

Esto se debe a que un XL puede introducir riesgos, lógica, integraciones o necesidades técnicas que no se compensan únicamente mediante puntos.

→ See: Component Complexity Standard — S / M / L / XL

4. What counts as a component

El Component Budget representa piezas de UI reutilizables que requieren trabajo propio de diseño y/o desarrollo.

No representa automáticamente:

• cada página;
• cada instancia del CMS;
• cada bloque de contenido;
• cada uso repetido del mismo componente.

Por ejemplo:

si /nk construye un componente Text + Media, utilizarlo luego en 15 páginas continúa representando un único componente.

Una variante válida del mismo componente tampoco debería convertirse automáticamente en un nuevo componente.

La definición detallada de componente, variante y nuevo componente vive en:

→ Component Complexity Standard — S / M / L / XL

5. Structural Elements

Los elementos globales o estructurales que requieren trabajo propio deben ser contemplados explícitamente.

Por ejemplo:

• Header / Navigation
• Footer
• Mega Menu
• Global CTA
• Cookie Banner
• Search
• Filtering
• Forms
• Modals
• Language Selector
• Global Notifications

Cuando requieran diseño o desarrollo relevante deben:

contabilizarse dentro del Component Budget

o

figurar explícitamente como deliverables adicionales fuera del Component Budget.

No deberían aparecer implícitamente durante Production.

6. Sitemap & Launch Pages

Incluso en un Component-based Website debe existir una visión inicial del sitio que estamos construyendo.

Antes de Readiness debe existir:

un sitemap inicial o listado de páginas esperadas para Launch.

El objetivo no es utilizar la cantidad de páginas como límite principal de scope, sino comprender:

• estructura general;
• navegación;
• jerarquías;
• content types;
• necesidades de templates;
• páginas especiales;
• contenido necesario para Launch.

El sitemap puede evolucionar durante Discovery.

Pages created through the CMS

Cuando el proyecto incluye Page Builder o un sistema equivalente:

la cantidad de páginas que el cliente pueda crear utilizando los componentes existentes no consume Component Budget adicional.

El Component Budget representa el sistema que /nk debe diseñar y desarrollar, no la cantidad futura de instancias que puedan crearse desde el CMS.

Sí puede aumentar el scope cuando una nueva página requiere:

• un componente nuevo;
• un template nuevo;
• una funcionalidad nueva;
• una integración nueva;
• o comportamiento no contemplado originalmente.

7. Templates

Todo template que tenga estructura o comportamiento propio debe quedar explícitamente contemplado.

Ejemplos:

• Blog Listing
• Blog Detail
• Careers Listing
• Job Detail
• Resource Center
• Resource Detail
• Search Results
• Product Detail
• Location Detail

Un template no debería confundirse con una página concreta.

Por ejemplo, cien artículos pueden utilizar el mismo Blog Detail Template.

Cuando un template incluya lógica particular, su alcance debe describirse suficientemente.

8. CMS Scope

Cuando el Website incluya CMS, el Project Definition debe especificar qué sistema de administración estamos construyendo.

Como mínimo:

CMS Platform

Qué CMS utilizará el proyecto o bajo qué condiciones se decidirá.

Content Types

Qué entidades estructuradas administrará.

Ejemplos:

• Blog Posts
• Team Members
• Jobs
• Resources
• Case Studies
• Offices
• Products

Editable Content

Qué contenido podrá modificar el cliente.

Page Building

Si podrá crear nuevas páginas mediante componentes reutilizables.

Permissions

Roles, permisos o approval workflows particulares cuando existan.

Multi-site / Multi-region

Si el mismo CMS administrará distintas marcas, países, regiones o Websites.

El Web Questionnaire ya releva CMS preferido, usuarios, permissions, workflows y escenarios multi-site, por lo que estas respuestas deberían trasladarse al Project Definition cuando sean relevantes.

9. Fixed-structure Website

Cuando el Website no utilice un sistema flexible de componentes, el alcance debe expresarse mediante páginas/templates concretos.

Debe incluir:

Sitemap

Listado de páginas incluidas.

Unique Templates

Cantidad y listado de estructuras únicas.

Páginas que utilizan exactamente la misma estructura no deberían contabilizarse como templates diferentes.

Editable Areas

Para cada template debe quedar definido:

• qué contenido es administrable;
• qué contenido es estático;
• qué elementos son compartidos;
• qué secciones pueden repetirse;
• qué restricciones existen.

CMS

Cuando corresponda, debe indicarse qué parte del Website estará conectada al CMS.

Toda nueva página que requiera un nuevo template no contemplado deberá evaluarse como posible cambio de scope.

10. Features & Functionalities

Toda funcionalidad que exceda el comportamiento estándar de contenido debe estar identificada.

Por ejemplo:

• Forms
• Search
• Filtering
• Authentication
• User Accounts
• E-commerce
• Calculators
• Interactive Maps
• Personalization
• Dynamic Data
• Careers Integration
• Booking
• Payments

No alcanza con nombrar una funcionalidad.

Debe existir suficiente definición como para saber qué significa que esté incluida.

Por ejemplo:

Too ambiguous

Salesforce Integration

Better

Lead form sends Name, Company, Email and Message to Salesforce through an existing API provided by the client.

No buscamos escribir todavía la especificación técnica completa.

Buscamos evitar que una única palabra represente cantidades radicalmente distintas de trabajo.

11. Integrations

Toda integración debe listarse individualmente.

Cuando exista información disponible debería documentarse:

System → Purpose → Data exchanged → Available API / documentation → Client owner → Known constraints

Ejemplos:

• Salesforce
• Shopify
• Auth0
• Marketing Cloud
• Payment Gateways
• Internal APIs

El Web Questionnaire ya releva third-party services, authentication, internal APIs, documentación y restricciones técnicas.

Si no existe suficiente información para determinar razonablemente la complejidad de una integración, deberá evaluarse si esa incógnita bloquea Readiness.

Una integración crítica no puede permanecer definida simplemente como:

“Integrate with internal system.”

12. Content Responsibilities

Antes de Readiness debe estar claro quién será responsable de:

Content Creation → Content Approval → Content Loading → Content Migration

Cada responsabilidad debe asignarse a:

Client / /nk / Third Party / N/A

Cuando corresponda también debe definirse:

• volumen aproximado;
• deadline;
• idiomas;
• formato esperado;
• fuentes actuales del contenido.

No debe comenzar un proyecto asumiendo implícitamente que:

“El contenido aparecerá durante el proyecto.”

El Web Questionnaire ya releva contenido existente, copywriting, migración y frecuencia de actualización.

13. Languages & Localization

Debe estar definido:

• cuántos idiomas;
• cuáles;
• quién genera las traducciones;
• quién las carga;
• si existen variantes regionales;
• si contenido o estructura cambian según región;
• si existen dominios diferentes por mercado.

Los idiomas impactan potencialmente:

• CMS;
• layouts;
• content loading;
• QA;
• SEO;
• integrations;
• timeline.

Por lo tanto, forman parte explícita del scope.

14. Design & Experience Complexity

El alcance también debe representar el nivel de experiencia visual e interactiva esperado.

El Web Questionnaire actualmente diferencia entre experiencias como Corporate and functional, Premium and design-driven, Interactive, Highly immersive, Experimental y 3D/WebGL-driven.

Esta definición debe considerarse al validar el scope.

Una misma cantidad de componentes puede representar proyectos muy distintos dependiendo de su nivel de interacción y motion.

Cuando existan elementos especiales deben identificarse explícitamente.

Por ejemplo:

• advanced motion;
• scroll-based interactions;
• interactive storytelling;
• WebGL;
• 3D;
• complex page transitions;
• custom cursor behavior;
• physics or canvas-based interactions.

Estos factores también forman parte de la clasificación S/M/L/XL.

15. Assets & Production

Todo asset adicional que forme parte del engagement debe quedar identificado.

Ejemplos:

• Custom Illustrations
• Custom Iconography
• Motion Graphics
• 3D Assets
• Maps
• Photography Direction
• Image Treatments
• Video-related work

El Web Questionnaire ya incluye este relevamiento.

Cuando este tipo de producción no esté incluida pero exista posibilidad razonable de confusión, debe aparecer como Explicit Exclusion.

16. SEO

Debe quedar definido qué significa SEO dentro del proyecto.

No debe utilizarse simplemente:

SEO Included

sin especificar alcance.

Según corresponda, debe indicarse si se incluye:

• Technical SEO
• Metadata implementation
• XML Sitemap
• Robots.txt
• Redirects
• Structured Data
• Existing URL migration
• SEO Strategy
• Keyword Research
• Content SEO

El Web Questionnaire ya releva existing SEO guidelines, structured data, sitemap, redirects y fuentes externas que utilizan URLs actuales.

17. Analytics & Tracking

Debe quedar definido qué nivel de Analytics forma parte del proyecto.

Por ejemplo:

• GA4 Setup
• GTM
• Existing Analytics Integration
• Standard Events
• Custom Events
• Conversion Tracking
• Dashboards
• Consent Management

Cuando existan Custom Events, debería indicarse aproximadamente qué interacciones o conversiones necesitan medirse.

El Web Questionnaire ya releva Analytics platforms, Custom Event Tracking y Tag Managers.

18. Accessibility & Compliance

Debe quedar explícito cualquier requerimiento particular de accesibilidad o compliance.

Por ejemplo:

• WCAG 2.1 / 2.2
• ADA
• Section 508
• GDPR
• CCPA
• LGPD
• Cookie Compliance
• CMP
• Industry-specific requirements

Si el proyecto requiere una auditoría o certificación externa, debe indicarse expresamente.

No debería inferirse automáticamente una certificación o nivel contractual de compliance que no fue vendido.

El Web Questionnaire ya releva estos requerimientos.

19. Infrastructure & Deployment

Debe quedar definida la responsabilidad sobre:

• Hosting
• Production Environment
• Deployment
• Domain
• DNS
• SSL
• Infrastructure Setup
• Monitoring
• Logging

Cuando producción viva en infraestructura del cliente debe documentarse cualquier restricción conocida que pueda afectar Delivery.

Ejemplos:

• internal DevOps team;
• custom deployment process;
• specific Git provider;
• code review requirements;
• security scanning;
• multiple instances;
• load balancers;
• specific logging tools.

El Web Questionnaire actualmente releva estas condiciones técnicas.

20. Explicit Exclusions

Deben escribirse las exclusiones especialmente importantes o fáciles de malinterpretar.

Por ejemplo:

Copywriting is not included.

Content migration is not included.

E-commerce is not included.

Translation services are not included.

Integrations other than those explicitly listed are not included.

New functionality in existing client backend systems is not included.

Ongoing maintenance after the warranty period is not included.

La intención no es llenar el SOW de disclaimers.

Es hacer explícitas aquellas fronteras del proyecto que razonablemente podrían generar interpretaciones diferentes.

21. Scope Refinement During Discovery

Discovery existe para mejorar la solución.

Por lo tanto, el scope inicial no busca definir anticipadamente cada componente final.

En un Component-based Website, Discovery puede:

• definir cuáles serán los componentes concretos;
• consolidar componentes;
• simplificarlos;
• modificar su distribución entre tiers;
• definir variantes;
• modificar el sitemap;
• reorganizar templates;
• refinar arquitectura de información.

Por ejemplo, un proyecto pensado inicialmente como:

8 S + 8 M + 6 L + 3 XL

puede terminar con otra distribución si resulta una mejor solución.

El principal límite continúa siendo:

Component Budget + restricciones específicas de L/XL + funcionalidades vendidas.

Discovery no puede incorporar silenciosamente:

• nuevas funcionalidades;
• nuevas integraciones;
• nuevos sistemas;
• nuevos XL significativos;
• nuevos deliverables;
• o trabajo que modifique materialmente el tamaño del proyecto.

22. Component Budget During Discovery

El Component Budget debe poder utilizarse como herramienta activa de decisión.

Por ejemplo:

si un componente inicialmente pensado como L — 6 pts termina resolviéndose como M — 3 pts, los puntos restantes pueden utilizarse razonablemente dentro del sistema acordado.

De manera inversa, si un componente estimado como M termina siendo L, el equipo debe revisar el impacto sobre el budget total.

Esto permite absorber cambios naturales de Discovery sin transformar cada diferencia en una conversación comercial.

El objetivo es controlar el proyecto completo, no discutir cada componente aisladamente.

23. Scope Review

Debe realizarse un Scope Review cuando ocurra, entre otros casos:

• Component Budget proyectado supera el acordado.
• Aparece un nuevo XL relevante.
• Un componente inicialmente S/M resulta L/XL debido a nueva información.
• Aparece una nueva funcionalidad.
• Aparece una nueva integración.
• Se incorpora un nuevo template.
• Se incorpora un Content Type con impacto material.
• Aparece un nuevo idioma.
• Aumenta significativamente la complejidad de motion/interacción.
• Se incorpora trabajo marcado originalmente como Not Included.

Un Scope Review no implica automáticamente un Change Order.

Primero debe evaluarse si el cambio puede absorberse razonablemente mediante:

• simplificación;
• consolidación;
• redistribución del Component Budget;
• eliminación o reemplazo de otra parte del scope;
• ajuste de solución.

Si no puede absorberse sin afectar materialmente el proyecto, deberá gestionarse mediante Project Health & Change Control.

24. Change Control

Cuando el mejor resultado para el cliente requiera ampliar materialmente el proyecto, el cambio debe hacerse visible.

Dependiendo del caso puede derivar en:

• Scope Adjustment
• Timeline Adjustment
• Change Request
• Change Order

La pregunta central debería ser:

Are we still executing reasonably the same project that was sold?

Si la respuesta deja de ser claramente sí, el cambio debe evaluarse antes de avanzar.

Validation

Antes de atravesar Project Readiness:

Sales

Confirma que el scope representa correctamente lo vendido y lo acordado con el cliente.

Design Lead

Valida:

• Scope Model
• Design scope
• Estimated component distribution
• Experience complexity
• Assets / production
• Relevant assumptions
• Design-related exclusions

Tech Lead

Valida:

• Component Budget from a technical perspective
• CMS scope
• Features
• Integrations
• Technical complexity
• Infrastructure constraints
• Technical assumptions
• Technical exclusions

Project Manager

Valida que:

• los límites sean suficientemente claros;
• responsabilidades estén definidas;
• Dependencies estén identificadas;
• no existan contradicciones;
• y el proyecto pueda planificarse responsablemente.

Definition of Done

El Website Scope está suficientemente definido cuando:

• Scope Model está definido.
• Sitemap inicial o Launch Pages están disponibles.
• Component Budget está definido cuando corresponde.
• La distribución estimada por complexity tier está documentada.
• Los componentes XL conocidos están identificados cuando corresponde.
• Unique Templates están cuantificados cuando corresponde.
• Structural Elements relevantes están contemplados.
• Features están identificadas.
• Integrations están identificadas.
• CMS Scope está definido.
• Content Types relevantes están identificados.
• Content responsibilities están definidas.
• Languages están definidos.
• Design / Experience complexity está entendida.
• Assets adicionales están identificados.
• SEO scope está definido.
• Analytics scope está definido.
• Accessibility / Compliance requirements están definidos.
• Infrastructure / Deployment responsibilities están definidas.
• Scope Matrix está completa.
• Explicit Exclusions están documentadas.
• No existe una incógnita material que deje abierto cuánto Website fue vendido.
• El alcance es consistente con el Component Complexity Standard.
• Design Lead validó.
• Tech Lead validó.
• PM validó.

Evidence

La evidencia del cumplimiento del estándar vive dentro del Project Definition en /nk.pulse.

No se requiere crear un documento de Website Scope adicional si toda la información correspondiente está correctamente estructurada en el sistema.