Durante mi "carrera" profesional siempre he desarrolado software, sin más, resolviendo lo que los clientes me pedían, no era consciente de que eso eran proyectos, no productos.

A partir de que en la empresa decidimos desarrollar un producto "estándar" empecé a darme cuenta de las diferencias entre desarrollar proyectos y productos.

En los proyectos resuelves problemas que te comentan personas que conoces, que tienes cerca, en un entorno conocido y sobre el que, en cierta forma, puedes intervenir para adecuarlo a la solución del problema. A cambio, no siempre se aplica la mejor solución (desde el punto de vista técnico) para el problema, muchas veces simplemente se soluciona, bien porque el cliente lo quiere para YA!!!! o porque sabes que no se va a utilizar mucho (a veces una sola vez).

En un producto... tienes que resolver problemas "abstractos" de gente que no conoces, de clientes que lo pueden ser del producto, sobre una plataforma determinada pero no sobre unos equipos concretos, debes dejar el software lo más abierto posible para que el usuario pueda "personalizarlo". Debes escribir código robusto, lo más que puedas, porque no sabes donde se va a ejecutar, no sabes la preparación "informática" de los usuarios. En definitiva, todo muy amplio, muy abstracto.

En un proyecto, estás a disposición del cliente (al menos esa siempre ha sido mi postura), te tienes que adaptar a sus necesidades cambiantes (porque cambian, verdad?), muchas veces se cancelan, o se congelan, determinadas funcionalidades porque se cambia de prioridad.

En un producto, debes escuchar a los usuarios, recoger información sobre sus necesidades, tener capacidad para sintetizarlas y extraer lo común, lo realmente útil y no "caprichos" individuales. Y en base a ésto realizar un plan de desarrollo, y seguirlo. Está en tus manos (en cierta forma) la evolución del producto (mal harás si no escuchas a tus usuarios).

Como veis las cosas son muy diferentes, por ello me costó mucho cambiar de "chip", acostumbrado durante varios años a atender a las necesidades concretas de un sólo cliente he pasado a tener que recopilar sugerencias, necesidades, estudios de competencia para decidir que funcionalidades se le añaden al producto y cuales se quedan en la recámara.

(Continuará ...)

Esta frase es el título de un libro que quiero leer, es un libro sobre usabilidad en web. Lo he visto como reseña al final del libro de Joel Spolsky "User Interface Design for Programmers", éste lo acabo de leer y he sacado muy buenas conclusiones, que estoy empezando a aplicar a las aplicaciones que desarrollo.

Una de las conclusiones es que los usuarios no leen, aunque es sabido por la mayoría de programadores no lo tenemos suficientemente presente, los usuarios no suelen leer los avisos, no suelen leer los manuales (bueno salvo como último recurso), por lo tanto, no les hagamos leer, no llenemos las aplicaciones con cuadros de diálogo llenos de texto, muchas veces incomprensible, vayámos al grano, simple por encima de todo.

Otra conclusión es que no permitas que los usuarios se equivoquen, porque no son los usuarios quienes lo hacen mal, es tú aplicación que no sabe responder a unas situaciones determinadas. Sobre esta conclusión quiero mostrar un ejemplo que he tenido recientemente:

Es una pantalla que sirve para introducir cobros de clientes, en la que se selecciona un cliente y se introduce un importe cobrado, y el programa va "repartiendo" ese importe por las facturas pendientes del cliente.



Teníamos un fallo, un bug, resulta que si seleccionabas un cliente que no tenía deudas, igualmente podías introducir una cantidad cobrada, y el programa intentaba repartirlo entre las facturas pendientes (o sea, ninguna), no daba un error, pero no hacía nada y el usuario se quedaba con la duda de que había pasado.

La primera solución que se nos ocurrió (creo que es la primera que viene a la cabeza) es la de avisar al usuario que no hay facturas pendientes entre las que repartir la cantidad introducida. Pero eso no resuelve la "frustación" del usuario, porque él ha introducido una cantidad, la solución buena es evitar que la introduzca si no ha de hacerlo. ¿Como? pues desactivando los controles donde se introduce la cantidad, de esa forma no se puede hacer y el usuario lo "ve" antes.



En otra parte del programa tenemos una pantalla que reorganiza los ficheros, reconstruye los índices y, opcionalmente, hace unas comprobaciones de integridad y de consistencia. La opción de comprobar los datos, estaba mediante un check que el usuario seleccionaba, porque esta opción tarda un poco más, estudiando lo que hacen los usuarios, nos dimos cuenta que o se seleccionaba siempre (por si acaso) o no se seleccionaba jamas (por si acaso). Esto realmente es un fallo de diseño, porque no tiene sentido que se pueda seleccionar, siempre se debería hacer porque no es un proceso que esten haciendo habitualmente, y por lo tanto, cuando lo hacen es porque ha ocurrido algo (corte de luz, problemas con el disco, cuelgue de Windows) y no les importa que tarde un poco en hacerlo, total que hemos quitado el check y ahora siempre hace la comprobación de datos además de recostruir los índices.

En próximos posts continuaré hablando de más cambios que estamos realizando para mejorar el interfaz de la aplicación.

En una de las aplicaciones que desarrollé, sin duda las más compleja que hecho jamás, trataba sobre una gestión del flujo de trabajo de una gestoría.

Se desarrolló la aplicación, se mostró a los usuarios, se les hizo una formación y se puso en producción. En este cliente estaba yo integrado en la empresa, por lo que ante cualquier eventualidad tenían solución inmediata, la mayoría de las veces.

De lo que se trataba era de desarrollar un nuevo sistema de gestión que consiguiera dos objetivos, aumentar la capacidad de procesamiento de la gestoría y conseguir mayor control sobre los procesos, para que al aumentar el volumen no se descontrolaran los procesos.

Pero hubo un problema, no involucramos a los usuarios completamente desde el principio, creímos, el cliente y yo, que nuestro modelo, nuestra idea de "workflow" era correcta, que era una buena solución para controlar el trabajo de la gestoría. Si que se les consultó, pero luego no se les mostró la evolución del programa, no se les hicieron pruebas para que opinaran, y eso fue un error.

¿Que ocurrió? Pues que los usuarios utilizaban el programa de una forma diferente a la que se diseñó. ¿Porque?, porque nosotros partimos, al diseñar el programa, de una premisa equivocada, que todos los documentos eran iguales, y lo son, pero no el 100%, si no un 70%, y lo que ocurre es que el 30% que falta consume casi el mismo tiempo de proceso que el resto, porque los documentos "problematicos" requieren de alteraciones en los procesos para adecuarlos a las particularidades de cada uno.

Moraleja: Ademas de dar solución a lo QUE necesita tu cliente, tienes que dar solución a COMO lo necesita.

No se si a vosostros os pasará tambien, pero en mis aplicaciones el número de tablas auxiliares crece de forma exponencial respecto a las tablas principales.

Si tomamos una tabla principal, digamos artículos, tenemos 5 o 6 tablas auxiliares, veamos:
- Linea negocio
- Familia
- Subfamilia
- Marca
- Estado (alta, baja, bloqueado, etc...)
- Color (por ejemplo)

Al final decidí hacer un mantenimiento genérico y único para todas estas tablas auxiliares, y es más, las metí todas en una metatabla con la siguiente estructura (mas o menos):

ID -> identificador único del registro
TABLA -> Que tabla es (FML, SBF, MRC, LNG, ...)
NOMBRE -> Descripción
ID_SUP -> indentificador del superior (para estructuras jerárquicas)

Luego utilizando vistas obtengo cada tabla auxiliar allí donde lo necesito.

¿Como lo haceis vosotros?