Proyecto de Comportamiento Humano en el Trabajo

Bienvenido!!!

2007-12-30T13:39:00.000-08:00

Visita nuestras diferentes secciones y links para que sepas de que se trata este proyecto.

- Secciones

Encuesta (Cliente): Contiene las entrevistas realizadas a clientes.
Encuesta (IR): Contiene las entrevistas realizadas a ingenieros en requerimientos.
Entrevista (IR): Contiene las encuestas realizadas a ingenieros en requerimientos.
Informaciones: Contiene información sobre el proyecto.
Metodología: Contiene los pasos mas importantes de la metodología SSM aplicada al proyecto.

- Links

Enlaces a otros proyectos realizados sobre el tema e información complementaria.

-------------

Mas información en:

Comentarios

2007-11-08T20:28:00.000-08:00

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.

Manual de Buenas Prácticas

2007-11-05T12:46:00.001-08:00

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

· Objetivo: Permite limitar la visión que posee el cliente sobre el proceso de toma de requerimientos. De esta manera no se generan falsas expectativas por parte del cliente.

Comisión

· Acción: Sugerir al cliente que genere una comisión encargada especialmente para la toma de requerimientos, personas expertas en el tema, que conozcan las tareas y procesos a fondo. Comisión que durante las reuniones se dedique única y exclusivamente al proceso.

· Objetivo: El objetivo de esto es que haya personas que se dediquen exclusivamente al proceso de la toma de requerimientos. De esta manera se evita que los clientes no tengan buena disposición o tiempo para realizar la toma de requerimientos o que lo saquen se sus tareas habituales perdiendo tiempo (al existir la comisión deben regularizar y planear sus actividades).

Reuniones recurrentes

· Acción: Establecer reuniones periódicas con los clientes para establecer requerimientos más detallados, establecer posibles ambigüedades, requerimientos incompletos, discrepancias y problemas en general. Las reuniones se realizan cuanta veces se estime necesario, hasta que todos los involucrados estén conforme con los resultados obtenidos.

· Objetivo: No perder ningún dato o detalle del proceso o actividad del cliente. De esta manera se podrá ver qué puntos presentan acuerdos o conformidades y cuales diferencias o dificultades.

Feedback

· Acción: En cada reunión debe existir un feedback constante y fluido para interiorizarse mas en el tema y, al mismo tiempo, que el cliente conozca los avances logrados y así pueda establecer si es realmente lo que él quiere. Se debe incentivar al cliente a que participe de manera activa en el proceso, logrando un lazo de confianza con este.

· Objetivo: Este feedback permite la real comunicación entre lo involucrados, la cual es vital a la hora de transmitir conocimientos, actividades, ideas, opiniones, quejas, etc.

Diagramas

· Acción: Se debe diagramar, de manera clara, los procesos descritos por el cliente y explicárselos de forma tal que se valide lo que se cree entender de las reuniones anteriores. Estos diagramas deben ser entendibles por el cliente, sino no lo son se debe estudiar la posibilidad de modificar estos diagramas apoyándose en gráficos, cuadros, tablas, imágenes, videos y todo lo que se estime necesario.

· Objetivo: Que quede claro al cliente lo que se entiende del proceso. Se debe tener en cuenta que no todos los clientes son profesionales, que no tiene los mismos conocimientos. Por ejemplo no todos saben UML, por lo que se debe simplificar lo más posible los diagramas.

Quejas y reclamos

· Acción: Debe escuchar todo lo negativo que su cliente estime, que cuente con detalle lo que no le parece de los requerimientos tomados o algún otro problema. En ningún caso debe interrumpirlo, espere a que se desahogue y luego ofrézcale una solución o hágale saber que va a trabajar en su solución. A penas tenga la solución, llame a su cliente y resuelva el asunto pendiente. Hay que hacer sentir al usuario de que está siendo considerado, está siendo tratado y de que su problema es importante.

· Objetivo: Esto evitará que el cliente se enoje. Si intenta evadir la situación, se tendrá un cliente impaciente y que el día de mañana no tendrá la misma disposición para aportar a la toma de requerimientos. Incluso puede llevar a problemas mayores, como hablar mal de Ud. o de su empresa, lo que obviamente influirá en futuros proyectos con otros clientes (pierde el prestigio).

versión: 2.0 (20071114)

Acciones a realizar

2007-11-05T12:41:00.000-08:00

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 una reunión con sus clientes, como mejorar la comunicación con sus clientes o incluso con sus pares, mejorar sus capacidades cognoscitivas, mejorar sus habilidades y competencias.

Cambios deseables

2007-11-05T12:39:00.000-08:00

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.

No es necesario realizar un cambio estructural en el proceso de TR básicamente porque para realizar el objetivo buscado no se necesita, además un cambio en la estructura sería algo difícil de implementar considerando que nos referimos a los IR y no a las empresas donde trabajan y sus tareas. El cambio buscado no va por este sentido.

Clientes

Es recomendable, en lo posible, generar una comisión encargada especialmente para la TR, que se dedique única y exclusivamente al proceso, personas expertas en el tema, que conozcan las tareas y procesos a fondo.

Cambios en los procedimientos

Los cambios en los procedimientos determinan los pasos necesarios a seguir para generar las modificaciones a incorporar en el sistema. Por lo tanto estos cambios responden a la pregunta del ¿Cómo generar el cambio deseado?

En la primera reunión con el cliente, el IR deberá dejar explícitamente planteado los objetivos y alcances del proceso de TR, dejar claro que solo se buscar capturar los requerimientos y no plantear soluciones.

Establecer una comunicación constate con el cliente, de manera que en cada reunión se discutan los posibles errores, discrepancias y acuerdos en los requerimientos establecidos. Para esto se debe diagramar, de manera clara, los procesos descritos por el cliente y explicárselo de vuelta, de forma tal que se valide lo que se cree entender de las reuniones anteriores. Estos diagramas obviamente deben ser entendibles por el cliente, si se utiliza UML y el cliente no conoce este lenguaje se debe estudiar la posibilidad de modificar estos diagramas de modo que le cliente los entienda.

Clientes

Es relevante que el cliente solo se centre en contar que hace y como lo hace, preocuparse del “Que” desea solucionar y no del “Cómo” quieren que funcione la aplicación. Además, deberá en cada reunión, discutir los posibles errores, discrepancias y acuerdos en los requerimientos establecidos.

Cambios en las actitudes

Tendrá que incentivar al cliente a que participe de manera activa en el proceso de TR, informándolo de los progresos realizados. Deberá tener paciencia y concentración, de manera que sea un elemento de contención, ya sea para escuchar las distintas quejas que el usuario pueda tener y de prudencia respecto de promesas asociadas a soluciones. Interiorizarse con el tema o área de trabajo de sus clientes, conocerlo mejor incluso que quienes realizan las tareas, así podrá dar soluciones integrales. Además es importante abstraerse de los impulsos iníciales de tecnologizar las soluciones.

Clientes

Tendrán que comprometerse de pleno con la TR, teniendo una buena disposición y una participación activa en el proceso. Manifestar sus satisfacciones e insatisfacciones de manera explícita con respecto a lo requerimientos tomados. Además, al igual que los IR, es importante abstraerse de los impulsos iníciales de tecnologizar las soluciones.

Sistema de actividad humana

