¿Quién no ha oído hablar mal de IT? Probablemente ya trabajaste en una empresa en la que otros sectores no ven a IT con buenos ojos. Tal vez porque allí pueden haber altos salarios en la organización, salvo la alta dirección. Pero el problema no ni el valor que un profesional de IT llega a recibir mas sí lo que él hace para merecer el mismo.
No quiero en este post hablar sobre gestión de competencias. Vengo a hablar de lo que podríamos hacer para dar más poder al usuario. Una de las primeras acciones ya debería estar clara en su cabeza ¿no? Desarrollo iterativo e incremental utilizando prácticas y métodos probados. Pero esto (que no es poco ni fácil) no será suficiente.
¿Parametrización?
La luz al final del túnel?
Quizás. Todo el mundo quiere un sistema parametrizable. Pero toda parametrización tiene un costo y parametrizar todo el sistema no es viable y mucho menos efectivo, porque tienen cosas que cambian tan poco que el retorno no pagaría el esfuerzo, todavía más porque las cosas cambian.
Una vez que hayas encontrado "lo que" parametrizar te tienes que preocupar por el "cómo". Esta tampoco es una tarea fácil. Muchas empresas han adoptado la solución de la parametrización mas simple que es el de "Cada caso es un caso". En este modelo normalmente, algunas tablas se exponen por lo general a través de pantallas de parametrizaciones. A veces se mezcla con CRUDs.
¿Por qué no parametrizar con pantallas?
Puedes optar por este enfoque. En algunos casos será suficiente, en otros no. Porque este tipo de enfoque tiene problemas con la flexibilidad. Y cualquier cambio por mas simple que sea puede generar una nueva demanda de desarrollo.
¿Cuál es el problema del desarrollo?
Desarrolladores planificando
En principio ninguno. Sin embargo, los desarrolladores son más caros que un profesional que está en la línea de producción y que conoce mejor el negocio. Ciertas cosas que el usuario no tiene aunque el quisiese no podría resolver. Otras el podría resolver sin pasar por el equipo de desarrollo y, por tanto, ahorrar dinero para la organización y dejar que el equipo de desarrollo se enfoque en lo que realmente vale la pena!
¿Niveles de Decisión?
Esa es una buena. Necesita proporcionar ciertos niveles de decisión al usuario. Un sistema mas parametrizable significa mas decisiones para el usuario. Esto no necesariamente significa más complejidad. Porque la complejidad dependerá básicamente de la complejidad inherente del problema y la complejidad que le das en la solución.
Debe dar al usuario ciertos niveles de decisión, es decir, no todo tiene que venir como una petición de desarrollo. Bueno yo hago eso, tengo pantallas que el usuario escoge como van a ser ciertas cosas en el sistema. El problema es que este enfoque puede ser costoso y no siempre claro para el usuario. Estudios sobre la experiencia del usuario y la usabilidad y puede dar resultado en esta parte aunque el costo es alto.
¿Por qué no exponer las reglas de negocio?
Esto puede ser la solución a sus problemas. ¿Cuál es el problema de eso? ¿Los analistas serán despedidos? ¿Los usuarios obtienen el control de IT? ¡"No" para las dos preguntas!
Para resolver este problema se utiliza otro modelo, el paradigma del que estoy hablando es BRMS el cual Drools implementa.
¿Business Rules Management System?
Consiste en desarrollar, mantener, versionar, probar, organizar y hacer el despliegue de reglas de negocio. Drools ofrece una excelente solución en este sentido, en mi humilde opinión el mejor del mercado en este sentido. A través de Drools podemos dar ciertos niveles de decisión para el usuario, que no es estúpido! Es un gran error tratar al usuario como ignorante! Luego con Drools podrá cambiar ciertos aspectos del comportamiento del sistema sin tener que pedir tiempo a IT.
Así vamos a dar poder al usuario. Ese poder se puede obtener a través de reglas escritas con los objetos de dominio aplicando un buen DDD, o por medio de DSLs escritos en un buen castellano con el lenguaje del usuario. O incluso con una buena hoja de cálculo.
En breve desarrollaremos más este apasionante tema con ejemplos en un proyecto de ejemplo.
