En la novela Frankenstein, el estudiante de medicina Víctor Frankenstein crea al célebre monstruo a partir de la unión de distintas partes de cadáveres diseccionados. Cual Víctor Frankenstein, muchos Product Owner nos hemos visto haciendo auténticos malabares para acomodar los requerimientos más o menos esperpénticos de ciertos clientes a nuestra plataforma principal. Corta-pega aquí, añade esto encima de lo otro, y así. Y, no, ni Scrum ni ningún framework o metodología te va a librar del riesgo de que, antes de que quieras darte cuenta, tengas a un engendro por producto.

Esta situación es común cuando gestionamos productos B2B y algunos de nuestros clientes tienen un peso especialmente relevante, o cuando, simplemente, hemos entrado en la dinámica de cobrar por desarrollos a medida para estos, aun cuando, a priori, nuestro modelo de negocio no es hacer plataformas a medida, sino que supuestamente ofrecemos la misma plataforma para todos los clientes.

En este post queremos explorar las causas, consecuencias y posibles estrategias ante casos de productos Frankestein.

¿Qué razones llevan a la creación de un producto Frankestein?

No decimos “no” lo suficiente. Nos allanamos ante todos y cada uno de los requerimientos de clientes, de ventas, marketing, inversores, etcétera. Queremos tener a todos contentos. Incluso, llegamos a aceptar que nos indiquen cómo debemos dar respuesta a esos requerimientos.

Falta de visión. Como carecemos de una visión de producto propia y no sabemos hacia dónde queremos ir, cualquier idea nos parece buena. Lo uno y lo contrario, todo nos parece bien siempre que genere algún ingreso a corto plazo.

Confusión respecto al modelo de negocio. No sabemos si somos una empresa “de producto” o “de proyectos”. Terminamos presupuestando y vendiendo funcionalidad ad hoc dentro de nuestra plataforma, como si fuéramos una consultora.

Necesitamos mantener al Equipo de Desarrollo ocupado. Las funcionalidades que tenemos sobre la mesa no son importantes, o no hemos hecho suficiente trabajo de discovery para saber dónde debemos concentrar nuestros esfuerzos. No obstante, como Product Owner tenemos la presión de seguir “alimentando” al Equipo de Desarrollo y le damos estas funcionalidades poco importantes o poco definidas, para mantenerlos ocupados, al tiempo que emponzoñamos el producto.

Pivotes estratégicos de calado (Frankestein temporal). Esta es la única buena razón para aceptar un producto Frankestein de manera transitoria. Sabemos que tenemos que hacer cambios de envergadura en la plataforma y, para llevarlos a cabo, aceptamos cierta fricción a corto plazo, puesto que no podremos materializarlos todos al mismo tiempo. En este caso provocamos el Frankestein a conciencia, sabiendo que el resultado final merecerá la pena.

La consecuencias del producto Frankestein

Deuda técnica. El sistema tendrá cada vez más “ñapas”, “hacks” de todas las clases y colores. Por ejemplo, en una plataforma para clientes B2B, uno de ellos, uno de los “peces gordos”, sí o sí tenía que tener Single Sign On. Esto suponía empantanar el registro y login no solo de los usuarios correspondientes a este cliente, sino de todos los usuarios de todos los clientes. Perdí aquella batalla. En mi opinión, hubiéramos estado mejor sin este cliente, pero no hubo forma. El caso de uso “esquina” se hizo genérico a todos los usuarios, en detrimento de todos. Ahora, el mantenimiento de una de las patas principales de la plataforma se complicaría de manera sustancial.

Desgaste del Equipo Scrum. A nadie le motiva trabajar con un sistema que se ha convertido en una ratonera.

Pérdida de clientes. Acomodar requerimientos peregrinos es “pan para hoy y hambre para mañana”. Y mañana llegarán otros competidores que serán capaces de avanzar muchísimo más rápido que nosotros, sin legacy.

Cómo salir de la espiral Frankestein

Decide una visión clara para tu producto. Decidamos qué queremos ser de mayores, haciendo partícipes a la totalidad del Equipo Scrum y a los stakeholders internos.

Aclara tu modelo de negocio. No hagas más desarrollos a medida, a menos de que aceptemos pasar a un modelo de consultoría y no de producto. O de que aceptemos la consultoría como un mal necesario a corto plazo, pero con un plan sólido a medio y largo.

Asumir riesgos. Sí, hay que estar preparados para perder a algunos clientes. Les explicaremos por activa y por pasiva lo que estamos intentando hacer. Les haremos ver que solo esta estrategia es sostenible a largo plazo, y que además obtendrán una mejor solución -quizás a menor precio, dado que no tendrán que pagar por más desarrollos a medida-. Ahora bien, si no están con nosotros, pues no lo están. Mejor “apechugar” con la pérdida de tesorería a corto plazo y que abandonen el barco.

Estrategia de minimización de la deuda técnica. Antes de seguir añadiendo funcionalidad, empieza a quitar. Identifica qué partes del sistema pueden salvarse con un buen refactoring y cuáles será mejor rehacer desde cero. En suma, asienta bien las bases para una plataforma de calidad.

¿Te suena la música del producto Frankestein? ¿Cómo piensas enderezar el rumbo?

Imagen: Vector de Fiesta creado por freepik – www.freepik.es