Artículos - Introducción

Aquí encontrará artículos de miembros del Instituto Lean Management, así como de autores de la Lean Global Network que puede encontrar en versión original en:

          

 

Como miembro registrado e identificado, tendrá acceso a muchos más contenidos

La sala de obeya limita el número de incógnitas antes de comenzar a desarrollar un producto. En este sentido, es una herramienta para descubrir, más que para entregar.

Uno de los principales desafíos de una empresa emprendedora es hacer crecer los equipos de desarrollo de productos e ingeniería. Siempre parece que los equipos de tecnología nunca son lo suficientemente rápidos: la hoja de ruta del producto está repleta de características por desarrollar, y los vicepresidentes de toda la empresa (ventas, mercadotecnia, atención al cliente, operaciones) están continuamente compitiendo para priorizar sus propias solicitudes. a la parte superior de la lista. Esto representa un desafío difícil para el CEO y muy difícil para el Responsable de Producto.

Al principio, parece un problema de productividad: ¿cómo podemos hacer que los desarrolladores amplíen las funciones más rápido? Tras una inspección más cercana, a menudo parece que:

  1. Los desarrolladores dedican una cantidad excesiva de tiempo a lidiar con especificaciones incompletas o incoherentes, debido a que las necesidades de los usuarios no se entienden completamente.
  2. Los cambios se solicitan con frecuencia durante el desarrollo, lo que aumenta el coste de las nuevas evoluciones y desperdicia un tiempo precioso de desarrollo.
  3. Las evoluciones generan nuevos problemas para los usuarios dentro y fuera de la empresa, porque se omitieron detalles importantes cuando se especificaron las funciones o porque el equipo se apresuró a entregar las características que presentaban defectos. Esto, a su vez, crea la necesidad de nuevas "características" para solucionar la situación.
  4. A pesar de todo el esfuerzo, los resultados del negocio son decepcionantes.

De hecho, el problema no es la entrega, ni la organización de personas y tareas para obtener un resultado conocido de manera más eficiente. Es una cuestión de descubrimiento: explorar y definir lo que debería ser el producto para hacer una apuesta menos arriesgada.

¿Qué nos enseña Lean sobre el descubrimiento?

Entender el valor: una cuestión de trabajo en equipo

Desde una perspectiva Lean, el descubrimiento es primero aprender cómo el producto crea valor para el cliente y, segundo, cómo diseñar y fabricar el producto para que no impongamos el coste de nuestros desperdicios al cliente.

El valor y el desperdicio deben considerarse a lo largo de la cadena de valor y no solo en el producto tecnológico principal. Como consecuencia, el descubrimiento abarca todo el producto, desde la experiencia del cliente hasta los procesos internos de la empresa.

Tomemos como ejemplo un servicio para compartir coches. El producto principal podría ser la aplicación utilizada para reservar un viaje o el sistema que asigna viajes a los conductores. Por el contrario, todo el producto abarca toda la gama de sistemas y servicios que forman la experiencia del usuario. En este caso, un elemento importante del rendimiento desde la perspectiva del cliente es el tiempo que uno tiene que esperar por un automóvil. Esto depende del algoritmo de asignación de recorrido, pero también del número de conductores en las carreteras en un momento dado. Esto significa que para diseñar un servicio que cumpla plenamente su promesa a los usuarios, también debe tener en cuenta toda la experiencia del conductor y persuadir a miles de ellos para que utilicen la plataforma. Esto, a su vez, crea la necesidad de un servicio de integración escalable para los conductores, así como de muchas personas responsables de manejar los contratiempos diarios.

Para que el producto sea un éxito, debe diseñar un conjunto completo de productos y procesos. Como consecuencia, el equipo de productos debe incluir representantes de todos los departamentos de una empresa: producto, tecnología, marketing, ventas, operaciones, legal, etc.