2007-11-04T22:12:00.000-08:00

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 tema y el cliente conozca los avances en la TR y pueda establecer si es realmente lo que quiere. Las reuniones se realizan cuanta veces se estime necesario.

El fin del proceso termina con la aprobación por parte del cliente, estableciendo un acuerdo en lo requerido y su conformidad.

El sistema requirente, es en otras palabras son los clientes, este debe cumplir con entregar la información pertinente para establecer los requerimientos.

El sistema recopilador, compuesto por los IR, los que está a cargo capturar o levantar los requerimientos.

El sistema planificador, compuesto por las personas encargadas del departamento o gerencia dedicada a la toma de requerimientos (este varía según la empresa, pero en general todos lo tienen), son los encargados de establecer la programación de reuniones.

Definición de raíz elaborada (Definición X Y Z)

2007-11-03T12:29:00.000-07:00

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”

Sistemas Sociales

2007-11-02T22:04:00.000-07:00

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

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 ayude a la TR.

Rich Picture

2007-11-02T15:06:00.000-07:00

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.

Entrevistado Nº3

2007-11-02T13:24:00.000-07:00

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á siendo tratado, su problema es importante, sino ahí entra el conflicto de que el usuario siente que no le están solucionando el problema, se frustra y eso te puede llevar a niveles de otros problemas.

Entrevistador: ¿Considera que los usuarios no saben expresar lo que necesitan?

Entrevistado: No, por lo general los usuarios son bastante proactivos, poseen un nivel bastante técnico, te llaman por temas muy específicos, y es muy especial, porque tienes que solucionarlo en el momento, no es un usuario que te llame por un problema a futuro, es un problema del momento, y hay que solucionarlo en el momento, además él te hace la validación también en el momento. Es muy distinto a otras empresas, en donde los llamas por un problema y te dicen que no lo pueden ver en el momento.

1.2 ¿De qué forma afectan a usted y al proceso de captura de requerimientos dichos problemas?

La comunicación estamos mejorándola con el nuevo sistema, donde en el sistema, tú dejas un caso y envía un reporte al usuario, también si no hay una respuesta o el caso no se cierra cada cierto tiempo pasa a una siguiente escala, supongamos de nivel 2 y se comunica al supervisor de informática con el supervisor del proveedor, si no me llega a mi ahí vemos que podemos hacer.

2. Definición de actores sociales

2.1 ¿Cuáles son los actores (personas/unidad) fundamentales en el funcionamiento del proceso de captura de requerimientos?

Tenemos centros de soporte, que son dos personas, dos técnicos, tenemos un nivel dos que es un experto del proveedor y también está la otra empresa.

Y como recurso vamos a tener ARAMDA, tenemos a disposición dos teléfonos para poder llamar, tenemos también controles remotos, acceso a control remoto, y ahora estamos implantando un procedimiento que si no se puede solucionar el problema por teléfono, o sea, la primera opción es tratar de que el usuario resuelva el problema para que el aprenda, con la experiencia que tiene él, aprenda a hacerlo de nuevo. El segundo nivel es tomar la máquina vía remota, y si ya no se puede esto, va a partir una persona de nuestro proveedor hacia la sucursal para solucionar el problema.

2.2 ¿Quién o Quiénes regulan el proceso de captura de requerimientos y su actividad?

Está Erasmo Fuentes que es nuestro IT manager, él es el que está encargado de contactar al proveedor. Tenemos por parte de nosotros, a Erasmo que es el inspector de contrato y también tenemos por parte del proveedor, a Pamela, que es también nuestra asesora.

2.3 ¿Quién o quiénes son sus clientes?

Todos los usuarios, tengo usuarios en Chile, también tengo otros clientes, que ya son corporativos, que son ITC que son nuestra corporación de IT y esos son los principales clientes.

3. Rich Picture

3.1 ¿Cree que el proceso es burocrático o expedito?

Yo pienso que el proceso que estamos implantando se ve bastante expedito, por lo menos en el papel se ve bien, vamos a partir la próxima semana.

Entrevistador: ¿Y lo que estaban ocupando anteriormente?

Entrevistado: Lo anterior era bastante malo, no había comunicación con el usuario, entonces cuando explotaba la situación era cuando el usuario o el jefe del usuario me llamaba a mí y me decía “oye Rodrigo está pasando esto…” y ahí tenía que tomar medias al respecto.

3.2 ¿Cómo es la relación entre las personas con las que usted tiene comunicación directa en el trabajo?

Buena, yo me llevo bastante bien con todo el mundo.

Entrevistador: ¿Cree que es fundamental una buena comunicación?

Entrevistado: Sí, es fundamental una buena comunicación y hacerlos sentir que tú trabajas para ellos, primero eres persona, segundo trabajas para darles solución a ellos, no para complicarles más la vida, o sea, de hecho también hay que hacerlos entender de que hay normas, tú no les quitas software por ejemplo, los restringes, y no es porque quieras hacerlo sino porque hay normas corporativas y también lo que hacen ellos es súper purgador, y como trabajamos en una red afecta otro usuario.

Entrevistador: En su percepción, ¿Ud. cree que es un buen líder?

Entrevistado: Yo creo que sí.

Entrevistador: ¿Y cuál es la clave para ser un buen líder?

Entrevistado: Trabajar en equipo. Es un día a día, porque es tratar de darle confianza a la gente, y que ellos confíen en ti. No pasándose los cánones de jerarquía, pero sí que ellos tengan la confianza de decirte, “estoy molesto”…, “tengo problemas con esto”…

3.3 ¿Realiza labores no asociadas con el trabajo propio del proceso de captura de requerimientos?

Si, bueno, mi función acá en ALSTOM es IT manager y IS manager, yo tengo que ver todo lo que es IT (Information Technology) y todo lo que es IS (Information Solution). Tengo que ver desde la compra de hardware, mantención del hardware y prestación de redes. Y la captar la implantación de los sistemas de gestión.

Entrevistador: ¿Esto afecta en algún grado el papel que Ud. desempeña?

Entrevistado: Es que son muchas cosas a la vez. Lo bonito es que ves todo el proceso, tú sabes que si vas a tener un 20 o 30 de usuarios más, vas a estar en el área internacional, vas a ser más grande, etc.

3.4 ¿Existen problemas que tengan que ver con contradicciones, poca claridad en los requerimientos o desconocimiento de los mismos?

Generalmente, cuando ellos hacen algún desastre, no falta el usuario que es “inquieto”, entonces…, normalmente está todo restringido, pero siempre hay alguna manera de vulnerar el sistema o hay una página nueva. Cuando hay un problema y ellos saben que el problema lo causaron ellos, es ahí donde aparecen las contradicciones y la experiencia de nuestros técnicos.

4. Sistemas sociales y políticos

4.1 ¿Cuál es su rol dentro del proceso?

Controlar. Comunicar y controlar.

4.2 ¿Qué es lo que debe resaltarse positivamente del servicio que usted entrega?

Tratamos de que el usuario tenga sus recursos la mayor cantidad de tiempo disponible. Pensar que un usuario puede estar media hora sin PC, eso es inaceptable.

4.3 ¿Se rige su trabajo particular por algún reglamento externo o interno? ¿Cuál y dónde se encuentra?

Nosotros tenemos normas corporativas que provienen de ITC y esto se ubica en Francia. Hay una jerarquía, está ITC France, y después se divide por regiones, América, Portugal, España, Norteamérica y Asia. Nosotros dependemos jerárquicamente de Brasil.

