El proceso para crear el MVP de tu startup

Hoy en día cualquiera que se encuentre en un entorno emprendedor o de startups conocer la palabra MVP, que no es otra cosa que el Producto Mínimo Viable que te permitirá estar en el mercado y probar si tu hipótesis de negocio puede funcionar. Es casi obligado pasar por esta fase para toda startup que comience su andadura. En esta primera fase, la startup normalmente no tiene mucho dinero y es necesario que el proceso de creación del MVP sea rápido, económico y con garantías de que tecnológicamente funcionará.

Tras trabajar con startups que se encuentran en su primera fase de desarrollo nos hemos dado cuenta de que además de ser sus partners tecnológicos, les aportamos la experiencia en el proceso de creación de su MVP. Para ello, hemos desarrollado un proceso específico de desarrollo del MVP, que vamos mejorando progresivamente con cada cliente que tenemos.

Nos gustaría proponer el proceso para crear el MVP de tu startup:

Primer contacto con el cliente

Normalmente antes de esta primera reunión ya hemos hablado con el cliente, nos ha comentado una idea general de su proyecto y le hemos dado consejos y asesoramiento desde nuestro punto de vista. ¿Cómo debería ser la aplicación? ¿Qué cosas son críticas y qué no?… Además, nos ha servido para saber si el cliente tiene la firme voluntad de llevar a cabo la idea o sólo está pensándolo y tiene dudas. No son contactos muy prolongados pero sí que intentamos tener una relación directa con el cliente y darle consejo sobre cómo lo haríamos nosotros. Esta fase es muy importante para empatizar y que todas las partes hablen un lenguaje parecido. El final de esta fase viene marcado por la generación de un documento donde intentamos resumir el proyecto y damos estimaciones sobre tiempo y precio.

Sesión de trabajo para definir conceptos

El cliente ha aceptado una primera propuesta y quiere trabajar con nosotros. Es hora de ponerse manos a la obra. Es necesario dedicar entre 1 y 2 días al cliente para hablar de todos los aspectos del proyecto. Aquí se aclaran exactamente términos y conceptos para empezar a hablar de lo mismo. Además, necesitamos que el cliente nos dé todo tipo de información que iremos clasificando y completando. Lo que obtenemos es un documento de tareas o backlog con todas las funcionalidades. Cada funcionalidad estará compuesta por una ficha descriptiva. En cada ficha al menos detallamos:

• Nombre de la tarea
• Descripción en lenguaje natural de la misma
• Perfiles de usuario (si los hay) a los que afecta
• Estimación temporal
• Cualquier información relevante que ha surgido hablando sobre la tarea

También podemos detallar:

• Diagramas de flujo que aclaren la funcionalidad y navegación
• Mockups de las pantallas a las que afecta
• Fechas relevantes
• …  Cualquier información que consideremos de utilidad

Planificación y estimación en tiempo

Con las tareas bien definidas es mucho más fácil realizar una estimación (aunque las estimaciones siempre sean adivinaciones). En esta etapa será necesario planificar el desarrollo. Para ello, nos basamos en los criterios de prioridad que entre el cliente y nosotros definimos. Así, ordenamos las tareas por orden de prioridad y realizamos una planificación en tiempo dividiendo el proceso en, al menos, 3 fases para tener un horizonte temporal. En esta fase, también definimos roles del equipo y sobre todo interlocutores. La figura del «Responsable de proyecto» dentro de nuestro equipo es muy importante. Es la persona que hará de enlace entre los desarrolladores y el cliente. Él será el que vele porque el producto entregado es lo que espera el cliente.

Reuniones y entregas periódicas

¡Comenzamos a programar! Pero antes de ponernos manos a la obra, acordamos con el cliente la duración de los sprints. Los sprints no son más que períodos de tiempo (solemos hacerlos de dos semanas) en los que desarollamos una serie de tareas acordadas con el cliente. Al final de cada sprint tenemos una reunión con el cliente en la que le entregamos y presentamos las tareas que hemos fijado, valoramos y validamos las mismas para darlas por terminadas y componemos el nuevo sprint con nuevas tareas. Una vez compuesto el sprint, no es posible realizar cambios, el equipo debe estar concentrado en esas tareas y las interacciones con el cliente vendrán dadas por dudas que puedan surgir a nuestro equipo y que necesitemos resolver. El cliente debe entender que debemos ser estrictos en esto.

Revisiones y cambios de funcionalidad

En las sprint meetings o reuniones al final de cada sprint, como hemos dicho, revisaremos las tareas con el cliente para que éste las valide y las demos por cerradas. Además, al comentar cada tarea para el siguiente sprint pueden surgir cambios en algunas de ellas que necesitamos definir bien en ese mismo momento. O incluso, pueden aparecer nuevas tareas que no teníamos definidas, por tanto, las definiremos y añadiremos al backlog para acometerlas en próximos sprints.

Tests y consolidación del sistema

Cada vez que acabamos un sprint y hacemos una entrega de funcionalidades significa que el cliente puede utilizar y probar esas funcionalidades en un entorno de pruebas a su medida. Normalmente todos nuestros proyectos los montamos en un servidor de pruebas al que el cliente puede acceder para probar y testear todo. Esto nos permite ir eliminando cierto bugs que el cliente pueda detectar e ir consolidando el sistema. Cuando se detecta un bug es necesario crear una tarea específica para ello. Para definir bien el bug será necesario incluir al menos:

• Nombre descriptivo del bug. Que se entienda bien.
• Entorno en el que se ha descubierto (navegador, sistema operativo, etc)
• Forma de reproducir el fallo. Muy detallado, deberemos de escribir los pasos para reproducir el error y que el desarrollador no pierda tiempo en ello.
• Fecha de detección del fallo
• Prioridad de la resolución. Si es crítica, importante, poco importante o nada relevante.

Subida a producción y lanzamiento

La subida a producción no supondrá demasiado esfuerzo ya que si todo ha ido bien tenemos una versión estable funcionando y testeada por el cliente en un entorno de pruebas. Lo más importante es hacer una instalación en el servidor definitivo, comprobar que funciona bien y realizar una carga masiva de los datos si fuera preciso. Mi recomendación es que hasta antes del lanzamiento la aplicación web se oculte detrás de una landing page de captura de correos electrónicos o que se proteja mediante usuario y contraseña para que ningún usuario no identificado no pueda acceder hasta el momento del lanzamiento.

Feedback y retrospectiva con el cliente

Cuando todo ha pasado, la aplicación está funcionando y el cliente aún dispone de algo de tiempo para nosotros, es importante que tengamos una reunión con él para poder mejorar. Se hablarán con él posibles problemas que se han tenido, impresión general del desarrollo, si se han cubierto las expectativas, posibles mejoras futuras, etc. Esto hace que ambas partes aprendan del proceso y puedan mejorar. A nosotros es una fase que nos hace mejorar este proceso y que nos permite adaptarnos a muchos tipos de cliente

La experiencia de trabajar con startups es muy estresante pero a la vez muy enriquecedora. Aprendemos mucho en cada trabajo. Muchas veces tenemos la sensación de que el producto es nuestro y nos dejamos la vida en ello. Como sabéis para esta línea de negocio lanzamos hace tiempo nuestra marca BigBangStartups de la que en próximas fechas os volveremos a hablar con novedades.

Si estás pensando en montar una startup o tu proceso de desarrollo no ha sido el que esperabas, ponte en contacto con nosotros y háblanos de tu proyecto. Quizás podamos ayudarte.