Factores humanos que afectan nuestro trabajo

Hola Cecilia

He leido tú comentario así como las respuestas del resto de usuarios.

Yo te voy a contar mi experiencia como responsable del area informatica de
una empresa (Mediana empresa). Yo he sido y soy el interlocutor de la
empresa con los proveedores de software (e incluso he desarrollado software
para mi empresa), y me voy a centrar en los proveedores de ERP.

Las empresas de informática creen que el usuario no sabe lo que quiere. Al
contrario, si lo sabe pero los analistas no escuchan. Y aquí radica la
diferencia entre implantación del software e implantación "REAL" del
software. El implantar software es para muchos colocar un software libre de
errores y que realiza el circuito que ellos habian pensado, a pesar de las
reticencias del usuario. Puede ser un software perfecto, pero que sea tan
complejo que el usuario no lo toque por desconocimiento, pereza o por que le
cuesta más que hacerlo como antes. Resultado: Monton de software sobre el
equipo e ingresos para la empresa que ha instalado el software.

La implantación REAL debe de tener en cuenta al usuario, y aunque el proceso
parezca más complejo que lo que debiera de ser, puede que al usuario le
resulte util y lo utilice, aunque parezca algo absurdo.

El valor del analista/implantador es ese. Ver lo que de verdad quiere el
usuario, que necesidades futuras o mejoras se pueden realizar, e intentar
implementar ambas en el software.

Como caso practico citare el siguiente:

Para realizar las expediciones, se penso que se podia crear un proceso que
asignaba el stock del almacen a los pedidos pendientes de servir utilizando
FIFO, de esa manera el usuario a la hora de realizar el albaran y cargar los
pedidos, obtenia también las cantidades y lotes a servir de forma rápida.
Este proceso bloquea el stock (es decir no se pueden realizar movimientos de
salida contra él) y que con este circuito la gente de ventas tardaria menos
tiempo en hacer los albaranes y se conseguiria un FIFO perfecto.

Pero la verdad es que el stock no sabia que para un mismo articulo podía ir
embalado de formas distintas ( Caja A a 400 y caja B a 600 y contenedor C a
1500),dependiendo del cliente al que iba. Tampoco tuvo en cuenta que el FIFO
esta bien, pero que la gente del almacen no va a ir a coger una caja de la
balda más alta si tiene otra caja al lado. EL resultado erá que habia que
estar despreparando continuamente y que la gente tenia siempre los stocks
bloqueados.

La solución más rapida y sencilla erá (y es la que yo he implementado) crear
un listado con los pedidos pendientes unido al stock(mostrandolo según el
FIFO). Este listado va al almacen y ellos preparan la mercancia y marcan de
que lote cogen. Luego van devolviendo ese listado a los que hacen los
albaranes.La cuestión erá haber escuchado a la gente y ponerse en su lugar
(incluyendo el salir a fabrica para ver como se preapara la mercancia DE
VERDAD).

Espero que este pequeño caso os haya ayudado

Un saludo

Jon Herrero

"Cecilia Loureiro" escribió en
el mensaje news:

Durante 9 años de trabajo desarrollando software he visto como la
tecnología
y nuestra forma de trabajo han cambiado. Toda esta experiencia también me
ha
servido para darme cuenta que a pesar de todo el trabajo que le ponemos
todavía se nos hace muy difícil entender a nuestros usuarios/clientes. De
nada sirve que te sepas todas las técnicas de modelaje de sistemas y todos
los lenguajes de programación y las bases de datos si al final no puedes
hacer que tu usuario te diga lo que quiere, o al menos si tu no puedes
deducir que es lo que el necesita.

No le estoy echando la culpa a los usuarios, ellos hablan su idioma,
nosotros el nuestro. Viendo en retrospectiva, siempre que me he
encontrado
con una situación difícil, por ejemplo, procesos no muy bien definidos o
gente haciendo lo que le parece sin seguir estándares, siempre he tendido
a
decirles que estandaricen sus procesos y que los documenten
(¿reingeniería?).
Solo después de cumplido eso, los desarrolladores podíamos empezar con
nuestro trabajo, ¿por qué? porque así es mas simple.