Lograr que todas estas personas trabajen juntas hacia un objetivo común es difícil: generalmente tienen diferentes prioridades y, a menudo, no ven el impacto de sus decisiones locales en el "panorama general". No hay ninguna receta a seguir para alinearlos todos. Tradicionalmente, esto se maneja como un problema organizativo, se maneja en términos de roles y procesos, pero se enmarca como un ejercicio de aprendizaje: “¿Quién necesita aprender qué para que el producto sea un éxito?” ¿Pero cómo se obtiene tal grupo diverso, persiguiendo diferentes agendas, para aprender juntos y avanzar en la misma dirección?

El ingeniero jefe

Toyota resuelve este problema al designar a un ingeniero jefe responsable de todas las dimensiones del producto. Piense en el ingeniero jefe como un empresario, una persona motivada y apasionada por el producto y los clientes. Una persona con conocimientos suficientes para profundizar en cuestiones técnicas y con suficientes habilidades de liderazgo para manejar la política del proyecto. Steve Jobs, a pesar de ser también CEO de Apple, fue el arquetipo de un ingeniero jefe.

El trabajo principal del ingeniero jefe es crear las condiciones para una colaboración profunda entre especialistas de áreas muy diferentes. El Ingeniero jefe no tiene autoridad jerárquica sobre ellos a medida que pasan de un proyecto a otro, pero tiene plena autoridad para hacer que el producto sea un gran éxito. Por lo tanto, es importante que su competencia sea reconocida y respetada si las personas deben seguir su visión. El Ingeniero jefe tiene que trabajar duro para construir un business case sólido para "vender" sus ideas y no puede imponer su punto de vista a las personas.

Los ingenieros jefe son una raza rara, y no hay dos iguales. Sin duda, tienen rasgos personales específicos, pero también se desarrollan a lo largo de los años para adquirir una amplia gama de habilidades, trabajando en muchas actividades diferentes en toda la empresa. Siguen aprendiendo y dirigiendo el aprendizaje del equipo de producto con una herramienta específica: la obeya.

La obeya

A principios de la década de 1990, Takeshi Uchiyamada, ingeniero jefe de Toyota, tuvo un desafío difícil: diseñar el automóvil del siglo XXI, con objetivos de consumo de combustible muy agresivos. En menos de tres años, el primer automóvil híbrido, el Prius, fue lanzado al mercado, 15 años por delante de la competencia. Para lograr tal hazaña, el ingeniero jefe también tuvo que inventar un nuevo enfoque de desarrollo de productos y procesos. Diseñó un nuevo tipo de gestión visual, que desde entonces se ha extendido por las oficinas de ingeniería de Toyota: la obeya.

Obeya significa "habitación grande" en japonés. Es una sala grande donde las paredes están cubiertas de información: gráficos, dibujos, planos, etc.

Una obeya no es otra herramienta de gestión de proyectos. El objetivo no es revisar el progreso ni priorizar las funciones. El objetivo es más bien pensar profundamente, hablar, discutir sobre los principales temas del proyecto. Es un espacio para el descubrimiento.

Los ingenieros jefe hacen que la información y el conocimiento sean visibles en la obeya porque es una forma poderosa de alinear a las personas. Los malentendidos aparecen rápidamente para que las personas puedan hablar sobre ellos y desarrollar una comprensión compartida de la situación. Esto lleva a discusiones prolongadas y argumentos acalorados, pero este es el proceso mediante el cual las personas se ponen en la misma página y aprenden juntas. El tiempo dedicado a alinear a las personas al principio se amortiza en las fases posteriores del proyecto.

No hay reglas establecidas para lo que el ingeniero jefe y su equipo deben mostrar en las paredes. Cada obeya es única, ya que depende de la madurez del equipo y la etapa del proyecto. Hay, sin embargo, algunos aspectos que deben ser explorados, independientemente del producto. Estos aspectos toman la forma de cuatro preguntas:

1. ¿Cuál es el problema que queremos resolver, y para quién?

Crear un producto exitoso es menos un asunto de construcción ("añadamos esta característica") que un ejercicio de resolución de problemas ("¿qué debemos hacer para obtener este resultado?"). El problema es que generalmente corremos a la solución antes de definir el problema a resolver.

