Hace muchos años el software se hacía bajo un enfoque de cascada. La metodología cascada(waterfall) te decía que el ciclo de vida de creación de software era un proceso lineal donde cada nueva etapa solo empezaba al terminar la anterior.
El problema de trabajar así es que si en la etapa de desarrollo el diseño tenía que ser modificado por algo inesperado o mal planificado, pues, se volvía en una situación complicada de manejar. Y cosas así podían pasar en cualquier etapa.
Otro inconveniente de trabajar en cascada es que la retroalimentación del cliente/usuarios iba a ser imposible tenerla en cuenta ya que para cuando estos pudieran ver/usar el software, ya el ciclo de desarrollo habría concluido, o sea, habría que hacer una extensión del proyecto para sacar más tiempo y recursos $$$$.
Por eso y mucho más nacen las metodologías ágiles. Estas te dicen que vayas en ciclos cortos de trabajo en donde en cada ciclo habrá(idealmente) retroalimentación temprana y constante por parte de los interesados del software que se trabaja.
Y de la agilidad nacen muchas otras cosas como las metodologías livianas o lean, las cuales te dicen que empieces siempre con implementaciones básicas, lo más básico y funcional para que lo puedas llevar a tu cliente/usuario final para que prueba, te dé retroalimentación y mejores el producto o software en proceso.
¿Por qué ir de a poquito?
Diferente a construir una casa o un carro, un proyecto de software muy difícilmente se podrá completar haciendo grandes etapas, una tras otra.
Para hacer una casa puedes hacerlo lineal sin ningún problema:
- Adecúan el terreno
- Arman las columnas
- Hacen el piso
- Construyen las paredes
- Ponen el techo
- Ventas, puertas, etc.
En una casa, sin las columnas, será complicado y peligroso, colocar el techo. Entonces primero hay que hacer las columnas y después sí se coloca el techo.
La dueña de la casa sabe que debe ser así. Tendrá que esperar una parte tras otra para poder vivir su nueva morada.
En software la cosa cambia. Al hacer software se pueden saltar ciertos pasos, momentáneamente, para dar forma a otras partes del mismo. Y eso es una ventaja que se puede aprovechar. Más adelante veremos cómo.
Sobre lo ambiguo y lo abstracto
Lo que más dificulta el proceso de crear software es que el mismo(bien o mal planeado y ejecutado) estará lleno de ambigüedades y cosas abstractas.
Al hacer la casa, cómo ya hemos visto tantas casas antes, sabemos la forma de una pared, el color del concreto o del ladrillo, el alto del techo, podemos palpar y ver el techo, pisar el nuevo piso, ver a través del espacio hueco de las ventanas y/o puertas.
La casa es tangible. El Software no lo es.
Cuando alguien pide que le hagan un software para gestionar el inventario de su negocio, hay un millón de formas de hacerlo, estructurarlo y mostrarlo.
La forma de ver el software para esa persona, tal y cómo lo quiere, varia muchísimo con respecto a la forma en que lo ven los desarrolladores, el diseñador, incluso yo que escribo este artículo.
Es por eso que hay que sentarse, antes de siquiera escribir la primera línea de código, a acordar cosas básicas que quedarán plasmadas en esquemas o bosquejos, y que finalmente tomarán forma en un diseño.
Sin embargo, cuando se toma ese diseño como la base única y para siempre durante el ciclo del proyecto para hacer ese software, eventualmente, el cliente solicitará cambios. Y habrá dos situaciones:
- No puede haber cambios porque ya entró en etapa de desarrollo y eso atrasaría el proyecto.
- Tiene que pagar un excedente por esa nueva solicitud ya que es nueva y no fue tenida en cuenta en el estimado inicial.
Habrá personas que tomen cada una de las situaciones de diferentes maneras, en todo caso, no tiene que ser así. Si trabaja bajo los conceptos de desarrollo ágil y lean, se puede hacer un mejor producto con los cambios que surjan en la marcha, que satisfaga las necesidades de todos los interesados.
Software cambiante, proceso fluctuante
Si el software, por su naturaleza llena de ambigüedades y abstracciones, es cambiante, ¿por qué tu proceso no lo puede ser?
No me imagino lo que habrán vivido los desarrolladores de la época de cascada pero mi generación puede disfrutar de ágil y lean. O eso creemos, ya que una cosa es saber que existen y otra es aplicar los conceptos y como uno no nace sabiendo, toca aprender a los golpes y equivocándose.
Educandome, primer golpe
Hace varios años atrás, participé en un proyecto de una emprendedora local. Ella contaba con un servicio de enseñanza de temas de salud el cual tenía clientes y vendía bien. Un tema solicitado en el sector y con poca oferta.
En determinado punto de la colaboración con la emprendedora, unas personas interesadas en invertir en su trabajo entablaron conversaciones con ella para desarrollar una plataforma en línea para vender sus vídeos y se acordó que yo sería el desarrollador. Es más, yo lideraría un equipo de trabajo seleccionado por mí.
Y procedimos a sacar historias de usuario, requerimientos, unos cuantos diagramas y todo parecía en orden. Había una imagen clara de lo que ser quería. Conseguí el equipo, diseñadora, desarrolladores. Configuramos máquinas, servicios, empezamos a trabajar.
Sin embargo, ocurrió lo menos esperado. El proyecto murió. Y no lo hizo por falta de entendimiento de los requerimientos, o porque hayan sido mal elaborados, no hubo falla en el equipo de trabajo. Nunca llegamos al punto donde una primera retroalimentación clara fuera dada.
El proyecto murió por un desacuerdo(a causa de un mal entendimiento) de la emprendedora con los inversionistas. No colaboró con reuniones ni retroalimentación y al final la película se acabó sin siquiera llegar a la mitad.
HCE, alcance grande, caída grande
La clave de superarse en la vida está en seguir intentando aunque se haya perdido o caído en un intento anterior. Por eso, tomamos fuerzas y organizamos un plan de trabajo para un nuevo proyecto: Historia Clínica.
De los sistemas más complejos que puede haber al hacer software, en salud no creo que hay alguno sencillo. El historial médico de un paciente tiene muchísima información. La captura y visualización de esta requiere de grandes esfuerzos en diseño y desarrollo. Sin embargo, mi colega y yo contábamos con experiencia en el sector y nos le medimos a sacar un software para la gestión de la historia clínica de pacientes en consultorios privados.
Sabíamos que no iba a ser tarea sencilla pero nos armamos de valor, sacamos una lista, más o menos detallada, de requerimientos y nos pusimos manos a la obra.
En todo caso, por más ganas y moral que hubiera, sin un buen plan estuvimos destinados a fallar. Pensábamos que lo que habíamos definido como MVP iba a ser alcanzable pero en realidad fue muy grande el alcance. Entendimos mal lo que es un producto mínimo viable y trabajábamos era en una versión inicial.
Un MVP es aquel que con un desarrollo básico provee y cumple con la necesidad por la cual se hace el software. Si el software es para enviar correos, el MVP es un editor de texto, un campo de correo y un botón enviar.
Francisco Quintero
Para colmo de males, decidimos usar unas tecnologías que apenas entendíamos y con las cuales no habíamos hecho ningún proyecto de pruebas.
Para el frontend decidimos usar AngularJS(versión 1.5 en aquel entonces) y para el backend, aunque eramos buenos en Ruby on Rails, una mala decisión mía nos llevó a usar una gema llamada Grape. Esta gema se suponía iba a facilitar la creación de una API REST para que el cliente Angular consumiera pero nada lejos de la realidad.
Al final, la falta de un objetivo claro también hizo que quedáramos sin un norte. ¿Era este proyecto algo de lo cual aprender si fallaba? ¿Qué esperamos lograr que no sea dinero?
No coordinamos nada bien para este segundo intento.
No todo fueron fallos
Eventualmente, sacamos unos proyectos pequeños con mediano éxito. Curiosamente fueron en escenarios donde no era usual que trabajáramos y para los cuales no pretendíamos, en el largo plazo, seguir trabajando.
Sacamos dos aplicaciones móviles integrando APIs de terceros que nos parecieron muy interesantes.
Primero, sacamos una app que llamamos Open Searcher la cual integraba la API de Open Libra(de ahí el nombre) y luego hicimos otra usando la API de Yify. Ambas aplicaciones las hicimos con Ionic framework para lo cual habíamos estudiado un poco mejor AngularJS.
Las aplicaciones las convertimos a archivos instalables de Android(.apk) usando Apache Cordova. El boom en su momento.
Letom, caminando el sendero correcto
Ideas hay muchas, tiempo hay poco. Junto con mi colega nos reunimos para hablar de lo aprendido, donde se falló y cómo seguir adelante.
Nació una nueva idea y decidimos que parecía alcanzable y justa. La definimos, miramos a ambos lados y cruzamos la calle. Empezamos a desarrollar Letom, una aplicación para encontrar moteles en la ciudad.
La idea era simple. Una API hecha en Ruby on Rails que surtiría de información a una aplicación móvil para buscar moteles, ver información de cada uno y al final tomar la decisión si reservar una habitación con el lugar.
Un proyecto mucho menos ambicioso que HCE pero con complicaciones, como todo. La primera complicación era llegar a los dueños de moteles en la ciudad. No conocíamos a nadie que tuviera un amigo o familiar o conocido, dueño o que trabajara en la parte administrativa de un motel.
Por otro lado, en el desarrollo, en la aplicación móvil, nos topamos con una barrera muy fuerte que tuvimos que haber sorteado de otra forma.
La otra forma era aceptando las limitaciones y sacando la aplicación con ellas. El MVP no tenía que ser perfecto, tenía que funcionar en lo mínimo de la idea. Listar y buscar moteles.
Ocurría que la aplicación, al usar el primer framework híbrido que fue Ionic, tenía mucho lag. Al hacer scroll vertical la pantalla se bloqueaba lentamente. No era nada optimo. Decidimos probar otro framework híbrido. Nos fuimos con NativeScript, en el cual también encontramos otro inconveniente que nos impedía lograr ciertas cosas(que ahora no recuerdo). Y así, probamos uno y otro framework hasta mi colega, encargado de la aplicación móvil, decidió hacerla en Android nativo, usando Java
Al final, logramos sacar una versión inicial del .apk para Android(aún lo conservamos pero el API está caído) pero inconvenientes a nivel comercial, limitantes a nivel de la app móvil y el cansancio del día a día, nos hicieron desistir, una vez más, de un proyecto.
¿Qué queda?
En todo caso, quedó el aprendizaje. Como equipo, engranamos en la gestión de las tareas, de herramientas, aprendimos a ir por lo seguro cuando se quiere empezar, a reducir el alcance inicial de los proyectos que queremos empezar para que sean más factibles y menos una ilusión.
Aprendimos mucho y todo lo que nos quedó de enseñanza, lo aplicamos en los proyectos actuales, propios y de nuestros clientes.
Además, por esos aprendizajes, en menos de seis meses sacamos dos proyectos de prueba. Una aplicación móvil hecha con React Native y una app web hecha con React integrando la API de Google Maps.
Muy seguramente, al cabo de unos meses, estaremos empezando otra aventura para seguir aprendiendo y quizá algún día sacar un producto y, por que no, vivir de él 🙂
El Camino del Pro 
Que excelentes anecdotas, definitivamente lo aprendido y lo interiorizado en cada uno de los proyectos serian las ganancias que se deben sacar de aquellos proyectos.
¿Alguna de forma de colaborar y de paso aprender de estos MVP que trabajan de manera autonoma?
Me gustaMe gusta