Un proceso de desarrollo de producto

Hablamos de las distitnas fases de desarrollo de un producto, desde la definición de OKRs a la planificación del sprint y cómo intervienen en ellas los distintos perfiles del equipo.

A la hora de desarrollar un producto todo equipo suele tener definido un proceso estructurado para organizarse. A modo de ejemplo hoy veremos el que sigue nuestro equipo en Voicemod.

De lo más estratégico a lo más operativo nuestro proceso de desarrollo de producto contempla las siguientes fases:

Definición de OKRs

El primer paso en nuestro proceso comienza con la definición de OKRs trimestral. Generalmente la compañía habrá marcado una dirección estratégica a seguir y los equipos deberán definir sus objetivos en base a esta. Así por ejemplo, si el foco estratégico es aumentar la facturación, los objetivos del equipo para el trimestre deberían ir alineados con este propósito.

Esta definición de objetivos y resultados clave suele estar liderada por el Product Manager, si bien es importante involucrar al equipo en la misma aprovechando para dar contexto al equipo sobre la estrategia de la empresa.

Propuesta de Iniciativas

Una vez definidos los objetivos para el trimestre, el siguiente paso será proponer una serie de iniciativas a abordar durante el mismo para impactar sobre ellos.

De nuevo, es una actividad generalmente liderada por el Product Manager quién, tirando de su conocimiento sobre los problemas de los usuarios, deberá priorizar aquellos que puedan tener un mayor impacto sobre el objetivo que se persigue.

Esta lista de problemas priorizados en iniciativas por sí misma no tiene demasiado valor sin una estimación aproximada del tamaño de cada una. Es por ello vital apoyarse en el Engineering Manager y el Product Designer para obtener una evaluación inicial de alto nivel sobre el tamaño de cada una de ellas.

Con cada iniciativa estimada a alto nivel, el PM ya puede priorizar las mismas dentro del trimestre atendiendo al impacto esperado. De nuevo, pese a que sea este el que lidere, es importante involucrar al equipo en la toma de la decisión.

Introducción al problema

Entrando ya en la parte operativa, con los objetivos y las iniciativas del trimestre priorizadas, llega el turno de comenzar a abordar la primera de ellas.

En Voicemod damos comienzo a ello con una reunión de introducción que da inicio a la iniciativa a la que llamamos Inception, pero que también podría llamarse Briefing o Kick-Off.

El objetivo de la misma es que el Product Manager introduzca el problema al equipo. En mi caso, lo hago apoyándome en un documento, generalmente breve, que aborda principalmente los siguientes puntos:

• Contexto: ¿Cuál es el problema que queremos resolver? ¿Por qué es importante resolverlo?
• Objetivos: ¿Qué esperamos conseguir?
• Definición de éxito: ¿Cómo sabremos que lo hemos conseguido?
• Usuarios y sus Jobs To Be Done: ¿Quiénes son los usuarios? ¿Cuáles son sus JTBD?
• Preguntas y respuestas: Sección de preguntas y respuestas que el PM ha ido resolviendo durante el análisis del problema y que ayudan a dar contexto sobre el problema.

Es importante que la reunión sea interactiva. Quieres que el equipo participe y plantee todas aquellas dudas que pueda tener. Es posible que puedas responder a muchas de ellas, pero en el caso de que no puedas no te preocupes. Precisamente para eso se hace esta reunión, para detectar esos espacios de incertidumbre que hay que resolver.

En algunos casos, si la iniciativa es pequeña o está muy claro lo que hay que hacer, se puede salir de la reunión directamente con una propuesta de solución articulada en un listado de épicas que pasarían directamente a refinamiento.

Para iniciativas más complejas, generalmente listamos aquellos siguientes pasos que son necesarios para seguir avanzando en la definición de la solución y quién se hace responsable de cada uno de ellos.

Así por ejemplo, si la iniciativa requiere de hacer un spike técnico, un ingeniero se encargará de ello. Si hace falta profundizar en los casos de uso, el Product Manager se puede encargar de organizar sesiones entre el equipo y los usuarios.

Idealmente, todo este proceso tiene que ser ágil, no podemos dejar pasar semanas entre reunión y reunión. Es por ello que hay que contar con que parte del esfuerzo del equipo en cada sprint se va a dedicar a encontrar las mejores soluciones para los problemas planteados.

Reunión de refinamiento

El siguiente paso en el proceso de desarrollo se da en otro tipo de reunión, llamadas reuniones de refinamiento. Lideradas por el Engineering Manager, son sesiones dónde el equipo:

• Analiza una a una las épicas de una iniciativa
• Discute y acuerda la solución técnica
• Hace una estimación sobre cada una de ellas

Pese a ser una reunión de carácter principalmente técnico, recomiendo al PM asistir. Por un lado, para resolver cualquier duda que surja en relación al problema. Por otro, para observar si hay algún punto en concreto que el equipo estima va a ser especialmente costoso. Si detectamos una situación así, se pueden llegar a discutir en el refinamiento alternativas que respeten la solución y, al mismo tiempo, reduzcan el tiempo de desarrollo.

El resultado de la sesión de refinamiento es doble. Por un lado, el Product Manager obtiene las primera estimaciones reales sobre la iniciativa. Por otra, las épicas ya divididas en tareas, pasan al backlog listas para desarrollar.

Un punto importante es el de las estimaciones. Hasta este punto en concreto, hemos trabajado con estimaciones de alto nivel. A partir de la sesión de refinamiento, contamos con las primeras a bajo nivel. Si coinciden o están por debajo, no será un problema. Pero si estas incrementan notablemente las iniciales, es posible que termine teniendo un efecto en cascada sobre todo el trimestre.

No es culpa de nadie. Ni siquiera las estimaciones a bajo nivel son fiables al 100% (la única forma de estimar con un 100% de certeza es hacer la tarea por anticipado). Sin embargo, tampoco podemos aceptarlo sin más. Es el momento de replantear la iniciativa con el equipo, eliminar aspectos problemáticos o directamente posponerla.

Planificación del sprint

La siguiente reunión en nuestro ciclo de desarrollo es el Sprint Planning. En esta reunión, liderada de nuevo por el Engineering Manager, se decide qué tareas se abordarán a continuación.

El Engineering Manager no decide qué tareas entrarán en el sprint, el backlog lo prioriza el Product Manager, pero sí será responsable de que el equipo cumpla con las historias que entran en el mismo. Es por eso que suele apoyarse aspectos como el histórico del equipo para definir cuántas tareas pueden entrar en el siguiente ciclo de desarrollo.

Cerrando el ciclo

Una vez el sprint está cerrado, el ciclo se vuelve a repetir por cada iniciativa. Por lo menos mientras no tengamos los dos siguientes sprints estimados.

En el momento nuestro backlog sube de esos dos sprints, preferimos centrarnos en cerrar las iniciativas abiertas. En mi experiencia, el backlog caduca muy rápidamente. Hacer el esfuerzo de refinar algo que sabes que no vas a poder abordar inminentemente es casi siempre una pérdida de tiempo.

A modo de resumen, he creado esta tabla en la que podéis ver cada una de las distintas fases, quién la lidera, quién participa y el resultado esperado por cada una.

Como siempre, gracias por estar ahí. Sé libre de contactarme o dejar un comentario si tienes cualquier duda o feedback sobre el artículo. También puedes encontrarme en Twitter en @simonvlc. Y, si no recibes la newsletter, recuerda que puedes suscribirte a Estrategia de Producto para recibir posts como este muy de vez en cuando. ¡Hasta pronto!

Originally published at https://www.estrategiadeproducto.com.