Cambio de mentalidad: proyecto vs producto.

¿Nunca os ha llamado la atención que, cuando estamos en un proyecto, hablemos de PRODUCTO mínimo viable? ¿Por qué en los proyectos con Scrum hablamos de PRODUCT Owner? ¿No debería ser Project Owner?

La palabra “proyecto” la tenemos muy manida, es un concepto que se ha establecido con fuerza en nuestro día a día. Nos cuesta decir “yo pertenezco a este equipo”, solemos decir “estoy en este proyecto”.

Esto es porque siempre nos han inculcado que trabajamos en proyectos y que en el sector IT todo el mundo pertenece a uno. Por contra, cuando hacemos un “proyecto interno” solemos llamarlo producto.

¿Es importante la diferencia entre un proyecto y un producto? ¿Por qué los proyectos gestionados con Scrum también fallan?

La diferencia entre un proyecto y un producto puede marcar la diferencia entre éxito y fracaso. Vayamos a la definición de proyecto que nos proporciona el Project Management Institute:

“Un proyecto es una actividad grupal temporal para producir un producto, servicio o resultado, que es único. Es temporal dado que tiene un comienzo y un fin definido, y por lo tanto tiene un alcance y recursos definidos”.

Si hacemos un análisis de la definición, hay dos cosas que son problemáticas: alcance definido y fecha de inicio y fin.

Proyecto cerrado VS Proyecto Iterativo

Todo proyecto siempre es cerrado porque debe contar con una fecha de fin. Por el contrario, un producto no tiene una fecha de finalización, se considera que no tiene fin en el sentido de que morirá el día que deje de ser rentable o que no se quiera evolucionar más, pero no tiene una fecha marcada donde ya no se desarrolla más.

Visto de esta manera, parece que un proyecto está más acotado y controlado. Sin embargo, cualquiera que tenga experiencia en desarrollo habrá experimentado las 3 verdades del software:

1. Nunca podremos tener todos los requisitos antes de empezar.
2. Los requisitos cambian con el tiempo.
3. Siempre queremos hacer más de lo que el tiempo y el dinero permite.

Bajo estas 3 verdades, es imposible tener un alcance definitivo, por lo que si tenemos que calcular una fecha de finalización acabaremos haciéndolo con una alta probabilidad de error.

Pero veamos más diferencias.

Objetivo de Proyecto vs Objetivo de Producto

En un proyecto uno de los objetivos es cumplir con la fecha para entregar un alcance acordado con un coste previsto y con una calidad definida.

Muchos equipos acaban por reducir la calidad (con el consiguiente aumento en los costes de mantenimiento) con tal de llegar a la fecha definida.

El producto, sin embargo, va más allá de cumplir con una fecha, busca generar valor para la organización (ya sea dinero u otro bien intangible como imagen de marca). El producto puede tener fechas, ¡por supuesto!, pero su éxito no se mide en el cumplimiento, sino en el valor que genere. ¿Qué organización pagaría por un software que nadie quiere? Muchas más de las que crees, ¡créeme que he visto decenas de ellas!

Seguimiento por % de avance vs Seguimiento por valor

Otra diferencia a la hora de hacer software con un proyecto es el % de avance. El % de avance te indica cómo vas respecto al objetivo final.

La teoría funciona si no fuera porque el alcance suele variar durante el proyecto. Hay quien hace cálculos como “si tengo 10 meses y llevo 9 estamos al 90%”, pero no deja de ser un autoengaño.

En los productos es diferente. No hay un % de avance porque no hay un fin a alcanzar sobre el que compararnos.

Dependiendo del contexto y del objetivo del producto tendremos que definir qué medida tendremos en cuenta para medir el valor que aporta: ingresos, retención, eficiencia, etc. En los productos digitales tendremos que definir nuestra medida y hacer que aumente con el paso del tiempo.

Jefe de proyecto vs Product Owner

En cuanto al liderazgo del equipo, en el modelo de proyecto recaerá en el Jefe de Proyecto, que es el máximo responsable de que se cumpla la fecha, el alcance, coste y calidad.

Por tanto, si genera un software que lo cumpla todo, pero que nadie lo usa, el Jefe de Proyecto lo considerará un éxito, ya que su responsabilidad se limita a la construcción, no a la venta posterior.

Sin embargo, a la hora de desarrollar un producto con Scrum, la figura clave será el Product Owner, cuya responsabilidad consiste en generar valor. Podría haber fechas de entrega, pero serán estratégicas para generar valor.

Si las fechas se cumplen y el software se rechaza en el mercado, entonces no estará siendo un éxito. Por tanto, deberá controlar no solo el alcance o requisitos, sino también el valor generado y los costes de propiedad (Total Cost of Ownership).

Por eso un buen Product Owner valora la calidad, porque entiende que una baja calidad genera, a medio plazo, costes en mantenimiento e impacto negativo en su producto.

Además, un Jefe de Proyecto se preocupa principalmente del equipo. Aunque es verdad que tiene que identificar y gestionar a los interesados y sus expectativas, pasará más tiempo con su equipo de trabajo. En el caso del Product Owner encontramos una diferencia clave.

