Disfruta programando

El podcast

La importancia de un buen análisis

La importancia de un buen análisis

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.

Archivado en: Podcast


Escrito, dirigido y producido por Jesús Arboleya y Mario Conde.

Deja una respuesta Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Entradas recientes

  • Vive en vidiv tus eventos online con Alfonso Gutiérrez
  • Aplicaciones muy interesantes de Ceesa con José Luis Cuesta
  • La importancia de entrevistar a tus clientes para mejorar tu producto
  • Conoce a HolaSoft una empresa 100% SaaS
  • Reduce la deuda técnica para mejorar tu productividad

Comentarios recientes

  • Matias Castro en Vive en vidiv tus eventos online con Alfonso Gutiérrez
  • Matias Castro en Reduce la deuda técnica para mejorar tu productividad
  • Matias Castro en 2021 odisea en el software
  • DProgramando en 2021 odisea en el software
  • Matias Castro en 2021 odisea en el software

Disfruta programando

Bienvenido al blog Disfruta Programando donde encontrarás información relacionada con el mundo del desarrollo de aplicaciones empresariales, con contenidos relativos a la programación, análisis, bases de datos, cloud, frameworks de trabajo, agilidad, marketing, productividad, comunicación, etc. Es decir, contenidos relacionados con el ámbito empresarial de los negocios.

Jesús Arboleya y Mario Conde trabajan en Velneo, dirigen y producen los episodios del Podcast que lleva el mismo nombre que este blog y que se publican en iVoox y iTunes.

Copyright © Jesús Arboleya y Mario Conde, 2018