• ¿Cuándo se va a ver más bonito?
• ¿Podemos subir/bajar/mover este campo?
• ¿Podemos cambiarle que diga “Fecha de Inicio” en lugar de “Inicio”?
• o me gusta como se ve, etc, etc, etc…

¿Y la funcionalidad? Bien gracias.

Cuando se entrega o presenta dicho usuario al cliente para que lo utilice es buena idea recordar no hacerlo con una contraseña de pacotilla como:

Usuario: admin
Contraseña: admin

Pueden pasar dos cosas (bueno, pueden pasar muchas, pero generalmente dos):

• En el mejor de los casos: El cliente se ríe de ti por darle una contraseña así de “patito”. Sobre todo si le has dado incontables sermones sobre las contraseñas seguras.
• En el peor de los casos: Al cliente le importa un comino y la deja así, por los siglos de los siglos amén. Y, felicidades, tu sistema queda abierto para cualquier entusiasta de la computación.

En breve, échale un poco de ganas al password del admin.

PD: Y no puedo expresar suficiente pasión por azotar con una vara verde a quienes usan contraseñas inseguras: 12345678, abcde, qwerty, cumpleaños, nombre del perrito, nombre de la novia, equipo de futbol/color/fruta/lugar favorito. Un artículo al respecto de contraseñas comunes.

A veces, tener dos recursos de capacidad “X” es mejor que tener un sólo recurso de capacidad “2X”.
Por ejemplo, dada una misma carga de trabajo, dos servidores de con 1GB de RAM operan más estable, eficiente y controladamente que uno solo de 2GB en RAM.

La idea se puede aplicar (de nuevo, a veces) para Bases de Datos, Sistemas en general, Ventas y hasta Recurso Humano.

y un juguete nuevo.

Ahhhhhhh…

Es frecuente la tentación de poner primero el deseo de utilizar “lo que conocemos” y después la necesidad real del cliente o el proyecto.

Es preciso estar en constante vigilia para que este “placer cómodo” de lo que “ya sabemos hacer” no supedite nuestra elección de la solución más segura, más certera, más correcta para el/nuestro proyecto.

En el mundo de las metáforas: “prefiramos el amor puro a la herramienta correcta seleccionada objetivamente sobre el deseo de utilizar lo que conocemos, sólo por el hecho de que lo conocemos”.

Es frecuente la tentación de poner primero el deseo de utilizar el “nuevo juguete” y después la necesidad real del cliente o el proyecto.

Es preciso estar en constante vigilia para que este “placer morboso” de la curiosidad no supedite nuestra elección de la solución más segura, más certera, más correcta para el/nuestro proyecto.

En el mundo de las metáforas: “prefiramos el amor puro a la herramienta correcta seleccionada objetivamente sobre el deseo de utilizar lo que desconocemos, sólo por el hecho de que lo desconocemos”.

La mente humana puede manejar un promedio de siete elementos a la vez.

Siete en promedio. Más o menos 2 (de 5 a 9) es aceptable.

Es decir:

• Siete elementos en pantalla
• Siete opciones en un menú.
• Siete botones, etc.

Es un punto de referencia veloz para recordarnos que debemos mantener la interfaz limpia, simple y organizada.

Si tenemos demasiados elementos simultáneos es recomendable distribuidorlo, organizarlos o agruparlos de manera que la atención del usuario sea eficiente y cómoda.

Típicamente el requerimiento: nace en el cliente > se comunica al consultor > se define con el líder de proyecto > se ejecuta por el programador.

Quién define un requerimiento busca ser lo más específico y preciso posible. Sin duda esto es positivo y útil, elimina ambigüedad y hace la tarea más clara y verificable.

El que recibe y llevará a cabo el requerimiento toma las palabras o diagramas y hará su mejor esfuerzo para llevarlo a cabo.

Sin embargo, en la peresecusión de cumplir excatamente con lo que se pidió, aquel que realiza la tarea puede caer en tratar de realizar una funcionalidad exáctamente como se describe sin que ello sea lo que realmente se necesita.

Por ejemplo, una vez un cliente nos solicitó para un sistema web de punto de venta:

Que al picar la tecla F1 apareciera una lista de los productos existentes. Y al picar F2 aparecieran las existencias del producto seleccionado.

Así se levantó el requerimiento y así se comunicó al programador.

El desarrollador terminó la funcionalidad de consulta de prodcutos y existencias muy rápido. Pero llevaba 2 días tratando de equilibrar la funcionalidad de F1 de su desarrollo con la funcionalidad F1 del navegador. Lo mismo con el F2.

A final de cuentas, el cliente no tenía un fetichismo o amor especial por F1 y F2. Sólo quería una manera de consultar sus productos y existencias. Pidió el F1 y F2 porque así lo tenía sus sistema (en Visual Basic) actual.

Es muy importante obtener y comunicar el espíritu o escencia de un requerimiento. Además de los específicos sugeridos. La escencia del requerimiento en el ejemplo era:

El cliente desea una manera de consultar su lista de productos y sus existencias en el Punto de Venta.

Por supuesto que sería deseable utilizar F1 y F2 porque son opciones que el cliente y su empresa ya conoce. Pero no es algo requerido. La escencia sí lo es.

Creo que deberíamos acompañar un requerimiento con una breve nota, inclusive una simple oración de defina el objetivo con el que se creó. Su espíritu.

Es una frase utilizada en exámenes profesionales para asegurarse que cada graduado sepa muy bien las conceptos y términos básicos. Les asombraría cuantos Licenciados no pueden definir lo que es Derecho ó determinar la diferencia entre Código y Ley y Reglamento.

Pensando es lo anterior vamos a empezar con una nueva categoría llamada “joven padawan”.

Tips y conceptos básicos como para un principiante en estos de los sistemas y similares. Nunca esta de más volver a las raíces y compartirlas.

… y les asombraría cuantos Informáticos no pueden definir lo que es un Sistema, confunden “registro” con “campo” ó no saben determinar la diferencia entre una llave primaria, foránea y compuesta.