Es normal cuando una persona decide crear software que sienta miedo a lanzar su producto. Creen que si no está completo el software, entonces la gente no lo quera usar o vendrá alguien más a copiar la idea.
Puede que esos miedos tengan razones de peso pero en el mundo del software esperar es perder tiempo. Veamos porqué.
Los Miedos
Cuando no se tiene experiencia en proyectos de software abundan los miedos. Hay muchos riesgos en cuanto a dinero y tiempo invertido en un proyecto, además de oportunidades de negocio que podrían perderse. Sin embargo, la solución a esos miedos no es sacar un software a las carreras y de mala calidad.
La solución para lograr un buen software, que sea longevo y dé solución a los problemas por los cuales se creó es aprovechar las técnicas y metodologías que permiten reducir el riesgo al desarrollar software. Que las pongamos en práctica no quiere decir que no habrá riesgo ni miedos pero si vamos a tener una mejor experiencia a lo largo del proceso.
Hablo de metodologías ágiles y de Producto Mínimo Viable.
Tales herramientas lo que buscan es simplificar y reducir los riesgos al construir software. Entre más demore una aplicación en ser usada más alejada podrá estar del objetivo buscado. Cuando se construye software hay muchas cosas involucradas, ideas y puntos de vista diferentes. Todo lo que respecta al software debe converger en un concepto claro y sin lugar a suposiciones.
De esa forma, se podrá llevar por el camino más cercano al éxito.
Se peca en pensar que al público se le hará fácil usar la aplicación pero cuando se les entrega sale todo tipo de problemas. Mediante ágil y definiendo un MVP muchos problemas podrían haberse descubierto antes.
Esos miedos son válidos pero recuerda que ya hay gente con experiencia hablando y escribiendo al respecto. Ellos no quieren que tú falles.
Siempre Habrá Alguien con Más Dinero
Otro motivo por el cual algunos emprendedores no quieren sacar versiones tipo MVP de su producto es porque les van a copiar la idea.
Eso es una excusa muy débil. Siempre habrá alguien con más dinero.
El valor de las ideas no está en si mismas sino en cómo la ejecutes. De nada me sirve tener la idea de una app que va a revolucionar el mercado sino la llevo a cabo.
Si alguien copia la idea y la ejecuta mejor, ¡pues bien! Hay competencia y habrá mercado. Si te copian, algo hiciste bien.
Un buen ejemplo de esto es la herramienta Trello. Un tablero donde se pueden organizar listas y tareas. Una idea sencilla traída del mundo de Kanban. Como Trello hay mucho software similar que hace lo mismo en mayor o en menor medida. ¿Se acobardaron los fundadores de Trello por ello? No lo creo.
No Está Completo el Software
También suelen decirse a si mismos los fundadores de una idea que su producto no está completo. Si el software no está completo entonces no es posible salir al mercado porque X característica es vital.
Señores y señoras, esto es otra excusa débil.
Cuando empezó Facebook no tenía todo lo que tiene hoy. Ni siquiera tenía chat, una de las características más usadas hoy en día.
El software completo o terminado no existe.
Cuando se crea software siempre habrá una interminable lista de peticiones, errores, mejoras, actualizaciones, cambios, etc.
El software es eterno hasta que se decide dejar de trabajar en el mismo.
Creer que si mi software no tiene 20 funcionalidades no puede salir es un gran error. Lo que necesitas es replantearte qué quiere hacer tu software y encontrar la forma de empezar pequeño.
Entre más funcionalidades haya más cosas hay que aclarar, definir, diseñar, programar, probar, lanzar. Por eso es que el desarrollo iterativo gusta tanto porque permite hacer esos pasos a escala menor y minimizar el riesgo a lanzar algo equivocado.
Conclusión
Es válido tener miedo cuando nos involucramos en proyectos de software. Hay un historial en la industria de fracasos pero también de éxito. Como todo negocio, hay muchos factores involucrados que afectan el resultado final.
Cuando se es inexperto (e incluso experto) en construcción de software, lo mejor siempre será cobijarse por alguna metodología ágil. Esta va a guiarnos para trabajar en ciclos donde podamos probar y aprender directo de los usuarios finales.
Definir un Producto Mínimo Viable también será de gran ayuda para definir versiones que nos ayuden a validar la idea del producto minimizando los riesgos y manteniéndonos siempre dentro de la Propuesta de Valor del software en construcción.
Aún así, riegos siempre habrá pero contamos con las herramientas para minimizar sus efectos lo más posible.
El Camino del Pro 