el zapato del usuario

Caminar en los zapatos del usuario es algo que pocas veces hacemos. Es importante y aquí una anécdota:
Como equipo de desarrollo y consultoría una de las “quejas” más común en revisiones internas es el hecho de que el usuario final se fija MUCHO en la interfaz, colores, posición de los elementos, tamaño y tipo de letra, etc. y muy POCO en la funcionalidad.
Es decir, podemos darle un sistema que calcule tablas financieras s 25 decimales mediante fórmulas iterativas, que sea eficente, rápido y que almacene todo de manera correcta y flexible y que exporte a PDF, HTML y CSV… y todo lo que obtenemos de retralimentación es “OK, pero… ¿puedes hacer el logo un poco más grande?”.
En una sesión de desahogo entre desarrolladores y consultores se puede llegar a esuchar que: La entrega puede ser un sistema que puede predecir el clima, bolear tus zapatos, hacerte café en la mañana, te pregunte ¿cómo te fue en tu día? y todo lo que obtendrás es “OK pero ¿Podemos poner el font en amarillo? Es que le voy al América.”
La conclusión sería que “Al cliente sólo le importa la forma, no el fondo.”
Riámonos todo lo que queramos, pero…
Hoy día estamos desarrollando un sistema para uso interno. Es decir, dentro de la empresa, hay un equipo que es el proveedor/desarrollador y el resto serán los usuarios/clientes.
Pues bueno… llevamos desarrollando 4 semanas y se hizo una entrega para iniciar el uso y prueba de algunos módulos en versión alfa. 100% funcional, 10% interfaz.
El “equipo de desarrollo” presentó a los “clientes” dicha entrega. Cabe mencionar que los “clientes” son consultores, líderes de proyecto y desarrolladores. ¿Qué obtuvo el equipo de desarrollo como retroalimentación? Obvio:

• ¿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.

¿admin admin? ¿admin 0123456789? No me… molestes.

Tooooooooodos los sistemas tienen un usuario admin. Todos. O por lo menos una de sus variantes (adminsitrador, administrator, test,…).

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.

1+1 > 2

Otra veloz… sólo para no dejarla pasar.

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.