Segundo diamante: Desarrollar y Entregar

El segundo diamante recibe un design brief firmado y devuelve una solución funcionando, medida y con un ciclo de retroalimentación abierto. Vuelve a abrir el campo, esta vez en el espacio de la solución, y vuelve a cerrarlo con criterios explícitos.

El capítulo continúa el caso de la municipalidad y su trámite de permisos de construcción. El design brief del capítulo anterior fijó el problema: los solicitantes primerizos no saben qué documentos presentar ni en qué estado está su expediente.

flowchart LR
    DB[Design brief firmado] --> DEV[Desarrollar]
    DEV --> C1[Concepto A]
    DEV --> C2[Concepto B]
    DEV --> C3[Concepto C]
    C1 --> P[Prototipos y pruebas]
    C2 --> P
    C3 --> P
    P --> DEL[Entregar]
    DEL --> PI[Piloto]
    PI --> L[Lanzamiento]
    L --> M[Medición de impacto]
    M --> N[Nuevo Descubrir]

Desarrollar: abrir el espacio de la solución

Principios de diseño del proyecto

Antes de generar conceptos, el equipo traduce el design brief en principios de diseño propios del proyecto. Son reglas cortas que orientan las decisiones y permiten descartar ideas sin discusiones interminables.

Principio del caso	Qué implica	Qué descarta
Decir qué falta antes de que falle	Los requisitos se informan según el tipo de obra, antes de ingresar la solicitud	Formularios genéricos con la lista completa de requisitos
El estado se consulta sin ir	Cualquier solicitante puede saber en qué etapa está su expediente sin acudir al mesón	Soluciones que solo digitalizan el ingreso
Funciona sin cambiar ordenanzas	Las mejoras se apoyan en la normativa vigente	Rediseños que exigen aprobación del concejo
Lo sostiene informática municipal	Tecnología compatible con el equipo interno	Plataformas que requieran un proveedor permanente

Co-diseño con usuarios y expertos

Desarrollar no consiste en que el equipo diseñe y los usuarios opinen al final. Los solicitantes, los revisores y el personal de mesón participan en la generación de ideas. En el caso se realizaron tres talleres de co-diseño:

Taller	Participantes	Resultado
Requisitos por tipo de obra	4 revisores, 2 arquitectos, 3 propietarios	Árbol de decisión de seis preguntas que determina la lista de documentos
Comunicación del estado	3 funcionarios de mesón, 5 solicitantes	Cinco estados comprensibles en lenguaje ciudadano en lugar de doce internos
Canales	Informática, oficina de partes, 4 solicitantes	Priorización de mensajería y web sobre una aplicación móvil propia

Múltiples conceptos en paralelo

La divergencia del segundo diamante se materializa en conceptos alternativos que compiten entre sí. Trabajar con uno solo invita a enamorarse de la primera idea. En el caso se desarrollaron tres:

Concepto	Descripción	Hipótesis que prueba
A. Asistente de requisitos	Cuestionario guiado que entrega la lista exacta de documentos y un comprobante para presentar	Los rechazos bajan si la lista se personaliza antes de ingresar
B. Seguimiento por mensajería	Notificaciones de cambio de estado al teléfono y consulta por código de expediente	Las visitas bajan si el estado llega sin pedirlo
C. Pre-revisión en mesón	El mesón valida la carpeta con una pauta antes del ingreso formal	Un filtro humano con pauta común reduce rechazos sin tecnología nueva

Los conceptos no son excluyentes. Parte del trabajo de Desarrollar es descubrir qué combinación resuelve mejor el brief.

Prototipos de distinta fidelidad

Un prototipo es cualquier artefacto que permita probar una hipótesis con menos esfuerzo que construir la solución completa. La fidelidad se elige según la pregunta.

Fidelidad	Ejemplo en el caso	Pregunta que responde	Costo
Baja: papel y guion	Cuestionario impreso aplicado por un facilitador	¿Las seis preguntas del árbol se entienden?	Horas
Media: clic simulado	Prototipo navegable sin lógica real	¿El flujo y los textos funcionan sin ayuda?	Días
Media: servicio simulado	Un funcionario envía mensajes manuales a 20 expedientes reales	¿Los mensajes reducen visitas?	Semanas
Alta: funcional acotado	Árbol de requisitos implementado en el sitio municipal	¿Se sostiene con la infraestructura actual?	Semanas

flowchart TD
    H[Hipótesis] --> Q{¿Qué necesito saber?}
    Q -->|Si se entiende| PB[Prototipo de baja fidelidad]
    Q -->|Si el flujo funciona| PM[Prototipo navegable]
    Q -->|Si cambia el comportamiento| PS[Servicio simulado con personas]
    Q -->|Si es viable técnicamente| PA[Prototipo funcional acotado]
    PB --> R[Resultado y decisión]
    PM --> R
    PS --> R
    PA --> R
    R -->|Hipótesis refutada| H

Pruebas con usuarios