Pero no se han puesto a pensar que haciendo eso estamos, quizás, limitando
la creatividad de nuestros usuarios, creatividad para solucionar problemas
y
realizar su trabajo. En vez de ayudar, el software puede estar
restringiendo
su trabajo, solo porque los desarrolladores somos incapaces de entender la
complejidad de los seres humanos y de sus interacciones en su lugar de
trabajo. La flexibilidad de la gente y su habilidad para adaptarse
rápidamente a situaciones nuevas no puede ser seguida por la
inflexibilidad y
rigidez de un software.

Pero no todo es tan malo. Por otro lado, también me pongo a pensar, que
esa
flexibilidad y facilidad para adaptarse de nuestros usuarios también nos
ayuda. Al fin y al cabo ellos son los que usan nuestro software (cuando no
tienen otra alternativa) y se adaptan a el aun si éste no es exactamente
lo
que querían.

Espero sus comentarios.
Gracias

Cecilia

Ha sido interesante leer todos los comentarios de esta discusión.

Pero creo que se esta dejando de lado un aspecto, que así como sistemas y
tecnologías cambian a través del tiempo, los usuarios cambian en las
instituciones (con esto me refiero a la rotación de personal), por lo tanto
si centramos todo nuestro trabajo en satisfacer las necesidades y "caprichos"
del usuario, sin tener una visión general del negocio (independiente del
usuario), podemos crear un sistema cuya eficacia dependa del usuario, y si
esta persona se va, su sucesor no va poder realizar el trabajo
eficientemente, lo que conllevará a que el nuevo usuario demande cambios
radicales al sistema original.

Ahora no digo que dejemos al usuario de lado, ni que ignoremos sus opiniones
o necesidades, si no que busquemos un balance entre las exigencias del
usuario y las exigencias del negocio al realizar nuestros planteamientos.

Por ejemplo, hay situaciones donde es imprescindible que el usuario se
comprometa (invirtiendo tiempo o recursos) para alcanzar cierto objetivo
puntual en el sistema. Frecuentemente el usuario tratará de desligarse de
este compromiso delegándoselo al área de sistemas o tratará de buscar la
salida fácil (aunque no sea óptima), alegando que "no puede" (no quiere).
Como consecuencia, esto nos llevará a replantear, retrasar u omitir alguna
actividad básica durante la implementación, incrementando la probabilidad de
encontrar problemas graves o vacíos dentro del sistema en el futuro. Por
tanto, la probabilidad de fracaso del sistema en cumplir su objetivo final
(servir a la mejora de la institución) se incrementará.

Un ejemplo real de este tipo de situación, ocurrió en la universidad donde
laboro. Se realizó un sistema para la administración y registro de la
historia académica de alumnos, como requisito a la implantación se requería
la migración de la información histórica desde la mainframe y documentos
oficiales, de la migración de la mainframe se encargo el área de sistemas,
pero la responsabilidad de la migración de documentos y revisión de la
información correspondía al usuario, esta persona alego que tenía demasiadas
labores, que no podía hacerlo antes de la implantación, como consecuencia se
implantó el sistema, con el compromiso del usuario de realizar la migración
en un plazo determinado. Pasaron los meses, y este compromiso no se cumplió,
lo que provoco que el sistema genere inconsistencias en la información de
varios alumnos. El usuario alego que era responsabilidad de sistemas, aunque
todo el problema se origino por su incumplimiento en la carga de información.

Saludos
Johany

"Cecilia Loureiro" wrote:

Durante 9 años de trabajo desarrollando software he visto como la tecnología
y nuestra forma de trabajo han cambiado. Toda esta experiencia también me ha
servido para darme cuenta que a pesar de todo el trabajo que le ponemos
todavía se nos hace muy difícil entender a nuestros usuarios/clientes. De
nada sirve que te sepas todas las técnicas de modelaje de sistemas y todos
los lenguajes de programación y las bases de datos si al final no puedes
hacer que tu usuario te diga lo que quiere, o al menos si tu no puedes
deducir que es lo que el necesita.

No le estoy echando la culpa a los usuarios, ellos hablan su idioma,
nosotros el nuestro. Viendo en retrospectiva, siempre que me he encontrado
con una situación difícil, por ejemplo, procesos no muy bien definidos o
gente haciendo lo que le parece sin seguir estándares, siempre he tendido a
decirles que estandaricen sus procesos y que los documenten (¿reingeniería?).
Solo después de cumplido eso, los desarrolladores podíamos empezar con
nuestro trabajo, ¿por qué? porque así es mas simple.

