La diferencia entre un Demo y un Protoptipo.

Durante el desarrollo de un producto o servicio es común no tener una idea clara y bien definida del entregable que vas a construir. Se suelen crear pequeñas piezas de código que permitan expresar una idea, mostrar un proceso en funcionamiento o solo demostrar que algo puede funcionar. Hay dos enfoques a la hora de construir estas pequeñas pruebas, a continuación te los explico.

Construir un Demo (o estrategia de balas trazadoras).

Una a ametralladora contiene dos tipos de proyectiles, balas y trazadores. Los primeros sirven para dar al blanco, los segundos como ayuda visual al operador para llegar al blanco. El objetivo de las trazadoras es llegar al blanco con el menor desperdicio de balas, para que esto ocurra el operador tiene que estar cerca de su objetivo. Este paso, la cercanía, es fundamental. En el desarrollo de un producto puedes tener una idea clara  de cual es el objetivo principal, por ejemplo:  automatizar un proceso de facturación, reducir el numero de pasos para completar trabajo en un sistema, mejorar una vieja interfaz de usuario, etc. Puedes hacer una base de código estable, la cual tendrá poca posibilidades de cambio y sobre ella aplicar pruebas o experimentos de tipo A/B, que ayudaran a estar mas cerca del producto correcto. Cada muestra o entrega del demo poco a poco tendrá menos experimentos y pruebas, estos pasaran a ser parte del código base y por lo tanto del producto.

Es importante recalcar que desde el principio en que se construye un sistema orientado al demo, la base de código debe ser estable y confiable. El desarrollo orientado al copy/paste o el uso de código basura no están permitidos. La demo solo refina la visión del sistema, no re interpreta la idea original.

Construir prototipos (o estrategia de código desechable).

No todos los proyectos comienzan con una idea clara de lo que se va a hacer. A veces es necesario producir código para automatizar algo que no conoces o dominas, por ejemplo: una entrevista con prospectos de clientes que tienen necesidades determinadas, es imposible que sepas el problema en concreto. Te pueden pedir que construyas algún programa rápido, algo que demuestre que tu equipo de desarrollo puede ofrecer una buena solución al cliente. Con poco tiempo, pocos recursos y poco conocimiento puedes elegir tomar pedazos de otros sistemas aquí y allá, bajar alguna plantilla en bootstrap, hardcodear código y hacer un sistema con un happy path que le indique al cliente como podrá funcionar un hipotético sistema, si se decide hacer con tu equipo. Producir un programa en las condiciones que te acabo de escribir puede resultar abominable, lo se, sera una asquerosidad, si y solo si, se continua construyendo en el. Construir un prototipo implica que el código hecho para mostrar es código basura, una vez cumplida su función deberá ser eliminado inmediatamente. Cada prototipo ayudara a refinar la idea de lo que se necesita,  su propósito es recolectar conocimiento, una vez que tengas una cantidad considerable ya podrás construir un buen producto y el producto correcto. Todas las lineas que escribiste habrán cumplido su propósito.

Escribir código basura, bajado de internet, de copy/paste por si mismo no esta mal, no te sientas mal de desecharlo. Lo que esta mal es querer conservar lineas de código de inferior calidad como la base para construir un sistema.

La importancia de diferenciar entre Demo y Prototipo.

Ante el cliente es vital siempre recalcar cuando se les muestra un demo y cuando un prototipo. La gente sin especialización técnica puede asumir que el ver una pantalla o un flujo mínimo completado es señal de que algo ya esta hecho,probado y validado. Cuando trabajas con un demo, cada reunión con un cliente mostrara un sistema mas terminado, no habrá mucho problema en estos casos. En cambio, si tu vas y muestras un prototipo, sin indicar lo que es (código basura), el cliente puede caer en la trampa del “ya esta hecho”, confundirse por los tiempos de entrega y actividades, desconfiar o generar un ambiente hostil de trabajo. Bajo ninguna circunstancia hay que mentir, esto solo afecta la relación que se tiene. Cada prototipo que se le muestra ayuda a cerrar el requerimiento. Un requerimiento robusto apegado a las necesidad del cliente le va a aportar valor.

Autor imagen: Adam Greig