La creación rápida de prototipos puede ser una herramienta útil para nosotros, como gestores de proyectos digitales, para ayudar a los clientes que hacen las preguntas: «¿Pero esto funcionará?» y «¿Cómo funcionará esto?». A menudo, la respuesta simple pero frustrante es simplemente: «Aún no lo sabemos, pero permítenos ayudarte a descubrirlo». Una excelente manera de hacerlo, y una que está ganando cada vez más popularidad entre agencias y clientes, es la creación rápida de prototipos: invertir un poco para tomar una decisión informada sobre la viabilidad del producto antes de realizar grandes inversiones.
Nuestra industria se mueve a la velocidad de la luz y, como gestores de proyectos digitales, debemos ser rápidos para adaptarnos a nuevas formas de trabajo. Un ejemplo actual de ello es la creación rápida de prototipos. Hace nueve meses, nunca había trabajado en un proyecto de prototipado rápido y ahora acabo de terminar mi cuarto proyecto de prototipado rápido para probar la viabilidad de un producto de manera ágil. Así que si aún no has trabajado en un proyecto de creación rápida de prototipos, no tengo dudas de que uno está a la vuelta de la esquina para ti.
Esta publicación explica diferentes caminos para explorar la viabilidad de un producto y te proporcionará algunos principios orientadores para ayudarte a gestionar proyectos digitales o analógicos de rápida evolución con confianza.
Pero antes, ¿qué es la creación rápida de prototipos?
La creación rápida de prototipos se refiere al proceso aplicado para construir una prueba de concepto o prototipos rápidos. Un prototipo es útil para comprobar la validez de una idea. Te permitirá desarrollar más funciones, más rápido, pero normalmente esto es a costa de la calidad y, por esa razón, el producto será, en su mayoría, desechable.
Los prototipos vienen en diferentes formas y tamaños
Aunque existen varias maneras de explorar la viabilidad de un producto, aquí tienes tres enfoques distintos:
- Prueba de concepto – Una prueba de concepto es un demostrador muy ligero y desechable del producto, orientado a comprobar la idea detrás del producto antes de desarrollarlo.
- Prototipo rápido – Un prototipo rápido es una primera versión ligera del producto que puede ser probada con usuarios reales para ganar más confianza en el producto antes del desarrollo completo.
- Mínimo producto viable (MVP) – Un MVP es la primera versión del producto en calidad de producción, desarrollando completamente funciones operativas para los usuarios.
Tu confianza en el producto debe ser el factor principal para decidir qué enfoque tomar.
A mayor riesgo en la idea = mayor rapidez en actuar.
Algunas personas pueden decir que si una idea es arriesgada entonces deberías dedicarle más tiempo a pensarla antes de ejecutarla. En cierto modo, tienen razón. Puedes validar una necesidad casi sin construir nada. Existen numerosos ejemplos de pruebas de validación que vale la pena investigar.
Sin embargo, una vez que sabes que existe una necesidad, la única manera de probarla es construir algo, lanzarlo lo más rápido posible en su forma más básica, obtener retroalimentación e iterar. Hemos comprobado en numerosas ocasiones que cuando investigas una idea, el cliente inevitablemente dirá «Compraría eso» y luego, cuando el producto sale al mercado, las ventas no despegan.
“Definitivamente compraría eso” – 100 personas
Personas que realmente lo comprarán = 10
Jeff Sheldon (@ugmonk) 1 de septiembre de 2016
La creación rápida de prototipos reduce el riesgo en cada ocasión al acortar el ciclo de retroalimentación y asegurarse de que estás creando un producto que se venderá.
Cómo saber cuál es la mejor opción para ti
| Estilo de prototipo | Confianza | Qué tan ficticio | Qué tan desechable |
|---|---|---|---|
| Prueba de concepto | Baja | Completamente | Completamente |
| Prototipo rápido | Media | Parcialmente | Parcialmente |
| Mínimo Producto Viable | Alta | Casi nada/ninguno | Pensado para durar |
Para construir cosas rápidamente, debes estar dispuesto a desarrollar nuevos procesos y formas de trabajo.
Principios orientadores para la gestión de proyectos de creación rápida de prototipos
Trabajar de las formas que se describen a continuación requiere una nueva mentalidad. Recomendaría empezar tu proyecto con una reunión de inicio interna para repasar estos principios y explicar por qué son importantes. Esto ayudará a asegurar que todo el equipo esté alineado desde el principio, sepa lo que se espera de ellos y estén al tanto de dónde y por qué el proyecto puede diferir de lo que están acostumbrados.
1. Prepárate para hacer menos
Esto probablemente significará menos planificación previa de la que estás acostumbrado e implicará estar cómodo con tener:
- No existen, o existen criterios de aceptación mínimos
- Sin sub-tareas en las historias
- Sin estimaciones
Lo que pierdes en un proceso rígido lo ganas en velocidad, confianza y comunicación. Acepta la falta de control.
Este principio recordará a todo el equipo que está bien abandonar procesos ya conocidos si eso significa entregar software funcional más rápido. Es bueno preguntarse regularmente a uno mismo y al equipo “¿es esta la forma más rápida de hacer x?”.
2. Muestra, no expliques
Puesto que harás menos planificación previa, conversarás y dibujarás más durante el desarrollo. Quizás quieras extender los scrums para poder hablar de la funcionalidad un poco más en detalle antes de que tu equipo empiece a construirla ese mismo día. Como se suele decir, una imagen vale más que mil palabras. A veces, un boceto de la página, un modelo de contenidos o un diagrama que muestre cómo se va a construir el sistema es suficiente para empezar a construir y después se puede iterar sobre eso.
Este principio generará confianza en ti y en el cliente, a todos les gusta ver avances y mostrar el trabajo regularmente brinda la oportunidad de recibir comentarios a tiempo, minimizando el desperdicio.
3. Pide perdón, no permiso
En la mayoría de los procesos rigurosos de desarrollo de software, el consenso es clave. Quieres que el product owner apruebe los criterios de aceptación y, como PM, quieres saber que tu equipo ha entendido los requisitos antes de escribir una sola línea de código.
Con los prototipos rápidos, es importante que el equipo se sienta facultado para construir conforme a su mejor entendimiento en ese momento y luego mostrar su trabajo lo antes posible, recibir retroalimentación e iterar.
Buscar el consenso desde el principio ralentizará las cosas y es raro que el trabajo se pierda si el equipo muestra en qué está trabajando temprano y con frecuencia.
Este principio es especialmente útil para los desarrolladores, ya que les da la responsabilidad de diseñar y construir inicialmente una funcionalidad con poca influencia externa. A menudo construimos demasiado, complicamos las cosas porque no siempre vemos la complejidad técnica involucrada en nuestras peticiones, por lo tanto, confiar en que los desarrolladores del equipo decidan cuál es la implementación más básica y que construyan eso primero es una excelente forma de proceder.
Para que esto funcione, es esencial que tus desarrolladores tengan un profundo entendimiento del proyecto para que puedan tomar las decisiones correctas y siempre construyan solo lo necesario.