Entrevistador: En el caso de que exista algún problema, ¿Ud. aplica alguna estrategia?

Entrevistado: En un momento de crisis hay que tomar la mejor decisión, y esa decisión la tomo yo. Pero depende del problema, por ejemplo, en general en los problemas hay que tratar de realizar el procedimiento normal.

5. CATWOE, HAS

5.1 ¿Cuáles serían las mejoras que realizaría para mejorar el funcionamiento del proceso? y ¿Por qué éstas no se han realizado?

Estamos en un proceso de mejoras. ¿Por qué no se habían realizado?, porque teníamos un contrato con un antiguo proveedor, del cual no nos podíamos deshacer. No era un problemas de recursos o de no querer arreglar la situación, si no que estábamos restringidos porque no nos podíamos cambiar de proveedor.

5.2 ¿Quién o quienes poseen la atribución de modificar la operatividad del proceso de captura de requerimientos si lo desean?

Como estoy a cargo, yo podría cambiar el proceso si no me gusta, pero generalmente es un equipo de trabajo, entonces en el equipo de trabajo se toma la decisión. No se trabaja con eso del “yo impongo”. Hay un estudio del porqué lo vamos a cambiar, eso lo va diciendo la experiencia

Para ver la entrevista original aquí

Entrevistado Nº2

2007-11-02T13:17:00.000-07:00

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 quieren. Ellos también asumen su responsabilidad por el cambio en su directiva. Pero, básicamente, se determino que nuestros analistas no pudieron extraer lo que ellos querían.

1.2 ¿De qué forma afectan a usted y al proceso de captura de requerimientos dichos problemas?

A nosotros nos afecta, porque esta empresa se maneja con rentabilidades de un cuarenta a un cuarenta y cinco por ciento sobre el precio de venta. Eso significa que de diez pesos que nosotros vendemos, cinco son para cubrir costos y cinco, para cubrir rentabilidad y riesgos asociados. Como sabemos que todos estos proyectos de software se demoran, pues no existe una buena comunicación entre los analistas y el cliente, asumimos que nuestra rentabilidad, finalmente, es de un veinte por ciento. En el caso del proyecto que estoy mencionando, la rentabilidad va en cero. Es más, ya está resultando negativa.

También nos afecta en términos de confianza. El cliente pierde la confianza y cuando esto sucede, no está dispuesto a negociar y es por esto que no quisieron aceptar nuestros controles de cambio sobre esos dos módulos que ya estaban construidos. Esto no obligó a nosotros como empresa a asumir esta pérdida de confianza y aceptar el control de cambio sin un pago de por medio, ya que lo que nos conviene es mantener la imagen.

2. Definición de actores sociales

2.1 ¿Cuáles son los actores (personas/unidad) fundamentales en el funcionamiento del proceso de captura de requerimientos?

Este proyecto tiene un gerente de tecnologías de información, por parte del cliente, quien podría llamarse el dueño del proceso. Está el sponsor, quién es el cliente final, el que recibe el sistema, el que lo va a usar. Están los clientes finales de este sponsor, que son los usuarios finales del sistema. Está el equipo de proyecto de este sistema, que está compuesto cuatro analistas, seis programadores, cuatro analistas de proceso, de levantamiento de requerimientos, seis programadores especialistas en .NET, de varias universidades. Tenemos, también, un jefe de proyecto, ejerciendo por primera vez el cargo, por lo tanto existe un factor de riesgo. Este proyecto ha tenido un cambio de jefatura varias veces. Yo debo ser el cuarto gerente que ha pasado por la jefatura de este proyecto. Por lo tanto a mi me toca terminarlo. Yo soy como un -¿como un salvavidas?-, no como un salvavidas, porque sería catalogarse como un superhombre. Un superhombre en un proyecto de tecnología, donde se involucra a varias personas, no existe. Esto es trabajo en equipo. Esto significa que se deben fijar normas y objetivos claros y proveer al jefe de proyecto de todo lo que necesita.

2.2 ¿Quién o Quiénes regulan el proceso de captura de requerimientos y su actividad?

Acá se plantean varios procesos. En términos del proceso de desarrollo de software, nosotros estamos trabajando bajo normas CMMI y CMM2. Hay testing, hay pruebas funcionales y unitarias, hay pruebas de negocios. Hay gente que está especializada en estos temas y son quienes los van resolviendo. Por lo tanto, en cada etapa del proceso, necesitamos entregables. Ahora, uno de los problemas que tiene este proyecto es que estos entregables existen, pero nunca fueron formalizados, producto de malas gestiones anteriores a las mías. Yo en este proyecto, tuve que involucrar a gente de QA y a gente de una oficina de PMO con el fin de aplicar buenas prácticas en la gestión de proyectos.

Tenemos otro proceso, que es la negociación con el cliente. Yo soy el responsable de ello. Discutir todo los temas económicos, cualquier cambio que involucre el poner más gente, sacar gente, etc. Es un proceso de negociación constante.

También tenemos un proceso administrativo. Hay problemas contractuales que tenemos que ir regulando en un proyecto que lleva de atraso, un año, está el problema de vigencia. Hay multas asociadas.

Este proceso administrativo lo llevo junto a la gente de PMO, que es gente que básicamente se preocupa de ver todo el tema contractual, el tema logístico, etc.

Y hay un proceso de gestión de recursos humanos, que es parte de las buenas prácticas de CMMI, cuyo fin es discutir la sobrecarga que tendrá el personal y que todo esto se vea compensado.

2.3 ¿Quién o quiénes son sus clientes?

En este caso es una empresa del sector público. Mi finalidad es terminar este proyecto que no se ha terminado en un año, finalizarlo en tres meses. Para mí, el cliente final es todo el sector público.

3. Rich Picture

3.1 ¿Cree que el proceso es burocrático o expedito?

En mi caso, yo soy muy apegado a las buenas prácticas de CMMI, pero me gusta trabajar rápidamente, entonces cuando veo “cuellos de botella”, hago todas las gestiones para que sea rápido. O sea, por parte de nosotros existen sistemas de gestión, sistemas de control y por parte del cliente también, porque es el gobierno. Pero el cliente es muy burocrático, ya que hacer cambios de contrato y anexos de contrato es muy engorroso, y por parte nuestra es engorroso, porque estamos recién aprendiendo a usar estos sistemas. Hoy día podríamos catalogar como burocráticos los sistemas, pero en mi caso, como tengo bastantes años de experiencia, trato de acelerar el proceso.

Entrevistador: ¿Cómo soluciona estos “cuellos de botella” que se producen?

Entrevistado: Generalmente lo que hago es tratar de identificar las fallas y su causa, en un proceso normal a veces consiste en reclutar un nuevo profesional, por ejemplo un programador, proceso que puede durar 2 meses, desde que nos ponemos en contacto, realizar la entrevista, buscar la persona idónea, etc., al final yo elijo a esta persona, pero luego viene el proceso de reclutamiento por parte de Recursos Humanos, los que realizan entrevistas psicológicas y las evaluaciones necesarias, y como estos procesos se están recién implementando en nuestra empresa, lo que yo hago hoy, es adelantarme, hablo con Recursos Humanos para facilitar la entrada del nuevo profesional, informándome bien como es el proceso.

Entrevistador: ¿Esta estrategia que aplica se debe a la experiencia?