Los profesionales de Lean utilizan el método científico, con el ciclo Planificar-Hacer-Verificar-Actuar (PDCA), para resolver problemas de negocios. El desarrollo de productos no es una excepción. Construir un producto es en sí mismo un bucle PDCA:

  • Plan: definir el problema del cliente a resolver, desarrollar una comprensión profunda de la situación e identificar las principales características del producto objetivo.
  • Do (Hacer): construir el producto.
  • Check (Verificar): analice los resultados del negocio para ver qué funciona y qué no.
  • Actuar: extraer lecciones para mejorar el próximo ciclo de desarrollo de productos.

Una buena definición del problemas conduce a un objetivo ambicioso. Por ejemplo, el desafío de Shinkansen era permitir que las personas viajaran de Tokio a Osaka en tres horas en menos de cinco años.

Lo siguiente para aprender y explorar en la obeya es cómo los clientes perciben el valor. Este tipo de aprendizaje es el resultado de una inmersión profunda en la vida de los clientes. Comienza con las quejas de los clientes, tratando de averiguar qué intentaban hacer con las soluciones actuales y de qué manera estas soluciones les fallaron. También significa pasar tiempo con ellos para comprender mejor cómo tratan de resolver sus problemas hoy.

El ingeniero jefe y el equipo de producto necesitan tener una idea de:

  • ¿Quiénes son los clientes objetivo, cuál es su estilo de vida y su gusto?
  • ¿Cuál es el problema concreto que quieren resolver por sí mismos?
  • ¿En qué contexto y circunstancias específicas?
  • ¿De qué alternativas pueden elegir para obtener lo que quieren?
  • ¿Por qué eligen una alternativa sobre otra?
  • ¿Qué aman y qué odian de las soluciones existentes?
  • ¿Qué problemas específicos experimentan con las soluciones existentes?
  • ¿Qué preferencias debemos asegurarnos de satisfacer completamente para no decepcionarlas?
  • ¿Qué aspectos podemos / debemos mejorar para captar la atención de las personas?

Por ejemplo, para un servicio de coches compartidos, el cliente desea ir del punto A al punto B, y para lograr esto, puede elegir entre servicios de la competencia, una compañía de taxis tradicionales, pero también servicios de tren o autobús. Su decisión se basará en un conjunto de preferencias para cada solución:

  • Facilidad de reservar un viaje.
  • No tienes que esperar demasiado.
  • Un paseo cómodo.
  • Una buena experiencia con el conductor.
  • No demasiado caro.
  • Etc.

Lo mismo se aplica a los conductores, que tienen que elegir entre diferentes plataformas. La pregunta decisiva que impulsará la visión del producto es: ¿cuál es la principal preferencia de los clientes objetivo? ¿Cómo podemos diferenciar la próxima generación del producto en algo que se alinee con lo que más importa a los clientes? Esto es clave para enfocar los esfuerzos de desarrollo de productos en lo que más importa.

2. ¿Qué se espera que la empresa gane con el proyecto?

Hace unos años, una compañía de publicitaria comenzó a desarrollar un sistema de gestión de flujo de trabajo interno. El objetivo era proporcionar a los fotógrafos, diseñadores gráficos, responsables de producto e impresores una solución todo en uno para evitar perder el tiempo en una avalancha de correos electrónicos y archivos de Excel. El proyecto fue difícil, principalmente porque el equipo de producto no tuvo acceso a representantes clave de los diferentes departamentos que se enfocaron en otras prioridades. Dos años después, el producto estaba en funcionamiento, pero dirección se enfrentó a un problema: habían invertido la mayor parte de las ganancias de la empresa en esa herramienta, pero no pudieron averiguar qué beneficios había aportado al negocio.

Una de las primeras preguntas de descubrimiento que el Ingeniero Jefe y su equipo deben responder al inicio del proyecto es: ¿cuáles son los beneficios esperados para la empresa? El objetivo aquí es elaborar un business case convincente que ayude a:

  • convertirlo en un elemento de alta prioridad para todas las partes interesadas necesarias;
  • establecer la estructura adecuada de costes del proyecto;
  • verificar que las ganancias sean efectivamente obtenidas cuando el producto esté listo.