Un buen Product Owner pasará el 50% de su tiempo con los usuarios, entendiendo sus necesidades para saber dónde aportarles valor. El otro 50% estará con su equipo para transmitir lo aprendido con los interesados.

Aquí quiero puntualizar una cosa, a los desarrolladores nos pagan por hacer software ya sea en un proyecto o para un producto. Los buenos desarrolladores quieren que el software que crean sea útil para un usuario final, que tenga sentido, hacer software que nadie quiere desmotiva y provoca en las organizaciones pérdida de talento.

La presencia de Negocio

Otro punto clave es la relación de IT con Negocio. En el modelo de proyecto normalmente Negocio aparece al principio para darnos los requisitos y al final para certificar que obtiene lo que pidió.

Durante el camino, Negocio no aparece salvo para cambiar los requisitos y está gestión acaba siendo muy dura para el Jefe de Proyecto. Cuando hacemos producto necesitamos que Negocio esté presente, hacemos inspección y adaptación con negocio cada Sprint para analizar el mercado y el valor de nuestro software, es más, se recomienda que nuestro Product Owner pertenezca a Negocio.

¡Y lo más importante! ¿Cómo podemos aumentar las probabilidades de éxito? En el caso de producto es vital que el usuario ocupe su silla y esté presente. Para eso no paramos de hacer inspección y adaptación con él.

No se trata de hacer lo que el usuario te pide, se trata de entender lo que realmente necesita y aportar soluciones que le den valor. Hay una frase de Henry Ford que dice “si le hubiera preguntado a mis usuarios qué querían me habrían dicho que caballos más rápidos”.

Si mientras tu producto crece lo muestras a los usuarios aumentarás las opciones de que ese software tenga sentido y aporte valor. En un proyecto el usuario no suele opinar porque la misión no es vender, solo cumplir con los requisitos que nos dio Negocio.

Eficiencia de Recursos vs Eficiencia de Flujo

Por último, mencionar el concepto que nos enseñó Jerónimo Palacios de lean sobre la diferencia entre Eficiencia de Recursos vs Eficiencia de Flujo.

Cuando hacemos un proyecto buscamos la eficiencia de recursos, que básicamente consiste en tratar de tener a todo el equipo ocupado al 100%. De esta manera incentivamos que se hace la mayor cantidad de trabajo, pero se corre el peligro de caer en la especialización..

En un producto Agile se fomenta más la eficiencia de flujo, que consiste en reducir el tiempo de respuesta al mercado para satisfacer a los usuarios y la sostenibilidad a largo plazo del modelo mediante la responsabilidad compartida de las tareas. Un ejemplo de esto es la subida a producción. En Scrum buscamos desde el primer Sprint que el incremento que acabamos de generar esté listo para subir a producción.

Mientras que en los proyectos esto se deja para el final porque es más “eficiente” (en términos de recursos) hacerlo todo a la vez al final. Eso sí, esto aumenta el riesgo de que acumules mucho software sin testar en el mercado y que nadie lo quiera, Scrum trata de evitarlo al poner cuanto antes al usuario a probar tu software.

La eficiencia de recursos siempre se asocia más a proyectos porque contamos con especialistas en los que tratamos de tener ocupados al máximo. En un producto se busca el concepto responsabilidad compartida entre los miembros del equipo para llevar cuanto antes al usuario final las funcionalidades que estamos desarrollando.

Este es otro motivo por el que Scrum funciona mejor para la eficiencia flujo, sus eventos, roles y artefactos están pensados para que la velocidad de interacción con el usuario final sea rápida.

¿Cómo se transforma un proyecto a producto?

Antes de acabar me gustaría contar una anécdota. Con un equipo con el que colaboré recientemente vi cómo se transformaban de proyecto a producto a raíz de ganarse la confianza de la organización.

Empezaron, como todo proyecto, definiendo un alcance y transmitieron una fecha al cliente, acto seguido llegaron a un acuerdo y firmaron un contrato. Pasado varios meses, un día le pregunté a la Scrum Master: ¿Cuándo acabáis? La respuesta me dejó helado: “No lo sé… ahora mismo vamos entregando en cada Sprint lo que nos pide el Product Owner en base a lo que le piden los usuarios, vamos firmando ampliaciones de contrato de meses sin alcance definido”.

Aunque ellos los seguían llamando “proyecto” no se habían dado cuenta de que se habían transformado en un producto digital.

Conclusión

Muchas compañías entienden la transformación cómo actualizar su web a nuevas tecnologías modernas.

Si sigues haciendo software en base a requisitos no definidos, sin tener a tu usuario cerca, mediante bonos personales por cumplir fecha, con fechas cerradas entonces no podemos decir que estás transformado aunque tengas microservicios y una base de datos NoSQL.

Mientras que si montas un equipo Agile entorno a tu producto “web”, trabajas mediante inversiones, realizas inspección y adaptación con el usuario y mirando en todo momento el valor que te genera, entonces podrás competir en el mundo digital.