En muchas ocasiones ocurre que las pérdidas empresariales más grandes ocurren cuando se construye mal un software, esto se debe a un mal análisis, mala selección de metodología de desarrollo de software, mala asignación de recurso personal y herramientas, falta de entendimiento del ciclo de vida de desarrollo, o hacer que una sola persona haga todo. Bueno, para ello hay estudios, prácticas, journals, etc, etc, y cada vez es más constante acelerar la curva de aprendizaje en actualizaciones de tecnologías antiguas como en la emergencia de nuevas. Pero vamos por partes.

Analista funcional vs Analista programador vs Programador

En muchas organizaciones existe el cargo de analista programador, y éste debe ser una persona con experiencia en el negocio y además con el conocimiento holístico de la arquitectura de los sistemas que comprende la organización. Esta persona se encargará de hablar dos idiomas, el lenguaje de experto de TI y el lenguaje del negocio, debe ser capaz de por ejemplo: si un contador le habla sobre modificaciones que necesita para el libro diario y libro mayor, éste ya debe ir entendiendo los elementos de la arquitectura que van a ser afectados, por ejemplo, agregar nuevas columnas a tablas, modificar la generación de reportes en txt o csv, implementar nuevos índices en cierta tabla, eliminar APIs antiguas, configurar certificados de seguridad, etc. Pero obviamente esta persona no debe hablar técnicamente ante usuarios finales, porque es muy probable que no lo entiendan. Para ello debe parafrasear y expresar en lenguaje del usuario lo que conlleva su "modificación" y no piense que es un cambio muy fácil cuando atrás hay toda una estructura qué modificar.
Un analista funcional está enfocado netamente en lenguaje de negocio, no tiene conocimiento avanzado de la infraestructura interna del sistema, sin embargo en cuestión de reglas de negocio es un experto, tanto para la seguridad a nivel conceptual (roles, usuarios, etc.) como diversos caminos de decisiones en el sistema. Su contraparte, el programador, se encargará de codificar lo que le indiquen, él es el experto conocedor de la arquitectura del sistema, detalles en librerías, algoritmos, estándares y técnicas de programación presentes en la organización.
Cada organización tiene su propia manera de manejar las cosas y hacer que fluya el flujo de trabajo en cuestión de desarrollo de software. El fin, sea cual sea su denominación o cargo es producir software de calidad. Y todo parte desde un buen análisis, diseño y negociación, sí, esa habilidad blanda muy poderosa para cualquier campo y muy valiosa para el desarrollo de software, ya que aquí determinas los recursos a utilizar, el resultado a querer y en cuánto tiempo se necesitará. Muchas veces sucede que se acepta desarrollar una funcionalidad en el sistema y justo a días de hacer la entrega, el cliente dice que eso no fue lo que pidió. Esa molestia da pase a la negociación y finalización de nuestro siguiente punto.

Obtener la aprobación

Las palabras se las lleva el viento, y si bien es cierto, a veces exageramos de brindar confianza a ciertos amigos del trabajo, no deben quedar acuerdos muy impactantes para el resultado final, en palabras habladas o conversadas. Por más que sea un dato pequeño, éste debe pasar por un control de registro documentado, el cual puede ser a través de un acta, email, grabación de audio o video. El promedio de olvido de cosas de trabajo que se hablan y no se documentan, en una organización, aproximadamente es una semana, y si consideramos que en oficina los correos llueven a velocidad acelerada, muchas cosas pueden tender a la redundancia o sobre escritura de desarrollos. Para ello se pueden basar en el control de documentos y registros que nos brinda la ISO 9001 y concientizar a su personal en el correcto uso de ello. Cuando se documentan estos acuerdos y buscamos la aprobación estamos construyendo un escudo que nos evitará dolores de cabeza en el futuro ante posibles cambios inesperados o ante amnesias de los usuarios.

Requisitos No Funcionales

Muchos desarrolladores se enfocan en la funcionalidad que quieren que tenga su sistema y demostrar lo rápido que son programando dicha funcionalidad, y cuando lanzan a producción su sistema, éste sufre cosas como lentitud en transacciones súper masivas no contempladas. Por ejemplo (en el caso de un sistema desarrollado en .NET) utilizar un datatable para poder leer un millón de registros, cuando pudo haberse trabajado con un datareader debido a su complejidad de procesamiento masivo. Los requisitos funcionales son necesidades tácitas de los usuarios. Lo clásico en estos requisitos es la velocidad de respuesta que debe tener el sistema, duración de procesamiento, cantidad de usuarios que deben acceder al sistema de manera concurrida, etc. Esto claramente indicará si necesitas cierta cantidad de núcleos de procesador, memoria RAM, distribución de request/response, balanceador de carga, entre otros.

Consejo audit

No tomes riesgos innecesarios aceptando requerimientos que no entiendas y que piensas que el usuario tendrá todo el tiempo del mundo para colaborar contigo, y repetirte todo de nuevo. Trata de plasmar resúmenes de lo que vas a desarrollar en gráficos y poco texto para tu kick-off. Recuerda, los usuarios necesitan que les hables en su lenguaje de negocio y los programadores necesitan más detalle técnico. No olvides las pruebas de aceptación (este tema lo veremos en un siguiente post), finalmente, las habilidades blandas son la pieza clave para unir el resto del proyecto.