Entrevistado: A la experiencia básicamente, he tenido la suerte de gerenciar proyectos con presupuestos anuales de 4 millones de dólares, y para manejar esas cifras te tienen que haber pasado muchas cosas. Me ha pasado de todo en los proyectos.

Entrevistador: ¿Para planificar los proyectos Ud. establece un tiempo determinado, es decir, ha estandarizado el tiempo necesario para finalizar el proyecto?

Entrevistado: Sí, como he participado en varios puestos en el rubro de informática, uno de los puestos que ocupé fue el de Gerente de Preventas, quien es el responsable de preparar la oferta que va a salir al mercado, crear la propuesta, estimar plazos, roles, recursos involucrados, etc. Y eso entregárselo al Gerente Comercial. Hoy día yo cumplo el rol de Gerente Comercial, como ves he estado en toda la cadena productiva. Empecé en el área tecnológica y ahora estoy en el último eslabón de la cadena de valor.

Nosotros tenemos planillas de cálculo para evaluar proyectos, y estas planillas han sido elaboradas principalmente con Juicio Experto, inicialmente ocupábamos Puntos de Función, pero hoy día no se ocupa porque los Ingenieros no vienen especializados en el tema.

3.2 ¿Cómo es la relación entre las personas con las que usted tiene comunicación directa en el trabajo?

Es bastante buena, porque como te comenté he hecho cuatro Magíster, dos de los cuales son del área de ciencias políticas y sector público, los otros dos del área tecnológica, pero me he titulado de tres. El éxito de los proyectos se basa en la comunicación, y para tener buena comunicación hay que ser cercano a las personas, hay que saber ponerse en su lugar y darse el tiempo para hacer una llamada telefónica, saber como están, y cuando el equipo es un equipo cercano aprovechaba de almorzar con ellos, mantenía reuniones diarias, reuniones semanales para hacer un seguimiento del rendimiento de la semana, me daba el tiempo de escuchar a las personas, escuchar sus problemas, etc. Mantengo una comunicación muy abierta. Con los jefes de proyecto la comunicación es más profesional, yo les tengo que exigir a ellos y ellos obviamente me tienen que pedir cosas, para que ellos puedan cumplir su misión.

Entrevistador: ¿Ud. cree que la clave es tener buenas relaciones con el personal?

Entrevistado: Sí, efectivamente, el éxito hoy en día de todo proceso está en mantener buenas relaciones. Todo lo que esté relacionado con la inteligencia emocional, todo lo que es “soft” de lo que se aplica muy poco en las universidades. Dentro del mundo de los informáticos, no solo trabajan informáticos, sino que también hay gente de diversas especialidades, Ingenieros Agrónomos, Contadores Auditores, Gerentes de Proyectos, Gerentes de Áreas de empresas tecnológicas. Mi primer jefe, quien fue mi guía, tenía el título de Técnico Programador estudió en un colegio y hoy día trabaja en un grupo empresarial, ha crecido mucho. Y su éxito se basa en tener muy buena relación con el personal, hacia arriba, hacia abajo y hacia los lados.

3.3 ¿Realiza labores no asociadas con el trabajo propio del proceso de captura de requerimientos?

Sí. Veo oportunidades de negocios, veo temas más comerciales, hoy día tuve dos reuniones para concretar dos nuevos proyectos, me toca dirigir, armar los grupos de trabajo para atacar estas oportunidades de negocios; la idea aquí no es seguir un proyecto, si no que seguir un proceso comercial, cuya función es principalmente estimar costos, estimar la viabilidad de la ejecución del proyecto, ver como estamos posicionados frente al cliente para asegurarnos si nos conviene o no presentarnos, si hay que realizar algo de marketing, alguna promoción, auspiciar algún evento, etc.

3.4 ¿Existen problemas que tengan que ver con contradicciones, poca claridad en los requerimientos o desconocimiento de los mismos?

Sí, principalmente este problema se da, volviendo al proyecto que comentábamos al principio del sector público, porque el cliente no tiene claro lo que quiere y por esto lo transmite muy mal al analista, y como el analista generalmente no tiene mucha experiencia en el negocio, el resultado del análisis de requerimientos no es lo que espera el cliente.

4. Sistemas sociales y políticos

4.1 ¿Cuál es su rol dentro del proceso?

El rol que cumplo es Gerencial.

4.2 ¿Qué es lo que debe resaltarse positivamente del servicio que usted entrega?

Particularmente, lo que resalto es que soy bastante proactivo, gestiono muy bien los riesgos, me trato de adelantar a las situaciones, pienso con 2 o tres meses de anticipación. En el equipo de proyecto con el cual estoy involucrado, estoy pensando con dos o tres semanas de anticipación, porque los plazos no nos dan, voy atacando los riesgos, lo que se podría decir que es la clave del éxito. Detectar, analizar, evaluar los riesgos e inmediatamente comunicárselo al cliente, para que en conjunto los resolvamos.

¿Esta detección la realiza en base a la experiencia o de acuerdo a los estudios que Ud. ha realizado?

Bueno, aparte de los Magíster, soy relator de CMMI y soy apegado a éstos estándares, he gerenciado el área de calidad bajo las normas CMM2, y estoy en proceso de certificación de normas ITIL; todo eso sumado, te entrega una serie de cimientos, para mí es una forma muy natural de detectar los problemas y llegar a la causa inmediatamente, para proponer rápidamente soluciones. Es ahí donde juega la experiencia.

4.3 ¿Se rige su trabajo particular por algún reglamento externo o interno? ¿Cuál y dónde se encuentra?

Básicamente, apegarse a las buenas prácticas, no es necesario tener un MBA para saber que hay instituciones que se han dedicado a normar e indicar que es lo que se tiene que hacer en un proyecto, que no es ninguna novedad, es igual a las ISO 9001, no inventan nada. Para cumplir las expectativas del cliente hay que seguir una serie de buenas prácticas. Aparte de eso, hay que tener habilidades directivas, que si yo siento que los ingenieros nuevos no las tienen, y esas habilidades directivas, están muy relacionadas con lo que yo te comentaba, a tener buenas relaciones en el trabajo, es decir, ser un componente más del equipo, que los invita a comer algo y les da la oportunidad contar sus temas, cuando la gente tiene problemas entenderlos, y cuando hay que jugar un rol duro y drástico, no dudar en tomar las acciones necesarias, sobre todo si uno ya ha rayado la cancha.

5. CATWOE, HAS

5.1 ¿Cuáles serían las mejoras que realizaría para mejorar el funcionamiento del proceso? y ¿Por qué éstas no se han realizado?

Hasta ahora, las mejoras del proyecto han sido dar un enfoque más estratégico, no es una visión táctica la que he aplicado, el proyecto lo he visto en tres dimensiones, una, el proyecto tecnológico en sí, en donde existe una fase de análisis que hay que realizar de nuevo, que fueron nuestros controles de cambios, y otra fase en que hay que terminar de programar lo que no se ha programado, para eso he puesto a un jefe de un proyecto antiguo, que acaba de llegar de una reunión de donde lo confirman en su puesto, y él va a tener la visión conceptual, va a ser el jefe de proyecto, así mismo he designado a otro jefe de proyecto, cuya función velar por el tema operativo, el día a día, los temas administrativos, he creado una pequeña oficina de proyectos para ver todos los temas administrativos y aplicación de las buenas prácticas. Desde el punto de vista de Recursos Humanos, me he preocupado de conocer todas las falencias, ya he hecho el levantamiento de carencias, y estoy canalizando que sean resueltas, por quien corresponda que tienen que ser resueltas, no tomo decisiones yo. Desde el punto de vista gestional, las expectativas del cliente o velar por el proyecto en si, por el proceso completo e involucrado a la alta gerencia en este proyecto en particular, porque así estamos todos preocupados del proyecto, y no que pasen 6 meses y nos enteremos nuevamente que estamos atrasados.

