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.

• Implica que no es posible ganar sin riesgo. Peligrosa afirmación, cuasi adolescente, casí estúpida. Es como decir, “El que no chupa, no se divierte”.
• No es posible negarla completa para asegurar el valor del riesgo: “El que arriesga, gana” es una falacia implícita. Si esto fuera cierto, no habría riesgo.
• Me parece un poco un mantra del poco preparado para justificar un salto a una acción poco estudiada. Donde el deseo quiere convencer a los hechos de que la fortuna estará a su favor.

• No ve sus defectos
• Cree que todo lo puede
• Todos lo que lo critican están mal

En fin… si yo fuera una colegiala, el artista sería el CSS.