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 cuál es el objetivo principal, por ejemplo: automatizar un proceso de facturación, reducir el número 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 más cerca del producto correcto. Cada muestra o entrega del demo poco a poco tendrá menos experimentos y pruebas, estos pasarán 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 reinterpreta 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á. Luego, 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 sé, será una asquerosidad, si y solo si, se continúa construyendo en él. 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 ayudará 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 líneas que escribiste habrán cumplido su propósito.
Escribir código basura, bajado de internet, de copy/paste por sí mismo no está mal, no te sientas mal de desecharlo. Lo que está mal es querer conservar líneas 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 está hecho, probado y validado. Cuando trabajas con un demo, cada reunión con un cliente mostrara un sistema más 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 está 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
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20