Aqui vengo con mi teoría del modelo del usuario sobre el deseo del programador.
Cuando uno desarrolla y encuentra bellezas como Delphi, que cuentan con muchísimos componentes fáciles de usar y a esto le añadimos los mil y un trucos que hay en el club y otros lugares además de las bibliotecas de terceros super complentas, fácilmente cae uno en la tentación de tratar de hacer interfases muy bonitas, brillantes, sorprendentes y nos olvidamos de lo verdaderamente importante: lo que el usuario (no el cliente que va a pagar) espera que haga nuestro software.
Hay softwares con interfases sobrias y quizá hasta un poco feítas que sin embargo realizan su función tal como esperamos y nos resuelven el problema sin mucho esfuerzo y de la forma que pensamos debe hacerlo.
El mismo windows per se ya nos proporciona varias formas digamos "estándares" en las que nuestro software debe funcionar, de hecho el usuario que ya ha usado windows esperará que nuestro software funcione de la forma que funciona todo lo demás que ya usa.
Otro problema que nosotros mismos generamos surge al momento de trasladar un objeto real a un objeto virtual, siendo que no son lo mismo. En este caso que vemos, podríamos caer en la tentación de modelar un TAnimal como wrapper del animal verdadero y ponerle tantas o cuantas propiedades queramos. Esto al final nos va a arrojar diagramas muy bonitos que nos servirán para engrosar la documentación que entreguemos pero nuevamente nos alejamos de nuestro objetivo: resolver el problema del cliente.
Si empezamos nuestro diseño pensando primero en como resolver todos los problemas planteados y codificamos para ello, será mucho más fácil crear la interfase.
Tenemos por lo tanto que entrevistarnos con los que serán los usuarios de cada parte de nuestro sistema para poder entender como es que ellos ven al sistema, claro, ayudándoles con mejoras que ellos no han visto todavia. Por ejemplo:
Cita:
Prog:Como harías(haces) el trabajo tal.
Usario: "Bueno, primero reviso que el animal tenga tal y tal dato...luego...etc.
Prog.: Bien, te ayudaría si al poner el nombre o id del animal te muestre automáticamente sus hijos
[Opcion 1]
Usuario: No mucho, porque en realidad para esta tarea no necesito esa información.
[Opcion 2]
Usuario: Si, bastante porque de ahi puedo tomar tal o cual dato.
|
Como podemos ver la respuesta del usuario ya nos dá una guía para la interfase, está claro que si al usuario no le sirve algo no hay necesidad de codificarlo y ponerlo. Es como el famoso caso de los menús de Word o Excel, la cantidad de items en ellos es considerable y sin embargo el usuario promedio solo usa unos cuantos. Es decir que si quitáramos a esos programas todas las opciones que no se usan mucho el usuario aún estaría satisfecho con él.
Como es obvio, a menores opciones que codificar menor tiempo de desarrollo y obviamente mejores condiciones para negociar con el cliente un buen precio y obtener buenas utilidades.
REGLA DE ORO DEL DESARROLLO A MEDIDA:
" Si no te lo pidieron y no sabes si lo necesitan, no lo codifiques"
Así de simple.