Metodología de Digital Consulting Plus
Español
← Mapa completoResumen público curado
Índice
Handbook
01DCP Flow: qué es y por qué existe02Cómo funciona DCP Flow03Cómo iniciar un proyecto04Kai y el trabajo con agentes de IA04ACapacidades operativas de Kai05Prompt Cookbook institucional06Solution Discovery explicado para humanos07Arquitectura, stack y ecosistema tecnológico07ATool & MCP Registry07BHostinger MCP para webs y hosting DCP08Quality Gates, QA, seguridad y evidencia08APerfiles de calidad y estrategia de testing09Git, branches, PRs y trabajo multiagente10Deploy, release, soporte y evolución operativa10AContainer First y operación estandarizada de hosts10BDemo práctico de Container First11Cómo evoluciona DCP Flow12Casos y aprendizajes reales13Cómo enseñar DCP Flow14Casos de uso prácticos de DCP Flow15Playbooks end-to-end: Web y Laravel
Entrada 0633%
33%7 / 21
Entrada 06PUBLIC HANDBOOK

Solution Discovery explicado para humanos

Problema, Capability Matrix, SaaS, OSS, componentes, licencia, seguridad, shortlist reproducible, Golden Flows, GAP/TCO/riesgo, ADR y ADOPT/CONFIGURE/INTEGRATE/EXTEND/BUILD.

Source & authority

Explicación pública

PUBLIC HANDBOOK
Basado en
Human Handbook 06 — Solution Discovery explicado para humanos
Fuentes normativas relacionadas
  • NORMATIVE SOURCEStandard · Development Methodology
  • NORMATIVE SOURCEStandard · Solution Discovery Gate
  • NORMATIVE SOURCEStandard · Existing Solution Assessment
Autoridad
Explicación pública — NON-NORMATIVE
Resumen

Problema, Capability Matrix, SaaS, OSS, componentes, licencia, seguridad, shortlist reproducible, Golden Flows, GAP/TCO/riesgo, ADR y ADOPT/CONFIGURE/INTEGRATE/EXTEND/BUILD.

Solution Discovery evita construir por reflejo. Antes de desarrollar, DCP Flow exige investigar qué existe, probar candidatos materiales y medir el GAP con criterios funcionales y técnicos.

El recorrido de discovery

El proceso parte del problema y una Capability Matrix, revisa SaaS como benchmark, productos OSS completos y componentes, y valida licencia, seguridad, compliance, mantenibilidad y dependencia. La shortlist se prueba mediante Golden Flows reproducibles.

Puntos clave
  • SaaS benchmark.
  • Full OSS Product Discovery.
  • Engines y components.
  • Shortlist reproducible y Golden Flows.

ADOPT, CONFIGURE, INTEGRATE, EXTEND o BUILD

La decisión final se documenta en un ADR. ADOPT usa una solución existente con cambios mínimos; CONFIGURE resuelve mediante configuración soportada; INTEGRATE conecta capacidades existentes; EXTEND amplía mediante mecanismos soportados; BUILD crea implementación propia cuando las alternativas anteriores no resuelven razonablemente el outcome o existe justificación material explícita.

Puntos clave
  • GAP funcional y técnico.
  • TCO y complejidad.
  • Security, compliance y lock-in.
  • Maintainability y dependency risk.

Discovery es un recorrido de evidencia, no una lista de enlaces

El Gate parte de Problem Definition y Capability Matrix, usa SaaS como benchmark, busca productos OSS completos y después engines o componentes. Licencia, seguridad y compliance filtran candidatos materiales. Cuando el comportamiento importa, la shortlist se instala de forma reproducible y se ejecutan Golden Flows antes de medir GAP, TCO y riesgo.

Puntos clave
  • 1 Problem → 2 Capabilities.
  • 3 SaaS → 4 Full OSS → 5 Components.
  • 6 License/Security → 7 Reproducible shortlist.
  • 8 Golden Flows → 9 GAP/TCO/Risk → 10 ADR.

Cinco decisiones actuales, evaluadas de forma proporcional

DCP Flow evalúa ADOPT → CONFIGURE → INTEGRATE → EXTEND → BUILD como preferencia, no como escalera mecánica. ADOPT usa una solución existente con cambios mínimos; CONFIGURE usa configuración soportada; INTEGRATE conecta capacidades existentes; EXTEND cubre gaps con mecanismos soportados; BUILD crea implementación propia solo cuando las alternativas anteriores no resuelven razonablemente el outcome o existe justificación material explícita.

Puntos clave
  • ADOPT: cambios mínimos.
  • CONFIGURE: configuración soportada.
  • INTEGRATE: conectar capacidades existentes.
  • EXTEND antes de BUILD cuando fit, riesgo, TCO, upgrades, lock-in, arquitectura y capacidad operativa lo justifican.

Ejecutar candidatos y documentar la decisión evita discovery decorativo

Encontrar un repositorio o leer un README no equivale a validar una solución. Una POC registra versión, runtime, instalación, configuración no sensible, errores y límites; los Golden Flows pueden quedar PASS, PARTIAL, FAIL, BLOCKED o NOT RUN. El ADR conserva candidatos, evidencia, trade-offs y consecuencias para que la decisión sobreviva a la conversación que la originó.

Puntos clave
  • Repository found ≠ candidate validated.
  • Shortlist reproducible cuando la decisión depende del runtime.
  • NOT RUN nunca es PASS.
  • ADR convierte investigación en memoria de decisión.
Glosario contextual＋
Solution Discovery

Proceso de investigar alternativas reales y evaluar ADOPT → CONFIGURE → INTEGRATE → EXTEND → BUILD de forma proporcional antes de una decisión material.

ADOPT

Usar una solución existente con cambios mínimos cuando cubre razonablemente el outcome.

CONFIGURE

Resolver el outcome mediante configuración soportada de una solución existente.

INTEGRATE

Conectar capacidades o sistemas existentes cuando la combinación gobernable resuelve el outcome.

EXTEND

Ampliar una plataforma mediante mecanismos de extensión soportados para cubrir gaps reales.

BUILD

Crear implementación propia cuando ADOPT, CONFIGURE, INTEGRATE y EXTEND no resuelven razonablemente el outcome o existe una justificación material explícita.

IMPLEMENT

Terminología histórica: antiguo término paraguas para implementar una solución existente; superseded por ADOPT / CONFIGURE / INTEGRATE / EXTEND / BUILD.

GAP

Diferencia entre capacidades requeridas y capacidades disponibles en una alternativa evaluada.

TCO

Costo total de propiedad, incluyendo operación, mantenimiento, dependencia y evolución.