— 7 min de lectura
Siempre que alguien nos contacta con un nuevo proyecto, una de las primeras cosas que hacemos es revisar juntos las distintas fases en las que dividiremos el trabajo. Esto lo hacemos porque, aunque a veces no se diga directamente, todos tenemos en la cabeza un calendario y un presupuesto al que nos gustaría ceñirnos, cuando nos metemos en un desarrollo a medida. Aparte, es algo que no solemos hacer, quiero decir, en el Mundo Real™️ compramos pocas cosas a medida, no tenemos costumbre de pedir cosas hechas artesanalmente para nosotros, así que es normal que sea difícil hacerse una idea de lo que va a costar, tanto en dinero como en tiempo.
- Entender la motivación, el problema a resolver o nueva idea a desarrollar.
Cuando alguien nos contacta es porque, o bien tiene un problema que resolver, o una idea nueva a desarrollar. Para nosotros es muy importante entender bien la motivación detrás de iniciar el desarrollo, porque la motivación puede afectar al enfoque y los objetivos del proyecto, así como el éxito del mismo.
Por un lado nos ayuda, obviamente, a definir los objetivos que se quieren conseguir: Si sabemos por qué alguien quiere hacer una aplicación o sitio web, podemos definir claramente el proyecto y asegurarnos de que la solución que proponemos aborde adecuadamente sus problemas o necesidades. También, en algunas ocasiones, es importante entender por qué ahora y no antes, si es que es un problema nuevo o, aunque era conocido, hay otras circunstancias y características que permiten abordarlo ahora.
También nos evita malentendidos: un poco al revés de lo anterior, si no comprendemos la motivación de la persona que nos está pidiendo el proyecto, puede haber malentendidos que provoquen errores y retrasos, lo que puede afectar la calidad y la entrega del proyecto.
Una vez entendida la motivación, queremos entender bien el problema a resolver o la idea nueva a desarrollar. ¿Qué necesidades tiene el usuario que no están siendo cubiertas actualmente? ¿Cuáles son las limitaciones que se quieren superar? Comprender bien el problema permite definir claramente el alcance del desarrollo.
Por último, parte del proceso de entender bien el problema o dominio de la aplicación, es analizar la competencia, si la hay, si el cliente tiene unas referencias de competencia con las que se está comparando, por ejemplo. Esto en parte nos ayudará a ver con el cliente qué conceptos son los que le gustan de su competencia, en qué aspectos cree que podría hacerlo mejor, etc.
Definición de requerimientos: Una vez definido el problema y estudiada la competencia, se deben definir los requerimientos de la aplicación. ¿Qué funcionalidades debe tener la aplicación? ¿Cuáles son los requisitos de los usuarios? ¿Qué tecnologías se utilizarán? Todo esto debe quedar claramente establecido en la fase de planificación.
2. Análisis de requisitos
Como nosotros utilizamos siempre metodologías ágiles, un error frecuente es pensar que no es necesario hacer un análisis de requisitos previo a empezar el proyecto, que podemos simplemente empezar por definir "el primer sprint" y de ahí seguir, pero esto sería un error. Realmente, aunque usando metodologías ágiles definamos una serie de ciclos de desarrollos cortos, es importante analizar los requisitos completos, en conjunto, de una nueva aplicación web, porque es esencial comprender las necesidades y expectativas finales que van a tener nuestros usuarios y clientes y, porque a la hora de establecer las prioridades y qué incluir o no en los primeros ciclos, es importante tener una visión completa.
Los requisitos pueden cambiar con cada sprint a medida que se obtiene más información y se ajustan las prioridades, pero tener una comprensión clara de los requisitos iniciales puede ayudar a establecer una visión y objetivos claros para el proyecto. Además, un análisis adecuado de los requisitos puede ayudar a garantizar que el equipo esté trabajando en las características y funcionalidades que realmente importan para el cliente.
3. Diseño de la arquitectura
La definición de la arquitectura de una aplicación web es crucial porque ayuda a establecer una base sólida para el desarrollo. Es similar a tener un plano para construir una casa, sin él, es probable que el proyecto falle o sea ineficiente.
Al definir la arquitectura, se pueden establecer los componentes y la estructura de la aplicación, asegura que el desarrollo de la aplicación sea coherente y escalable, permitiendo que los nuevos requerimientos sean fácilmente incorporados y facilita dar un presupuesto del coste que tendrá la infraestructura sobre la que montaremos la aplicación, para el cliente.
4. Diseño visual, experiencia de usuario (UX) y prototipado
En esta fase, se crea un diseño visual de la aplicación web, que incluye la interfaz de usuario, el flujo de navegación y la estructura de la información. Aquí nos enfocamos en la creación de una interfaz atractiva, intuitiva y fácil de usar para los usuarios finales.
Trabajaremos el diseño visual de la aplicación, incluyendo la elección de colores, tipografía, imágenes, iconos y otros elementos gráficos que se utilizarán en la interfaz, que puede que el cliente ya tuviera desarrollados previamente, o que haya que desarrollar de cero. También trabajamos la experiencia de usuario (UX), lo que significa diseñar la forma en que los usuarios interactuarán con la aplicación.
Además, en esta fase solemos hacer prototipos de la aplicación, que son representaciones interactivas de la interfaz y la funcionalidad de la aplicación, que nos facilitan ver con el cliente cómo funcionará la aplicación antes de construirla completamente. Esto nos facilita hacer mejoras y ajustes en la interfaz antes de que se inicie la fase de desarrollo.
5. Desarrollo de la aplicación
Mira que nos gusta programar, eh, y hemos tardado 5 fases en llegar aquí. Pero en realidad, cuánto más tiempo le dediquemos a las fases anteriores, menos problemas tendremos en esta y las siguientes, así que son realmente muy importantes. En este punto escribimos el código de la aplicación web. Aquí le dedicaremos tantos ciclos de desarrollo como sean necesarios para tener una versión inicial, realizando todas las pruebas y corrección de errores que hagan falta para asegurarnos de que la aplicación cumple con los requerimientos que habíamos definido previamente.
Se han escrito libros, para ver qué sería eso de "una versión inicial", quizá hayas oído hablar de un Producto Mínimo Viable, o cosas así, pero sin entrar en grandes definiciones, digamos que aquí intentamos pulir de todas partes hasta reducir lo que se va a hacer a la mínima expresión posible, que realmente aporte valor y merezca la pena ser entregada y disfrutada por el cliente. Esto, claro está, dependerá mucho de cada caso, pero en general maximizar lo que no se hace en esta versión inicial y se deja para más adelante.
Entre ciclo y ciclo los requisitos podrán cambiar, porque al final sabemos que vivimos en un mundo cambiante y que lo que podía dejarse para más adelante hace un mes, ahora ha resultado ser una pieza fundamental del proyecto, pero en la versión inicial tratamos de reducir al mínimo estos cambios.
6. Despliegue
La fase de despliegue es en la que entregamos el código en los distintos entornos de ejecución que tenemos. Lo normal es que tengamos un entorno inicial, de desarrollo, en el que se integran todos los distintos cambios que hemos ido desarrollando en local, un entorno de Staging, o pre-producción, en el que el cliente puede ir validando los distintos desarrollos y el de Producción, que sería el entorno final, en el que los clientes definitivos pueden usar la aplicación.
Por nuestra forma de desarrollar, desplegando artefactos, el código entregado en los distintos entornos es el mismo. Esto minimiza los posibles errores entre despliegues en un entorno u otro, ya que siempre entregamos lo mismo. Lo único que cambia entre estos despliegues son unas variables de configuración que dependen del entorno. Además de garantizar que siempre entregamos lo mismo, se asegura la privacidad de determinada información que, en lugar de ir en el repositorio de código, va en esas variables de configuración por entorno.
Aunque hayamos situado esta fase de despliegue al final, para explicar su funcionamiento, es importante entender que en un desarrollo basado en metodologías ágiles, lo normal es ir desplegando con cierta frecuencia, a medida que se van teniendo suficientes tareas que aportan valor.
7. Evolutivos, mantenimiento de la aplicación.
Como decíamos en párrafos anteriores, vivimos en un mundo cambiante. Lo normal es que nuestra aplicación vaya a tener nuevos requisitos con el paso del tiempo, queramos introducir nuevas funcionalidades que, quizá, habíamos dejado aparcadas para la versión inicial, o simplemente ideas que no habíamos tenido, con el paso a Producción y el uso por parte de los clientes, han salido a la luz y las queremos incorporar.
Aunque no hayamos pensado en nuevos desarrollos, las librerías que utilizamos van desarrollando nuevas versiones, incorporando mejoras, las bases de datos también van evolucionando, etc, lo normal será que queramos ir incorporando estos cambios en las versiones de las librerías, poco a poco.
Como decimos, lo normal es que nuestra aplicación sea un producto vivo que requiera de constantes evolutivos. Estableceremos en esta fase una forma de ir desarrollando y entregando nuevas versiones del producto con estas mejoras.