5.2 ¿Quién o quienes poseen la atribución de modificar la operatividad del proceso de captura de requerimientos si lo desean?

En este caso en particular, desde el punto de vista de la ejecución proyecto, yo puedo hacer modificaciones de toda índole, yo soy el responsable final y yo reporto al Director Regional de toda Sudamérica, y también reporto a España, pero yo reporto resultados, no reporto problemas buscando soluciones; y por parte del cliente, al Director de TI y al usuario, que también tiene un cargo gerencial.

Para ver la entrevista original aquí

Entrevistado Nº1

2007-11-02T12:54:00.000-07:00

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 evitar eso, se desarrollan prototipos funcionales y se muestran antes de mostrar la implementación al final. Si no que se muestran estos prototipos funcionales para saber con anticipación si se está haciendo lo que el cliente quiere, o no.

2. Definición de actores sociales

2.1 ¿Cuáles son los actores (personas/unidad) fundamentales en el funcionamiento del proceso de captura de requerimientos?

El director de orquesta del proceso es el arquitecto de diseño o de dominio, quien es la persona que define los procesos para el levantamiento de requerimientos y después llevar esos requerimientos al equipo de desarrollo para plasmarlo en el sistema que se quiere desarrollar. Por otro lado el tiene que estar monitoreando cómo los analistas de negocios están interviniendo con los usuarios y si el levantamiento de requerimientos es el adecuado o no.

Los otros actores, los analistas de negocios, son las personas encargadas de interactuar con el cliente para recabar cuales son los aspectos que éste espera que contemple el sistema. Esto tiene que ver con la funcionalidad y lo que espera el cliente.

Por otro lado están los analistas funcionales, que son los que, entre comillas, dominan el módulo de la aplicación y que son los que interactúan con el desarrollador, para que el desarrollador, en vez de ir con el cliente, interactúe con ese analista para saber qué es lo que necesita el cliente.

2.2 ¿Quién o Quiénes regulan el proceso de captura de requerimientos y su actividad?

Como te decía en el punto anterior, el que regula realmente el proceso de levantamiento de requerimientos es el arquitecto de dominio o el arquitecto general del proyecto. No obstante, también hay un ente que regula el proyecto, que sería el jefe de proyecto. Y si el proyecto es lo suficientemente grande en tiempo y dinero, incluso existe hasta un gerente de proyecto. No obstante, cuando existe este gerente, éste no regula lo que es el proceso de levantamiento de requerimientos. Pero el jefe de proyectos sí lo puede hacer, ya que él es el que se encarga de revisar a nivel macro tanto lo que es el levantamiento de requerimientos, como el proceso de desarrollo y los procesos posteriores como es soporte o el paso del sistema a producción.

2.3 ¿Quién o quiénes son sus clientes?

El trabajo anterior donde estaba yo, era ING. Ese era un caso particular en el desarrollo de software, pues el cliente era una persona miembro de ING, que se le llama sponsor. El sponsor es una persona que solicita una cantidad de dinero para desarrollar sistemas informáticos, para que funcionen de mejor forma o para apoyar procesos nuevos dentro de la compañía. Ese es un caso particular. Pero por lo general, los clientes son empresas o personas naturales externas. En este último caso, en mi trabajo, nuestros clientes son empresas mineras y petroleras en general.

3. Rich Picture

3.1 ¿Cree que el proceso es burocrático o expedito?

Mientras más grande es la empresa de desarrollo de software, siempre es más burocrático. Por ejemplo en ING, como estaban con el modelo CMMI, estaba todo demasiado definido y estructurado. Por ejemplo, desde que tu terminas de producir un cierto componente o módulo del sistema hasta que los analistas de calidad, que son los QA (el analista de calidad es el que mediante una serie de pruebas revisa si lo que tu produjiste es lo que quería el cliente o no). Bueno, la iteración entre que tú desarrollas y pasas a QA, que es el ambiente donde se hacen las pruebas funcionales a tu sistema, a veces se hacía muy tedioso. Podían estar desde una semana hasta un mes.

Por otro lado, desde que tú tienes una duda como desarrollador, para pasársela al analista funcional y que este a su vez se la transmitiera el cliente y que retornara la respuesta, podía demorar hasta dos semanas, dentro de mi experiencia, por eso a veces es muy tedioso. Mientras que en empresas chicas, el desarrollador puede ser el mismo analista funcional e ir a preguntar directamente al cliente. El problema es que no hay una persona que se abstraiga de lo que es el desarrollo y otra del levantamiento de requerimientos.

3.2 ¿Cómo es la relación entre las personas con las que usted tiene comunicación directa en el trabajo?

Yo era analista de sistema y desarrollador. A nosotros nos llegaban los requerimientos a través del analista funcional, que era el encargado de desarrollar el caso de uso, para que tú lo desarrollaras. Entonces mi relación se basaba entre mi team líder, que es la persona que manejaba el equipo de desarrollo, y el analista funcional. Una vez al mes se hacían reuniones con el analista de planificación, que era la persona que básicamente se encargaba del cumplimiento de las cartas Gantt y cada tres meses, con el jefe de proyecto que era donde se ponían todas las cartas sobre la mesa y se comentaban los problemas que habían ocurrido en el pasado.

3.3 ¿Realiza labores no asociadas con el trabajo propio del proceso de captura de requerimientos?

Te voy a nombrar los roles que tuve en mi antiguo cargo:

Uno de ellos era analista de impacto, que cuando llegaban los requerimientos del cliente, en caso de realizar soporte a una aplicación o modificación a una aplicación, tenias que ver cómo iba a impactar lo que estaba pidiendo el cliente en lo que ya había hecho. Entonces tú tenías que ver en los modelos de datos, el código de las aplicaciones hechas, y ver si lo que estaba pidiendo era posible o no de hacerlo y cuanto iba a demorar. Entonces ahí también venia una especie de planificación donde tu tenias que dar una estimación de cuanto iba a demorar. Después, venía un tiempo de desarrollo y un tiempo de testing, que si bien ya había un equipo encargado de hacer testing, el equipo de QA, nosotros también hacíamos pruebas funcionales para tratar reducir los tiempos de iteración entre nosotros y el equipo de QA. Pero básicamente los roles que tenía siempre estaban dentro de mis funciones.

3.4 ¿Existen problemas que tengan que ver con contradicciones, poca claridad en los requerimientos o desconocimiento de los mismos?

Te voy a decir un caso bien puntual. El problema que hay ahora con las empresas informáticas es que como muchas están trabajando con recursos out sourcing, por ejemplo, si bien la persona de ese proyecto de ING, era sponsor de ese proyecto y era gerente del área comercial. Él debería saber todo lo que eran las condiciones de negocio o las reglas de negocio, por ejemplo cuando dar crédito a una persona. Pero como ella, supongo yo que no sabía, delegaba toda esa responsabilidad de sabiduría o conocimiento a personas externas que tampoco lo sabían. Entonces eso hacía que cuando llegaban los requerimientos al analista funcional, estos eran poco claros y aún así como algo natural, quizás, cuando se pasan las cosas de una persona a otra, se va perdiendo información.