Cada prototipo se prueba con un protocolo mínimo: objetivo, tareas, participantes, qué se observa y qué resultado confirmaría o refutaría la hipótesis.

Resultados del caso:

Concepto	Prueba	Hallazgo	Decisión
A	12 solicitantes con cuestionario en papel	10 de 12 obtuvieron la lista correcta; dos obras mixtas no encajaban	Agregar una séptima pregunta y una salida al mesón para casos mixtos
B	20 expedientes reales con mensajes manuales durante 3 semanas	Visitas de consulta de esos expedientes cayeron de 2,4 a 0,6 por expediente	Avanzar; definir los cinco estados en lenguaje ciudadano
C	Pauta aplicada por mesón durante 2 semanas	Rechazos bajaron, pero el tiempo de atención por persona subió 40 por ciento	Mantener solo para casos mixtos derivados del concepto A

Desarrollar cierra cuando las hipótesis críticas tienen evidencia y el equipo puede argumentar cuál combinación de conceptos llevar a Entregar.

Entregar: converger y poner en uso

Convergencia a la solución final

La convergencia del segundo diamante usa los criterios del design brief y los principios de diseño del proyecto. En el caso se eligió la combinación A más B, con C reservado para obras mixtas. El concepto de una plataforma completa de solicitud en línea, origen del brief inicial, quedó postergado con una justificación documentada: no atacaba los dos problemas definidos y requería cambios normativos.

Pilotos

El piloto es la primera exposición de la solución a condiciones reales con alcance limitado. Sus parámetros se fijan antes de empezar.

Parámetro	Definición en el caso
Alcance	Solicitudes de ampliación de vivienda, un tercio del volumen total
Duración	Diez semanas
Grupo de comparación	Solicitudes de los mismos tipos en las diez semanas previas
Métricas	Rechazos en primera revisión, visitas de consulta por expediente, tiempo a primera respuesta
Criterio de continuación	Rechazos bajo 40 por ciento y visitas reducidas al menos un tercio
Responsable de la decisión	Director de Obras con el equipo de diseño

Pruebas finales y lanzamiento

Tras el piloto, la solución se ajusta y se extiende al resto de los tipos de obra. El lanzamiento incluye lo que suele olvidarse: capacitación del mesón, actualización de instructivos, comunicación a los colegios profesionales y un canal para reportar fallas.

sequenceDiagram
    participant E as Equipo de diseño
    participant G as Comité de gobernanza
    participant O as Dirección de Obras
    participant U as Solicitantes
    E->>G: Resultados de Desarrollar y propuesta A+B
    G-->>E: Aprobación del piloto con criterios de continuación
    E->>O: Despliegue del piloto en ampliaciones de vivienda
    O->>U: Asistente de requisitos y mensajes de estado
    U-->>O: Solicitudes y consultas durante 10 semanas
    O-->>E: Datos del piloto y del grupo de comparación
    E->>G: Informe del piloto contra criterios
    G-->>E: Decisión de extender a todos los tipos de obra
    E->>O: Lanzamiento con capacitación e instructivos

Medición de impacto

La medición compara contra la línea base del primer diamante y contra los criterios de éxito del design brief.

Indicador	Línea base	Criterio de éxito	Resultado a 6 meses
Rechazos en primera revisión	62 por ciento	Menor a 30 por ciento	27 por ciento
Visitas de consulta por expediente	2,4	Reducción a la mitad	0,8
Tiempo a primera respuesta	21 días hábiles	Sin criterio inicial	14 días hábiles
Satisfacción del solicitante	Sin medición	Instalar medición	4,1 de 5

Las cifras del ejemplo son ilustrativas; lo relevante es la estructura: base, criterio y resultado en la misma tabla.

Bucle hacia un nuevo Descubrir

Entregar no termina el trabajo. La medición expone nuevas preguntas: en el caso, la variación de criterios entre revisores, excluida del primer brief, pasó a ser el desafío más visible una vez resueltos los rechazos por documentación. Ese hallazgo abre un nuevo primer diamante con su propio brief.

Gobernanza y stage gates

Un stage gate es un punto de decisión formal entre fases. Define quién decide, con qué evidencia y cuáles son las salidas posibles: avanzar, iterar, pausar o cancelar.

Compuerta	Evidencia requerida	Decisores	Salidas
Fin de Definir	Design brief firmado	Stakeholders del brief	Avanzar o volver a Descubrir
Fin de Desarrollar	Resultados de pruebas por concepto y recomendación	Comité de gobernanza	Piloto, más pruebas o cancelar
Fin del piloto	Métricas contra criterios de continuación	Director de Obras y equipo	Extender, ajustar o detener
Post lanzamiento	Medición de impacto a 6 meses	Comité de gobernanza	Cerrar, iterar o abrir nuevo Descubrir

La gobernanza protege al proyecto de dos riesgos opuestos: avanzar sin evidencia por presión de plazos y no avanzar nunca por exceso de prudencia.

