Factores humanos que afectan nuestro trabajo

On Wed, 9 Feb 2005 07:55:08 -0800, "Cecilia Loureiro"
wrote:

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.

Es que todas esas técnicas no ayudan para nada a comprender a los
usuarios.

No le estoy echando la culpa a los usuarios, ellos hablan su idioma,
nosotros el nuestro.

Lo más efectivo es aprender su idioma.

Antes de comenzar un proyecto hay que documentarse bien. Igual que
hacen los buenos actores antes del rodaje de una película. Hay que
aprender a ser uno de ellos.

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?).

Pues yo casi siempre me he tenido que adaptar a su forma de trabajar.

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.

Pues yo creo que cuando ocurre esto quiere decir que los
desarrolladores no están haciendo bien su trabajo.


Saludos

"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.

Pienso que la mejor forma de acercarse a lo que quiere o necesita el
usuario, es ponernos en el lugar de ellos, tener una visión más global del
negocio o proceso, ya que muchas veces quedandonos en el lado técnico
tendemos a limitar los aplicativos/sistemas.

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.

Así es, es más simple para nosotros; pero no siempre la forma como ya tienen
definidos sus procesos es lo más optimo.

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.

Es por todo lo que comentas y la falta de retroalimentación de los
usuarios/clientes, que muchas veces los sistemas pasan por n versiones o
entran en mantenimiento constante. Además no hay perder de vista que los
software deben ser seguros y eso puede entrar en conflicto con la
"flexibilidad".

Espero sus comentarios.
Gracias

Cecilia

Un factor humano que no ha sido tocado, es que la tecnologia cambia nuestro
trabajo, afectando a los que trabajamos con tecnologia.
Muchas veces, este cambio tecnologico afecta a los programadores y analistas
de sistemas, haciendolos reacios a que una nueva solucion que ellos estan
brindando a un usuario, sea la mas indicada.
Pero me refiero con esto a una primera fase o a una primera version de la
solucion brindada al usuario, hasta que los analistas/programadores, superen
el shock del cambio de tecnologia impuesto por la empresa/cliente/usuario.

Debo hacer una acotacion al comentario que has hecho Cecilia, con respecto
al idioma del usuario.
Estas pasando en alto, que al momento que el usuario se ha dado cuenta que
esta en la necesidad de usar una herramienta de software personalizada para
su trabajo, este debe empezar a concientizarse, que su modo de trabajo va a
entrar en una fase de cambio, pues no va a ser lo mismo, va a empezar a usar
una computadora o un equipo movil o algun equipo electronico programable, el
cual reemplazará o quizás entre a la cadena de procesos de su actividad
diaria.
Es por este sentido, que el idioma del usuario, necesariamente tiene que dar
un giro hacia la tecnologia, sea esta software, automatizacion o la que
fuera; y empezar a documentar, todas sus actividades, por mas minimas que
sean, que pueden tener un impacto importante en el desarrollo de su nueva
aplicacion.
De esta manera, sus actividades, pueden ser interpretadas proceduralmente
por el analista/programador y llegar a una solucion que sea la mas
satisfactoria para el usuario.

Esto es un poco utopico, pero yo lo he logrado implementar de manera
satisfactoria con usuarios muy reacios al cambio, siempre con la actitud de
ayuda y apoyo, es frustrante cuando no se encuentra eco en el otro lado, pero
la efectiva comunicacion, ayuda mucho a la obtencion de este logro.

Saludos,
Alberto

"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

On Fri, 11 Feb 2005 09:31:13 -0800, Alberto Guillen (AGO) <Alberto
Guillen (AGO)@discussions.microsoft.com> wrote:

Es por este sentido, que el idioma del usuario, necesariamente tiene que dar
un giro hacia la tecnologia, sea esta software, automatizacion o la que
fuera; y empezar a documentar, todas sus actividades, por mas minimas que
sean, que pueden tener un impacto importante en el desarrollo de su nueva
aplicacion.

Pues yo no veo ninguna relación entre la tecnología y documentar
procesos de trabajo.

Eso debería de ser totalmente independiente de la tecnología.

De esta manera, sus actividades, pueden ser interpretadas proceduralmente
por el analista/programador y llegar a una solucion que sea la mas
satisfactoria para el usuario.

Para eso no se necesita tener en cuenta la tecnología.


Saludos

Hola Cecilia

Es interesante tu planteo, yo me lo he hecho también.

Te doy mi opinión, por supuesto basada en mi experiencia.
Durante muchos años los desarrolladores creamos las aplicaciones sin
escuchar demasiado a los usuarios, el concepto era el usuario no es
informático y no sabe lo que quiere, mas o menos eso.
La otra era con conocimientos muy parciales encarar un desarrollo sin tener
un acabado conocimiento del negocio.

Resultado el ciclo de dearrollo se convierte en una conversación de sordos,
los usuarios no escuchan nustros porquesssss y nosotros no escuchamos o
menos preciamos la opinión / necesidades de los usuarios.

Hace ya unos años empece a usar, al principio con mucha dificultad, el
proceso unificado de desarrollo de software, de ahora en más UP, en lo
personal me ayudo a cambiar mi metodología de trabajo y el nivel de
conformidad de los usurios que usan mis desarrollos.
Creo que UP ataca este problema en forma directa, propone metodologías para
el relevamiento de requerimientos y aplicables aún cuando el usuario no sabe
exactamente que es lo que nos esta pidiendo.

Tal vez ya hayas caminado por UP, no lo se, te recomiendo que leas EL
PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE de Jacobson, Booch y Rumbauch.
ISBN84-7829-036-2.
Es un libro para leer lentamente, repasando y reconfirmando lo leido. (Es un
poco tedioso.) Te recomiendo el capitulo 6 Captura de requisitos: de la
visión a los requisitos.

Realmente para entender hay que leer todo el libro desde el primer capítulo.

Como complemento y te aseguro que no tiene desperdicio UML y PATRONES
segunda edición por Craig Larman. ISBN 84-205-3438-2
No te guíes por el nombre, si podés pegale una mirada.

Si conoces todo esto te pido disculpas y por supuesto soy conciente que UP
no resuelve totalmente el problema. Creo que nos hace ver a los
desarrolladores la otra cara de los usuarios y sus necesidades, ver nuestros
errores al encarar el análisis y la captura de requisitos.

Un saludo

Daniel A. Calvin
MCP



"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