Siempre que desarrollamos un producto, nos demos cuenta o no, estamos haciendo un balance entre construir lo correcto (la funcionalidad exacta que necesita nuestro cliente), construirla correctamente (siguiendo la mejor arquitectura o los mejores estándares), o construirla de la forma más rápida posible.
Por supuesto, todos queremos estar en el punto del centro de la imagen y conseguir los tres aspectos al mismo pero es muy difícil lograr el equilibrio perfecto, cuando no imposible. A menudo debemos ir hacia uno de los lados de la figura para sacar la mejor versión de nuestro producto adelante.
Si nos movemos hacia el punto 1, en la intersección entre construir lo correcto y construirlo correctamente tendremos un producto perfecto con una arquitectura también perfecta pero podemos haber tardado demasiado en construirlo y no tenerlo disponible cuando el cliente la necesita o cuando el mercado lo demanda. Construir un Whatsapp con interfaz web puede estar muy bien justo ahora y hacerse muy popular y hacerse muy popular en poco tiempo pero podría ser demasiado tarde si lo entregamos dentro de un año.
En cambio, si tendemos hacia la intersección del punto 2, crearemos muy rápido el producto correcto partiendo quizás de un prototipo evolucionado pero que podría llevarnos a arrastrar una deuda técnica muy grande. Esta deuda técnica podría hacer que termine siendo inabordable cada vez que queramos construir nuevas cosas sobre una arquitectura base tan pobre.
En la tercera y última de las opciones podríamos construir muy rápidamente un vehículo con una bonita línea deportiva y un gran motor pero olvidamos construir lo correcto: nuestro cliente en realidad necesitaba un producto con algo de capacidad de carga para su trabajo diario.
Según sea nuestro papel en el proyecto todos tenemos cierto sesgo hacia alguno de los círculos. Los dueños del producto, es decir nuestros clientes, tienden a poner todo el foco en construir lo correcto. A su vez los miembros del equipo de desarrollo tienden en cambio hacia construir correctamente, centrándose en las cuestiones de diseño de la arquitectura y de la solución técnica. Por último el Scrum Master tiende habitualmente hacia construir el producto de la forma más rápida posible.
Ese es el papel que suelo tener yo, el de Scrum Master o jefe de proyectos, que solemos andar preocupados por el tiempo en el que vamos a entregar las cosas. En nuestro descargo debo decir que la velocidad es siempre un aspecto importante. Iterar y entregar nuevas funcionalidades más pronto nos va a permitir aprender antes qué es lo más importante a construir ahora y cómo construirlo técnicamente de la mejor forma posible.
Todo esto que comento aquí lo puedes encontrar de forma muy condensada en el vídeo sobre Product Ownership de Henrik Kniberg. No sólo habla de este dilema entre construir lo correcto, construirlo rápido o de la mejor forma posible sino de muchos otros aspectos relevantes para los dueños del producto y directores de proyecto en el cliente. Échale un vistazo, es muy bueno.
