Factores humanos que afectan nuestro trabajo

El tema es muy interesante...
Creo que lo primero que debemos tener en cuenta es que todos los seres
humanos somos diferentes. Si le pones un mismo problema a diferentes personas
cada una va a tener una solución distinta. Es por esto que es complicado para
los analistas de sistemas obtener esa información básica para el desarrollo
de un sistema. La mayoria de usuarios necesitan alguien que los oriente y los
ordenen. La gran mayoria realizan sus procesos de forma desordenada o de
manera no optima. Es por esto que la labor del analista de sistemas no se
basa solo en desarrollar aplicaciones si no en brindar una solución, la cual
debe estar alineada siempre con el plan estrategico de la empresa, y debe
hacerle notar a todos los departamentos que la forma de trabajo escogida
ayudará en el cumplimiento de un determinado objetivo.
Como dices, puede que en el hecho de estandarizar un procedimiento estemos
limitando la creatividad del usuario, pero esto solo se daria en una
organización que es conformista y que no realiza un plan estrategico. Las
empresas son y deben ser cambiantes, siempre estan cambiando según el
mercado, la competecia, factores internos, etc. Asi es que si la empresa
cambia los sistemas que manejan tambien deberian hacerlo.
Un sistema debe ser revisado periodicamente y adapatado según los nuevos
procedimientos, objetivos, estrategias de la empresa. Al menos ese es mi
punto de vista. Una empresa que no cambia esta destinada a fracasar.


"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

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

Es mas muchas veces uno tiene que involucrarse en las tareas del usuario
para tratar de comprenderlo mejor en muchas oportunidades no esto no es
suficiente ya que podemos llegar a conocer muy bien el negocio pero eos no
garantiza que lo que se implemente es lo que la organizacion necesita.
En algunas oportunidades uno puede dar en el clavo, es decir, que
probablemente cumpla con sus expectativas pero esto no necesariamente esta
apoyando la operacion de la empresa.
Si hablamos desde el punto de vista de procesos tal vez hayamos
automatizado el problema, ni siquiera haber llegado a un mejoramiento del
proceso en si y mucho menos a una reingenieria.
Esto obedece creo yo, no sólo al desconocimiento del marco general (desde el
punto de vista de IT) sino tambien del descocnocimiento del usuario para con
la tecnologia.
Muchas veces las necesidades de uno son tambien la de los otros, esto sucede
mucho en un corporación donde los usuarios de areas similares locales piden
informacion y solicitan desarrollos a las areas de IT entonces se produce
doble esfuerzos.
Esto se puede agrabar con la falta de comunicación en una organización es
necesario que la estrategia llege a todo nivel.

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

Hola Alfredo,
Gracias por tus comentarios. Aquí van los míos,

Estoy de acuerdo en que uno debe aprender el idioma de los usuarios. Lo malo
es que no hay metodologías o técnicas que nos ayuden a hacer eso. Hasta ahora
es solo cosa de tener sentido común y aprender a trancotes.

Cuando dije situaciones difíciles me refería a situaciones en donde es
difícil entender que lo pasa, en donde no puedes obtener los requerimientos
fácilmente y no puedes diseñar un software que tenga sentido. Adaptarse a la
forma de trabajar de los usuarios ayudaría en algo, pero no creo que sea
suficiente si esa forma de trabajar al final no la puedes traducir en código.

Creo que debe haber un punto de encuentro entre el trabajo de los usuarios y
el trabajo de los desarrolladores. Lo que quise hacer en el penúltimo párrafo
es criticar un poco a los seguidores radicales de la ingeniera de software.
Me parece que todo lo ven “reingienirable” y no toman en cuenta los factores
humanos dentro del ambiente de trabajo. El mismo nombre “ingeniería” me da
mucho que pensar. Ingeniería me suena a máquinas y no a seres humanos. **
Ojo, yo también soy ingeniera, pero haber convivido en un ambiente de trabajo
me ha hecho pensar diferente. **

Gracias otra vez.

Hola, muchas gracias por sus respuestas. Les escribo a todos juntos porque
así es menos complicado.

Alberto, estoy de acuerdo cuando dices que los usuarios también tienen que
cambiar un poco su lenguaje. No pueden esperar que el uso de la tecnología no
los afecte. La tecnología afecta tanto a desarrolladores como usuarios. Creo
que debe haber un acercamiento entre desarrolladores y usuarios, los
desarrolladores reconociendo el papel que juegan los factores sociales y los
usuarios reconociendo el papel que juegan la tecnología en sus trabajos. La
documentación de un proceso de trabajo debería considerar ambos factores.

Daniel, muchas gracias por las referencias. No, no he leído los libros. Pero
si son como dices creo que tendré que echarles una miradita. ;)
Me gustó mucho la analogía de la conversación de sordos porque representa
muchas de mis experiencias. Cada cual tirando para su lado y olvidándose de
que tienen que trabajar en equipo. Una pregunta, ¿cómo es que UP ayuda al
levantamiento de requerimientos?

Nadir, Jacky y EPG, de acuerdo con que ser 100% técnico en nuestro trabajo
no es bueno. Limita nuestra visión. Tampoco darle 100% de libertad absoluta a
los usuarios es tan bueno, porque como bien dicen, ellos no necesariamente
están haciendo un trabajo óptimo. También creo que el software debe estar
alineado con la estrategia de la empresa, pero también es cierto que son los
usuarios quienes van a tener que lidiar con él y quienes al final decidirán
su éxito o fracaso. Lo malo es que a veces los usuarios no saben ni dónde
están parados y una salida para nosotros es estudiar los procesos de negocios
objetivamente sin tomar en cuenta algún usuario en particular. Pero, pero,
pero, otra vez estaríamos cayendo en el circulo vicioso, ignorar el factor
humano en el desarrollo de software.


