¿Cuáles son las reuniones periódicas más útiles para que un gerente de producto de software sea propietario y organice como parte de un proceso de lanzamiento iterativo (por ejemplo, Agile)?

Creo que debe tener en cuenta tanto la gestión técnica de la creación del producto, como también todas las demás actividades relacionadas con la comercialización. Construir el producto es solo una de las responsabilidades clave para un PM.

Nuestros equipos de productos sostienen reuniones semanales con un “núcleo” o “equipo de producto” para administrar el producto a través de su ciclo de vida y trabajar en equipo a través de oportunidades y problemas relacionados con el cliente, soporte, ventas y lanzamiento.

En términos de planificación de la hoja de ruta, utilizamos dos “fases de estimación” clave en Aha! cuando se construye software y generalmente suceden por separado. Tener dos fases también proporciona un control y equilibrio sólidos y conduce a resultados más predecibles.

Primero, los PM y los líderes de ingeniería trabajan juntos cuando PM está buscando un lanzamiento o sprint y una colección de características. La priorización temprana requiere saber si la característica es una roca, roca o piedra. Puede usar una serie de métricas aquí en las discusiones, que incluyen tamaños de pizza, tamaños de camisetas y, sí, incluso puntos si insiste.

Use cualquier métrica de alto nivel que desee siempre que haya alguna relación directa entre la métrica y el tiempo (por ejemplo, hora, día, semana, semanas, mes, meses).

Simplemente está tratando de hacerse una idea de lo que costará algo en términos de esfuerzo para ayudar a identificar las características que ofrecerán el mayor valor por el menor costo. Cualquier “fecha de lanzamiento” discutida en este punto son realmente solo “fechas de deseo” de PM que ayudan a enfocar al equipo en un objetivo hasta que se examinen y se acuerden los objetivos.

En segundo lugar, el siguiente y más detallado nivel de estimación llega una vez que el PM y el liderazgo de ingeniería generalmente acuerdan los objetivos y el momento aproximado para el próximo lanzamiento importante. La ingeniería generalmente hace esto en conjunto para racionalizar lo que puede encajar en un cierto marco de tiempo y estas estimaciones basadas en el tiempo están conectadas con las características.

Si el objetivo de los negocios es crear tanto valor en el menor tiempo posible, seguramente el reloj importa. Y solo porque es difícil estimar cuándo se completará el trabajo complejo (como el desarrollo de software), no es excusa para esconderse detrás de una masa desconocida disfrazada de algo que incluso un futbolista no entendido entiende.

Si está buscando crear hojas de ruta brillantes de software, articular requisitos claros y crear lo que importa, ¡ pruebe Aha!

Se ha dicho ** que lo único que debe hacer un equipo verdaderamente ágil es tener reuniones retrospectivas frecuentes.

Cosas como la planificación del sprint, las paradas, el “tiempo de la historia” (o incluso la programación en pareja, CI, tdd) deberían surgir de una decisión grupal de experimentar. Esas decisiones se discuten y se toman en retrospectiva. Algunas ideas pueden funcionar, otras muy probablemente no. Es por eso que se reúnen nuevamente la próxima semana e intentan otra cosa.

** Creo que Alistair Cockburn dijo esto primero, pero fácilmente podría estar equivocado.

Depende de a qué otros miembros del equipo tenga que pueda delegar la responsabilidad o quién administrará otras partes del proceso. En mi experiencia, a menudo he sido ScrumMaster y Product Owner para mis equipos Agile, lo que generalmente significa que he sido responsable de las siguientes reuniones regulares:

• Registros regulares con las partes interesadas, fuera del equipo de desarrollo, generalmente 1 vez al mes.
• Retrasar sesiones de preparación y estimación, según sea necesario, no menos de 2 veces al mes.
• Sesiones de planificación de sprint al comienzo de cada sprint.
• Sesiones de revisión de sprint (incluidas las partes interesadas, cuando corresponda) después de cada sprint.
• Retrospectivas de sprint después de cada sprint.
• Reuniones diarias de pie.

Si tiene un ScrumMaster a tiempo completo, probablemente pueda abandonar la propiedad de la planificación, la revisión, las retrospectivas y las actividades diarias, aunque le recomiendo que asista a cada una de estas reuniones para mantener la visibilidad y la comunicación con el equipo.

Probablemente tendrá otras reuniones relacionadas con las operaciones continuas del producto y las necesidades de sus partes interesadas, incluidas demostraciones de productos / lanzamientos fuera de los sprints programados, discusiones con personas de capacitación y documentación, y otros puntos de contacto donde necesite para dar información y obtener comentarios.

En todos mis años de gestión de productos, la reunión REGULAR MÁS importante y útil fue la reunión de equipo multifuncional que mantuvo sincronizados a todos los equipos internos.

