Sencillez (aparente)

No sé dónde lei que cuanto más sencilla es una aplicación para el usuario, más complicado es para los desarrolladores construirla. Y también es cierto que cuando un stakeholder te presenta sus necesidades, el primer modelo mental que se construye es francamente sencillo (o sea, poco detallado).

Cuando por fin vas pasando de un análisis del problema al diseño de una solución, el número de detalles aumenta naturalmente. Este tipo de detalles tiene muchas veces que ver directamente con el problema y siempre con los requisitos del usuario, tanto funcionales como no funcionales. Así, lo que antes era sólo introducir información se transforma en un conjunto de decisiones relativas a la validez de esos datos, a su tipo, a la estructura entre ellos, a qué hacer cuando los datos son parcialmente incorrectos. Sin decir nada sobre los mecanismos de seguridad, que determinan quién puede introducir qué datos y cuando. ¿Habrá un proceso de introducción por una clase de usuarios y otro de validación por parte de otra clase distinta? ¿Se querrá registrar quién introdujo la información? ¿Sólo la última modificación, o un histórico de ellas?

Para los que diseñamos y construimos sistemas de gestión, un síntoma de este Big Bang que transforma un problema primordial en un universo de soluciones galácticas (y el energético proceso que pasa de una a otra) aparece cuando tenemos que agregar "un campo más". Un campo más, es revisar desde la base de datos hasta todas las capas de presentación (incluyo informes), qué partes se ven afectadas... Sí, es cierto, es la más fácil de las modificaciones... :-) Imagínate cualquiera otra...

Por cierto, me niego a traducir "stakeholder" por tenedor de apuestas. Creo que la traducción más cercana podría ser "implicado en" o "interesado por" un proyecto. ¿Alguien tiene alguna otra sugerencia?