Gracias por sus comentarios.

Cecilia

Hola cecilia

Bueno, no es facil responder en forma escueta, de todas formas tratare de
ser breve.

UP cubre todo el ciclo de desarrollo, desde la captura de requerimiento
hasta las implementaciones, pasando por todo lo que queda en el medio.

Tené en cuenta ademas que UP esta basado en iteraciones, el ciclo se repite
varias veces. Esto se debe a que a lo largo del desarrollo aparecen detalles
nuevos o que por un problema de comprención del negocio no se pudo abordar en
una itración anterior.

Cada etapa del ciclo de desarrollo esta especificada en detalle en UP, en
cuanto la captura de requisitos esto también esta contemplado.

Las condiciones para poder realizar la captura de requisitos en forma
correcta son:

PRIMERO Y FUNDAMENTAL:
El desarrollador debe manejar el lenguaje del dominio del problema.
Este lenguaje es el que maneja en forma natural el usuario.
El usuario NO debe manejar conceptos distintos al del dominio del problema,
pues es el EXPERTO EN INFORMACIÓN sobre el mismo.

Debido a esto se invierte el problema, el usuario no tiene que comprender
términos informáticos, ahora el desarrollador tiene que comprender términos
relativos al Dominio del Negocio.

Como se sabe si el desarrollador comprendio acabadamente toda la terminología?
Bueno aca aparece el primer documento para la captura de requisitos, o que
servira de herramienta entre otras para la captura de requisitos.
El Glosario, el glosario de términos se confecciona por el desarrollador y
es corregido por el usuario.

Para algunos términos esto parecerá ridículo, para otros es fabuloso porque
gracias al glosario surgen las ambiguedades. (Que entiden el desarrollador
por PAGO ADELANTADO y a que se refiere exactamente el usuasrio cuando habla
de PAGO ADELANTADO.

SEGUNDO
Crear un modelo de Dominio
En el aparecerán las entidades que interralacionadas completarán el sistema,
este modelo estará formado por entidades, de estas entidades algunas se
convertirán en clases software y otras simplemente serán agentes externos al
sistema pero que interactuan de alguna forma.
( este moedlo es muy genérico, no es una especificación completa de las
entidades, es mas una lista de las mismas.)

TERCERO
Crear el modelo de negocio
Es aquí donde se inicia la captura de los reqrimientos, se crean los casos
de usos principales, en ellos se enuncian las precondiciones y pos
condiciones para un proceso determinado y quienes intervienen, (actores y
entidades)

Es asi como UP te ayuda a capturar requerimientos, pensa que esto sufre
intearciones, los modelos nombrados se enriquecen en cada iteración y ojo,
las iteraciones incluyen desarrollo de software y su implementación.

Los casos de uso que son el artefacto por excelancia para la captura de
requisros estan expersados en términos del negocio, es decir, en el lenguaje
natural del usuario.

El tema es muy largo y al querer resumir tengo miedo de deformar los
conceptos, pero basicamente la cosa pasa por estos puntos.

Te recomiendo que leas o consigas el primero de los dos libros que te
recomende. Esta editado en español y la traducción es de muy buena calidad.

Contesta muchas de las preguntas que te haces y te propone metodologías para
atacar esos problemas y muchos otros.

Un abrazo.
(Si necesitas que mejore o aclare algun concepto solo pidelo y te preparare
un documento con estractos del libro.)

Daniel Calvin
MCP





"Cecilia Loureiro" wrote:

Hola, muchas gracias por sus respuestas. Les escribo a todos juntos porque
así es menos complicado.

Alberto, estoy de acuerdo cuando dices que los usuarios también tienen que
cambiar un poco su lenguaje. No pueden esperar que el uso de la tecnología no
los afecte. La tecnología afecta tanto a desarrolladores como usuarios. Creo
que debe haber un acercamiento entre desarrolladores y usuarios, los
desarrolladores reconociendo el papel que juegan los factores sociales y los
usuarios reconociendo el papel que juegan la tecnología en sus trabajos. La
documentación de un proceso de trabajo debería considerar ambos factores.

Daniel, muchas gracias por las referencias. No, no he leído los libros. Pero
si son como dices creo que tendré que echarles una miradita. ;)
Me gustó mucho la analogía de la conversación de sordos porque representa
muchas de mis experiencias. Cada cual tirando para su lado y olvidándose de
que tienen que trabajar en equipo. Una pregunta, ¿cómo es que UP ayuda al
levantamiento de requerimientos?

Nadir, Jacky y EPG, de acuerdo con que ser 100% técnico en nuestro trabajo
no es bueno. Limita nuestra visión. Tampoco darle 100% de libertad absoluta a
los usuarios es tan bueno, porque como bien dicen, ellos no necesariamente
están haciendo un trabajo óptimo. También creo que el software debe estar
alineado con la estrategia de la empresa, pero también es cierto que son los
usuarios quienes van a tener que lidiar con él y quienes al final decidirán
su éxito o fracaso. Lo malo es que a veces los usuarios no saben ni dónde
están parados y una salida para nosotros es estudiar los procesos de negocios
objetivamente sin tomar en cuenta algún usuario en particular. Pero, pero,
pero, otra vez estaríamos cayendo en el circulo vicioso, ignorar el factor
humano en el desarrollo de software.


Gracias por sus comentarios.

Cecilia