Scrum, y una reflexión sobre Product Management
Esta charla que he encontrado en Google resume desde un punto de vista práctico algunas de las características del diseño y desarrollo ágil de aplicaciones, basándose en Scrum (para aquellos que quieran saber más de metodologías ágiles, escribí hace años un resumencillo, pero Joselu, de Peopleware, está describiendo en algunos posts de su blog la experiencia de aplicar Scrum en un proyecto open source real). Me permito recoger algunos detalles de la charla aunque, como siempre, mejor vedla :)
Agile: significa "ritmo". La premisa es que una frecuencia alta del ritmo mejora la creatividad y la productividad.
El autor describe cinco niveles de planificación, más que el Scrum clásico. Un desarrollador necesita "foco" para su tarea semanal, pero también una "visión" para no perder el rumbo.
Por ello, los cinco niveles reflejan ese paso del detalle a "la idea":
1. Diario, una vez al día, se describen básicamente la lista de tareas a realizar.
2. "Sprint plan", uno o dos al mes, se realizan las "stories" y tareas.
3. Release plan, 3 o 4 al año, que contiene las "features" y las stories.
4. Product Roadmap, 1, 2, al año. Evolución del producto con respecto al tiempo.
5. Visión. 1, 2 al año. Vision Statement.
Lo cierto es que los últimos niveles son muy "estándar", se parece mucho a la organización realizada en Product Management.
Quizá la diferencia es que el Product Manager/Owner en esta charla tiene una primera responsabilidad en la estimación de la release, cosa que, en algunas organizaciones, no tiene sentido, pues puede que el Product Manager venga de marketing, y su responsabilidad sea la de entender las necesidades del mercado, y no tanto la de convertir esas necesidades en requisitos cuantificables. Para ello se encuentra el responsable de desarrollo de producto. En otros casos, sin embargo, sí que el Product Manager se involucra más, si proviene de la parte técnica del negocio.
El Roadmap lo tratan de una manera interesante, y también conocida, como es que la fecha es la que delimita las funcionalidades que aparecen en cada release.
Desde que veo el mundo del desarrollo de producto desde un punto de vista más general, se confirma que, si se dividen las tareas en desarrollo, diseño, gestión de proyectos, gestión de producto y márketing, está bastante claro que empieza a haber bastante madurez en la gestión de proyectos (o, al menos, empieza a quedar claro el papel que tienen las metodologías de desarrollo, y la utilidad que tiene cada tipo). Sin embargo, no ocurre lo mismo con la gestión de producto. En este post de "On Product Management", se discute este tema. Es un rol (de hecho, todavía hay dudas de si es un rol) sin definir perfectamente, con muchas definiciones dependiendo del área donde nos encontremos. Yo lo he visto refrendado por las siguientes observaciones:
1. ¿A qué zona de la librería de la esquina irías a por un libro de Product Management? ¿Márketing? ¿Project Management? ¿Desarrollo de aplicaciones? De hecho, en todas te puedes encontrar libros de product management, que han sido colocados en un sitio o en otro dependiendo del título, sin más deliberaciones. Aunque los libros de Gestión de Proyectos aún tienen algún problema entre el área de "management" y el área de "gestión de proyectos", suele ser más por torpeza de organización que por dudas reales.
2. Meted en un lector de "feeds" todos los blogs de product management que encontréis. En el mío tengo 25, de los cuáles 17, 18 están relativamente activos. Sin exagerar, el 15-20% de los posts todavía tratan, directa o indirectamente con el tema "qué es un product manager" o "cómo diferenciar entre un product manager y un product marketing manager".
3. Dependiendo de la empresa, product management está en marketing, en desarrollo de producto, o en un departamento aparte. En algunos es el "propietario" del producto, en otros es un técnico que recopila requisitos, en otros es el propio responsable de márketing...
En definitiva, esto se puede ver como un problema, pero también como una oportunidad para aquellos que están metidos en esto de definirlo adecuadamente, y que no se convierta en una serie de "tareíllas" tácticas.
Agile: significa "ritmo". La premisa es que una frecuencia alta del ritmo mejora la creatividad y la productividad.
El autor describe cinco niveles de planificación, más que el Scrum clásico. Un desarrollador necesita "foco" para su tarea semanal, pero también una "visión" para no perder el rumbo.
Por ello, los cinco niveles reflejan ese paso del detalle a "la idea":
1. Diario, una vez al día, se describen básicamente la lista de tareas a realizar.
2. "Sprint plan", uno o dos al mes, se realizan las "stories" y tareas.
3. Release plan, 3 o 4 al año, que contiene las "features" y las stories.
4. Product Roadmap, 1, 2, al año. Evolución del producto con respecto al tiempo.
5. Visión. 1, 2 al año. Vision Statement.
Lo cierto es que los últimos niveles son muy "estándar", se parece mucho a la organización realizada en Product Management.
Quizá la diferencia es que el Product Manager/Owner en esta charla tiene una primera responsabilidad en la estimación de la release, cosa que, en algunas organizaciones, no tiene sentido, pues puede que el Product Manager venga de marketing, y su responsabilidad sea la de entender las necesidades del mercado, y no tanto la de convertir esas necesidades en requisitos cuantificables. Para ello se encuentra el responsable de desarrollo de producto. En otros casos, sin embargo, sí que el Product Manager se involucra más, si proviene de la parte técnica del negocio.
El Roadmap lo tratan de una manera interesante, y también conocida, como es que la fecha es la que delimita las funcionalidades que aparecen en cada release.
Desde que veo el mundo del desarrollo de producto desde un punto de vista más general, se confirma que, si se dividen las tareas en desarrollo, diseño, gestión de proyectos, gestión de producto y márketing, está bastante claro que empieza a haber bastante madurez en la gestión de proyectos (o, al menos, empieza a quedar claro el papel que tienen las metodologías de desarrollo, y la utilidad que tiene cada tipo). Sin embargo, no ocurre lo mismo con la gestión de producto. En este post de "On Product Management", se discute este tema. Es un rol (de hecho, todavía hay dudas de si es un rol) sin definir perfectamente, con muchas definiciones dependiendo del área donde nos encontremos. Yo lo he visto refrendado por las siguientes observaciones:
1. ¿A qué zona de la librería de la esquina irías a por un libro de Product Management? ¿Márketing? ¿Project Management? ¿Desarrollo de aplicaciones? De hecho, en todas te puedes encontrar libros de product management, que han sido colocados en un sitio o en otro dependiendo del título, sin más deliberaciones. Aunque los libros de Gestión de Proyectos aún tienen algún problema entre el área de "management" y el área de "gestión de proyectos", suele ser más por torpeza de organización que por dudas reales.
2. Meted en un lector de "feeds" todos los blogs de product management que encontréis. En el mío tengo 25, de los cuáles 17, 18 están relativamente activos. Sin exagerar, el 15-20% de los posts todavía tratan, directa o indirectamente con el tema "qué es un product manager" o "cómo diferenciar entre un product manager y un product marketing manager".
3. Dependiendo de la empresa, product management está en marketing, en desarrollo de producto, o en un departamento aparte. En algunos es el "propietario" del producto, en otros es un técnico que recopila requisitos, en otros es el propio responsable de márketing...
En definitiva, esto se puede ver como un problema, pero también como una oportunidad para aquellos que están metidos en esto de definirlo adecuadamente, y que no se convierta en una serie de "tareíllas" tácticas.
Comments