En una de sus últimas entradas, Wardog define a los usuarios como periféricos orgánicos de activación mecánica de la interfaz física de entrada de datos. Y en el resto del artículo muestra como en la central se puede decidir que hay que hacer, se pueden montar programas para esas tareas. Pero como los usuario no lo usen y trabajen a su manera no hay nada que hacer.
Pero en esta entrada voy a llevarle la contraria a Wardog. Para mi lo importante es separar el tipo de proceso. Siguiendo con su ejemplo de TPVs… yo he sufrido a cada dependienta (lo siento, en estos casos siempre, 100% son mujeres) que es para llorar.
Informatizamos una tienda, ponemos un bonito PC con un software de TPV, le explicamos al jefe y a los dependientes su uso, en ocasiones colaboramos en la primera carga de artículos… Al cabo de unas semanas, el jefe quejándose de que nadie usa el TPV. Que las chicas siguen apuntando los pedidos en una libreta… Aquí estoy con Wardog, mano dura, son tareas simples y siempre las mismas. Si para trabajar tienes que usar un PC, pues se usa y ya está.
Pero hay otras tareas, donde se olvida a los usuarios por completo y no debería ser así.
Mi empresa de por las mañanas, está en el segmento más regulado que hay en España. Tenemos que cumplir normas europeas, normas de varios países que no son España, normas estatatales, normas autonómicas, normas municipales… y muchísimas normas internas. Hay muchos procesos que juntando a las tres personas que más saben del tema en la empresa, no se ponen de acuerdo de cómo ha de hacerse. Y quieren que en la red comercial, donde están peleándose con los clientes, sepan aplicar todas las normas y sepan siempre qué proceso usar en cada caso.
En estas situaciones, es donde una aplicación con buena usabilidad y pensada para guiar al usuario marca la diferencia. Es decir aquí invertir en que la aplicación sea algo “espabilada” es algo que luego ayuda mucho a los usuarios, no que ayuda, sino que permite que los usuarios trabajen de verdad.
En muchas grandes aplicaciones se parte de la premisa que el usuario debe saber de todo y eso hoy en día es cada vez más difícil. Así que el que la aplicación tenga mucha lógica del negocio es algo imprescindible y la mayoría de las veces no es así.
El analista de la aplicación es un experto en ese área del negocio y no piensa que los usuarios finales a lo mejor usan su aplicación solo una vez al mes. Y no pueden acordarse de unas normas que como mínimo son 20 páginas solo para ese módulo… y tienen que usar 200 aplicaciones así.
Así que analistas y programadores, no olvidéis que el usuario tiene enfrente al cliente, que es el que gana dinero para todos… y hay que mimarlo. Y si el usuario usa un proceso que no es el pensado por los jefes… la culpa no es del usuario, sino de los analistas y programadores.
En mi empresa de por las mañanas tenemos algunos ejemplos muy divertidos. Hace unos años sacaron una aplicación que había costado años de desarrollo… Pues nada, se sacó, todo el mundo se felicitó, pero los usuarios nunca la usaron. Era complicada, lenta, farragosa. y le gente no la usaba. Se amenazó con el fuego eterno y cuando los usuarios consiguieron que algún jefe bajase a un PC y viese la aplicación… pues allí se quedó.
13 Comentarios
Comentarios Cerrados
normalmente estoy de acuerdo contigo en lo que escribes y tal.. pero hoy NO!
Los progamadores hacen lo que les mandan, ya que estos son simples “operarios” o remeros como les llamamos la mayoria. Los analistas pillan los requerimientos del usuario y hacen lo que ellos piden, el problema es que estos usuarios suelen cambiar de opinion mil veces y marean a la gente (apostillando que la mayoria de ellos de informatic ano tienen ni idea y se suelen pedir cosas a veces algo impossibles).
Los programadores no tienen culpa de nada!
Uri:
Te acepto la crítica, en este caso, el culpable al principio de la cadena el usuario que pide la aplicación, que en estos casos no es el que la usa.
Pero en muchas ocasiones el programador decide si la aplicación ayuda más o menos al usuario.
Esto me pasa a mi, que siempre termino peleándome con los programadores, porque estos vienen siempre con recortes e implantan menos de la mitad del análisis
Yo creo que la culpa es de la organización en sí, un sistema donde no se fomenta la pasión por lo que se hace, la excelencia y la orientación al cliente, sino que estamos ante un sistema donde abundan el bodyshopping masivo, la rotación del 80%, el “te firmo el contrato en el puticlub con unas cuantas copas” y sobre todo, el marear la perdiz. Con estos mimbres, pocos cestos se pueden hacer, y menos, entender al usuario.
Yo creo para el usuario final lo único útil es lo que cumple con el minímalismo de Google (una barra y un botón), Ipod (una pantalla y un par de botones juntos)… Creo que tenemos más que comprobado que los usuarios no leen ni observan, por eso nos preguntan done está “Inicio”… El problema es que es muy complicado desarrollar una aplicación minimalista y que realmente de la utilidad que se necesita con la cantidad de información que se ha de procesar en muchas empresas.
Una pregunta, tengo en las estadísticas de la última semana de mi página más de 40 visitas diarias que tienen como Referer Changlonet.com. Y tengo curiosidad por saber si son visitas reales o es algún tipo de script que estás probando… Gracias!
#Tendero:
Hay expertos de usabilidad y expertos en interaccion que se encargan de estas cosas, ademas de una rama de la psicologia que toca estos temas, no es cosa de los ingenieros… (otra cosa es que la empresa no quiera dedicar dinero a estas cosas y le acaba tocando al ingeniero implementarlo)
Santeados:
Son visitas reales
Ger:
No es eso de lo que hablo. Te pongo un ejemplo. Imáginate que tienes una aplicación que admite ventas a plazo. La normativa que hay que cumplir para montar una venta aplazada, es bastante compleja. ¿Dejamos que el usuario busque, en la Intranet, en papel lo que necesita en cada caso, o se lo proporcionamos desde el software?. El especialista en créditos que está en la central de la empresa lo sabe de memoria, pero él solo hace créditos. Las tiendas que hacen una operación de venta aplazada a la semana, no saben por donde empezar. Lo que yo pido es que la aplicación ayude al usuario, la usabilidad también.
Esta vez yo también discrepo contigo, tendero. Es cierto que es un error no facilitarle la tarea al usuario en esos casos, pero cargas tintas contra las personas equivocadas. La culpa no es de los programadores, que codifican el programa, la culpa la tienen los que lo diseñaron por no contemplarlo. La fase de diseño está para algo y no precisamente para decidir los colorines del programa. Si son las mismas personas o no ya va aparte.
Gracias por la aclaración que me tenía contrariado y alucinado a partes iguales 😉
1º Una cosa es lo que dice el usuario y otra lo que quiere decir.
2º Una cosa es lo que entiende el analista que hay que hacer, en una materia que normalmente no domina, y otra lo que realmente hay que hacer.
3º El programador hace lo que le mandan como buenamente puede y luego se come el marrón de todas, todas.
El resto… proyecto bicicleta
para nada de acuerdo!!!
creo que la mayor parte de las veces cuando se hace un programa para una determinada tarea, es para facilitar el trabajo, pero no solo para facilitarselo al dependiente, sino a todo el conjunto de la empresa, por lo que hay que verlo de una manera global, claro que al usuario le cuesta aprender cosas nuevas y hacer cosas de forma diferente de como las ha estado haciendo toda la vida! pero por dios que no sea tan vago, si sigue apuntando las cosas en una libreta, ya me dirás tu como van a salir luego los pedidos automaticamente, las facturas, etc
en fin, creo que no es tan dificil y no exige mucho esfuerzo, asi que, si hay que leerse un manual de 200 paginas para una cosa que luego vas a manejar dia tras dia pues se lee ¡coño! que parece que habéis nacido cansados!! (que diría mi madre).
saludos
Mindungui:
Cuando quieras te pasas por una Oficina de mi empresa de por las mañanas y te pones a atender a unos clientes que te piden:
– Un seguro de vida, pero que el beneficiario sea el querido/a y no la pareja estable del cliente… ah y que desgrave
– Un préstamo hipotecario, pero la vivienda se la vamos a comprar a una persona, que es la dueña, pero hay un usufructuario, y quiero poner el préstamo a nombre de una sociedad, porque fiscalmente me interesa y lo quiero para dentro de 2 días.
– Quiero comprar una warrants, de la bolsa de Nueva York…
Y así todo el día sin parar. No hay persona humana que sea capaz de aprender toda la normativa legal de todo eso… por eso el sistema informático debe ayudar, no penalizar.
Buenos dias tendero-digital
Por supuesto de acuerdo en que el sistema informatico debe hacer todas esas cosas, precisamente para liberar esa carga al usuario y para minimizar errores, pero coño, si luego el usuario tiene que leerse un manual para aprender a utilizar el sistema, que se lo lea y se lo aprenda y que se lo lea las veces que hagan falta, no que le parezca demasiado ‘complicado’ y prefiera seguir haciendo las cosas a su manera (perdiendo mas tiempo, pudiendo cometer mas errores…)…
Que no se piensen que el sistema les va a liberar de trabajo y van a poder estar todo el dia rascandose las pelotas (con perdon).
Ahí es a donde voy, ni mas ni menos…
Buenas, he llegado a este post desde wardog. Estoy de acuerdo parcialmente con lo que dices, pero el error principal no creo que sea de los analistas o los programadores, sino del proceso de creación en si mismo, me explico: generalmente cuando se desarrolla una aplicación (desde el análisis en si mismo) se olvida que al final de cuentas esto deberá ser utilizado por un usuario, este será mejor o peor, pero al final de cuentas es el “cliente final” del desarrollo, y siempre se excluye a este del proceso de creación y de validación, generando más iteraciones en el proceso de la creación de la versión final de la aplicación y un mayor nivel de “no conformidades” que luego se traducen en retrabajo y en “mejoras” facturables al cliente.
Generalmente la validación se le requiere a quien define y aporta los requisitos, y no será luego éste el que utilice la aplicación en el día a día, con lo que da el visto bueno solamente con la visión parcial de si se ajusta o no a los requisitos (que él mismo ha aportado), con lo que sabe si se ajusta a la lógica del negocio, pero no si será realmente usable por un usuario real.
O sea: la culpa no es de las personas, sino del método.
Salu2