Optimizando el desarrollo de productos digitales: Estrategias para un flujo de trabajo efectivo (I)

‍

En el desarrollo de productos digitales, la capacidad para organizar el trabajo, definir responsabilidades y mantener un seguimiento efectivo no solo marca la diferencia entre el éxito y el fracaso, sino que también determina la eficiencia y productividad de cualquier equipo de producto. La clave para navegar por el complejo ciclo de vida del desarrollo de un producto yace en la división estratégica de categorías según el tipo de tarea y la implementación de un flujo de trabajo simple pero robusto y flexible (como el bambú). Esta metodología no solo facilita el manejo eficiente de las diversas necesidades y problemas que emergen, sino que también garantiza la correcta implementación de soluciones y el mantenimiento de un roadmap perfectamente alineado con la estrategia de la compañía.

En este post, explicaré cómo la estructuración y categorización del trabajo desde la dimensión más estratégica a la más táctica puede transformar la forma en que los equipos operan, promoviendo un ambiente de trabajo cohesivo y altamente eficiente.

En mi día a día, he conseguido dividir las dimensiones del desarrollo de producto de la siguiente manera para organizar un flujo adecuado y dividir las responsabilidades:

‍

1. Problemas o necesidades

‍Es el origen de todo, puede ser una petición del equipo de negocio, una observación que identificas en los usuarios, una petición de ahorro, o una idea innovadora que crees que será el nuevo bombazo de la empresa. Sea cual fuere el origen, necesitamos entender cuál es el problema o la necesidad, y para ello tenemos antes de definir la solución, necesitamos preguntarnos para todas lo mismo: Qué, Quién, Dónde, Cuándo y Por qué.
‍

En esta etapa es muy importante plantearnos el por qué, y muchas veces, tendremos varias posibles explicaciones. No te preocupes, ¡hemos venido a jugar! Escríbelas todas, y crea diferentes hipótesis, te aseguro que si lo haces empezarán a brotar multitud de ideas para validarlas o rechazarlas. Aquí entrará en juego el análisis profundo. Habrá algunas que desecharás y otras que sonarán fiables. Es el momento de seleccionar las ideas que crees que pueden funcionar para conseguir resolver ese problema o necesidad. Es el momento de pasar a construir las soluciones.

‍

2. Soluciones (o cómo vamos a llamarlas Features)‍

Es el momento de pensar en cómo es esa solución, su objetivo, su alcance, definir su público objetivo, los kpis que usarás para medir su impacto, y algo muy importante:  su rentabilidad y su urgencia. Estos dos últimos puntos son los que te ayudará más adelante para gestionar la multitud de features que inundan tu backlog y que esperan a ser colocadas en algún lugar del roadmap.

‍

Rentabilidad

Aquí viene la parte más compleja y la que puedes pasarte horas si no sabes hasta que punto llegar. Tu objetivo final es saber el ROI y el Payback esperado, y para ello tienes que medir: el coste y el beneficio (ingreso o ahorro).

‍

Beneficio

Yo siempre empiezo midiendo el beneficio, para ello, según cada feature, tienes que establecer cual es tu estado actual, por ejemplo, para una feature sobre crear una landing para mejorar el SEO, me planteo: ¿Cuánto tráfico está llegando actualmente para este tipo de búsqueda? ¿Cómo posiciono? ¿Qué conversión tiene este tipo de tráfico? ¿Cuánto valor (en dinero) tiene cada conversión de este tipo? Eso te ayudará a tener un punto de partida, y te ayudará a evaluar la dimensión del problema (en un mundo idílico esto ya lo tienes antes cuando pensaste en el problema, pero todos sabemos que la vida no es ideal).

Con ese punto de partida, toca la hora de la suposición, ¿qué es lo que pretendes hacer? ¿cómo crees que vas a mejorar esos kpis? ¿cuándo esperas ver el impacto? ¿es inmediato o es a medio-largo plazo? ¿el resultado es lineal o es exponencial? Aquí dependerá de tus conocimientos y el de tus compañeros especialistas para tratar de ser lo más acertado posible (acuérdate de tus hipótesis), pero un consejo, haz dos escenarios: uno negativo y uno positivo, y quédate en medio tirando a bajo. Tendemos a ser demasiado positivos.

