Proyecto de Comportamiento Humano en el Trabajo

No dudes en comentar lo que quieras sobre el proyecto, cualquier opinión es bienvenida. Además si lo deseas puedes comentar un artículo en especial, solo dirígete a él y coméntalo.

El manual contiene seis puntos, en donde se indican las acciones a realizar y los objetivos que estas acciones poseen. Pre-estudio · Acción: Ir al lugar de trabajo del cliente para conocer su entorno y hablar con los involucrados del proceso en cuestión de manera informal, y, en lo posible, obtener los factores genéricos de la problemática (no entrando en detalles). Si no posee conocimientos sobre el área en que está envuelta la problemática, infórmese y busque asesoría sobre el tema. · Objetivo: Poder conocer previamente las características del ambiente físico y humano en el que estará envuelto en los pasos siguientes. Además tener una idea parcial de cuál es la problemática e interiorizarse con el área de trabajo del cliente. Objetivos y alcances · Acción: Se debe dejar explícitamente planteado los objetivos y alcances del proceso de toma de requerimientos, dejar claro que solo se buscar capturar los requerimientos y no plantear s

La modificación principal consiste en un cambio en el interactuar de los participantes del sistema, es decir, un cambio en la forma en que se presentan las reuniones entre los IR y clientes. Este cambio buscar mejorar el feedback, en especial cambiar el modo de abordar las reuniones por parte de los IR, ya que estos deben incentivar este cambio hacia los clientes y procurar una comunicación fluida. Existen dos posibles acciones a realizar, una es efectuar cursos o capacitaciones a los IR que le permitan desarrollar su capacidades cognoscitivas y de comunicación. Estos cursos deberán ser realizados por las empresas donde trabajen los IR, es decir, que la responsabilidad será única y exclusivamente de las empresas. Otra solución, la que propone esta investigación, es crear un “Manual de Buenas Prácticas” orientado a mejorar las capacidades cognitivas y de comunicación de los IR. Este manual pretende ser un documento abierto a cualquier IR que desee conocer como se debería abordar un

Para llevar a cabo esta etapa se debe tener presente cuál o cuáles son las modificaciones a efectuar, y por sobre todo, cuál o cuáles son los objetivos deseados al interior del sistema en estudio. La principal modificación buscada es lograr un eficiente feedback entre los ingenieros y los clientes. Si bien la elección de esta modificación se basa en una falencia detectada por todos los participantes del sistema, es labor del IR que este feedback se dé y asegurar que el cliente se involucre en el proceso TR. Además la labor del IR es interiorizarse con el área de trabajo del cliente, transformarse en un experto en el tema. Los cambios a realizar se clasificaran en estructura, procedimientos y actitudes, estos se detallan a continuación. Cambios en la estructura Los cambios en la estructura tratan de solucionar el ¿Qué cambiar o incorporar al interior del sistema en estudio?, pero afectando a las organizaciones o las tareas que estas cumplan al interior del sistema. IR N

Individualizada la situación problema, se presenta un modelo conceptual que ilustra los cambios a realizar en el proceso de TR. Como se puede apreciar en la figura , se encuentra el Sistema de Actividad Humana o HAS. Descripción El proceso se inicia cuando el sistema planificador establece la primera reunión formal o informal entre el (los) IR y su (sus) cliente(s). Una vez establecida la fecha de la primera reunión, el IR va hacia el lugar de trabajo del cliente para conocer su entorno y hablar con los involucrados del proceso en cuestión. Luego se estable el dialogo entre clientes y ingenieros de manera de dirigir al requirente de forma tal de obtener los factores genéricos de la problemática. Luego se establecen nuevas reuniones entre los IR y clientes, para establecer requerimientos más detallados, establecer posibles ambigüedades, requerimientos incompletos, discrepancias y problemas en general. La idea es tener un feedback constante para que el IR se interiorice mas en el te

Con la raíz elaborada se consigue tener una mayor claridad sobre la situación problema en base a las transformaciones con su correspondiente dominio y recorrido. “Proceso de TR en el QUE se mantiene en constante contacto el IR y cliente MEDIANTE la confección de un plan de trabajo coordinado, que contemple un recurrente feedback PARA establecer posibles ambigüedades, requerimientos incompletos, discrepancias y problemas en general, además de permitir al IR familiarizarse con el tema”

