Hay diversas prácticas y formas de abordar la creación de software. Todas tienen sus falencias y bondades. No hay forma definitiva de hacerlo.
Muchos proyectos de software mueren antes de siquiera ver la luz del día. Cada software tiene vida propia y por más que se intente hacerlo perfecto, nunca lo será.
No necesitamos que nuestro software sea perfecto sino que funcione con la mínima cantidad de errores posibles.
Es importante que las personas interesadas en invertir dinero o crear software entiendan esta naturaleza del mismo. Que abran su mente y ajusten sus expectativas al entrar en proyectos de desarrollo de software. Hay muchas industrias que son casi perfectas en el desarrollo de sus productos. La industria del software, me atrevo a decir, jamás logrará la perfección.
Si ajustamos nuestra mentalidad cuando queremos trabajar software, si nos esforzamos en entender que es una dinámica totalmente diferente, que hay que quitar la ambigüedad al hablar y definir lo que se requiere y que lo más importante es que funcione y se valide con el público objetivo, tendremos muchos factores a favor nuestro para crear software que viva para ser usado.
¿Cómo Abordar Proyectos de Software?
Mi experiencia ha sido siempre en desarrollo web y es de lo que puedo contar.
Una gran ventaja que hay en el desarrollo web es que las aplicaciones se pueden llevar a los usuarios de manera casi que instantánea. Caso diferente a otro tipo de software que debe instalarse en algún dispositivo.
Tal ventaja debe aprovecharse cuando se trabaja en software para la web.
Son muchos proyectos web fracasan porque se abordan como si fueran de otro entorno. Fracasan porque se busca la perfección desde el día uno. En la web, la perfección (si fuera posible), es gradual. Lo más importante es llevar el producto, lo más pronto posible al usuario para que este lo «sienta», lo vea, lo use y nos dé su opinión: sea que le guste o disguste.
Cuando se hace software para escritorio es más normal encontrar ciclos de entrega más largos. Ejemplo, un sistema operativo. No hay beneficio en sacar versiones de un sistema operativo cada mes porque requiere mucho trabajo del usuario final instalarlo. En la web ese impedimento no existe y es algo a usar a nuestro favor.
Con esto tampoco quiero decir que cada día debe entregarse una nueva versión. Lo que intento decir es que debemos sacar provecho de la ventaja de la web y llevar nuestras ideas pronto al público.
Podemos tener procesos serios como etapas de aseguramiento de calidad y pruebas cerradas, eso está bien, pero que no esperemos seis meses para liberar una versión que estuvo lista hace cinco meses atrás.
No aprovechar la ventaja de la web es una receta para el fracaso.
Dado lo anterior, creo que una buena forma está comprendida por los siguientes puntos:
- Estimación
- Proceso y Retroalimentación
- Funcional vs No Funcional
- Producto Mínimo Viable (o MVP por las siglas en inglés)
Voy a desglosar cada uno.
Estimación
De manera errada, muchos ven la estimación como algo pactado con sangre. La estimación es solo una guía de cuánto algo tardará en hacerse. Lograr un estimado 100% preciso es demasiado difícil y requiere de medición rigurosa y de práctica constante haciendo la misma cosa una y otra vez.
No nos interesa ser estrictos ni los más rigurosos. Nos interesa estimar y definir lo que se necesita, ser claros y desglosar lo más que se pueda las características del software. Queremos detallar que hará y que no hará nuestro producto. Cuanto más podamos desglosar, más fácil será estimar y tener una idea de cuánto tardará en estar listo.
Y en serio, hay que desglosar. Muchos proyectos tienen estimados demasiado ambiguos como: «habilitar carrito de compra». Eso no facilita para nada la labor del desarrollador que debe estimar. Cuando desglosamos hay que pensar que pasa en ese carrito de compra, que textos hay, si se puede quitar los productos, se puede aplicar un cupón, etc, etc.
Cuando no se es claro y conciso con el requerimiento quedan muchos puntos al aire y al final solo habrá problemas.
Proceso
Acá nos vamos a valer mucho del concepto de desarrollo ágil. Cuidado, no digo Scrum, ni Kanban, ni XP, ningún marco de trabajo en particular. Vayamos al ágil puro y sencillo. Queremos iteraciones cortas donde todas las partes interesadas trabajen en conjunto para lograr el objetivo en común.
Cuando no se trabaja ágil, pasa que el dueño de la idea da una lista de requerimientos y quiere verlos completos y disponibles al cabo de tres meses. Esto es una receta para el fracaso. Lo ideal es que el producto se evolucione de manera gradual, entregando y probando lo pedido en ciclos cortos para validar y tener retroalimentación pronta.
Si no tenemos retroalimentación pronta, pasa que al cabo de un mes al cliente/emprendedor se le ocurre una idea y llega emocionado a contarla al equipo de desarrollo y resulta que esa idea implica atrasar las entregas o cambiar algo ya completo o quitar algo del todo. Con ello, lo único que se consigue es poner al equipo de desarrollo en contra porque no se tiene en consideración el esfuerzo que han hecho.
Además, siempre ocurre que el dueño de la idea cree que cada nueva idea es vital e importante y que sin ella su producto no será exitoso. Esa es la mentira más grande que puede haber.
Simple y sencillo: si tu producto aún no lo usa nadie, no puedes saber si una idea nueva lo hará más exitoso.
Ciclos cortos, pruebas y retroalimentación es la receta que ayudará a tu proyecto de software a llegar lejos.
Funcional vs No Funcional
Si eres un dueño de una idea de software o trabajas con un equipo de desarrollo de software, lee bien esto:
Enfocate en lo realmente importante.
Si tu software dice que sirve para alquilar carros, lo más importante es que cada paso para alquilar un vehículo funcione. Entiendo que ese botón está un poco grande, o que los párrafos están muy extensos, o que la caja de búsqueda no arroja resultados al escribir.
Si ese botón permite comprar, funciona.
Si los párrafos no han hecho que los usuarios se vayan, funciona.
Si la caja de búsqueda arroja resultados aunque no sea al escribir, funciona.
Hay que enfocarse. Cuando el dueño de la idea no se enfoca pasa lo que describía anteriormente. Se tiene ese temor de que sin ese párrafo perfecto entonces no va a servir la aplicación. Tonterías. Si tus usuarios (si los tienes) no han dicho nada en contra del párrafo, no pasa nada.
Ahora, si en verdad te preocupa ese párrafo Y ya tienes visitas y usuarios constantes, puedes aplicar técnicas para medir el impacto de este comparado con una versión nueva. Para saber si algo ayuda o estorba hay que medir. No se sabe nada a punta de corazonadas.
Cuando el dueño de la idea no se enfoca en lo funcional el proyecto comienza a tambalear. Se vuelve un temor liberar una versión sino está perfecta y ya sabemos que nunca será perfecta.
Al trabajar en software para la web, lo importante es que funcione, sea estable y que cumpla con lo que se promete. Lo demás es secundario y puede hacerse después, cuando haya tiempo o tal vez nunca 🙂
Simple vs Complejo
Hay una imagen muy graciosa en internet. Compara el producto de un emprendedor contra Google. El producto del emprendedor tiene cientos de características y elementos en la interfaz gráfica. En cambio, el buscador de Google tiene solo 3 o 4 elementos.
La cuestión con esto no es que debemos hacer solo productos sencillos sino que debemos empezar pequeños y asegurarnos de dar los pasos correctos para crecer adecuadamente.
Aquí es donde el concepto de Producto Mínimo Viable (MVP) ayuda mucho. Idealmente, queremos encontrar la versión mínima de nuestra idea que logra su objetivo, desarrollarla y llevarla al público. Cuando esté en acción, ver como responden los usuarios y seguir trabajando a partir de ahí.
Ahora, puede que tu MVP demore en completarse 6 meses. No hay problema, la clave está en no esperar los 6 meses para revisarlo todo sino que cada fin del ciclo se revisen los avances y se ajuste el plan de trabajo según se necesite.
Crear software es una labor difícil y si solo pensamos que necesitamos todas las características para que funcione, lograrlo será una tarea maratonica.
La clave del MVP es simplificar para volver este proceso de desarrollo manejable y predecible de tal forma que se minimicen los riesgos y se optimice el tiempo de trabajo.
Conclusiones
El software ni los procesos para crearlo jamás serán perfectos, sin embargo, tenemos herramientas y prácticas que nos ayudan a minimizar riesgos y tratar de obtener los mejores resultados posibles.
Como dueño de idea o emprendedor trabajando con un equipo de desarrolladores, lo mejor que puedes hacer es entender que se necesita tu acompañamiento constante y estar abierto a la idea de llevar tu idea pronto al público. Que no sirve de nada tenerla encerrada en un ambiente privado por demasiado tiempo.
Estimaciones de requerimientos bien desglosados, ciclos de avances cortos, retroalimentación constante, comunicación asertiva y bidireccional, son elementos que llevarán a cualquier proyecto de software por buen camino.
Las herramientas y las ventajas están ahí para aprovecharlas.
El Camino del Pro 
Un comentario sobre “Abordando Proyectos de Software”