Fase de toma de datos y análisis
En todo proyecto es necesaria la figura del analista.
El trabajo de un analista consta de 4 verbos:
Escuchar
Tenemos 2 orejas y 1 boca para escuchar el doble de lo que hablamos.
Es una parte muy complicada y difícil, ya que hay que entender las necesidades que nos transmite el cliente. No siempre las entenderemos bien, no siempre nos las explicarán todas. Analiza, analiza y analiza.
Cuidado con hablar más de la cuenta, proponer más de lo que el cliente necesita. En esta fase lo que importa es escuchar y anotar.
Levantar acta de todas las reuniones es importante y puede llegar a ser un seguro de cara a futuras reuniones, hay que evitar que nos puedan decir, yo te dije…, para eso están las actas y cuando se envía al cliente hay que solicitarle por escrito que la revise e indique si ve errores o ausencia de información relevante.
Pensar
Para que un proyecto de software tenga éxito, el 80% depende de un buen análisis inicial de las historias de usuario (requisitos).
Aunque todo encaje en tu cabeza, plásmalo en papel o documentado digitalmente en una aplicación. Da igual que sea un editor de textos, un software de gestión de proyectos, un mapa mental, etc.
Documenta tu análisis para que lo puedan entender todos, el equipo de desarrollo, el cliente y tu mismo si lo ves muchos meses después. Cuando ya esté claro, enfría tu cerebro, deja pasar unos días y vuelve a revisarlo una vez más. Seguro que detectarás algún error o incongruencia, o párrafos que requieren mayor explicación. Dejar pasar las horas y los días te ayuda en la segunda lectura a ver si está documentado de tal forma que dentro de un tiempo lo seguirás entendiendo o realmente hay cosas que no están plasmadas en el documento y que de no hacerlo se nos olvidarán o tendrán el riesgo de que sólo las sabrás tú pero no tu equipo de desarrollo.
Si tu no vas a ser el product owner del proyecto, debes hacer que la persona que lo vaya a ser valide tu análisis.
Abstraer
El documento de análisis debe describir funcionalmente la aplicación, pero cuando llega el momento de convertir las ideas en código fuente debemos abstraer esas ideas con el objetivo de obtener una estructura de base de datos flexible, escalable y rápida.
El papel lo soporta todo, pero cuando algo que parece claro lo tratas de convertir en tablas y campos surgen dudas y dificultades. Es normal, debemos asumir que pasará, esta es una de las fases más divertidas y motivantes para un analista, para esto hay que pasar a la fase de concreción.
Concretar
Abstraer es un paso necesario pero luego hay que llevar esa abstracción a la práctica definiendo los objetos de base de datos: tablas, campos, índices, triggers, …
No siempre lo abstracto es lo mejor, en muchos ocasiones puede ser más óptimo un diseño sencillo y práctico, que reduzca el número de peticiones del cliente al servidor, esto ayuda a tener aplicaciones mejor optimizadas para el cloud.
La complejidad no es una buena compañera, hay que evitarla siempre que sea posible, facilita el trabajo del equipo y sobre todo la mantenibilidad de la aplicación.
Normalmente cuando algo es complejo suele ser un síntoma de falta de conocimiento sobre la historia de usuario a resolver o falta de análisis.
La interfaz no tiene porqué reflejar cómo es la base de datos. El analista debe pensar en la base de datos como en una caja negra que soportará las necesidades de la aplicación, pero la estructura de base de datos no debería condicionar al diseño de la interfaz.
La arquitectura de los datos es lo más importante. Después, ya nos centraremos en interfaz y procedimientos.
Programar
Escribir o diseñar el código fuente de mi aplicación es un paso que va siempre después del análisis.
En un proyecto de software un mal análisis garantiza un 100% de fracasos.
Analiza, analiza y analiza antes de escribir tu primera línea de código.
Evidentemente, tras un buen análisis debe seguir un buen desarrollo.
Comunicación
Un buen analista debe ser también un buen comunicador. Tendrá que comunicarse con el cliente, equipo de desarrollo, usuarios, …
En un proyecto el equipo no sólo está formado por lo desarrolladores, para que el proyecto pueda tener éxito deben participar todos los stackeholders cliente tanto dirección como usuarios, analista, desarrolladores y dependiente del proyecto puede ser buena la participación de otros departamentos como calidad, comerciales, soporte, incluso proveedores de referencia.
Es necesaria la implicación de los usuarios durante todo el ciclo de desarrollo, sino el proyecto tendrá muchas papeletas para no ser un éxito.
Los testers deben trabajar en el equipo multifuncional al igual que los desarrolladores y probar día a día lo que se desarrolla.
Detectar una incidencia en un desarrollo a la vez que se está desarrollando esa parte de la aplicación facilita la corrección de las incidencias.
Cuando más tiempo pasa sin corregir una incidencia, más coste supondrá para el proyecto, porque afectará a más partes de la aplicación, porque el desarrollador necesita volver a repasar el funcionamiento del código para resolver la incidencia.
Al cliente siempre hay que informarle con antelación de todo, de lo bueno y lo malo.
Hay que ser firmes… pero con un poco de “mano izquierda” 😉
Por muy buen analista que seas, cometerás errores. Ten en cuenta esto para tu presupuesto, estimación… y sobre todo… díselo a tu cliente. Él también cometerá errores.
Funcionalidad
No caer en el error del efecto “barra libre”. El cliente puede pedir de todo.
Evita añadir funcionalidades salvo que sea necesaria, no pienses que “tener lo máximo” es positivo, al contrario es un problema. Recuerda… menos es más.
No añadir nada que no nos hayan pedido. A los programadores nos encanta desarrollar cosas que consideramos buenas para la aplicación, aunque el cliente no nos lo haya pedido. Eso es un error. “Lo que sobra es tan malo como lo que falta”. Lo que sobra también hay que mantenerlo, puede fallar y generar incidencia y engorda innecesariamente el código.
Ten en cuenta que habrá cambios evolutivos en las necesidades del cliente. Cuanto más avanzado esté el proyecto, más costosos serán los cambios.
A mayor acierto en el análisis, menores son los cambios evolutivos y ajustes o resultan menos costosos.
Una aplicación nunca está terminada. El software es como un ente vivo, nace, durante su vida sigue desarrollándose y hasta que se deje de usar no puedes asumir que está terminado.
Deja una respuesta