por
pobrecito hablador
el Miércoles, 22 Agosto de 2012, 17:46h
(#1318280)
"A veces es complicado transmitir correctamente como se quiere realizar el flujo de trabajo de un programa al usuario"
Es el usuario tiene unos mecanismos manuales de trabajo y un flujo de trabajo para realizar sus tareas. El usuario es experto en su trabajo, él es el que sabe cómo hacer sus cosas. Tú eres experto en programar (automatizar), no eres experto en su trabajo. lo único que tienes que hacer es automatizar las tareas que él ya hace manualmente. Si le quieres imponer *tú* manera de hacer las cosas (las cosas en lo que él es experto) muy probablemente, de facto, ya tienes todo tipo de problemas, incluso, de usabilidad.
No se impone al usuario cómo trabajar, se automiza lo que él hace. Si se te ocurren mejores maneras y ciertas características para aumentar su productividad, se las comunicas, y si las acepta, las realizas.
"Pero a veces el usuario no quiere cambiar, aunque los cambios fueran a mejor"
¿?Y por qué tiene que cambiar, ¿Y quién define lo que es mejor?, ¿tú, que no sabes nada del trabajo que él ha hecho por años?. Problema de usabilidad, no oyes. El usuario no va a cambiar, eres tú el que te adaptas y automatiza sus necesidades. Si le ofreces buenas ideas que mejoren sustancialmente su productividad, él las aceptará. Nadie se niega a eso.
"Si bien es cierto que algunos cambios o novedades pueden ser una mierda, lo que no puede ser es tener esa pereza por aprender (coño, es lo que tiene la informática, y lo que mola) y adaptarse"
Pues no seas tan perezoso, adáptate. Eres un servidor. Le prestas un servicio al usuario, no le impones tus ideas por la fuerza, lo convences.
"Hace poco desarrollé una pequeña aplicación en mi trabajo. Si no lo llego a desarrollar sentado junto al administrativo que la iba a utilizar, seguro que no le hubiera sido de lejos lo útil que es ahora, por que yo no podía preveer sus necesidades"
Ese es el camino. Yo *NUNCA* hago nada si no he hablado por días enteros y a veces semanas con el usuario. Él me enseña su trabajo, sus necesidades, su manera de hacer las cosas, y yo le enseño las posibilidades que se pueden hacer con el computador, y entre los dos desarrollamos el programa. Al final, siempre sale algo estupendo, tanto desde el punto de vista del usuario, como desde el punto de vista del programa.
Re:Tema peliadguro
(Puntos:0)Es el usuario tiene unos mecanismos manuales de trabajo y un flujo de trabajo para realizar sus tareas. El usuario es experto en su trabajo, él es el que sabe cómo hacer sus cosas. Tú eres experto en programar (automatizar), no eres experto en su trabajo. lo único que tienes que hacer es automatizar las tareas que él ya hace manualmente. Si le quieres imponer *tú* manera de hacer las cosas (las cosas en lo que él es experto) muy probablemente, de facto, ya tienes todo tipo de problemas, incluso, de usabilidad.
No se impone al usuario cómo trabajar, se automiza lo que él hace. Si se te ocurren mejores maneras y ciertas características para aumentar su productividad, se las comunicas, y si las acepta, las realizas.
"Pero a veces el usuario no quiere cambiar, aunque los cambios fueran a mejor"
¿?Y por qué tiene que cambiar, ¿Y quién define lo que es mejor?, ¿tú, que no sabes nada del trabajo que él ha hecho por años?. Problema de usabilidad, no oyes. El usuario no va a cambiar, eres tú el que te adaptas y automatiza sus necesidades. Si le ofreces buenas ideas que mejoren sustancialmente su productividad, él las aceptará. Nadie se niega a eso.
"Si bien es cierto que algunos cambios o novedades pueden ser una mierda, lo que no puede ser es tener esa pereza por aprender (coño, es lo que tiene la informática, y lo que mola) y adaptarse"
Pues no seas tan perezoso, adáptate. Eres un servidor. Le prestas un servicio al usuario, no le impones tus ideas por la fuerza, lo convences.
"Hace poco desarrollé una pequeña aplicación en mi trabajo. Si no lo llego a desarrollar sentado junto al administrativo que la iba a utilizar, seguro que no le hubiera sido de lejos lo útil que es ahora, por que yo no podía preveer sus necesidades"
Ese es el camino. Yo *NUNCA* hago nada si no he hablado por días enteros y a veces semanas con el usuario. Él me enseña su trabajo, sus necesidades, su manera de hacer las cosas, y yo le enseño las posibilidades que se pueden hacer con el computador, y entre los dos desarrollamos el programa. Al final, siempre sale algo estupendo, tanto desde el punto de vista del usuario, como desde el punto de vista del programa.