Pero no se han puesto a pensar que haciendo eso estamos, quizás, limitando
la creatividad de nuestros usuarios, creatividad para solucionar problemas y
realizar su trabajo. En vez de ayudar, el software puede estar restringiendo
su trabajo, solo porque los desarrolladores somos incapaces de entender la
complejidad de los seres humanos y de sus interacciones en su lugar de
trabajo. La flexibilidad de la gente y su habilidad para adaptarse
rápidamente a situaciones nuevas no puede ser seguida por la inflexibilidad y
rigidez de un software.

Pero no todo es tan malo. Por otro lado, también me pongo a pensar, que esa
flexibilidad y facilidad para adaptarse de nuestros usuarios también nos
ayuda. Al fin y al cabo ellos son los que usan nuestro software (cuando no
tienen otra alternativa) y se adaptan a el aun si éste no es exactamente lo
que querían.

Espero sus comentarios.
Gracias

Cecilia

Llevas razón en lo que expones desde tu experiencia. Fíjate que en el mundo
de la Ingeniera de sistemas es difícil encontrar personas que reflexionen de
forma general sobre el desarrollo de software y menos que se hable de la
inconformidad de los usuarios e incapacidad del grupo de software para
identificar lo que éste necesita realmente.

Los Ingenieros que nos dedicamos en esta rama de la construcción de software
supongo que sabemos que jugamos con desventaja con respecto a otras carreras
con m s experiencia a nivel mundial, se sabe que esta carrera es aún joven y
sumémosle que para el ser humano lo nuevo -como es la tecnología, asusta y
complica la existencia. Llegar a que las personas del grupo de software den
con los requerimientos necesarios sin caer en programas caprichos, llevar
tiempo, tanto en la experiencia de los costructores de software, como tiempo
en la experiencia de los usuarios manejando muchos más programas y entre
todos empiecen a discernir por ellos mismos el por qué de los estándares en
los programas. Cuestionamientos de ambas partes en que es un requerimiento
capricho de uno que no lo es.

El que un usuario se adapte a un software capricho es peligroso, ya que
cuando se le explique las razones por las cuales se hacen programas
estandarizados se van a rehusar a utilizarlos y esto solo retrasará la
existencia de programas buenos por programas no tan buenos -que en este
momento abundan en el mercado. Tampoco creo que se limite la creatividad
del usuario al limitar un poco su imaginación.

Ing. LubyC.




"Cecilia Loureiro" escribió en
el mensaje news:

Durante 9 años de trabajo desarrollando software he visto como la

tecnología

y nuestra forma de trabajo han cambiado. Toda esta experiencia también me

ha

servido para darme cuenta que a pesar de todo el trabajo que le ponemos
todavía se nos hace muy difícil entender a nuestros usuarios/clientes. De
nada sirve que te sepas todas las técnicas de modelaje de sistemas y todos
los lenguajes de programación y las bases de datos si al final no puedes
hacer que tu usuario te diga lo que quiere, o al menos si tu no puedes
deducir que es lo que el necesita.

No le estoy echando la culpa a los usuarios, ellos hablan su idioma,
nosotros el nuestro. Viendo en retrospectiva, siempre que me he

encontrado

con una situación difícil, por ejemplo, procesos no muy bien definidos o
gente haciendo lo que le parece sin seguir estándares, siempre he tendido

a

decirles que estandaricen sus procesos y que los documenten

(¿reingeniería?).

Solo después de cumplido eso, los desarrolladores podíamos empezar con
nuestro trabajo, ¿por qué? porque así es mas simple.

Pero no se han puesto a pensar que haciendo eso estamos, quizás, limitando
la creatividad de nuestros usuarios, creatividad para solucionar problemas

y

realizar su trabajo. En vez de ayudar, el software puede estar

restringiendo

su trabajo, solo porque los desarrolladores somos incapaces de entender la
complejidad de los seres humanos y de sus interacciones en su lugar de
trabajo. La flexibilidad de la gente y su habilidad para adaptarse
rápidamente a situaciones nuevas no puede ser seguida por la

inflexibilidad y

rigidez de un software.

Pero no todo es tan malo. Por otro lado, también me pongo a pensar, que

esa

flexibilidad y facilidad para adaptarse de nuestros usuarios también nos
ayuda. Al fin y al cabo ellos son los que usan nuestro software (cuando no
tienen otra alternativa) y se adaptan a el aun si éste no es exactamente

lo

que querían.

Espero sus comentarios.
Gracias

Cecilia