4. Anima siempre al equipo a mostrar lo que están haciendo (aunque esté feo)
Este proceso está inspirado en los principios de prototipado de los Servicios Digitales del Gobierno.
Normalmente solo mostramos las funcionalidades a los clientes cuando están terminadas. En proyectos de prototipado rápido, es importante mostrarlo tan pronto como sea funcional para poder minimizar el desperdicio, iterar y cambiar de rumbo si es necesario.
Haz que funcione. Enseña lo que hay.
Hazlo bonito. Enseña lo que hay.
Haz que escale. Enseña lo que hay.
Este principio libera a los miembros del equipo de sentir que solo deben mostrar el trabajo cuando ha sido revisado por diseño o ha pasado todas las pruebas. Celebra el trabajo en curso.
5. Elige procesos físicos antes que en línea
En palabras de Brett Harned, gestionamos proyectos con la mente, no con las herramientas. No tengas miedo de dejar tus herramientas de gestión de proyectos. Visualiza el trabajo, utiliza un backlog físico, pega bocetos, flujos de usuario y personas en la pared y haz scrum alrededor de ello. Haz referencia a todo con frecuencia y anima a la gente a apropiarse de mover tarjetas y celebrar el despliegue de nuevas funcionalidades. Si tu cliente no está en la misma ubicación, fotografíalo todo y mándalo por Slack para que no quede fuera.
Probar un proceso nuevo puede ser complicado, visualizar el trabajo probablemente generará conversaciones que no ocurrirían si estuvieras en videollamada mirando un tablero digital. Rápidamente quedará en evidencia si una tarjeta física no se ha movido en un día o si hay demasiado trabajo en curso. El uso de procesos físicos proporciona una capa adicional de transparencia que, créeme, cuando todo parezca confuso, agradecerás eternamente.
6. Sé excelente con los demás
Es natural sentirse abrumado cuando tratas de incorporar un nuevo proceso y una nueva forma de trabajar, especialmente cuando también eres nuevo en ello. Lidera con confianza y apoya al equipo si está teniendo dificultades. Escucha atentamente sus inquietudes y sé flexible para ajustar el proceso sobre la marcha. Asegúrate de que el proceso no esté añadiendo presión adicional al equipo, el prototipado rápido se trata de trabajar con mayor inteligencia, no con mayor esfuerzo.
Dependiendo de las personalidades en tu equipo, algunos miembros acogerán esta nueva forma de trabajar mientras que otros podrían resistirse. Todos aprendemos a ritmos diferentes y cada disciplina afrontará diferentes desafíos al adaptarse a una nueva manera de trabajar. Como PM, mantente consciente de esto y procura crear un ambiente de apoyo y seguridad para el equipo: siéntense juntos, tomen té y verifica regularmente con cada uno cómo les está yendo.
7. Minimiza las distracciones
A veces es complicado saber, como PM, en qué aspectos puedes hacer concesiones con un proceso nuevo y en cuáles debes mantenerte firme. Cuando se trata de aceptar nuevos cambios a mitad de un sprint, sigue defendiendo tu postura y diciendo que no. Es importante que, al comenzar un sprint, tu equipo no sufra interrupciones; proteger su tiempo es lo más valioso que puedes hacer.
Este principio le da poder al equipo para rechazar solicitudes. Es probable que estés trabajando con sprints de una semana y, con un periodo tan corto, no puedes permitirte perder tiempo. Logra la aceptación del resto de la empresa para que las personas puedan aplazar reuniones internas o responsabilidades adicionales, de manera que puedan concentrarse durante ese tiempo.
Haz que la creación rápida de prototipos funcione para ti
He encontrado esta nueva forma de trabajar extremadamente gratificante; a veces se sintió caótica, desordenada y fuera de control. Es difícil saber dónde y cuánto deberías desviarte de tu proceso actual, pero te animaría a experimentar, fallar rápidamente y ser abierto con tu equipo sobre lo que necesitas de ellos.
En ocasiones, eliminamos una parte fundamental del proceso y más adelante la restituimos porque se hizo evidente que me resultaba complicado gestionar el proyecto sin ella. En esos momentos del proyecto, me aseguraba de poder explicar claramente las consecuencias de eliminar ese proceso al resto de mi equipo. Como equipo, discutíamos si había una forma alternativa de obtener esa información y, si no encontrábamos una mejor solución, restablecíamos el proceso. Es en momentos como esos cuando se cosechan los beneficios de construir un ambiente de apoyo, confianza y respeto mutuos. En cada etapa, aprendemos, iteramos y seguimos adelante como todo un equipo.
Crédito a Chris Thorpe por estos principios; todo lo que sé es gracias a él.
