El Inicio Difuso (The Fuzzy Front End)

El Inicio Difuso (The Fuzzy Front End)

El Inicio Difuso (Fuzzy Front End) es como llamamos a todo lo que sucede en el desarrollo de producto antes de crear una sola línea de código. Déjame explicarlo con un ejemplo de otra industria.

Hace unos meses hice un pedido de varios libros en Amazon. Unas horas más tarde, recibí un correo electrónico de Amazon informándome que uno de los libros ya no estaba disponible y que podía obtener el pedido sin el libro o cancelarlo. Decidí cancelarlo porque el libro que faltaba era el que más necesitaba.

¿Qué pasó aquí? Amazon había estado analizando mi pedido y su capacidad antes de comprometerse a entregarlo. Esta fase es lo que llamamos El Inicio Difuso (The Fuzzy Front End). Cuando realizas un pedido a Amazon, no se comprometen a entregarlo hasta que te envíen el correo electrónico confirmando que se está procesando. Antes de ese momento, tanto tú como Amazon o podéis cancelar el pedido.

En la fabricación de productos físicos, el Inicio Difuso (The Fuzzy Front End) no es tan difuso. Se hace algún tipo de análisis económico y de mercado, luego se diseña. Cuando los diseños están listos, se envían a fábrica para su fabricación. Aquí es donde ocurre el compromiso real, cuando la mayoría de las personas y los recursos se asignan para construir o producir algo.

Pero en el desarrollo de software y otros trabajos de conocimiento, el Inicio Difuso (The Fuzzy Front End) es realmente difuso. Mucha gente me dice “estamos haciendo Scrum”, y yo digo “Sí, estás haciendo Scrum, pero tu empresa se toma un año antes de que una idea entre en el Sprint Backlog de un equipo de desarrollo. ¡Muy ágil!”

El Inicio Borroso - The Fuzzy Front End - Upstream Kanban - Kanban System - AKTIA Solutions

El Inicio Difuso

Cada mes de retraso tiene un coste cuantificable de retraso (Cost of Delay). Nuestro objetivo es encontrar oportunidades para comprar Lead Time por menos de este coste. Estas oportunidades aparecen a lo largo del proceso de desarrollo. Sin embargo, hay un lugar en el que encontramos las oportunidades menos costosas para lograr grandes mejoras en el tiempo de comercialización. El extremo delantero difuso.

Cuando los mercados son predecibles y el coste de la demora es bajo, podría tener sentido agregar comprobaciones, puntos de decisión y mucho análisis a esta etapa. Sin embargo, en los mercados en rápido movimiento, cuando el coste de la demora es alto, la toma rápida de decisiones acorta tu horizonte de planificación. En proyectos con un alto coste de retrasos, los errores en la selección de oportunidades pueden ser mucho menos costosos que comenzar un proyecto tarde.

¿Por qué es el Inicio Difuso tan Importante?

  • Es una etapa larga. En muchas compañías, el Inicio Difuso (The Fuzzy Front End) es culpable de más de la mitad del time-to-market.
  • Está lleno de oportunidades baratas de compresión de tiempo. La idea de que para mejorar el time-to-market debemos mejorar los procesos de desarrollo aún es generalizada, pero en primer lugar, recomiendo analizar los procesos de front-end. Este es el lugar donde comprar tiempo es más barato.
  • Esta etapa generalmente consume una pequeña cantidad del presupuesto de desarrollo, pero constituye una gran parte del tiempo disponible. El coste más importante del Inicio Difuso (The Fuzzy Front End) es el coste del retraso (Cost of Delay), no el coste de las personas asignadas al proyecto.

El Reloj del Mercado

El reloj del mercado es implacable. Sigue corriendo tanto si estamos trabajando en el proyecto o no, y con cada minuto que pasa pagamos el coste de la demora. Este coste sigue acumulándose de manera constante incluso cuando nadie está trabajando en el proyecto.

La Paradoja de la Urgencia

Esta es la tendencia de poner más presión y urgencia al desarrollo de productos cuando la oportunidad de mercado es más baja. Al principio de la vida de un proyecto parece haber poca urgencia. Aunque la oportunidad de mercado es mayor en este momento, la oportunidad no es demasiado aparente y existe poco temor a la competencia. Pero, cuando la oportunidad llega al equipo de producto o al equipo de desarollo, la presión comienza a aumentar. Y todos los esfuerzos se ponen en el suboptimizar el desarrollo, mientras que esta es una parte pequeña y generalmente la más eficiente de todo el proceso.

¿Qué sucede en el Inicio Difuso (The Fuzzy Front End)

Durante esta fase difusa, las organizaciones intentan determinar hasta qué punto desean comprometerse a desarrollar una idea. En las compañías ágiles, el Product Manager con la ayuda específica del equipo de desarrollo se ocupará de esta fase. Cuanto más burocrática sea la organización, más tiempo y más personas participarán en esta fase: gestión de producto, finanzas, ingeniería, gestión de proyectos, marketing, ventas, …

Por ejemplo, si estás haciendo Scrum, el Fuzzy Front End incluiría cualquier cosa que le suceda a una idea antes de que llegue al Product Backlog, además de todo el trabajo realizado antes de entrar en el Sprint Backlog de un equipo (punto de compromiso).

