Hace unas semanas encontré un artículo en la que comparaba la gestión de productos y la gestión de proyectos (mencionan a Scrum contra predictivo), esto me pareció curioso, sin embargo, al leer el artículo, «casualmente» el navegador me comenzó a mostrar más artículos del tema y al parecer, varias personas creen que son dos enfoques diferentes para crear un producto. Si deseas saber si son incompatibles o no, te invito a seguir leyendo.
En estos artículos y en algunos videos, indican que la gestión de proyectos es una forma de crear un producto a través del enfoque predictivo, de por sí, se ha etiquetado que un proyecto es sinónimo de enfoque en predictivo (o cascada) y los productos pueden hacerse a través de otro enfoque como el ágil con el marco de trabajo Scrum. Algunos argumentan que cómo Scrum tiene un rol de Product Owner y está orientado a crear valor al usuario por medio de un producto que funciona en cada iteración, es otra manera de entregar un producto y no se necesita de un proyecto. Veamos algunos conceptos de varios términos que hemos utilizado hasta ahora.
Producto
La séptima edición del PMBOK del PMI (última edición al momento de escribir este artículo) dice que el producto es: «…un artefacto que es producido, es cuantificable y puede ser un elemento terminado en sí mismo o un componente de un elemento.» El producto puede ser uno o varios elementos que buscan valor al usuario final y que forman parte de una estrategia de una empresa a lo largo del tiempo. Hay productos que duran días porque al salir al mercado, ya está obsoleto (se dieron cuenta que la competencia tiene un producto con mejor tecnología) o productos que llevan más de 100 años en el mercado y son muy populares. En algunas empresas, tienen equipos enfocados a crear nuevos productos o mantener los existentes, con el fin de incrementar el valor al cliente y mejorar el retorno de inversión para la empresa, a esto se le puede llamar una gestión del producto.
Ciclo de vida del producto
Los productos tienen varias etapas a través del tiempo, estas son: introducción, crecimiento, madurez y declive.
- La introducción tiene que ver con la creación del producto, concepción de marca, como se va a distribuir, establecer el precio, etc.
- La etapa de crecimiento se realiza actividades de mantenimiento de calidad, precios, mejoras en los canales de distribución, ampliación en la promoción del producto, etc.
- En la etapa de madurez, se realizan varias actividades de acuerdo al producto, se puede agregar otras características, mejoras en la producción del producto, mejoras o cambios de distribución del producto, etc.
- La etapa del declive puede ser por varios factores como ser un producto obsoleto en comparación a otros productos, el cliente ya no está interesado en adquirirlo, por lo que comienzan a tomar decisiones para reemplazarlo, buscarle otros usos o disminuir la producción paulatinamente.
En cada una de estas etapas, se realiza actividades que pueden ser temporales como la introducción y el declive que se tienen un objetivo a un plazo específico. Una vez el producto está en el mercado, surgen actividades que son operativas, es decir que no son temporales, como el servicio al cliente, mantenimiento del producto, incrementar las ventas, etc.
Enfoque ágil, Scrum y el producto
El enfoque ágil es una series de valores y principios que se enfocan en crear un producto en base a la adaptación del entorno, interacción con el cliente y entregar un producto que funciona a corto plazo. Hay varios marcos de trabajo que están alineados a estos valores y principios, uno de ellos es Scrum, que tiene artefactos, eventos y un equipo Scrum (conformado por desarrolladores, dueño de producto y Scrum Master) los cuales tienen como fin crear valor al usuario final a través de Sprints. Utiliza una lista llamada Product Backlog que es una lista ordenada de necesidades que tiene como fin, alcanzar el objetivo del producto por lo que las actividades en Scrum orbitan alrededor de éste, puede ser que, por ello, muchas personas creen que trabajar en un producto es sinónimo de Scrum y que al tener Scrum, no necesitan hacer más, sin embargo, no es así. En la guía Scrum 2020 dice lo siguiente: «Scrum es un marco de trabajo liviano que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos«, con problemas complejos se puede decir que hay una alta incertidumbre y complejidad a lo que queremos dar solución, si lo asociamos a un producto, se podría decir, por ejemplo que es un producto que no tiene claridad en el alcance ya sea porque el mercado es muy dinámico o el usuario no tiene claro que necesita, obligando a trabajar en conocer nuevas prácticas(reemplazando a otras) u optimizando las que ya se manejan, si el alcance del producto está bien definido y no hay mayor complejidad en crearla, puede que sea mejor utilizar otro enfoque para optimizar el tiempo y recursos. Scrum es un marco de trabajo muy popular en los últimos años por su simplicidad, sin embargo, el aplicarlo no es tan sencillo, porque no es una metodología.
Ambigüedad de Scrum
Recuerdo haber visto un video hace años sobre una capacitación de Scrum, el expositor preguntó a la audiencia qué es lo que más le llamaba la atención o que les gustaba de Scrum, un joven se levantó y dijo que estaba emocionado porque en el equipo Scrum no había jerarquías, todos podían opinar, el resto de la audiencia lo aclamaron. Lo que no dijeron en esa capacitación es que la responsabilidad de crear valor recae al equipo y no al individuo, ya no hay jefe a quien culpar, sino que la responsabilidad recae a todos, esto significa que tienen que trabajar en la auto gestión como equipo y no como individuos, pudiendo llevar una complejidad para realizarlo porque hay una dependencia de cada miembro del equipo. Sobre este tema, la guía dice lo siguiente: «El marco de trabajo Scrum es incompleto de manera intencional, solo define las partes necesarias para implementar la teoría de Scrum. Scrum se basa en la inteligencia colectiva de las personas que lo utilizan. En lugar de proporcionar a las personas instrucciones detalladas, las reglas de Scrum guían sus relaciones e interacciones«. Esta explicación tiene sentido, si vamos a trabajar en situaciones complejas, significa que no tenemos certeza de varios temas como el alcance, procesos, técnicas o prácticas, por ejemplo:
- Crear un producto con tecnología que no existe hoy en día.
- Mejora en la calidad de un producto, significa que hay que replantearse si lo que estamos haciendo hoy en día es lo mejor.
- El cliente no sabe lo que necesita por lo que es necesario aprender nuevas técnicas para obtener el alcance o para interactuar con el cliente.
Los motivos para crear un producto pueden ser varias (oportunidad, necesidad, etc.) y también es importante conocer de dónde se origina la iniciativa, por ejemplo, puede ser una decisión corporativa (implementar un producto en varios países), de la gerencia, del departamento del producto o de otro departamento como el informático (IT), en ocasiones simplemente con solicitar a este departamento (IT) una necesidad (de menor tamaño), se dedican a trabajarlo y aplican Scrum sin mucho trámite (he participado en este tipo de desarrollos). Sin embargo, cuando se necesita un sistema de mayor tamaño que involucre varios departamentos, puede que se necesite hacer un análisis de la viabilidad de la creación del producto como el Retorno de Inversión(ROI), contratación de personal, compra de equipo, manejo del presupuesto, del riesgo, etc. Esto son actividades que, si bien no los va a utilizar el usuario final, son necesarios para crear el producto, es aquí donde comenzamos a hablar del proyecto.
Que es el proyecto
La séptima edición del PMBOK define al proyecto como: «Esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único. La naturaleza temporal de los proyectos indica un principio y un final para el trabajo del proyecto o una fase del trabajo del proyecto«. Con temporal, quiere decir que es un esfuerzo que tiene un final (puede ser de años), por ejemplo, al momento de crear un producto (etapa de introducción), ese producto que va al cliente tiene un objetivo, para ello necesita un presupuesto y una fecha límite, este es un tema de confusión de muchas personas, creen que no tener un alcance definido del producto, significa que no hay fin porque no se sabe cuándo van a terminar, pero no es así de literal, por ejemplo, si contrato a una persona a construir mi casa, esa construcción debe terminar en algún momento, porque quiero utilizar la casa, tengo una fecha límite para trasladarme a esa casa o porque tengo un presupuesto limitado. En una empresa pasa lo mismo, aunque no tenga claro el alcance del producto, se tiene una fecha límite y un presupuesto, esto define el producto que pueda tener al llegar la fecha límite o se haya agotado el presupuesto. El proyecto tiene un alcance, que incluye al producto en sí y todas las actividades que se necesitan para finaliza este producto, ahora bien, si se contrata a una empresa para que se encargue del proyecto o parte de ella, también hay que gestionarlo, esto es parte del alcance del proyecto y no del producto.
Los enfoques en los proyectos
Los proyectos utilizan diferentes tipos de enfoques para trabajar un producto, el que ha sido popular por muchos años ha sido el predictivo (o cascada), el cual, de manera errónea se cree que un proyecto solo tiene esta forma de trabajar, es por ello que varios de estos artículos asumen que trabajar en un proyecto significa que solo en este enfoque se puede utilizar. El mundo actual sufre cambios constantes, en la tecnología, el mercado, la política, etc. Esto hace que surjan nuevas formas de construir un producto, servicio o resultado, algunos de estos enfoques son el predictivo, el incremental, el iterativo o el ágil. Se utiliza el enfoque más adecuado para crear valor en los proyectos, dependerá del contexto del proyecto. Esto significa que se puede utilizar un enfoque ágil para crear un producto, implica que se utilizará un marco de trabajo que esté alineado a este enfoque como Scrum, SAFE, XP, Crystal, etc. Esto quiere decir que los proyectos y productos son compatibles, recordemos, el alcance del proyecto incluye el alcance del producto y el alcance de las actividades que ayudan a alcanzar ese objetivo (equipo, contratación de personal, riesgo, etc.), ahora bien, al utilizar Scrum para crear el producto, ¿las actividades que me ayudan a alcanzar el objetivo del producto, son las mismas que utilizaría en el enfoque predictivo? La respuesta seria que sufren cambios algunas de ellas, ¿porque? Esto es porque en Scrum (por ejemplo) hay varias entregas a lo largo del proyecto, por lo que los presupuestos deben reflejar esta situación, los riesgos se evidencian para un Sprint y pueden no existir para el siguiente, la resistencia al cambio se evidencia en cada entrega, esto hace que estas actividades se manejen de diferente forma. Si deseas saber más sobre los proyectos ágiles, te invito a leer el libro Creando valor con proyectos ágiles.
En conclusión, los productos y los proyectos no son incompatibles, es todo lo contario, el producto tiene varias fases a través del tiempo (introducción, crecimiento, maduración y declive) , esto requiere actividades temporales para alcanzar ciertos objetivos, como la creación del producto. Estas actividades temporales se manejan a través de proyectos que pueden utilizar varios enfoques para crearlos, entre ellos el enfoque ágil que tiene asociado varios marcos de trabajo como Scrum para desarrollarlo.
Referencia:
PMBOK Guide | Project Management Institute (pmi.org)
Creando valor con proyectos ágiles: Cambia de la rigidez a la agilidad
Acerca del autor:
Jorge Paz es Coach, Consultor y autor de los libros «Creando valor con proyectos ágiles» y «Transforma la incertidumbre en oportunidades «. Con más de 10 años en la gestión de proyectos. Ha trabajado en proyectos en varios países de Latinoamérica apoyando a equipos de proyectos en alcanzar sus objetivos.