Cómo documentar decisiones

Las decisiones del segundo diamante se olvidan con rapidez y luego se discuten de nuevo. Un registro de decisiones evita repetir debates y explica a quien llega después por qué la solución es la que es.

Campo	Contenido
Fecha y fase	Cuándo y en qué fase se tomó
Decisión	Qué se decidió, en una frase
Alternativas consideradas	Qué otras opciones hubo
Evidencia	Qué prueba, dato o principio la respalda
Consecuencias	Qué habilita y qué cierra
Quién decidió	Personas o comité
Revisión	Cuándo o bajo qué condición se revisará

Ejemplo del caso: “Postergar la plataforma de solicitud en línea. Alternativas: incluirla en el piloto o descartarla. Evidencia: no reduce rechazos ni visitas según benchmarking y pruebas; requiere cambio de ordenanza. Consecuencia: el ingreso sigue siendo presencial con carpeta validada. Decidido por comité de gobernanza. Revisar cuando los rechazos bajen del 30 por ciento.”

Errores frecuentes en el segundo diamante

Error	Síntoma	Corrección
Un solo concepto desde el inicio	El equipo solo refina la idea original	Exigir al menos tres conceptos con hipótesis distintas
Prototipar sin hipótesis	Se construyen pantallas sin saber qué se quiere aprender	Cada prototipo nace de una pregunta escrita
Piloto sin línea base ni criterio	El piloto termina y nadie sabe si funcionó	Fijar comparación y umbral antes de empezar
Lanzar sin capacitar ni comunicar	El mesón no sabe explicar el cambio	Incluir capacitación e instructivos en el plan de lanzamiento
Cerrar el proyecto al lanzar	Nadie mide ni recoge lo aprendido	Programar la medición y la revisión post lanzamiento como compuerta formal

Ejercicio práctico

Continúa el caso de la municipalidad o aplica los pasos a tu propio design brief.

1. Deriva cuatro principios de diseño del proyecto a partir del design brief. Para cada uno, anota una idea que descarta.
2. Propón tres conceptos alternativos, cada uno con la hipótesis que pone a prueba.
3. Para cada concepto elige la fidelidad de prototipo adecuada y justifica la elección con la pregunta que necesitas responder.
4. Redacta un protocolo de prueba de una página para uno de los prototipos: objetivo, tareas, participantes, observaciones y resultado esperado.
5. Define el piloto: alcance, duración, grupo de comparación, métricas, criterio de continuación y responsable de la decisión.
6. Construye la tabla de medición de impacto con línea base, criterio y una columna vacía para el resultado.
7. Escribe dos entradas del registro de decisiones usando la plantilla del capítulo.
8. Dibuja las compuertas del proyecto en un diagrama Mermaid flowchart con las salidas posibles de cada una.

Autoevaluación

1. ¿Para qué sirven los principios de diseño del proyecto en Desarrollar?

• A. Para reemplazar el design brief.
• B. Para fijar el presupuesto del piloto.
• C. Para orientar decisiones y descartar ideas con reglas acordadas en lugar de discusiones repetidas.
• D. Para definir los indicadores de impacto.

2. ¿Qué determina la fidelidad adecuada de un prototipo?

• A. La pregunta o hipótesis que se necesita responder.
• B. El tamaño del equipo de desarrollo.
• C. La fase del proyecto en el calendario.
• D. La preferencia de los stakeholders.

3. ¿Qué debe fijarse antes de iniciar un piloto?

• A. La fecha del lanzamiento masivo.
• B. Línea base, métricas, criterio de continuación y responsable de la decisión.
• C. El diseño de la campaña de comunicación.
• D. El proveedor que mantendrá la solución.

4. ¿Qué ocurre con lo aprendido en la medición de impacto según el Doble Diamante?

• A. Se archiva como cierre del proyecto.
• B. Se usa solo para calcular el retorno de inversión.
• C. Se entrega al área de informática para el mantenimiento.
• D. Alimenta un nuevo Descubrir con su propio brief.

Respuestas

1. C. Los principios traducen el brief en reglas operativas para decidir rápido y de forma consistente.
2. A. La fidelidad se elige según lo que se quiere aprender, no según la etapa ni el gusto.
3. B. Sin esos cuatro elementos no es posible saber si el piloto funcionó ni quién decide continuar.
4. D. El modelo es cíclico: la medición abre nuevas preguntas que inician otro primer diamante.

Checklist

• Derivé principios de diseño del proyecto a partir del design brief.
• Desarrollé al menos tres conceptos con hipótesis distintas y co-diseño con usuarios.
• Cada prototipo nació de una pregunta escrita y tiene la fidelidad que esa pregunta exige.
• El piloto tiene línea base, métricas, criterio de continuación y responsable antes de empezar.
• Las decisiones están registradas con alternativas, evidencia y condición de revisión.
• La medición post lanzamiento está programada como compuerta formal y alimenta un nuevo Descubrir.