Cuando tengas las estimaciones esperadas, compáralas con lo que pasaría si te mantienes en la situación actual (sin hacer nada) y traduce esta diferencia a dinerito.

‍

Coste

Ahora viene el momento del coste, esto tampoco es tarea simple, pero dependerá del conocimiento de tu equipo, de tu experiencia previa y del grado de incertidumbre. Ten calculados los costes por cada equipo especializado por jornada (yo prefiero no hacerlo con horas) o por story points (para esto ten calculada la velocidad media de tu equipo por Sprint) (esta medida para mí es más real ya que es una medida de esfuerzo teniendo en cuenta la capacidad de tu equipo y cómo ellos estiman su trabajo, pero si no llevas mucho tiempo trabajando con el mismo equipo en Scrum, te la desaconsejo por completo). Con esa vara de medir, siéntate con tu equipo, con el alcance a alto nivel, y hacer un cálculo a alto nivel (NO TE OBSESIONES) de cada parte del desarrollo. Y consejo adicional, métele margen para imprevistos, desconocimiento y infradimensionamiento de tu equipo. Muchas personas no piensan en las dependencias, las gestiones y los cambios de alcance. ¡Más vale prevenir que curar!

Ten en cuenta el CAPEX, la inversión inicial o gasto para implementarlo, y el OPEX, a veces, nuevas cosas requieren coste adicional de un servicio recurrente o un mantenimiento adicional.

‍

ROI y Payback

Ahora ya lo tienes chupado, tan solo un par de fórmulas y listo, te las recuerdo para que no tengas que buscar:

ROI =(Ingresos anuales-Coste anual)/Coste anual

Decide para qué medida temporal lo quieres calcular, esto dependerá de si tu empresa mide los resultados al año o a los 6 meses.

Payback = Coste inicial /Ingreso

Yo lo suelo calcular por meses. Pero puedes hacerlo por años, por días, como te vaya mejor.

Cuidado con este cálculo, a veces no es tan simple, solo si el impacto de tu feature es inmediata, y vas a percibir beneficio desde el minuto 0, es recomendable simplificarlo tanto. Si por el contrario los beneficios van a ir llegando progresivamente y crecer con el tiempo de manera exponencial, entonces, recuerda esto, el payback no es más que el momento en que todo lo invertido inicialmente y el coste de mantenimiento, se ve superado por el acumulado de ingresos generados.

‍

Urgencia

La urgencia es algo normalmente fácil de establecer, haz una tabla del 1 al 5 para estandarizar está métrica cuando la quieras comparar con el resto de features, y hazte las siguientes preguntas:

• ¿Qué pasa si no lo hago ahora?
• ¿Qué sucede si espero para hacerlo?
• ¿El mercado lo necesita cuanto antes o puede esperar?
• ¿Tu empresa lo necesita urgentemente?
• ¿Genera dependencias con otras iniciativas de negocio?
• ¿Eres el primero en lanzarlo al mercado? ¿Importa?

Estas y muchas otras te pueden ayudar a establecer la urgencia. Y para estandarizar, piensa en lo más urgente que te puedes encontrar para encontrar el grado máximo (5)y piensa en lo menos urgente que te hayas encontrado jamás, y marca el grado mínimo (1).

‍

¡Bueno! Y todo esto porqué te lo contaba... Pues una vez ya tienes todo de tu potencial solución:

• Contexto del problema o necesidad
• Descripción de la feature
• Objetivo
• Público objetivo
• Rentabilidad
• Urgencia

Es el momento de llevártelo a tu querido roadmap y priorizarlo. De esto ya he hablado en post anteriores como en Dominando la priorización de productos: Técnicas para maximizar el valor donde te explico algunas de la técnicas más usadas para priorizar las features. Pero siguiendo con esta visión financiera de tu backlog, una buena forma de poner orden en el caos es crear una pequeña fórmula de impacto para determinar de manera objetiva de comparar entre tantas features. Yo personalmente uso Product Discovery de Jira Atlassian, y me permite establecer una puntuación de impacto relativa a todas las features de mi backlog, dando peso relativo de la siguiente manera:

Inputs positivos:

• 40% Urgencia
• 60% ROI

Inputs negativos:

• 100% Payback

De esta manera genero puntuaciones relativas según todo mi backlog, donde a mayor urgencia y mayor ROI, pero un payback más bajo, más puntuación de impacto tiene.

