Blog

Google Design Sprint - Fase 5: Prototipo

Hasta ahora, en el Google Design Sprint hemos avanzado por cuatro fases clave. Primero, se identificó y comprendió el problema, estableciendo un enfoque claro. Luego, se generaron múltiples soluciones mediante brainstorming y bocetos. Y finalmente, el equipo evaluó estas propuestas utilizando dinámicas estructuradas para seleccionar la idea más prometedora.

Google Design Sprint - Fase 4: Decisión

En las primeras tres fases del Google Design Sprint, el equipo ha trabajado en comprender el problema, definir un enfoque claro y generar posibles soluciones. Con un conjunto de propuestas sobre la mesa, el equipo entra en la Fase 4: Decisión, en esta etapa, el objetivo es evaluar los Solution Sketches presentados y seleccionar una única dirección a seguir. Para lograrlo, el equipo utiliza dinámicas de toma de decisiones que permiten alcanzar un consenso sobre la idea más prometedora.

Google Design Sprint - Fase 3: Boceto

En las primeras dos fases del Google Design Sprint, el equipo ha trabajado en comprender a fondo el problema y definir un enfoque claro para resolverlo. En la Fase 1: Entendimiento, se creó una base de conocimiento compartida mediante la exploración de distintos puntos de vista, obteniendo un listado de los diferentes problemas y oportunidades del proyecto.

Google Design Sprint - Fase 2: Definición

La segunda fase que comprende la metodología del Google Design Sprint es la fase de Definición. En la fase anterior, Entendimiento, el equipo exploró los diferentes problemas y oportunidades del proyecto, sin enfocarse en soluciones y recopilando información clave.

Google Design Sprint - Fase 1: Entendimiento

La metodología del Google Design Sprint está compuesta por 6 fases, cada una de ellas con tareas y objetivos claramente definidos. La primera fase es la del Entendimiento, en ella se busca crear una base de conocimiento compartida entre todos los participantes. Para ello, expertos de diferentes áreas del negocio exponen el problema desde perspectivas clave, como la empresarial, la del usuario, la de los competidores y la tecnológica.

Google Design Sprint

El Design Sprint, inicialmente desarrollado por Google Ventures, es un proceso de cinco días diseñado para resolver preguntas clave de negocio mediante diseño, creación de prototipos y pruebas con clientes. Este proceso combina lo mejor de la estrategia empresarial, la innovación, la ciencia del comportamiento y el design thinking en una metodología probada que cualquier equipo puede usar.

8 pasos de john Kotter

John Kotter, un profesor emérito de la Escuela de Negocios de Harvard, es reconocido mundialmente por su trabajo en liderazgo y cambio organizacional. Su modelo de cambio de ocho pasos, descrito en su libro "Leading Change" (1996), se ha convertido en un estándar para guiar a las organizaciones a través de procesos de transformación exitosos. A continuación, se detallan estos ocho pasos junto con ejemplos prácticos y recomendaciones para su implementación efectiva.

1. Crear un sentido de urgencia

Técnicas ágiles de Discovery

Veamos qué significa hacer Product Discovery o Descubrimiento de Producto y cómo lo podemos aprovechar para crear productos con agilidad.

Para qué sirve el Product Discovery

Agilidad Disciplinada

La Agilidad Disciplinada (Disciplined Agile, DA) es una metodología que combina la flexibilidad y la adaptabilidad del desarrollo ágil con un enfoque estructurado y disciplinado. Diseñada por Scott Ambler y Mark Lines, DA busca ofrecer un marco integral que abarque todo el ciclo de vida del desarrollo de software, proporcionando una guía completa para la entrega ágil.

Principios y Valores de la Agilidad Disciplinada

Diseño Ágil con TDD

El Desarrollo Dirigido por Pruebas (TDD) es una metodología de desarrollo de software que pone énfasis en escribir pruebas automatizadas antes de escribir el código de producción. En lugar de escribir código y luego probarlo, con TDD primero se escriben las pruebas que describen el comportamiento deseado del código. Luego, se implementa el código mínimo necesario para que las pruebas pasen. Finalmente, se refactoriza el código para mejorar su estructura y legibilidad, sin cambiar su funcionalidad.

Pages