4. Sistemas sociales y políticos

4.1 ¿Cuál es su rol dentro del proceso?

Se respondió en la pregunta N° 3.3

4.2 ¿Qué es lo que debe resaltarse positivamente del servicio que usted entrega?

Si bien, en ING había demasiada burocracia. La misma burocracia permitía ordenar el trabajo, otorgar responsabilidades cosa de que si una persona o proyecto “X” tenía alguna disfunción, tú ya sabías a quien recurrir. O si tenías algún problema de cualquier índole, estaba todo bien documentado, entonces tú ya sabes quién era el responsable y habían los mecanismos necesarios para reportar los errores o saber escalar y a quién escalar si es que esa persona no podía responder por cualquier motivo.

4.3 ¿Se rige su trabajo particular por algún reglamento externo o interno? ¿Cuál y dónde se encuentra?

En el caso de ING, el reglamento lo daba directamente la casa matriz, que reside en estados unidos. Son las personas que envían todo lo que son los procedimientos básicos de la empresa y en caso de nosotros como informáticos, el departamento de arquitectura de ING en estados unidos, son los que envían los documentos a ING Chile para normar los roles y funciones de cada persona y acá en Chile lo que hace el arquitecto es velar por que esas normas se cumplan.

5. CATWOE, HAS

5.1 ¿Cuáles serían las mejoras que realizaría para mejorar el funcionamiento del proceso? y ¿Por qué éstas no se han realizado?

Yo creo que a veces, como en ING se estaba trabajando directamente con un cliente que está dentro de la empresa, más que saltar como católicamente que yo tenía que transmitirle a una persona y esa a otra y así sucesivamente, podría haber...

Entrevistador: ¿Reuniones grupales?

Entrevistado: Claro, reuniones grupales o la posibilidad de consultar directamente a esa persona, porque son cosas tan pequeñas que te las pueden responder con una llamada telefónica o un email, pero que por la norma de la empresa, en este caso el modelo CMMI a veces no se puede, pues está contradiciendo a lo que te dice el modelo o la especificación de los roles.

5.2 ¿Quién o quienes poseen la atribución de modificar la operatividad del proceso de captura de requerimientos si lo desean?

En caso de ING, arquitectura, porque el jefe de proyecto no puede violar los procedimientos o políticas de una empresa. Pero el arquitecto sí lo puede hacer, o sea, más que violarlo puede modificar el reglamento en forma excepcional para un proyecto si es requerido, pero ni el team líder ni el jefe de proyecto lo pueden hacer.

Para ver la entrevista original aquí

Encuestado Nº5 (Cliente)

2007-11-01T13:06:00.000-07:00

· Nombre: Viviana Durán
· Profesión: Periodista

a) ¿Cuál es el principal problema que ve usted en los ingenieros a la hora de tomar los requerimientos?
El problema que veo es que algunos ingenieros es que no se saben expresar bien, no establecen una comunicación fluida. A pesar de que el problema a solucionar es nuestro y así el interés que tenemos en este, creo que los ingenieros deberían mostrar ese mismo interés en resolver el problema, más que mal para eso pagamos. Ese es el principal problema, una comunicación no fluida que no permite aclarar puntos que creemos importantes o que ellos creen importante, ya que la solución va por un trabajo en equipo, yo soy experta en mi área y ellos en la suya, así ambos nos complementamos.

b) ¿Cuál es su actitud frente al ingeniero cuando se presentan problemas?
Trato de que entren en confianza y hablen, que se establezca la comunicación que se necesita, que yo sea la entrevistada y ellos los periodistas ya que ellos deben tomar mis requerimientos y yo no puedo adivinar lo que les interesa saber y que no.

Encuestado Nº4 (Cliente)

2007-11-01T13:04:00.000-07:00

· Nombre: Claudia Leiva
· Profesión: Secretaria

a) ¿Cuál es el principal problema que ve usted en los ingenieros a la hora de tomar los requerimientos?
A veces cuando presentan avances de los requerimientos no les entiendo, utilizan dibujos que son confusos. Digo “a veces” porque no siempre no entregan avances, esa es otra razón por la que tenemos problemas, bueno en realidad yo no tengo problemas porque me da lo mismo que entreguen avances, sino que le problema lo tiene mi jefe, ya que discute que no sabe en qué va el proyecto.

b) ¿Cuál es su actitud frente al ingeniero cuando se presentan problemas?
No sé, creo que trato de entender lo que me quieren decir o si lo que me están diciendo es lo que realmente yo dije o lo que yo manejo.

Encuestado Nº3 (Cliente)

2007-10-18T08:16:00.000-07:00

· Nombre: Claudia Neira
· Profesión: Profesora

a) ¿Cuál es el principal problema que ve usted en los ingenieros a la hora de tomar los requerimientos?
No me explican los que el programa va a hacer, siendo que nos interesa su funcionalidad para ver si nos servirá o no.

b) ¿Cuál es su actitud frente al ingeniero cuando se presentan problemas?
Trato de que me entienda lo que quiero (en realidad lo que queremos como colegio).

Encuestado Nº2 (Cliente)

2007-10-18T08:15:00.000-07:00

· Nombre: Elena Cerda
· Profesión: Secretaria

a) ¿Cuál es el principal problema que ve usted en los ingenieros a la hora de tomar los requerimientos?
A veces no tienen paciencia para realizar la toma de requerimientos y mas encima me imponen un modo de trabajo o lo cambian, no adecuándose al que tengo, yo creo que es porque no me entienden por lo que es más fácil que lo cambien.

b) ¿Cuál es su actitud frente al ingeniero cuando se presentan problemas?
Al final me convencen que lo que me plantean está bien, o más bien dejo que me convencía para que me dejen tranquila y no me quiten más tiempo.

Encuestado Nº1 (Cliente)

2007-10-18T08:12:00.000-07:00

· Nombre: Alejandra Durán
· Profesión: Contadora Auditora

a) ¿Cuál es el principal problema que ve usted en los ingenieros a la hora de tomar los requerimientos?
Uno de los problemas es que a veces los plazos establecidos no se cumplen. Además muchas veces me sacan de mis tareas habituales perdiendo tiempo valioso, creen que no tengo trabajo que hacer. También se complican mucho si cambio un requerimiento, siendo que a veces la culpa no es de nosotros sino que no entendieron lo que realmente queríamos, ya que a veces no manejan algunos términos.

b) ¿Cuál es su actitud frente al ingeniero cuando se presentan problemas?
Habitualmente tenemos buena disposición. Tratamos de que nos entiendan lo que queremos, pero hay veces que perdemos la paciencia.

Encuestado Nº3 (IR)

2007-10-18T08:05:00.000-07:00

· Nombre: Mauricio Escobar Allende
· Profesión: Productor en Sistemas Multimedia e Internet
· Empresa donde trabaja: CEPAL
· Años de experiencia: 3

a) ¿Existe un esquema o norma para la toma de requerimientos? Si la respuesta es afirmativa, ¿Se siguen estas normas en la práctica?
Sí existe una norma que rige cómo se especifican los requerimientos. Habitualmente esta norma se sigue, pero dependerá del tipo de proyecto en que se esté trabajando, pero básicamente el esquema es el mismo y en ocasiones sufre modificaciones que deben ser debidamente justificadas.