Y ahora, esto suena muy bien, la pregunta es ¿se respeta? Pues no te creas, ya sabemos que muchas empresas son corto-placistas y se guían por la urgencia y las emociones. Pero bueno es una buena manera de argumentar contra esas corrientes a veces imparables.

Muchas de las features en este punto es donde se rechazan o quedan relegadas a la espera eterna. Pero cuando ya tenemos todo claro qué es lo que vamos a hacer y lo hemos ordenado en nuestro roadmap, es la hora de la verdad, toca ponerse manos a la obra (¡por si lo de antes no era suficiente!). Aquí es cuando desmenuzamos cada Feature a sus Épicas correspondientes.

‍

3. Épicas

Las features son una manera muy eficaz de entender que iniciativas a alto nivel vas a trabajar, explicarlo a dirección y que todo el mundo fuera de tu área lo entienda, pero las épicas para mí son la manera de trasladarlo a los equipos y agrupar grandes conjuntos de tareas o historias de usuario. Normalmente no suelo crear más de una épica por feature, pero cuando una feature es muy grande para desarrollarlo en un sprint o tiene varias vertientes que diseñar y desarrollar, lo ideal es crear varias.

Una vez tenemos las épicas creadas con el equipo, mi preferencia personal, es que el líder de cada equipo baje al detalle técnico (para algo tenemos especialistas, no podemos pretender saber de todo, somos un equipo!). También es muy útil para organizar el trabajo en el que deben estar enfocados, sin que tengan que lidiar con el caos de otras áreas, ni marearlos con cosas que nunca verán la luz. Las épicas pasan por un estado de refinement donde cada equipo baja a crear cada tarea y cada historia de usuario necesaria para cumplir con el objetivo y el alcance de la mejor manera. Desde tareas de research, diseño de UX o UI, arquitectura de la aplicación o bbdd, a componente del frontend y tarea de testing y lanzamiento.

El orden de las épicas sigue el mismo que el del roadmap de features, pero puede variar según el equipo si hay una épica necesaria antes que otra, esto es algo a decidir conjuntamente con tu equipo.

‍

4. Tareas e historias de usuario (HU)

Las tareas e historias de usuario, hablo indistintamente, una vez refinadas, estimadas y preparadas son aquellas que siguiendo con el mismo orden, el equipo es quien ordena tarea a tarea o HU a HU, cuando debe ejecutarse. En las plannings será donde realmente te darás cuenta de si son capaces de lograr entregarlo en un solo sprint o por contra tienes que partirlo en bloques para por lo menos, en cada sprint tener una parte de la feature lista para entregar.

Recomendación; no te vuelvas loco, delega en tu equipo, deja que ellos sean los owners de su propio trabajo, ayúdalos a priorizar como PO su trabajo, haz muchas preguntas, plantéales problemas, y sobre todo, confía en ellos. Si eres capaz de trasladarles el objetivo principal y que lo hagan suyo (o encontrar como sus objetivos pueden alinearse con el del producto), no te fallará.

‍

Conclusión

Después de desgranar el laberinto que es el desarrollo de productos digitales, llego a la conclusión de que, aunque a veces me siento como un malabarista intentando mantener en el aire cien pelotas llamadas "tareas", "epicas", y "features", hay un método en esta locura. Al dividir el trabajo, establecer flujos claros y asignar cada pedacito de responsabilidad, no solo he logrado que las pelotas no caigan, sino que también he coreografiado una danza bastante bonita. Así que, mientras me aseguro de que cada problema se transforme en una oportunidad y cada necesidad en una solución innovadora, me doy cuenta de que, en el fondo, organizar este caos es parte de la diversión. ¿Quién hubiera dicho que ser un director de orquesta digital podría ser tan entretenido?

Por hoy creo que ya es suficiente, me hubiera gustado hablarte del workflow de cada una de ellas, pero eso lo dejaremos para una segunda entrega de Optimizando el desarrollo de productos digitales: Estrategias para un flujo de trabajo efectivo.

Esto es muy fácil de explicar pero muy difícil de implementar, así que tranquilo, estoy seguro que serás capaz, o mejor aún encuentra el tuyo y escríbeme para compartirlo, si tu aprendes, aprendemos todos.