En la mayoría de las empresas, esto fue algo que inicié y sostuve diligentemente. Los invitados a la reunión fueron representantes de Marketing, Ventas, Soporte, Servicios, Operaciones, Ingeniería y todo lo que consideramos necesario.

El propósito de la reunión (generalmente celebrada cada dos semanas o semanalmente cuando fuera necesario), no solo era actualizar a las personas sobre los nuevos desarrollos, sino también dar a cada grupo la oportunidad de compartir sus perspectivas, sus problemas y, cuando sea posible, resolver problemas interfuncionales.

Después de las reuniones, se pidió a los asistentes que transmitieran los resultados y las decisiones a sus respectivos equipos para que estuvieran informados y actualizados.

Por ejemplo, si el Soporte estaba viendo muchos casos relacionados con un tema en particular, no solo era importante informarle a Ingeniería y PM para que se pudiera enfocar, sino que Marketing y Ventas estarían al tanto para que pudieran reaccionar inteligentemente (posiblemente incluso de manera proactiva) si los clientes lo plantearon con ellos.

por ejemplo, cuando un cliente plantea el problema con un vendedor: nos hemos encontrado con . ¿Me pregunto si está al tanto y cuándo podría solucionarse? – el vendedor puede (con confianza y sinceridad) decir:

“Sí, somos conscientes de ello. Y en una reunión la semana pasada, el equipo de Ingeniería confirmó que están trabajando en ello y que deberían solucionarlo en breve ”.

¿Cuánto mejor es eso frente a la típica respuesta de “Déjame verlo y responderte “ que de otro modo sucedería?

Este es solo un ejemplo, pero la Gestión de productos es una gestión CRUZADA FUNCIONAL, y mantener a las personas ALINEADAS significa que la empresa puede funcionar de manera eficiente.

Minimiza el “arrastre” y la “fricción” innecesarios que de otro modo existirían en los procesos de comunicación, y construye una fuerte cultura de comunicación abierta y oportuna que beneficia a TODOS.

• Entrevistas a clientes => Vea lo que quieren, lo que funciona y lo que no. Estás desarrollando el producto para ellos, después de todo.
• Kaizen / Retrospectivas de mejora continua => Ad-hoc o regular, para ver cómo su equipo puede mejorar la forma en que gestionan el trabajo, y si hay algo que el PM puede hacer para simplificar esto.
• Refinamiento de la cartera de pedidos / Hoja de ruta del producto => Utilizando quién es relevante (equipo de desarrollo, administración, clientes, etc.), desarrolla lo que está por desarrollarse o elabora una función próxima.
• Stand-up / Sit-down => Utilice una herramienta de comunicación asincrónica, como Slack , (perfecta para equipos remotos) o reúnase cara a cara en la oficina, y “camine por el tablero” ( diariamente o tan seguido como usted) trabajando ) para ver si hay algo que impida el progreso del equipo.

Las respuestas anteriores incluyen varias reuniones que deberían ser dirigidas por el Scrum Master, pero son listas bastante completas. El propietario del producto siempre debe liderar la preparación de la reserva y la planificación de versiones. El resto de las reuniones son vitales para que asista el Propietario del producto, pero normalmente no las dirige (a menos que se desempeñe como el scrum master. Eso está bien para equipos pequeños, pero puede crear conflictos de intereses).

Nombrando algunos aquí:

1. Preparación del trabajo atrasado
2. Planificación de sprint
3. Revisión de Sprint
4. Reunión semanal con las partes interesadas para revisar métricas, hoja de ruta, características actuales en desarrollo
5. Reuniones con un cliente / usuario. (PM nunca debería delegar esto)
6. Pruebas de usabilidad y sesiones UER

Menos esenciales en el sentido más estricto, pero quizás igual de valioso, son las reuniones de ‘descubrimiento’: reunirse con UX y Viz design, líderes de desarrollo, para hablar sobre productos, diseños, eventos o lecturas que fueron inspiradores, y ver si esa inspiración puede ser canalizado de nuevo al producto en cuestión. Es más una estrategia oblicua, pero es buena tanto para la moral como para una perspectiva fresca. Sostengo uno cada dos semanas.

El refinamiento de la cartera de productos es el más útil. Esa es la reunión clave para establecer la dirección correcta en línea con la visión del Producto.
El equipo de funciones también sabrá lo que está por venir y puede planificar en consecuencia.

La siguiente importante es la Revisión de Sprint para probar y firmar que el equipo ha desarrollado lo que se ha pedido y que no hay problemas.

Aunque el sprint comienza con una reunión de planificación de Sprint Parte 1, he mantenido esto más bajo en términos de utilidad ya que el PBR se encarga de la priorización de la acumulación y no siempre algo cambia en esos 5 días.