b) ¿Cuál es el rol o actividad que tiene usted en el proceso de toma de requerimientos?
Mi rol es conocer la actividad del cliente y que es lo que desea resolver con la aplicación. Me dedico a la captura de requerimientos cuando los sistemas tienen que ver con el área de multimedia e internet, en otro ámbito no participo en la toma de requerimientos y me dedico a otras actividades.

c) ¿Trabaja individualmente o con un grupo de trabajo a la hora de tomar los requerimientos a un cliente en particular?
En grupo. Además me dedico por mi parte a realizar sitios web, por lo que capturar lo que requiere el cliente lo individualmente.

d) ¿Cuales son la acciones concretas que realiza usted para lograr extraer adecuadamente lo que el cliente requiere?
Básicamente conocer el negocio del cliente. Estudiar lo que desea y sugerir, en lo posible, alternativas.

e) ¿Cuál es el principal problema que ve usted en los clientes a la hora de establecer sus requerimientos?
Que piensan en el “Cómo” quieren que funcione la aplicación y pierden la visión de “Qué” desean resolver con la aplicación.

f) ¿Cuál es su actitud frente al cliente cuando se presentan problemas?
Tratar de entender lo que quiere y llegar a un acuerdo.

g) ¿Alguna observación o dato extra que quiera incluir?
Tratar de entender lo que quiere y llegar a un acuerdo.

Encuestado Nº2 (IR)

2007-10-11T22:02:00.000-07:00

· Nombre: Javier Jara Valencia
· Profesión: Ingeniero Civil en Informática
· Empresa donde trabaja: TAISA
· Años de experiencia: 5

a) ¿Existe un esquema o norma para la toma de requerimientos? Si la respuesta es afirmativa, ¿Se siguen estas normas en la práctica?
Sí existe: es un proceso que rige cómo se detallan los requerimientos y cómo se controlan a través de la vida del proyecto. La norma sí se sigue.

b) ¿Cuál es el rol o actividad que tiene usted en el proceso de toma de requerimientos?
Ninguno, existe una gerencia dentro de la empresa que se dedica al levantamiento de requerimientos.

c) ¿Trabaja individualmente o con un grupo de trabajo a la hora de tomar los requerimientos a un cliente en particular?
Trabajan en grupo.

d) ¿Cuales son la acciones concretas que realiza usted para lograr extraer adecuadamente lo que el cliente requiere?
Estudiar el problema a resolver, sus objetivos y más tarde presentar bocetos y maquetas que le muestren cómo funcionará la aplicación.

f) ¿Cuál es su actitud frente al cliente cuando se presentan problemas?
Negociar con ellos para lograr una solución en pro del proyecto.

g) ¿Alguna observación o dato extra que quiera incluir?
No hubo respuesta.

Encuestado N°1 (IR)

2007-10-10T08:14:00.000-07:00

· Nombre: Marcelo Tapia Contreras

· Profesión: Ingeniero Civil en Informática

· Empresa donde trabaja: Ministerio Publico

· Años de experiencia: 10

a) ¿Existe un esquema o norma para la toma de requerimientos? Si la respuesta es afirmativa, ¿Se siguen estas normas en la práctica?
No. No existe, explicito, un modelo consensuado o basado en alguna norma respecto de la toma de requerimientos. No obstante lo anterior, el esquema básico consiste en considerar 3 niveles asociados a definir el requerimiento. Nivel estratégico, vale decir, los niveles superiores del cliente respecto de toma de decisiones de largo plazo., Nivel táctico, o mandos medios, que requieren de tomar decisiones de mediano plazo y los niveles operativos (generalmente la etapa más larga del proceso) que responde a quienes deben tomar decisiones de corto plazo.

b) ¿Cuál es el rol o actividad que tiene usted en el proceso de toma de requerimientos?
El rol de responsable de definir de manera adecuada el requerimiento y sus alternativas de solución. Este rol, en términos de tareas especificas, consiste en dirigir al requirente de forma tal de obtener los factores genéricos de la problemática (¡no de la solución!), que en definitiva te permitirán modelar el problema y posteriormente una solución.

c) ¿Trabaja individualmente o con un grupo de trabajo a la hora de tomar los requerimientos a un cliente en particular?
Grupalmente.

d) ¿Cuales son la acciones concretas que realiza usted para lograr extraer adecuadamente lo que el cliente requiere?
Las acciones concretas son tres:
Conocer el negocio o área de negocio a la que se prestará asesoría. Solicitar al cliente que explique en qué consiste su negocio y que quiere lograr con él. Es relevante saber y conocer respecto de negocio sobre el cual se deberá generar alguna solución respecto del requerimiento, principalmente por las implicancias que una solución pueda tener sobre áreas relacionadas.
Reuniones acotadas, utilizando el conocimiento general adquirido en el punto anterior, definir los temas a tocar en cada reunión e intentar abarcar todas las alternativas de operación posibles asociadas a ellos. Es importante no definir soluciones sino que sólo entender la problemática. Es importa hacerse de datos cuantitativos y cualitativos que soporten los diagnósticos que se realicen
Diagramar los procesos descritos por el cliente y explicárselo de vuelta, de forma tal que se valide lo que se cree entender de las reuniones anteriores, señalando claramente las problemáticas indicadas por el cliente u otras detectadas en el proceso de análisis.

e) ¿Cuál es el principal problema que ve usted en los clientes a la hora de establecer sus requerimientos?
Que te cuenten, claramente, lo que hacen, lo que esperan hacer, y lo que esperan de ese nuevo hacer. Es relevante que el cliente te cuente que hace y como lo hace, ya que es esta la instancia para ir develando las problemáticas que a él se le presentan y que en definitiva es la que se busca solucionar.

f) ¿Cuál es su actitud frente al cliente cuando se presentan problemas?
Tranquilidad, concentración. El capturador de requerimientos debe ser un elemento de contención, ya sea para escuchar las distintas quejas que el usuario pueda manifestar respecto de su situación actual y de mesura respecto de promesas asociadas a soluciones. Es por eso que es relevante solo capturar el requerimiento y no plantear soluciones, y bajo ninguna circunstancia en la primeras reuniones en que, generalmente, aun no se tiene un acabado manejo del negocio.

g) ¿Alguna observación o dato extra que quiera incluir?
Es importante abstraerse de los impulsos iníciales de tecnologizar las soluciones. Lo primero que se debe solucionar son aspectos operativos (generalmente) ya que, sobre todo en clientes que ya consideran tecnología en sus procesos.
Finalmente, el objetivo final de las reuniones con tus clientes debe ser el transformarte en el mayor experto en el tema, conocerlo mejor incluso que quienes realizan las tareas, sólo así podrás dar soluciones integrales para resolver un requerimiento, por pequeño que este sea.

Algo sobre Ingenieria de Software

2007-10-09T09:01:00.000-07:00

INGENIERIA DE SOFTWARE

La Ingeniería de Software es la rama de la ingeniería que crea y mantiene las aplicaciones de software. Esta requiere llevar a cabo muchas tareas o etapas que dependerán del modelo de proceso de software que se adopte (modelo de cascada, desarrollo evolutivo, entre otras).
Sea cual sea el modelo de proceso escogido, este tendrá, básicamente, las siguientes etapas asociadas:

• Definición y Análisis de Requerimientos
• Especificación se Software
• Diseño e Implementación
• Validación
• Manutención