Lo que encuentro en muchas compañías, incluso las que adoptan Agile, es que su tasa de descarte es cercana a cero. Por lo tanto, hay poco valor en el proceso de front-end. Si no estás descartando ideas significa que no tienes un criterio para determinar que ideas son mejores y por tanto estás generando mucho desperdicio.

Tareas típicas realizadas en el Inicio Difuso:

  • Modelo de Negocio
  • Estrategia de Producto
  • Validar la oportunidad de mercado
  • Definición de Épicas
  • Dividir Épicas en Historias de Usuario
  • Refinar la comprensión
  • Calcular Cost of Delay
  • Identificar alternativas de solución
  • Estimación de costes
  • Caso de Negocio
  • Evaluación del riesgo técnico
  • Evaluación del riesgo de mercado
  • Evaluación del riesgo económico
  • Proyecciones financieras
  • Investigación de Mercado
  • Especificación del Producto
  • Investigación UX
  • Diseño Visual

¿Cómo podemos mejorar el Inicio Difuso?

Adopta Kanban

En Kanban, nos referimos al Inicio Difuso (The Fuzzy Front End) como Upstream Kanban o Discovery Kanban. Sea como sea, si deseas mejorar, necesita aplicar las seis prácticas básicas de Kanban a tus procesos de front-end y vincularlos a tus procesos de desarrollo.

El Inicio Difuso - The Fuzzy Front End - Kanban System Design - Upstream Kanban - Downstream Kanban - AKTIA Solutions

 

Institucionaliza las Métricas

Esta es una consecuencia de la anterior. Al obtener métricas puedes mejorar un sistema. Lo que no mides no se puede mejorar.

Comenzamos midiendo la duración del upstream, porque el tiempo de entrega es el parámetro de mayor importancia económica aquí. Para medir el tiempo de entrega, debemos acordar los límites que marcan el principio y el final del Inicio Difuso.

Consideramos que el Fuzzy Front End ha comenzado cuando se cumplen dos condiciones:

  • La idea debe ser documentada como una oportunidad.
  • La tecnología para implementar la idea debe existir en algún lugar del mundo.

La segunda condición es importante porque marca la distinción crítica entre el desarrollo de productos y el desarrollo de tecnología.

El verdadero final para el Fuzzy Front End es cuando un número considerable de personas comienza a trabajar en el proyecto (ingenieros, desarrolladores, diseñadores, ventas, operaciones). Es decir, cuando el equipo esté al completo, ya que poco ocurrirá sin un equipo trabajando en una oportunidad.

Crea la Infraestructura de Tecnología y Marketing

Con demasiada frecuencia, el desarrollo de tecnología y la investigación de mercado se encuentran innecesariamente en el camino crítico del desarrollo de productos. Esto hace que estas actividades agreguen enormes costes de demora al proyecto.

Si es necesario desarrollar una nueva tecnología, es aconsejable que esta sea una fase separada del proyecto.

Podemos usar un enfoque similar para la investigación de mercado. En lugar de ver la investigación de mercado como una actividad que se produce como un paso temprano en el desarrollo del producto, debemos verla como una actividad continua. Para comprender a nuestros clientes, sus preferencias, nuestras aplicaciones de productos, productos de la competencia y las tendencias del mercado debe ser una actividad continua.

Necesitamos desarrollar una base de información de mercado independiente de cualquier producto nuevo específico.

Asigna Responsabilidades

Tiene que haber alguien responsable de esta parte del ciclo de desarrollo. Lo que sucede en las grandes empresas es que muchas personas de diferentes áreas están involucradas en esta fase. Entonces, nadie es realmente responsable.

Scrum resolvió este problema al otorgar la mayor parte de esta responsabilidad al Propietario del producto (Product Owner), pero aún así suceden muchas cosas que están fuera del control del Propietario del producto.

Customer Lead Time y System Lead Time

En las adopciones de Kanban, diferenciamos entre el tiempo de entrega del cliente y el tiempo de entrega del sistema (tiempo de entrega local).

El plazo de entrega del cliente es el tiempo que le importa al cliente. El tiempo desde que se realiza el pedido hasta que se realiza la entrega.

El tiempo de entrega del sistema o el tiempo de entrega local es el tiempo de desarrollo, desde el punto de compromiso hasta la entrega. Si estás haciendo Scrum, este será el tiempo transcurrido entre que un ticket ingresa al Sprint Backlog hasta que se entrega a producción.

Los equipos suelen preocuparse por su tiempo de entrega local, pero ¿a quién le importa el tiempo de entrega del cliente? Este es uno de los problemas que encuentro en muchas compañías, hay una presión para que los equipos cumplan, pero a nadie le importa todo lo que ocurre antes.

En algún momento, alguien preguntará: “¿Cuándo se va a hacer?” o “¿Podemos obtener esto por la fecha X?“. Y tenemos que ser capaces de responder a eso adecuadamente. Si tu sistema es impredecible y no estás reuniendo las métricas adecuadas, no podrás responder a esas preguntas. Y las estimaciones con puntos de historia no son una opción 🙂

Si quieres saber más sobre estimaciones en Kanban, echa un vistazo a este artículo.