Diseñando Sistemas I: La toma de requerimientos

Antes que nada, quiero decir que este artículo como los que le seguirán en esta serie, estarán basados en la experiencia que he acumulado desde 1971, año en el que comencé a estudiar y trabajar en los sistemas de tratamiento de la información, antes de que tuviera la posibilidad de obtener una titulación oficial que entonces no existía. Reflejaré tan solo ideas generales, sin entrar en metodologías concretas, (he tenido que aprender y utilizar distintas metodologías, según la empresa para la que trabajé), sino tan solo en las prácticas que me han dado buenos resultados independientemente del negocio, ambiente o método utilizado, la base ha sido siempre muy similar.

Una de las labores más gratificantes o frustrantes que el profesional de la informática puede llevar a cabo es el diseño de un sistema de proceso de información, tanto si es autónomo (el sistema) o forma parte de otra aplicación de mayor ámbito con la cual deberá integrarse.

Captar las necesidades del proceso, decidir cómo realizarlo y plasmar estas ideas en un diseño, tiene bastante de creativo y personal, aún cuando haya que aplicar metodologías y normas, e incluso haya que integrar otras herramientas en él. Personalmente, a lo largo de mi carrera como informático, me he sentido feliz cada vez que un sistema salido de mis manos daba el resultado esperado y permanecía activo largo tiempo sin requerir un soporte significativo o dar problemas. Debo añadir que también he tenido experiencias frustrantes (afortunadamente pocas veces), generalmente por no haber dedicado el tiempo necesario a analizar un problema y resolverlo correctamente, atendiéndolo con urgencia —y coste mínimo por supuesto—, lo que normalmente acaba volviéndose en nuestra contra, generando un problema aún mayor.

Llevo bastante tiempo sin realizar esta labor por lo que intuyo y digo “intuyo”, que las herramientas de desarrollo actuales, con bases de datos pre-definidas, lenguajes de alto nivel, etc., facilitan mucho el trabajo de desarrollo, pero estoy seguro de que sigue existiendo la posibilidad de ser creativo en la etapa de diseño, durante el proceso de análisis y definición de las necesidades del usuario final, entendiendo lo que se necesita hacer y sugiriendo soluciones, aunque sea a nivel funcional, para que orienten al equipo que después va a desarrollar estas ideas durante la programación.

Mi primera recomendación antes de diseñar un sistema es procurar comprender el proceso, pero no como algo aislado que hay que resolver sino como parte de una entidad mayor, ya sea un sistema informático más complejo o tal vez una actividad de negocio. Esto que parece obvio, no siempre se hace, porque entender el proceso es entender de qué forma parte, donde se integra, de dónde le llega la información, qué hace con ella, qué se espera obtener como resultado y dónde va a ser utilizado éste y para qué. Es decir, entender el antes y después del proceso, antes de entrar en los detalles del mismo.

Esto sin duda requerirá más tiempo dedicado tanto a la recogida de información como al análisis de la misma, añadiendo coste al proyecto, pero nos permitirá comprender ciertas particularidades del proceso exigidas no sólo por nuestro cliente, sino por las características de su negocio, por la legislación vigente o por prácticas del mercado o el entorno en el que se mueve. Con ello, además de obtener una motivación y una experiencia extra, nos convertimos en un interlocutor más efectivo frente al usuario que nos va a describir sus necesidades, en su lenguaje propio y con unos límites de visión que tal vez no nos convengan. También estaremos en condiciones de hacer preguntas de mayor calado y detectar puntos de posible riesgo o conflicto en el tratamiento de la información. Si somos capaces de hacer esto, en mi opinión, no solo podremos hacer un diseño más ajustado a las necesidades del cliente, sino que estaremos en condiciones de prevenir otras necesidades no descritas inicialmente, que se van a dar una vez puesto en marcha nuestro sistema.

El clásico “esto no me lo habías contado y no está previsto” debería quedar minimizado o anulado y por lo contrario, responder con “es fácil integrar lo que me pides” da confianza y satisfacción al cliente y crea un vínculo más sólido con su proveedor, ya que piensa que no sólo se le entiende sino que empezamos a tener una buena experiencia en su negocio y le vamos a servir de apoyo.
Con bastante frecuencia, los requerimientos de un sistema no reflejan solamente las necesidades de los procesos de la compañía donde va a ser instalado, sino que también incluye ciertas exigencias de sus clientes, principalmente de aquellos que deben seguir normativas y protocolos establecidos (clientes de la gestión y administración de la salud o de la alimentación, por ejemplo) que pueden requerir formatos de documentación específicos, con otros adjuntos y firmados que no forman parte del proceso en sí, pero que el sistema debe controlar su existencia y seguir unos ciclos específicos de aprobación, etc., y que complican bastante la forma de gestionar algo que en la empresa de al lado es bastante estándar y sencillo.

Si además, toda esa “cultura” está en la cabeza de dos o tres empleados “expertos” que la gestionan manualmente, por lo que no forma parte del flujo de información y conocimiento de la empresa, eso supone un alto riesgo para esta última, y una buena solución es diseñar un sistema automatizado y bien documentado que aporte dicha gestión de un modo ágil y claro, que pueda ser ejecutada con personal menos “culto” o bien que esa culturilla pueda divulgarse en todo el equipo de trabajo.

Plasmar los requerimientos en un documento ordenado y claro es muy importante, para presentarlo al cliente y que dé su aprobación antes de seguir adelante con el análisis funcional del sistema. Para ello, es conveniente adoptar una metodología de trabajo adecuada entre las existentes, o como mínimo adoptar un formato de documentación en el que indiquemos el nombre del proyecto, el cliente, la fecha, autor, el tema o sujeto del documento, etc. y apliquemos un código dentro de nuestra librería de documentos, para facilitar su localización, consulta y actualización. Una buena organización de la documentación es esencial para facilitar el desarrollo de cualquier proyecto.

En cuanto al mencionado incremento de coste, si no ha sido adecuadamente previsto en los presupuestos del proyecto, debería ser considerado —dentro de unos límites claro está— como una inversión de la empresa proveedora en beneficio de futuras colaboraciones con este cliente o en competiciones con otros clientes del mismo ámbito de actividad. Tener un “equipo experto” en el tema a solucionar dará un gran valor añadido a la propuesta de servicios que se presente ante cualquier otro cliente posible, además de fidelizar a los ya existentes.