En los últimos años han surgido muchos conceptos que hemos interiorizado en mayor o menor medida, como big data, SaaS, cloud o agile, pero existen todavía algunos conceptos más difíciles de interiorizar; es el caso de desarrollo de productos. La idea en este artículo es reflexionar un poco más acerca ello, sus implicaciones y las diferencias con el concepto más tradicional de desarrollo de proyectos.
¿Qué es un producto?
Aunque la pregunta puede parecer trivial, si vamos a la Wikipedia podemos encontrar más de 20 definiciones en función del campo en el que apliquemos el término “producto”. En este caso, las que más se acercan a la definición que nos podría interesar serían las siguientes:
- Producto (business), un item que sirve como solución a un problema específico del consumidor.
- Producto (project management), un entregable o conjunto de ellos que contribuye a una solución de negocio.
Aplicado al sector tecnológico, podríamos definir un producto como un “item” o una aplicación conseguida mediante el desarrollo de un software que nos permite ofrecer una solución a un problema o necesidad derivada del día a día del negocio de una unidad concreta, de un área, de una organización e incluso de un conjunto de empresas, si entendemos el producto como algo que podemos ofrecer al mercado.
Dicho de otra manera, un producto sería una aplicación de software capaz de ofrecer un conjunto de funcionalidades o capacidades que satisfagan las distintas necesidades que un cliente o conjunto de estos pueda tener.
Diferencias entre proyecto y producto
Una vez vista la definición de producto podemos considerar que no encontramos, a priori, muchas diferencias con el enfoque más tradicional y conocido de proyecto de software, por lo que intentaremos examinarlas en mayor detalle.
Diferencia 1: Planificación vs Ciclo de vida
Un proyecto es una iniciativa normalmente acotada en el tiempo. Un equipo dedica un tiempo preestablecido, con un alcance predefinido para llevar a cabo la creación o implantación de una solución que responde a esas necesidades concretas y definidas previamente. A diferencia del proyecto, el producto no tiene un alcance cerrado, sino que se parte de la identificación de una necesidad y se evoluciona, a través de la entrega de valor continua y la recogida de feedback de los usuarios. Por lo tanto, el proyecto tendrá un comienzo y un fin, mientras que el producto podrá (y deberá) extenderse en el tiempo mientras sea válido, pudiendo evolucionar y crecer adoptando nuevas capacidades (incluso llevando a cabo nuevos proyectos para que el producto evolucione).
Esto nos lleva a otra de las diferencias: el ciclo de vida del producto. A diferencia de un proyecto (el cual, en lugar de un ciclo de vida, tiene una planificación) tiene múltiples estados: la concepción del producto, su construcción e introducción en el mercado, su evolución y, finalmente, la retirada del producto cuando este es discontinuado o sustituido por uno nuevo. Imaginemos, por ejemplo, un sistema operativo. Cuando este se lanza al mercado tiene una serie de capacidades y novedades, pero pronto evoluciona solucionando posibles problemas y adoptando nuevas capacidades, hasta que pasado un par de años es sustituido por uno nuevo comenzando de nuevo el ciclo.
Diferencia 2: Alcance vs Funcionalidad
Otro punto diferencial entre proyecto y producto es que cuando empezamos a construir un producto, en muchas ocasiones, no tenemos toda la información acerca de las capacidades que debe tener sino que, conforme empezamos a construirlo y a revisar sus capacidades con product owners, product managers y usuarios, pueden surgir nuevas características en torno a él.
Por contra, en un proyecto toda la información debe estar recogida al principio del mismo para evitar problemas durante el desarrollo, siendo este un punto crítico que, a su vez, no siempre es posible conseguir, desembocando en uno de los problemas tradicionalmente encontrado en el desarrollo de proyecto de software (y de otros tipos).
Diferencia 3: Product Manager/Owner vs Project Manager
Una vez entendido que el objetivo del producto excede en el tiempo al objetivo del proyecto y que este (producto) dispone de un ciclo de vida propio, parece obvio poder pensar que los roles involucrados en la definición y construcción de un producto sean distintos a los roles tradicionales para llevar a cabo un proyecto. De esta manera surgen nuevas figuras, entre las que destaca una: el product owner/manager.
El product manager es una figura tradicionalmente ligada al mundo del marketing que ha evolucionado hasta convertirse en el responsable final de un producto. Siendo este, por lo tanto, el responsable de recoger las distintas necesidades del mercado o unidades de negocio y, una vez recogidas, busca una solución que se materializa en la creación de un producto con una serie de características, capacidades y funcionalidades.
Por otro lado, el product owner como tal no es una figura en las empresas, si no un rol adoptado por figuras como el product manager, cuyo objetivo es la gestión del ciclo de vida de un producto. De esta manera un product manager colaboraría asumiendo este rol en la construcción del producto.
En contrapartida, el jefe de proyecto o project manager tradicional era una figura responsable del equipo de proyecto y de llevar a cabo la entrega de unas capacidades a lo largo del mismo, cumpliendo con la planificación y el presupuesto del proyecto. Una vez acabado el proyecto, el jefe de proyecto y el equipo pasan a uno nuevo a diferencia del product manager, que no se desliga mientras no acabe el ciclo de vida del mismo. Además, el product manager/owner es el responsable último de la funcionalidad incorporada en el mismo, mientras que el jefe de proyecto únicamente es responsable de entregar la funcionalidad comprometida en el alcance del proyecto.
Otra diferencia significativa es que el project manager, en muchos casos, puede ser un rol desempeñado por una persona externa a la organización, mientras que el product manager deberá ser una persona propia de la empresa que tenga la capacidad de recoger la información y decidir la funcionalidad del producto.
Diferencia 4: Metodología de proyecto vs Framework Ágil
Aunque el hecho de hablar de proyecto no necesariamente implica que en términos de metodología hablemos del tradicional Waterfall. Si hablamos de proyecto como una iniciativa acotada en el tiempo, en la que un equipo dedica un tiempo preestablecido con un alcance predefinido para llevar a cabo la creación o implantación de una solución que responde a esas necesidades concretas y definidas a priori, lo que nos pediría el cuerpo es gestionarlo de una manera tradicional, siguiendo un Gantt y usando la gestión del cambio como un pilar dentro de proyecto. Sin embargo, la forma de enfocar el desarrollo de un producto, va más ligado al uso de metodologías y frameworks ágiles para lograr:
Entrega de valor contínua al usuario final: El producto se construye de forma incremental e iterativa y se realizan entregas frecuentes que se ponen al servicio del cliente desde el primer momento. Lo entregado es utilizable por el cliente y le proporciona servicio end-to-end.
Enfoque customer-centric: El producto crece entorno a las necesidades del cliente y el feedback continuo que se incorpora al producto, optimiza su valor y reduce el riesgo de invertir en funcionalidades que no interesan.
Time-to-market reducido: Se debe priorizar el generar un Producto Mínimo Viable (MVP) y ponerlo a disposición del cliente rápidamente, optando por la funcionalidad que mejor responde a la demanda del mercado en cada momento.
Diferencia 5: Centro de Coste vs Centro de Beneficio
Otro punto relevante, y que en muchas ocasiones las empresas todavía están en proceso de interiorizar, es la visión del producto como una solución que aporta un beneficio tangible a la empresa y que, por lo tanto, tienen un retorno de la inversión más allá del dinero invertido en el mismo. Este punto, que muchas veces se da por supuesto, no está totalmente asimilado, al compararse muchas veces con el presupuesto invertido en los proyectos más tradicionales que, en contrapartida, se consideran un coste (y el proyecto, por tanto, un centro de coste). A diferencia de los productos, que deberían considerarse (y empieza a hacerse) como un centro de beneficio. No obstante, de cara a interiorizar cada vez más este concepto, es importante poder conocer el ROI esperado del producto, el periodo necesario para su payback y, de esta manera, cuantificar de la mejor manera el valor aportado por el producto.
Diferencia 6: Medición del producto vs Entrega del proyecto
En línea con el punto anterior está la forma de entender la validez del proyecto o su éxito en contraposición con lo que sería un producto exitoso.
Un proyecto acabado en tiempo y “forma” (con unos entregables bien definidos, en el plazo previsto, con los recursos y presupuestos planificados) puede considerarse un proyecto exitoso, al margen de que los usuarios encuentren valor en su uso o aplicación. En contrapartida, un producto que se considere exitoso deberá reunir una serie de capacidades que realmente aporten valor al negocio y a los usuarios y, precisando más, ser capaz de cumplir con unos KPIS como los comentados en el punto anterior. Además, el cumplimiento de estos KPIS son un punto clave para dar continuidad al producto y mejorarlo. Imaginemos un producto de machine learning que nos ayuda a mejorar la venta de nuestros productos con un coste mucho menor del beneficio aportado, seguramente la mantendremos mucho tiempo y, no solo eso, sino que intentaremos mejorarlo.
Nuestra visión de los productos (de datos)
En Keepler tratamos de ayudar a nuestros clientes a desarrollar más allá de proyectos (que también lo hacemos) productos orientados al diseño, explotación y obtención de valor de los datos disponibles en las distintas organizaciones. Esto es lo que denominamos Data Products. Y lo construimos basado en tres pilares:
El valor de los datos: Los datos son el nuevo activo de las empresas. El verdadero valor de los datos reside de la capacidad para interpretarlos para tomar decisiones inteligentes que ayuden al éxito del negocio.
Conocimiento de los clientes: En un entorno competitivo, las empresas cobran mayor valor cuanto mayor sea la información que reúnen sobre sus clientes / productos, de forma que puedan mejorar los servicios que prestan y diferenciarse de la competencia.
Ajuste del coste y la demanda: Más valor con menos coste. Producto adaptado al mercado que genera mayor beneficio y ventaja competitiva a través del uso de la nube pública: pago por uso, automatización, reducción de costes de operación.
Imagen: unsplash | rawpixel
Business Development en Keepler. "Computer engineer with experience in technology consulting with public cloud providers. I have managed traditional projects and product development for large accounts. In recent years I have combined it with internal mentoring and team management applying agile practices."
0 comentarios