En este ejemplo, el business case podría haber sido reducir la rotación de clientes al ofrecer una interacción más agradable con los equipos de clientes. También podría haber sido reducir a la mitad el tiempo de entrega de las nuevas campañas publicitarias, o aumentar la productividad del equipo de diseño gráfico, medido como la cantidad de proyectos de diseño gestionados por persona cada mes. También podría contribuir al crecimiento de la empresa desbloqueando ventas que no serían posibles sin ese producto.

3. ¿Qué decisiones técnicas debemos tomar para crear un producto coherente y rentable?

El ingeniero jefe y su equipo desarrollan su conocimiento del producto explorando cómo sus diferentes funciones contribuyen o no al valor percibido por los clientes y cómo estas funciones interactúan entre sí. Intentan descubrir qué problemas deben resolverse antes de construir el producto.

Tomemos por ejemplo el aumento de precios. Esta función ayuda a reducir el tiempo de espera para los pasajeros al atraer a más conductores para que estén disponibles cuando la demanda es alta. Sin embargo, también daña la experiencia del conductor con precios altos en el momento en que más necesitan el servicio. También hace que el precio sea menos claro para los conductores, que pueden sentirse engañados cuando tienen la impresión de que la demanda debería ser alta pero que no aumentan sus ingresos. En la escala de dicho servicio, esto significa cientos o miles de llamadas adicionales para los equipos de soporte de usuarios y conductores, y por lo tanto un gran impacto en los costes operativos.

Para detectar y abordar este tipo de problemas antes de que se desarrollen, el Ingeniero Jefe comienza por hacer que el equipo haga un mapa de cómo se relacionan las funciones del producto con las preferencias del cliente y velar por las compensaciones que deben abordarse. El objetivo es descubrir cómo satisfacer mejor estas preferencias sin dejar de ser rentable. El equipo también trata de comprender cómo las funciones del producto interactúan entre sí para encontrar fricciones que pueden hacer que el producto sea más complejo y difícil de construir y mantener.

Luego, el equipo puede aprender sobre las maneras de resolver las compensaciones probando diferentes combinaciones y analizando su desempeño, y resumiendo sus aprendizajes en la obeya.

En esta etapa, uno de los principales riesgos es cambiar aspectos de los productos que no deberían tocarse, lo que llamamos "tecnología heredada", mientras mantenemos aspectos que crean una complejidad innecesaria y evitan la innovación, lo que llamamos "tecnología legada". Para el equipo de productos, éste es un verdadero desafío, ya que no siempre es tan fácil distinguirlos.

La tecnología heredada es todo lo que define la esencia misma del producto y justifica su existencia. Un ejemplo común son los teclados QWERTY y AZERTY que no han cambiado en 150 años desde que se inventaron las máquinas de escribir. Estas extrañas distribuciones de teclado se crearon originalmente para compensar un desafío mecánico: las teclas más utilizadas se enredarían. Algunas fábricas de teclados han tratado desde entonces de proponer velocidades de escritura más altas con diseños más eficientes, pero ya no están aquí para contarlo. Las personas de todo el mundo se han acostumbrado tanto a ellos que se han resistido enérgicamente al cambio. Esta es la esencia de la tecnología heredada.

A la inversa, el sistema de resortes que hace rebotar las teclas puede considerarse una tecnología legada, ya que los nuevos enfoques resultan en una escritura más silenciosa y rápida. Compañías como Apple invierten constantemente en otros aspectos de la tecnología (la forma y el espaciado de las teclas, la distancia de desplazamiento vertical, etc.) para mejorar las soluciones legadas y mantener el mismo diseño de herencia.

Pero, una vez más, quizás incluso el diseño pueda ser considerado algún día como "legado", especialmente si la tecnología de reconocimiento de voz fuera lo suficientemente confiable como para reemplazar la escritura. Esta es una discusión interminable dentro de un equipo de productos, por lo que debe estar sucediendo en la obeya.