Basado en los aspectos culturales de la organización y las diversas visiones de cada uno de los grupos destacados , se definieron los siguientes sistemas sociales. Para la definición se utiliza un vector , según la definición de Vickers (1970). IR Rol Recopilador. Reúne la información que entregan los clientes y la analiza. Norma Reunir los requerimientos de los clientes y documentarlos. Valor Realizar su trabajo de forma responsable y eficiente de manera de obtener requerimientos completos y solucionar los problemas que se presenten. Clientes Rol Explica. Otorga información sobre sus actividades y sobre lo que desean. Norma Otorgar los requerimientos del sistema aportando información que ellos manejan. Valor Realizar el proceso de manera seria y responsable, entregando información explicita, clara y de calidad que ayud

De las opiniones obtenidas de las encuestas, observaciones y la charla, se seleccionan las más importantes para generar el Rich Picture, donde se ven reflejadas las opiniones que tienen un sentido común y las opiniones que generan controversia.

Nombre: Rodrigo Riquelme Profesión: Ingeniero Años de experiencia: 10 1. Identificación del problema 1.1 ¿Cuáles son los principales problemas que posee el proceso y de dónde provienen dichos problemas? Lo primero es tener la claridad de donde tienen que llamar, los usuarios necesitan saber, tener claro, cual es el proceso de requerimientos y gestión del caso. Nosotros ahora estamos cambiando el sistema justamente, estamos cambiando un sistema hecho en Visual Basic, por nosotros, estamos cambiando por un sistema que se llama ARAMDA, es un proveedor que se está certificando con las normas ITIL. El principal problema más que nada es la comunicación hacia el usuario, cómo va el caso, el usuario siempre tiene que sentirse, yo creo, atendido, porque se puede que un problema no lo puedas resolver en el instante, puede ser un problema un poquito más complejo de lo que tú crees, pero lo que tiene que tener el usuario es la visibilidad de que está haciendo considerado, está

Nombre: Arnoldo Carrilanca Profesión: Ingeniero Años de experiencia: 10 1. Identificación del problema 1.1¿Cuáles son los principales problemas que posee el proceso y de dónde provienen dichos problemas? Estas preguntas las voy a responder dentro del contexto de un proyecto que estoy gerenciando para el sector público. Este proyecto ya culminó su etapa de diseño y actualmente está en su etapa de construcción. De un total de nueve módulos se han construido cinco, de los cuales dos hay que hacer de nuevo. El problema fue que esta institución de gobierno hizo un cambio en su directiva y se dieron cuenta que lo que se estaba construyendo no se ajustaba a lo que el cliente final quería. Se procedió a solicitar un control de cambio. Este control de cambio, finalmente no fue aprobado por el cliente, porque el proyecto lleva un atraso de un año. Negociamos con el cliente y una de las cosas que resultó, es que nosotros nunca hemos logrado entender lo que ellos realmente q

Nombre: Luis Berrios Profesión: Ingeniero Años de experiencia: 1,5 1. Identificación del problema 1.1 ¿Cuáles son los principales problemas que posee el proceso y de dónde provienen dichos problemas? Uno de los problemas que hay, propios del levantamiento de requerimientos, es que si bien existe un lenguaje estándar que es para hacer este proceso, UML, el usuario, por lo general, no sabe ocuparlo y aún así, aunque el analista pueda hacer un levantamiento de requerimientos y plasmar los requerimientos funcionales y no funcionales del usuario, al llevarlo a UML a veces se olvidan cosas o hay cosas que no son claras como para redactarlas en un párrafo o en una serie de puntos que describan el sistema que va a desarrollarse. 1.2 ¿De qué forma afectan a usted y al proceso de captura de requerimientos dichos problemas? Uno de los grandes problemas, cuando se llevan los requerimientos a desarrollar el sistema, es saber si se está haciendo lo que quiere el cliente. Para ev