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.