4. ¿Estamos construyendo un producto de calidad a tiempo para vencer a la competencia?

El descubrimiento también se aplica al proceso de desarrollo del producto en sí. El ingeniero jefe y el equipo de producto acuerdan:

  • cómo definen y rastrean la calidad a lo largo del proyecto;
  • qué hitos deben alcanzar para poder cumplir a tiempo;
  • Cómo medir los costes.

La calidad se refiere al producto en sí. Las métricas de calidad proporcionan información sobre si las funciones del producto cumplen con las expectativas de los clientes en términos de fiabilidad, rendimiento y facilidad de uso. Para elegir las métricas correctas que los guiarán a lo largo del ciclo de vida del producto, el ingeniero jefe y el equipo del producto deben ponerse en el lugar de sus clientes objetivo: ¿qué NO debe salir mal? Tome una bombilla LED de luz: un indicador de calidad podría ser que respete la vida útil, el brillo y el color esperados, que no se sobrecaliente o que sea resistente a los golpes. Estos indicadores de calidad son a menudo el resultado de compensaciones técnicas que el equipo de producto tuvo que resolver con anticipación. Por lo tanto, tiene sentido realizarles un seguimiento a lo largo de las etapas de diseño y desarrollo, para que el equipo pueda descubrir todas las formas en que no están logrando construir un producto de calidad.

Además de la calidad, el ingeniero jefe y el equipo de productos generalmente realizarán un seguimiento del tiempo de entrega utilizando un plan de proyecto grande y visible. Este plan se utiliza para alinear a todos en los hitos principales del producto y ver cómo las actividades y decisiones de cada equipo afectan a los demás. El plan del proyecto permite a los miembros del equipo anticipar mejor los problemas y discutir formas de resolverlos antes de que comprometan la entrega oportuna del producto. Pero, sobre todo, el plan del proyecto es una forma para que el ingeniero jefe y el equipo de producto descubran formas de intensificar la colaboración entre los diversos equipos y partes interesadas dentro y fuera de la organización.

Finalmente, una obeya generalmente incluye métricas para monitorizar los costes (no solo los costes de desarrollo del producto, sino también los costes que son necesarios para apoyar a los clientes una vez que el producto está activo). Esto incluye infraestructura, equipos de soporte y operaciones diarias. Por ejemplo, para una empresa de comercio electrónico, cuánto tiempo requerirá añadir un nuevo producto a su sitio, reponer una acción o proponer una nueva promoción. Aquí, el objetivo es descubrir el impacto de las opciones de ingeniería del equipo en todo el proceso, no solo en el desarrollo.

Durante las últimas dos décadas, Agile se ha extendido enormemente como una contramedida a las metodologías en cascada donde los productos vieron la luz solo después de meses de especificación, diseño, desarrollo y prueba. La consecuencia inesperada de este cambio de paradigma es que los equipos de desarrollo de productos ahora tienen una tendencia a acelerar las fases iniciales de un proyecto. Al pasar de un extremo a otro, hemos creado nuevas fuentes de costes, en forma de retrabajo a lo largo del desarrollo, que ahora se consideran una parte normal del proceso iterativo.

El problema es que construir el producto rápidamente para validar su utilidad y luego volver a trabajarlo continuamente hasta que alcancemos el objetivo correcto es una forma muy costosa de aprender. Un número de nuevas empresas han quemado sus fondos de inversión sin encontrar nunca un mercado lo suficientemente bueno para su producto. Obeya proporciona un enfoque innovador para reducir las incógnitas antes de comenzar el desarrollo, que tiene el doble efecto de ser más barato y acelerar la entrega, por lo que puede dejar una idea cuando aún no es demasiado tarde o decidir continuar con ella y ser el primero en hacerlo. Introduce tu producto en el mercado. En este sentido, obeya es más una herramienta para el descubrimiento que para la entrega.

Régis Medina
Lean Coach y experto en Lean IT en el Institut Lean France.
Sandrine Olivencia
Executive coach y miembro del Institut Lean France

Extraído de: Planet Lean


Más leídos