Binary Bridges
Menú

Método

Cuatro pilares, un solo puente.

No inventamos una metodología: combinamos marcos probados en la industria y en la academia, y los adaptamos a equipos pequeños que construyen y operan lo que diseñan. Cada fase termina en una decisión que tomas tú, con evidencia en la mano.

01 / Marco de referencia

De dónde viene cada fase.

Nuestras cuatro fases se corresponden con los marcos que usan las consultoras y los equipos de producto más grandes. Esta tabla muestra la equivalencia.

Binary BridgesDouble Diamond[1]Stage-Gate[2]Entrega y operación[15]
01 EntenderDescubrirDescubrimiento y alcance (etapas 0 y 1)Hipótesis y línea base
02 DiseñarDefinir y desarrollarCaso de negocio (etapa 2)Lean Inception y producto mínimo viable
03 ConstruirEntregarDesarrollo, pruebas y validación (etapas 3 y 4)Scrum y ciclo construir-medir-aprender
04 OperarFuera del diamante: empieza tras la entregaLanzamiento y revisión posterior (etapa 5)SRE y métricas DORA

02 / Fases

Qué pasa en cada fase.

  1. Entender

    1 a 2 semanas

    Convertir una intuición en un problema escrito y medible.

    Qué hacemos

    • Entrevistas con quienes operan el proceso, no solo con quienes lo aprueban
    • Mapa del proceso actual y de los sistemas que toca
    • Revisión de datos disponibles y de su calidad
    • Línea base: cuánto cuesta hoy el problema, en tiempo o en dinero

    Qué recibes

    • Diagnóstico con el problema y la línea base medida
    • Mapa de sistemas, datos y riesgos
    • Recomendación honesta: construir, comprar o no hacer nada
    Tu equipo
    Un responsable del negocio y acceso a quienes hacen el trabajo, unas 4 horas por semana.
    Punto de decisión
    Decides si el problema vale la inversión. Si no, te quedas con el diagnóstico.

    Marcos de referencia

    • Double Diamond: descubrir[1]
    • Stage-Gate: descubrimiento y alcance[2]
    • Resolución de problemas guiada por hipótesis[5]
    • Design thinking: inspiración[3]

    Plantillas y artefactos

    • Árbol de problemas (issue tree)[5]
    • Diagnóstico con la conclusión primero (principio de la pirámide)[6]
    • Blueprint del servicio actual[9]
    • Comprensión del negocio y de los datos (CRISP-DM), en proyectos de IA y datos[14]

  2. Diseñar

    2 a 3 semanas

    Decidir qué construir, qué no, y cómo sabremos que funcionó.

    Qué hacemos

    • Arquitectura de la solución y decisiones técnicas documentadas
    • Prototipo navegable probado con usuarios reales
    • Plan de entregas por incrementos, del más valioso al menos
    • Estimación de costo y tiempo por incremento

    Qué recibes

    • Documento de arquitectura y experiencia en uno solo
    • Prototipo validado
    • Plan de entregas con alcance, costo y métricas de éxito
    Tu equipo
    Sesiones de revisión semanales y la aprobación del alcance.
    Punto de decisión
    Apruebas arquitectura, alcance y presupuesto antes de la primera línea de código.

    Marcos de referencia

    • Double Diamond: definir y desarrollar[1]
    • Diseño centrado en las personas (ISO 9241-210)[4]
    • Lean Inception[8]
    • Stage-Gate: caso de negocio[2]

    Plantillas y artefactos

    • Blueprint del servicio futuro[9]
    • Diagramas de arquitectura C4[11]
    • Registros de decisiones de arquitectura (ADR)[10]
    • Canvas del producto mínimo viable[8]

  3. Construir

    Iteraciones de 2 semanas

    Software funcionando en producción desde las primeras iteraciones.

    Qué hacemos

    • Entregas pequeñas, probadas y desplegadas en cada iteración
    • Pruebas automatizadas y revisión de código en cada cambio
    • IA evaluada contra tus datos, con métricas de calidad antes de salir
    • Demostración cada dos semanas con lo que ya funciona

    Qué recibes

    • Software en producción en tu infraestructura o en la nube que elijas
    • Código en tu repositorio desde el primer commit
    • Documentación técnica y de uso, al día con cada entrega
    Tu equipo
    Un dueño de producto que prioriza y asiste a la demostración quincenal.
    Punto de decisión
    Cada dos semanas ves software funcionando y decides qué sigue, o si paramos.

    Marcos de referencia

    • Scrum[13]
    • Construir-medir-aprender (Lean Startup)[12]
    • Double Diamond: entregar[1]
    • Stage-Gate: desarrollo, pruebas y validación[2]

    Plantillas y artefactos

    • Definición de terminado[13]
    • Evaluación de modelos antes de desplegar (CRISP-DM)[14]
    • Métricas de entrega de DORA[15]
    • ADR vivos, actualizados con cada decisión[10]

  4. Operar

    Continuo

    Que la solución siga entregando valor cuando nos vayamos.

    Qué hacemos

    • Monitoreo, alertas y tableros de salud del sistema
    • Medición contra la línea base del día uno
    • Capacitación y traspaso a tu equipo
    • Soporte y evolución con acuerdos de servicio claros

    Qué recibes

    • Tablero con el impacto medido frente a la línea base
    • Manuales de operación para cada incidente previsible
    • Accesos, cuentas y conocimiento a nombre de tu empresa
    Tu equipo
    Las personas que van a operar la solución, durante el traspaso.
    Punto de decisión
    Decides si tu equipo sigue solo o si continuamos con soporte.

    Marcos de referencia

    • Site Reliability Engineering (SRE)[16]
    • Programa de investigación DORA[17]
    • Stage-Gate: revisión posterior al lanzamiento[2]

    Plantillas y artefactos

    • Objetivos de nivel de servicio (SLO) y presupuesto de errores[16]
    • Manuales de operación (runbooks)[16]
    • Análisis de incidentes sin culpables (postmortems)[16]
    • Tablero de métricas de entrega[17]