Como se menciono, el trabajo gira en torno a la TR, esta actividad se encuentra en la etapa de Definición y Análisis de Requerimientos, la cual se describe a continuación.

Definición y Análisis de Requerimientos

Esta etapa consiste en extraer los requisitos de un producto de software, recopilando y estudiando toda la información relativa a la actividad del cliente, estableciendo los objetivos y prioridades de este. Aquí también se analiza las restricciones bajo las cuales será desarrollado el software, estableciendo y manteniendo un acuerdo con el cliente, este acuerdo cubre requerimientos técnicos y no técnicos, además forma las bases para estimar, planear, ejecutar y monitorear el proyecto de desarrollo de software a través de todo su ciclo de vida.

Los requerimientos se dividen en las siguientes categorías:

• Los requerimientos de usuario: Son escritos en leguaje natural y en diagramas. Se establecen los servicios que se espera del sistema y restricciones bajo los cuales debe operar.
• Los requerimientos de sistema: Especifican el detalle y restricciones del sistema. Generalmente estos requerimientos sirven como base para el contrato en entre el cliente y el desarrollador.
• Especificación del diseño de software: Básicamente consisten en una descripción abstracta del diseño.

Los requerimientos de usuario y sistema son los que tienen una relación mas estrecha a la hora de interactuar entre el IR y el cliente. Dentro de estos puntos, son diversas las actividades que el IR debe hacer, por ejemplo debe estudiar la factibilidad del sistema, la obtención y análisis de los requerimientos, la especificación y la documentación y la validación.

El proceso de TR abarcado en este trabajo, se refiere principalmente a la realización de las actividades de obtención y análisis de requerimientos. Para realizar estas actividades se requiere a personas con habilidad y experiencia en la Ingeniería de Software para reconocer requerimientos incompletos, ambiguos o contradictorios. En la siguiente sección se describe el porqué son necesarias estas habilidades.

COMPORTAMIENTO HUMANO EN LA TR

Desde el punto de vista del la Ingeniería de Software, los errores en el proceso de TR se consideran los más difíciles de descubrir debido a los factores humanos involucrados en este. Si bien existe un grado técnico en la TR, también se establece un alto grado social o humano para realizar este proceso.

Muchos de los detalles específicos del proceso de TR para un producto o proyecto dado dependen de la naturaleza de este, del dominio, semejanzas y las diferencias a los productos existentes. Cuando estas variaciones se combinan con la presión de terminar lo antes posible el proyecto, la habilidad y juicio del IR en el manejo de las contingencias toma un papel fundamental.

El comportamiento humano de los IR tanto en el trabajo como en la relación con sus clientes, dependerá del entorno en que se encuentre. Se puede considerar en términos de personas que trabajan individualmente, participantes dentro de grupos sociales y como miembros de organizaciones. Cualquiera sea el entorno de trabajo, la TR tiene que ver con la capacidad cognoscitiva, de comunicación y adaptación que tiene el IR tanto con sus pares como con sus clientes.

Mas información aqui

Sobre información y datos

2007-10-09T08:20:00.000-07:00

La recolección de información y datos se realizo a través de encuestas con los IR involucrados en la TR (las encuestas realizadas se encuentran en aqui), así como encuestas a personas que han actuado en alguna ocasión como clientes (las encuestas realizadas se encuentran en aqui).

Además, como fuente de información adicional, se considera:

La charla dictada por el Ingeniero Bruno Jerardino W. en la asignatura Comportamiento Humano en el Trabajo sobre la TR, esta charla se realizo el 25 de septiembre de 2007.

Una experiencia personal realizada en Enero-Febrero de 2007 en la empresa Ariztia, trabajando en el Proyecto de Integración Informática Ariztia (PIIA).

Entrevistas realizadas a IR. Estas fueron efectuadas por los alumnos Patricio Castro y José Nuñez pertenecientes en la asignatura Comportamiento Humano en el Trabajo del presente semestre (las entrevistas realizadas se encuentran en aqui o en el blog de su proyecto)

Alcances

2007-10-07T14:59:00.000-07:00

El estudio solo considera la interacción IR-Cliente y no a los demás actores involucrados en el proceso de TR. Se tiene que tener en cuenta que existe un tercer grupo, que para el caso de estudio no tiene una importancia significativa, este grupo está compuesto por los desarrolladores, probadores y los encargados de mantenimiento del software, que también hacen uso de los requerimientos obtenidos.

Además se considera a cualquier profesional involucrado en la TR y no solamente Ingenieros Informáticos.

Objetivos

2007-10-07T14:58:00.000-07:00

Objetivos Generales

El objetivo de este trabajo es observar y determinar las competencias y habilidades que posee un IR para el desarrollo de proyectos informáticos, estableciendo un “Manual de Buenas Prácticas”.

Objetivos Específicos

Los objetivos específicos de este trabajo de investigación son:

Observar como es en la práctica el proceso de la TR.
Establecer la participación que tiene un IR durante la TR.
Descubrir las habilidades y falencias que poseen los IR a la hora de TR.
Ver los distintos puntos de vista en los procesos de TR, considerando no solo a los IR sino también a los “clientes”.
Ofrecer una propuesta de solución.

Metodología utilizada

2007-10-06T08:55:00.000-07:00

La metodología utilizada es Soft System Methodology (Metodología de Sistemas Blandos), desde ahora SSM.

La SSM de Peter Checkland es una técnica cualitativa que se centra en estudiar un problema o situación desde un enfoque sistémico. Es una manera de estudiar las situaciones o problemas en los cuales hay una actividad con un alto componente social, político y humano, como es el caso de la TR (de ahí la razón que se escogió esta metodología). Esto distingue el SSM de otras metodologías que se ocupan de los problemas “duros”.

El enfoque sistémico practicado en la SSM atiende al estudio de las redes de relaciones que conforman numerosísimos factores de un sistema, tomando muy en cuenta la intensidad con que dichos elementos se comunican unos a otros, al integrar una estructura organizacional determinada. El SSM por lo tanto es una manera útil de acercarse a situaciones complejas.

Mas información aqui

Descripción del problema

2007-10-05T08:50:00.000-07:00

La toma o levantamiento de requerimientos, desde ahora TR, es una etapa esencial e importante en el ciclo de vida de un proyecto de software, esto debido a que en esta etapa se recopila y estudia toda la información relativa a la actividad del cliente, estableciendo los objetivos y prioridades de este. Aquí también se analiza las restricciones bajo las cuales será desarrollado el software.

Es muy importante entonces que los Ingenieros Informáticos o los profesionales encargados de la TR de sistemas, desde ahora IR (Ingenieros de Requerimientos) tengan una cierta habilidad y en lo posible experiencia, ya que los clientes creen que ellos saben lo que el software tiene que hacer, lo que la mayoría de las veces es incorrecto debido a que estos entregan requisitos incompletos, ambiguos o contradictorios.

Acerca de...

2007-10-03T12:50:00.000-07:00

Este blog es un complemento de una investigación realizada para la asignatura Comportamiento Humano en el Trabajo, de la carrera Ingeniería Civil en Informática, de la Universidad de Santiago de Chile.

El objetivo de la investigación es observar y determinar las competencias y habilidades que posee un Ingeniero Informático en la toma o levantamiento de requerimientos para el desarrollo de proyectos informáticos, para así establecer un “Manual de Buenas Prácticas”.

Mas información aqui