03 / Conexión con la gran consultoría

Los mismos marcos, sin la estructura de una gran firma.

Estas son las prácticas de firmas globales que adoptamos, y dónde aparecen en nuestro método. No tenemos relación comercial con estas firmas: citamos sus marcos publicados.

  • McKinsey & Company

    Resolución de problemas guiada por hipótesis y principio de la pirámide[5]

    En Entender partimos de una hipótesis y un árbol de problemas, y entregamos el diagnóstico con la conclusión primero.

  • McKinsey & Company

    Índice de Diseño de McKinsey[7]

    Su estudio encontró que las empresas del cuartil superior en diseño crecieron sus ingresos 32 puntos porcentuales más que sus pares en cinco años. Por eso diseñamos con usuarios antes de escribir código.

  • Thoughtworks

    Lean Inception[8]

    En Diseñar usamos su dinámica para alinear a las personas en torno al producto mínimo viable en pocos días.

  • IDEO

    Design thinking: inspiración, ideación e implementación[3]

    Entender y Diseñar siguen ese ciclo: primero observamos a las personas, luego proponemos, y probamos antes de construir.

  • Google

    Site Reliability Engineering y DORA[16]

    En Operar medimos lo que importa: objetivos de nivel de servicio y las métricas de entrega que DORA asocia al desempeño de los equipos.

04 / Referencias

Bibliografía.

Formato APA, 7.a edición. Enlaces verificados en septiembre de 2026.

  1. Design Council. (2019). Framework for innovation: Design Council's evolved Double Diamond. https://www.designcouncil.org.uk/our-resources/framework-for-innovation/
  2. Cooper, R. G. (1990). Stage-gate systems: A new tool for managing new products. Business Horizons, 33(3), 44–54. https://doi.org/10.1016/0007-6813(90)90040-I
  3. Brown, T. (2008). Design thinking. Harvard Business Review, 86(6), 84–92. https://hbr.org/2008/06/design-thinking
  4. International Organization for Standardization. (2019). Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems (ISO 9241-210:2019). https://www.iso.org/standard/77520.html
  5. Rasiel, E. M. (1999). The McKinsey way. McGraw-Hill.
  6. Minto, B. (2009). The pyramid principle: Logic in writing and thinking (3rd ed.). Pearson Education.
  7. Sheppard, B., Sarrazin, H., Kouyoumjian, G., & Dore, F. (2018). The business value of design. McKinsey Quarterly. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-business-value-of-design
  8. Caroli, P. (2022, February 22). Lean inception. martinfowler.com. https://martinfowler.com/articles/lean-inception/
  9. Shostack, G. L. (1984). Designing services that deliver. Harvard Business Review, 62(1), 133–139. https://hbr.org/1984/01/designing-services-that-deliver
  10. Nygard, M. (2011, November 15). Documenting architecture decisions. Cognitect. https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
  11. Brown, S. (n.d.). The C4 model for visualising software architecture. https://c4model.com/
  12. Ries, E. (2011). The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses. Crown Business. https://theleanstartup.com/
  13. Schwaber, K., & Sutherland, J. (2020). The Scrum guide. https://scrumguides.org/scrum-guide.html
  14. Chapman, P., Clinton, J., Kerber, R., Khabaza, T., Reinartz, T., Shearer, C., & Wirth, R. (2000). CRISP-DM 1.0: Step-by-step data mining guide. SPSS.
  15. Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science of lean software and DevOps. IT Revolution Press. https://itrevolution.com/product/accelerate/
  16. Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (Eds.). (2016). Site reliability engineering: How Google runs production systems. O’Reilly Media. https://sre.google/sre-book/table-of-contents/
  17. DORA. (n.d.). DORA research program. Google Cloud. https://dora.dev/

¿Empezamos por entender tu problema?

La primera fase es corta y termina con un diagnóstico que te sirve aunque no sigamos juntos.

Agenda una conversación