Toma de Requerimientos

Resumen de la investigación

2007-11-18T21:13:00.000-03:00

ResumeN

El proceso de captura de requerimientos es una etapa de suma importancia dentro del proceso de desarrollo de software. Éste se preocupa de descubrir y analizar las necesidades del usuario del sistema a construir. Pero, como la mayoría de los procesos de desarrollo, no está exento de problemas. El principal inconveniente encontrado, es la imposibilidad de transmitir, tal cual son, los requerimientos de los clientes a los ingenieros o analistas de requerimientos.

Actualmente, existen diversas metodologías y normativas que rigen el desarrollo de este proceso. En términos generales, estas indican la secuencia de pasos a seguir, dentro de los cuales, las interacciones entre personas no están del todo bien definidas. Esto incide directamente en la incomprensión de los procesos de negocio involucrados por parte de los desarrolladores y, en consecuencia, el producto final es deficiente

Para identificar las causas, responsables, repercusiones y soluciones al problema, se utilizará la Metodología de Sistemas Blandos de Peter Checkland. Esta metodología esta construida con el objetivo de dar tratamiento a sistemas de actividad humana. Su enfoque es el abarcar todas las visiones existentes entre los actores del sistema, reunirlas y llegar a consenso en pos de una reingeniería sobre el sistema actual. Para ello se describen siete diferentes etapas, que comienzan por una identificación del problema, pasando por un profundo análisis de la información y finalizando en un listado de mejoras al actual proceso de estudio.

Durante la aplicación de la metodología, se entrevistarán a actores reales del actual sistema, tanto a ingenieros como a clientes. A partir de la información reunida, habrá que identificar los puntos clave dentro del malfuncionamiento para diseñar las transformaciones necesarias. Estos dos aspectos están dados, respectivamente, por la visión enriquecida (Rich Picture) y por las definiciones raíces (elementos a mejorar). Seguido de esto, se concretará una definición formal del actual sistema y se comparará con la definición de un sistema propuesto, ambos expresados como sistemas de actividad humana (HAS). Con ello se evaluarán las mejoras que aporta el nuevo diseño, para luego concretar el objetivo final, el cual pretende alcanzar efectivamente los cambios propuesto, y que es un listado de competencias y habilidades que debe poseer el analista de requerimientos en el proceso de captura de requerimientos para el desarrollo de software.

Palabras clave: captura de requerimientos, desarrollo de software, metodologías, analistas de requerimientos, clientes, procesos de negocio, competencias y habilidades.

Modelos conceptuales

2007-11-18T20:47:00.000-03:00

A continuación se muestra, tanto el HAS(sistemas de actividad humana) actual del proceso, como el HAS deseado, para solucionar la problemática en cuestion. Además se procede a explicar el funcionamiento de estos sistemas de actividad humana

HAS ACTUAL

En la figura de abajo se puede apreciar la situación actual del proceso, el cual comienza en el momento en que el Sistema Solicitante pide la creación de un sistema informático al Sistema Regulador para satisfacer las necesidades que le aquejan. Por otro lado, el Sistema Regulador es el encargo de recoger esa petición y planificar las tareas que se deben de asignar al Sistema de Análisis. Una vez delegadas las tareas respectivas al Sistema de Análisis, este se encarga de realizar cuestionarios y entrevistas formales para lograr obtener las necesidades de los distintos clientes involucrados.

Debido a que, tanto el Sistema de análisis, como el Sistema Solicitante, muchas veces desconocen el proceso de negocio, la comunicación se torna confusa, lenta y muy iterativa, lo cual conduce a que en las mayoría de los casos no se puedan cumplir con los plazos establecidos por el Sistema Regulador. Al finalizar cada una de las citas, se formula una lista de requerimientos y casos de uso que se muestran en la siguiente sesión a los clientes. Una vez que el Sistema de Análisis establece una lista definitoria de requerimientos se la pasan al Sistema Regulador, el cual es el encargado de discutir los requerimientos obtenidos con el Sistema Solicitante. En caso que dicha lista de requerimientos sea satisfactoria, el proceso termina, sino se vuelven a tomar nuevos requerimientos con lo cual el proceso se reanuda.

HAS SITUACIÓN DESEADA

El nuevo sistema, esquematizado en la figura de abajo, habla de nuevas tareas asignadas a los distintos actores y la aparición de un nuevo subsistema: Documentación interna sobre procesos de negocio. Estas tareas dan un nuevo enfoque al proceso de captura de requerimientos, donde el analista deberá interiorizarse en profundidad acerca de la problemática en cuestión antes de irrumpir con los clientes. Esto se logra a través de dos vías complementarias: la documentación interna de la empresa, que entrega nociones teóricas y practicas recopiladas por la empresa de desarrollo; y la documentación del proceso del cliente junto a la observación de la ejecución del mismo.

A modo de aclaración, el subsistema de documentación interna consiste en la definición de los procesos de negocio que la empresa ha tenido que atender en proyectos anteriores, aprovechando así, la experiencia ganada. Estos documentos, además, contendrán las diferencias que posee un mismo proceso en organizaciones distintas. Por último, se incluirá documentación anexa que contemple el lado teórico definido por eruditos del tema.

Este análisis mas acabado permitirá la construcción de un listado potencial de requerimientos y casos de uso y, junto a él, el respectivo prototipo funcional.

Lo que se logra con esto, a diferencia del actual sistema, es comprender el lenguaje del cliente, adelantarse a él, identificar sus necesidades antes que las enuncie y, de este modo, llegar a consenso más rápido y con menos iteraciones.

Finalizada la captura de requerimientos, el analista deberá aportar a la documentación histórica interna, con las semejanzas y diferencias encontradas.

Una tarea anexa al proceso es incentivar a la empresa cliente a que documente sus propios procesos para esclarecerlos, tanto interna, como externamente. Este ejercicio aporta a su organización interna y a una efectiva futura captura de requerimientos.

Manual de buenas practicas

2007-11-18T20:41:00.000-03:00

A continuación se muestra el manual de competencias y habilidades que debe poseer un ingeniero informático para la toma de requerimientos. Este listado fue obtenido mediante la metodología aplicada SSM

1. Conocimiento a cabalidad del Proceso

El Ingeniero debe poseer un conocimiento completo del proceso que va a tratar, de esta manera podrá centrarse en las necesidades relevantes planteadas por el cliente, abstrayéndose de las particularidades de esta.

2. Adelantar requerimientos

Habiendo incorporado el lenguaje y las características del proceso de negocio, el ingeniero deberá adelantar requerimientos, en base a lo observado, y formular prototipos funcionales, los cuales negociará finalmente con el cliente, en una primera iteración del levantamiento de requerimientos.

3. Realizar una planificación adecuada

El ingeniero debe realizar una adecuada planificación, mediante algunas herramientas disponibles en el mercado como la carta Gantt, del proceso de captura de requerimientos con el objetivo de establecer citas que le permitan reunirse con los clientes para capturar las necesidades de ellos

4. Establecer una buena comunicación con el cliente

Una vez conocido y planificado el proceso, el analista debe mostrar disposición en su trato con el cliente de modo tal de poder hablar en el mismo lenguaje que él dejando de lado su lenguaje técnico.

5. Asesorar a los clientes

Debido a que es muy frecuente que el cliente no conozca bien el proceso, el analista deberá instruir al cliente de manera tal que en conjunto encuentren las necesidades importantes que le aquejan al cliente, con lo cual se puede realizar una adecuada toma de requerimientos en base a los objetivos que persigue del sistema a desarrollar.

6. Utilizar herramientas adecuadas para capturar requerimientos

Una vez capturado los requerimientos de los clientes, en una primera cita, es necesario que el analista establezca diagramas de casos de usos, modelos de datos, o utilice otro tipo de herramientas de manera tal que en encuentros posteriores se puedan ir refinando los requerimientos, para acercarse de a poco a las necesidades deseadas.

7. Mantener un feed-back cliente-analista

Es importante mantener una comunicación periódica con el cliente, para que él pueda ir viendo los avances del proceso y pueda sugerir cambios de requerimientos, que inevitablemente siempre estarán presentes.

8. Registrar los procesos de negocio

El mantener una documentación de cada proceso de negocio es muy importante, ya que esto le permitirá tener una fuente inagotable de conocimiento, en la cual podrá agregar, modificar, consultar o eliminar información sobre los distintos procesos de negocio con los que deba tratar.

9. Mantener una buena relación entre el equipo de trabajo

Es importante mantener una buena relación entre los integrantes del grupo de trabajo, debido a que una de las claves del éxito en la construcción de un sistema es que exista un grupo ameno de trabajo donde se consideren entre todos personas y no máquinas solucionadoras de problemas.

Entrega final

2007-11-18T18:14:00.000-03:00

Este documento es el resultado de aplicar la metodología mencionada. Dentro de él, se encuentra la entrega anterior, con la definición del problema y la descripción de la metodología, y la nueva documentación, con el seguimiento de la metodología y los resultados obtenidos.

Pinche aquí para descargar el informe.

Sugerencias

2007-11-10T11:29:00.000-03:00

Esta sección es para que puedas dejar tus sugerencias o críticas con respecto al sitio. Cualquiera de estás será bienvenida, debido a que la idea es mejorar cada día la información expuesta a ustedes.

Entrevista al usuario Alejandra Durán

2007-11-08T16:56:00.000-03:00

La siguiente entrevista fue concedida por Sergio Ahumada el cual esta desarrollando el mismo trabajo.
Si desea mayor información pinchar aqui

1. ¿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.
2. ¿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.

2007-11-08T16:46:00.000-03:00

Metodología de trabajo: Soft System Methodology

2007-11-07T20:04:00.001-03:00

La metodología de trabajo empleada es la metodología de sistemas blandos de Peter Checkland. Para conocer la forma de aplicarla y las etapas involucradas, se dispone de esta sección, donde se expondrá de forma concisa cada punto contemplado.

“[La metodología de sistemas blandos, soft systems methodology (SSM en inglés, o MSB en español] es una metodología que busca lograr mejoras en áreas de interés social [v.gr., organizaciones humanas] catalizando un número indefinido de ciclos de aprendizaje en la gente involucrada en la situación [blanda que es objeto de atención]. El aprendizaje se canaliza a través de un proceso iterativo que consiste [primero] en reflexionar y debatir diferentes percepciones del mundo real, usando conceptos de sistemas; [segundo] llevando a cabo acciones en el mundo real [influenciadas por estas reflexiones y debates], y [tercero] usando conceptos sistémicos para reflexionar sobre los resultados obtenidos con dichas acciones. Tanto la reflexión como los debates se estructuran usando diferentes modelos sistémicos. Estos modelos son concebidos como tipos ideales holísticos [holones] de ciertos aspectos de la situación problemática y no como descripciones [o fotografías] de la situación...”

(López & Sotaquirá, [4] en cita a Checkland & Scholes, 1990, pag.28, traducción libre).

La SSM esta compuesta por siete diferentes actividades divididas en dos grupos: un grupo sobre la experiencia en el sistema y uno sobre el pensamiento de sistemas. Estos grupos, se ordenan en el siguiente gráfico:

Actividad 1: La situación problema no estructurada

En esta primera actividad de la SSM se identifica una primera impresión de la situación problema, presentando la porción de la realidad social en la que existe

Actividad 2: La situación problema expresada

En esta segunda actividad se convierte la primera impresión de la situación problema en una representación pictórica llamada Rich Picture del cual se seleccionarán las situaciones conflictivas, intereses en común, ideologías existentes y sus consecuencias futuras y el modo en los involucrados ven la situación problema

Actividad 3: Definiciones raíz de los sistemas pertinentes

1. Definiciones raíz. Las definiciones raíz son hipótesis que mejoran el problema y que tanto el investigador como los dueños del problema estiman viables.

2. Sistemas sociales a la Vickers y sistemas políticos. Los sistemas sociales a la Vickers permiten observar los sistemas sociales al interior de la organización y poder representarlos como instancia de un vector

3. Los sistemas políticos, permiten mostrar como el poder se expresa a través de la situación problema mediante distintos grupos.

4. CATWOE. Es un nemónico que tiene agrupado a los clientes(C), actores (A), transformación (T), weltanschauung (W), dueño (O) y entorno (E). Los clientes son quienes se ven beneficiados o perjudicados por el funcionamiento del sistema. Los actores son los que permiten que el proceso de transformación se lleve a cabo. El weltanschauung es el punto de vista que origina la definición raíz. Los owners son quienes pueden detener la transformación si lo desean. El entorno es el medio que restringe o posibilita las acciones dentro del sistema donde la transformación se efectúa.

5. Definición raíz elaborada. Es la reformulación de la definición raíz original que se determina con los datos obtenidos del CATWOE. La diferencia existente entre la definición raíz y la definición raíz elaborada radica en que la primera solo indica el “qué” se debe hacer, mientras que la definición raíz elaborada indica el “qué” hay que hacer, el “cómo” hay que hacerlo y el “para qué” hay que hacerlo.

Actividad 4: Confección y verificación de modelos conceptuales

En esta etapa se generan modelos que logren realizar lo que se describe en las definiciones raíces mediante sistemas de actividad humana (HAS)

Actividad 4a: Concepto de sistema formal

Esta “sub-etapa” consiste en verificar que los modelos construidos no sean deficientes, para esto se usa un modelo general de sistema de actividad humana

Actividad 4b: Otros pensamientos de sistemas

Con fin de estructurar el sistema en cuestión mediante una perspectiva distinta, es necesario modelar la situación para así identificar todas las variables del sistema. El pensamiento escogido se detalla en el documento de la etapa inicial.

Actividad 5: Comparación de los modelos conceptuales con la realidad

En esta etapa se realiza una comparación entre los modelos conceptuales o mentales obtenidos en la actividad 4 versus el mundo real obtenido en la etapa 2

Actividad 6: Diseño de cambios deseables, viables

Esta fase tiene por objetivo hacer comparaciones entre modelos conceptuales y generar tres tipos posibles de cambios

Actividad 7: Acciones para mejorar la situación problema

En esta fase se llevan a cabo las aplicaciones de los cambios realizados anteriormente (etapa 6)

Para mayor información sobre la metodología utilizada descargue aqui

Descripción de la problemática

2007-11-07T19:37:00.000-03:00

En la actualidad la toma de requerimientos es un proceso fundamental, debido a que es la primera etapa que se realiza para elaborar un sistema informático. En esta etapa se pueden distinguir dos grupos de actores fundamentales los cuales son Ingenieros capturadores de requerimientos (desde ahora en adelante analistas de requerimientos) y clientes, entre los cuales debe existir una excelente comunicación para que se pueda llevar esta etapa satisfactoriamente. En la captura de requerimientos los clientes solicitan desarrollar un sistema informático en bases a sus necesidades para lo cual acuden a los analistas tal como se muestra en la siguiente figura:

Dentro de una empresa desarrolladora de software existen distintos cargos, dentro de los que se pueden destacar son: Gerente de proyecto, Jefe de proyecto, arquitecto de diseño, analista. Debido a que los roles de dichas personas depende de la empresa en cuestión, se ha considerado, tanto a los analistas, que son los que se relacionan más con los clientes, como también al Jefe de proyecto quien es el que planifica toda esta etapa para que el sistema se realice dentro de los plazos acordados con los clientes.

En lo que respecta a los clientes, también se puede realizar una segmentación al igual que en el párrafo anterior. En los clientes (usuarios) se puede distinguir al (los) cliente clave, y los clientes secundarios. El cliente clave es el encargado de definir los requerimientos y es el que toma las decisiones en un momento determinado, mientras que los clientes secundarios son aquellos que usan los sistemas. De la misma manera en que se hizo abstracción entre los analistas, en este caso se junta al cliente clave y a los clientes secundarios en una misma congregación.

En la toma de requerimientos existen anomalías basadas principalmente en la comunicación existente entre los analistas y los usuarios finales, lo cual se debe a un “tecnicismo en el lenguaje”, “desconocimiento del proceso de negocio”, “poco compromiso con la captura de requerimientos”. El tecnicismo en el lenguaje es debido a que el dominio de conocimiento, tanto de los analistas, como los clientes es muy especifico y segmentado a sus respectivas áreas de trabajo. Este aspecto trae como consecuencia incomprensibilidad e incongruencia al momento de que el usuario plantea sus necesidades y esto conlleva a un estado de frustración en estos dos actores debido a que ninguno puede entender los términos del otro.

El desconocimiento del proceso ocurre, tanto en los clientes, como en los analistas. En los clientes esta carencia se produce debido a que muchas veces en las empresas no existen manuales de procesos y manuales de funcionamiento, los cuales son necesarios para que todo el personal conozca en forma clara el funcionamiento de la empresa a la que pertenece. La principal consecuencia de esto consiste en que, en el momento en cual se exprese este conocimiento tácito para ser recopilado por los analistas, se producirán una serie de contradicciones entre los clientes involucrados. Además, esta incongruencia en los requerimientos también se ve reflejada entre los altos y medianos mandos de la empresa, debido a que muchas veces existe un desconocimiento por parte de los primeros del funcionamiento real de algunos subprocesos, mientras que son los segundos son quienes conocen en detalle las necesidades que cada subproceso necesita para funcionar adecuadamente.

El poco compromiso con la captura de requerimientos es debido a que los clientes realizan distintas labores y por ende consideran una pérdida de tiempo el estar tratando de explicar las necesidades de la empresa a los analistas, lo cual se traduce en poca disponibilidad por su parte para gestar las respectivas entrevistas. También los clientes no se dan el tiempo para leer el documento de requerimientos, con lo cual no se puede realizar una revisión a cabalidad de lo que se debe realizar; y como el usuario no objeta dicho documento el ingeniero asume que ambos están de acuerdo con respecto a las necesidades que debe satisfacer el software.

En ciertas ocasiones una toma de requerimientos puede resultar complicada para los analistas debido a que es muy común trabajar con normativas como CMMI, CMM2, y PMO que son muy estructuradas. En el momento en que ocurren estos “cuellos botella”, se solucionan identificando las fallas existen y las causan que originaron estas fallas. Además el proceso es bastante engorroso para los clientes debido a que a que se le exigen que cumplan ciertas normativas para solicitar un proyecto con dos objetivos. El primero, es que se establezca una especie de contrato en el cual se dejen los puntos claros sobre lo que se pide que se realice. Mientras que el segundo, es realizar una asesoría a la empresa demandante sobre el sistema que solicita, con lo cual se logra una mejor comprensión y comunicación de lo que se solicita.

Finalmente, las consecuencias de una mala toma de requerimientos son perjudiciales para todos los actores. En los analistas esto repercute, tanto en que no se puedan cumplir los plazos establecidos lo que deriva a planificar nuevas sesiones de entrevistas con ellos para esclarecer las necesidades reales de la empresa contratista, como costos financieros y de oportunidad. Los costos financieros se relacionan con el hecho de que al no realizar un cumplimiento de las fechas establecidazas, se retrasa todo el proceso que deriva de la captura de requerimientos, lo que conduce a que la entidad desarrolladora de sistema asuma gastos (multas) innecesarias producto de este retraso. Los costos de oportunidad tienen relación con que la imagen de la empresa prestadora del servicio se ve afectada seriamente a nivel nacional como internacional, debido a que las empresas contratistas se recomiendan entre ellas a buenas prestadoras de servicios.

Para mayor información sobre la descripción del problema, descargue aqui

Ingeniería de Requerimientos

2007-11-07T19:35:00.000-03:00

Para que un proyecto de desarrollo de software pueda tener éxito es crucial realizar una comprensión total de los requerimientos del software a diseñar.
En la etapa del análisis y la especificación de requerimientos, tanto el cliente, como el desarrollador juegan un rol fundamental, debido a que el primero se encarga de describir las necesidades que le apremian, mientras que el segundo es el encargado de dar solución a dichas necesidades. Debio a que la especificación es complicada de detallar, desde el comienzo del desarrollo de los sistemas se ha tratado de realizar una adecuada identificación de los requisitos del sistema derivads de las necesidades de los usuarios. Por todo esto, dentro de la Ingeniería existe una rama que se dedica a la captura de requerimientos, la cual es la Ingeniería de requerimientos cuyo propósito general es desarrollar técnicas para que este proceso fundamental se realice en forma eficiente y segura.
La ingeniería de requerimientos se puede dividir en cuatro etapas, las cuales son: estudio de factibilidad, obtención y análisis de requerimientos, especificación de requerimientos y validación de requerimientos. Estas etapas se pueden observar en la figura 1 y se explican brevemente en la siguiente sección

Etapas de la Ingeniería de Requerimientos

El proceso de Ingeniería de requerimientos posee cuatro etapas: estudio de factibilidad, obtención y análisis de requerimientos, especificación de requerimientos y validación de requerimientos. Cada una de las siguientes etapas se especifica a continuación.

a. Estudio de factibilidad

El resultado de esta etapa es producir un informe de factibilidad como se ilustra en la figura 1 que consiste, tanto en realizar una recolección y evaluación de la información, como redactar el informe del estudio de la factibilidad.

b. Obtención y análisis de requerimientos

El objetivo de esta etapa es determinar: el dominio de la aplicación, desempeño del sistema, las restricciones que el sistema debe poseer, entre otras cosas. En esta etapa toman principal importancia los stakeholders, los cuales son aquellas personas con alguna influencia ya sea directa o indirecta en los requerimientos del sistema, es decir, pueden ser los usuarios finales, ingenieros desarrolladores, ingenieros de mantenimiento, etc.

c. Obtención y análisis de requerimientos

En esta etapa se establece la especificación de los requerimientos, es decir lo que el sistema debe realizar. Esta etapa es muy complicada debido a que la naturaleza de los problemas es muy compleja.
Es menester destacar que la especificación puede verse como un proceso independiente del modo en que se realice, todo esto con el objetivo de lograr una adecuada implementación de software. Además se han determinado los siguientes principios para representar los requisitos de software

1. Separar la funcionalidad de la implementación
2. Desarrollar un modelo de comportamiento de un sistema que comprenda los datos y las respuestas funcionales de un sistema a varios estímulos del entorno.
3. Establecer los componentes del sistema que interactúan con él.
4. Definir el entorno en que operara el sistema
5. Crear un modelo intuitivo
6. Considerar que una especificación es una abstracción de una situación real por lo cual será incompleta y existirá a muchos niveles de detalle.
7. Definir un contenido y estructura que sea susceptible a cambios.

d. Validación de Requerimientos

En esta etapa se establecen los requerimientos finales ó completos que definirán el sistema que el cliente desea

Para mayor información sobre la captura de requerimientos descargue aqui

Documento primera etapa

2007-11-07T18:24:00.000-03:00

En la primera etapa del proyecto, se analizaron algunas metodologías sobre la captura de requerimientos de software encontradas en la bibliografía. Además se entrevistó a los distintos actores involucrados en el proceso (analistas y clientes) con el objetivo de extraer las características que posee este proceso (visto de ambos puntos de vista) con el fin de establecer un manual de buenas prácticas sobre la toma de requerimientos que debe poseer un Ingeniero Informático, el cual será mostrado en la siguiente etapa del proyecto.

Descarga el documento aquí

Entrevista al Ingeniero Edgardo Sepulveda

2007-11-07T17:57:00.000-03:00

Descarga la entrevista en audio

1. Identificación del problema

1.1 ¿Cuáles son los principales problemas que posee el proceso y de dónde provienen dichos problemas.

Primero, yo diría, desde la perspectiva del ingeniero que toma los requerimientos puede haber una desconocimiento del proceso de negocio que está analizando. Entonces recomiendo en ese caso que, previo a una toma de requerimientos, el ingeniero encargado analice el problema, el proceso de negocio y después vaya a hablar con los usuarios habiendo interiorizado las cosas.

En segundo lugar, tiene que investigar respecto de las dificultades que hay en el proceso de negocio, no necesariamente con los usuarios, tiene que ver el mercado, tiene que ver en la misma empresa, hablando con otras personas cómo ven ellos el proceso de negocios. Una vez que ya se tiene claro el proceso de negocio, desde la perspectiva del ingeniero que va a levantar requerimientos, recién en ese momento tiene que establecer la relación con el usuario a quien va a pedir su requerimiento.

Ahí hay otra situación, que es, por un lado, la disponibilidad del usuario. Es común que uno de repente le dice al usuario: “oye, mira, juntémonos mañana para analizar este tema” y que es lo que ocurre, el usuario dice: “ya, perfecto, a las once y media, doce de la mañana” y se pierde un día completo, a veces, donde no se pudo entrevistar a un usuario. Entonces, la toma de requerimientos que uno había pensado que iba a durar dos días, tres días, una semana, a veces puede pasar mucho tiempo para poder concretarla.

Otra situación que se produce, otra situación problema, es el conocimiento del usuario. De repente uno espera o supone que el usuario conozca muy bien su proceso de negocio y en la práctica no siempre es así. A veces los usuarios no conocen su proceso de negocio. Te voy a comentar un caso real que me pasó a mi con un usuario de manejo de costos, donde yo le decía: “a ver, ¿cómo manejas tú los costos?” – “ee, mira, de esta forma”- “¿qué variables vamos a costear?” – “en realidad ahí no está clara la cosa todavía”. Qué es lo que pasa, que no se pudo lograr con ese usuario cuales eran las variables de costos que había que considerar. ¿Por qué?, porque hay usuarios que son muy reacios o le tienen miedo a la toma de decisiones, porque en la toma de requerimientos una de las cosas que son fuertes son las decisiones, por que cuando yo estoy planteando requerimientos, estoy decidiendo. Imagínate que yo fuera el director del departamento y me dijeran: “oye, vamos a hacer un sistema de atención de alumnos, ¿cuales son sus requerimientos?” entonces yo diría “aa, pucha, es que a lo mejor, si yo planteo requerimientos, quizás no tengo claro el problema, a lo mejor estoy pidiendo algo que puede ser difícil, etc”. Por lo tanto me cuesta tomar decisiones: “¿y que pasa si meto las patas?, si pido esta cuestión y no sirve”, entonces hay mucho usuarios que tienen miedo a hacer requerimientos. Entonces es difícil extraer requerimientos.

En resumen yo diría que el tema fuerte aquí es, por el lado del ingeniero, tener claro el problema, por el lado del usuario, tener claro también su negocio y tener la capacidad de decisión. No saco nada con entrevistar a un bodeguero, lo importante es entrevistar a un jefe de bodega o entrevistar a las personas claves.

- ¿Cree que una adecuada planificación ayuda a la toma de requerimientos?

¿Planificación de qué?

- Para hacer las preguntas, las encuestas por parte del ingeniero.

Si, yo diría más que una adecuada planificación, una adecuada preparación. Imagínate que si me voy a una compañía de seguros y me dicen: “oye, necesitamos hacer un sistema para manejo de pólizas de vivienda”, entonces me tengo que interiorizar de lo que dice la ley, que dicen las normativas de superintendencia de seguros, averiguar el mercado de cómo operan las compañías de seguros, ver como son las pólizas, ponerme en distintos escenarios y recién en ese momento ir a hablar con el usuario. Entonces yo diría más que una planificación, una preparación. Ahora, durante la entrevista en sí, están las herramientas que se aplican, qué instrumentos aplico. Yo me acuerdo que, cuando estudié estos temas, siempre me decían: “mire, usted tiene que preparar una encuesta, con preguntas claras, etc.”. Mira en la practica uno pone grandes lineamientos, pero en la practica ocurre que durante la conversación, van derivando cosas, es decir, uno no puede llegar con cien preguntas, de repente una pura pregunta puede significar dos horas de conversación, porque la pregunta te va llevando a otras cosas. Yo diría que es importante ahí tener una visión estructurada del problema. Si voy a estudiar el caso de las pólizas, yo no saco nada con decir: “oye, ¿ustedes incorporan datos de los vehículos?” y después: “oye, y para los vehículos ¿ustedes utilizan también el color del vehículo como una variable importante para asegurar el vehículo?”. Son preguntas muy puntuales. Entonces uno va estructuradamente, es decir, primero uno pregunta cual es tu negocio, cuales son tus procesos principales, quien hace la generación de pólizas y ese caballero por qué actúa de esa forma, qué tipos de pólizas existen y por qué se hace esta cosa, pero no entrar en cosas muy puntuales. Tú te pierdes en lo básico y te olvidas de lo medular.

Lo otro que yo recomiendo es, en la medida que uno está entrevistando al usuario, ir mentalmente estructurando casos de uso, ir mentalmente estructurando un modelo de procesos, ir mentalmente estructurando un modelo de datos. Ahora, si puede ir recogiéndolo en papel, mucho mejor. Lo ideal, pero es bien ideal, es, terminada una entrevista con un usuario, uno tiene dibujado un caso de uso. Ojo, un diagrama de caso de uso. Y si fuera posible, diagramado unos procesos de negocios y también, más ideal todavía, tener una lista de las identidades principales. Terminar un prototipo. Para la próxima reunión, llegar con cosas mucho mas finas y así entonces voy de a poco acercándome al detalle del problema.

Otra herramienta que yo he aplicado en la práctica, es, como me he interiorizado en el problema, uno adelanta requisitos. Por ejemplo, en el caso de la póliza uno pregunta: “esto va a ser Web o no Web”, entonces: “¿sabe?, yo recomiendo que sea Web”, “señor usuario, ¿qué le parece a usted también que generemos informes de pólizas caducas o de siniestros del último período?”, entonces el usuario dice: “aa ya, bueno”. Así uno va llegando a un nivel de detalle súper fino. También hay que tener presente para los requerimientos, ¿cual es la cantidad de requisitos? No hay un número de requisitos, entonces yo puedo enumerar requisitos generales del sistema y después entrar a detallar. A un nivel detalle alto, la cantidad de requisitos podría superar los mil, es decir, preguntar cual es al cantidad de requisitos adecuada para un sistema, yo te podría decir: miles. Lo que si, puedo agrupar requisitos, pero la cantidad es grande. ¿Por qué necesito hartos requisitos?, porque cuando vaya a probar el sistema, tengo que probarlo en base a los requisitos.

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?

Como decía, el ingeniero o analista o diseñador, que es el que va a tomar los requerimientos, el usuario, y dentro del usuario hay varios tipos de usuario. Usando la terminología que se usa en SAP, primero está el Key User, el usuario clave, que es el usuario responsable de los requisitos, que es el que define los requisitos y es el que firma la lista de requisitos y es el que puede tomar decisiones en un momento determinado. Y están los otros usuarios que hacen uso, directa o indirectamente, del sistema. Por eso que te decía que es bueno tener un diagrama de casos de uso decir: este es el sistema y estos son los usuarios del sistema. Entonces yo debería entrevistarlos a todos pero el Key User es el más importante. Ahora, el tema está en detectar quienes son realmente esos usuarios, porque a veces, pasa en la realidad, los verdaderos usuarios están medios ocultos o los que conocen el tema. A veces uno va a la estructura organizacional de la empresa y dice: “este sistema apoya a esta función” y luego identifica que esta función está soportada por estos procesos que están aquí, por estas unidades y estas personas, y así uno se enfoca en esas personas y resulta que en la oficina del lado esta la persona que mas sabe del tema. Entonces uno tiene que tener la capacidad de ver quien realmente le aporta información.

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

Primero, está el ingeniero capturador. Él se deja llevar a veces por sus ideas, su conocimiento, etc. y es difícil que el diga que están bien los requerimientos. Entonces tiene que haber un jefe de proyecto que debiera tomar la lista de requerimientos y validarla y hacer todas las verificaciones. En la práctica yo no he visto una separación entre un jefe de proyectos, un tomador de requerimientos y un diseñador. Normalmente en las tomas de requerimientos está el jefe de proyectos acompañado de dos analistas, entonces la toma se hace en conjunto. De hecho, te voy a contar una experiencia que me pasó a mi, una práctica que hice en la toma de requerimientos. Una vez estudié el problema completo, después me junté con los técnicos informáticos y les dije: “este es el problema, ¿que les parece?, ¿es así?”, entonces yo les expliqué la metodología. Les dije que vamos a ir donde el usuario y les vamos a explicar esto. Entonces, como que nos adelantamos a los requerimientos. Nosotros ya sabíamos del negocio y cuales eran los requerimientos, por lo tanto la presentación ante el usuario no fue como “oye, explícame el proceso de negocio y dime lo que quieres”, no. Yo lo que hice fue preparar un power point con el modelo de procesos de negocio e inclusive una interfaz gráfica de como sería un sistema de apoyo al usuario, y una lista de requisitos previos y casos de uso. Entonces, cuando partió la reunión con el usuario, yo le dije: “mire señor usuario, nosotros estamos viendo un sistema para usted”, obviamente ya habíamos hablado con usuarios en pasillo pero no habíamos entrado a estudiar requerimientos y dije: “así estamos viendo el tema”, y le mostré el caso de uso. Ahi le mostré donde esta él y que cosas puede hacer. Entonces el usuario inmediatamente dice:” mira, me parece bien, pero yo no hago eso, eso lo hace otra persona” – “a, perfecto” – “y me gustaría poder hacer esto otro” – “ok, se anota” y en la misma reunión se va corrigiendo el caso de uso, ¿te fijas?. Entonces, terminada la reunión, ya yo tengo un caso de uso detallado y bien afinado; y tengo un modelo de datos aproximado. En las primeras reuniones ya tienes bastante avanzado.

3. Rich Picture

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

No es burocrático. Burocrático sería un proceso donde se le diga al usuario que se van a tomar los requerimientos y de acuerdo a la metodología usted tiene que llenar esta planilla y después de llenarla hay que ir a entrevistar y después de la entrevista vamos a hacer tal y tal cosa y después va a ser iterativo esto, etc. Yo creo que ahí podría ser burocrático. Para mí el proceso de toma de requisitos no es burocrático. Yo lo miraba burocrático al principio, pero hoy en dia me he dado cuenta que es súper importante no hacer burocrático el proceso, porque es un proceso casi de aprendizaje.

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

Yo he estado con un jefe y como jefe, por lo tanto es clave la comunicación y el conocimiento aplicado. En otras palabras , si estoy metido en un proyecto y mi jefe no tiene idea de como se hace el proyecto o no me está guiando respecto del proyecto, obviamente que no va a haber espíritu de cuerpo dentro del equipo y la cuestión no va a funcionar bien.

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

Eso es muy común. Por ejemplo, en un caso de un sistema de costos, el usuario dice: “mira aquí manejamos todos los costos de producción y nos interesan todos los costos.”, entonces yo hago un modelo previo para discutir como se manejan los costos y digo yo: “a ver, las maquinas van a usar electricidad, van a usar vapor, petróleo, se va a usar mano de obra, etc” y digo que esos serán todos los costos involucrados. Entonces voy donde otro usuario que es gerente y me dice:”no, olvídate de la mano de obra. Eso es gasto” y me da todas las explicaciones razonables y al final esta ok. Voy donde el otro usuario y empiezan las discusiones y dificultades de que uno tiene que ser de mediador. Hay situaciones complicadas, hay un usuario A que es gerente y el usuario B es el que mete las manos todos los días y es el que sabe realmente. Es el que conoce lo problemas que hay, entonces uno tiene que ser tan sutil que debe decirle al gerente: “lo que pasa es que en la practica esto funciona así”. Es complicada esa situación, de equilibrar distintas visiones de un mismo problema. Entonces un requisito partió de una forma A y terminó de una forma B.

4. Sistemas sociales y políticos

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

Primero, el tener experiencia de cómo relacionarse con los usuarios. Yo he leído harto respecto de eso y lo he encontrado burocrático. Lo que he leído lo he encontrado burocrático. “Mire, usted, cuando atienda a un usuario haga una lista de requisitos y atiéndalos de esta manera y no mas de dos horas y las preguntas tienen que ser de este estilo”. Disculpa lo que voy a decir, pero... las pinzas. La cosa en la práctica, y a mi me resulta, es totalmente diferente. En la práctica uno tiene que entrar en un dialogo normal con los usuarios de igual a igual. Si tu eres el encargado de algún proceso, si tú eres contador de la empresa y yo soy el analista informático, ahora tengo que ser contador y empiezo a hablar de igual a igual contigo, como contador y en los mismos lenguajes tuyos. Entonces yo te digo que un factor crítico es que uno tiene que conocer de los procesos del negocio, que es lo que te dije al principio de la entrevista.

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

No existen reglamentos en informática. Lo que si existen son normas o estándar de trabajo. Yo nunca he visto en una empresa “reglamento”. He visto la norma ISO, que se aplica en algunos lados, que te dice que formulario se aplica en una entrevista, las minutas de reuniones son asi, aqui debe firmar el usuario, etc.

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?

Educar a los informáticos en los procesos de negocio. Es decir., no saco nada con tener muchas técnicas, muchas herramientas, muchas metodologías, muchas normas estándar, etc., si el caballero que tomará los requerimientos no tiene idea de lo que es contabilidad, lo que es producción, lo que es el área comercial. Para mí, los procesos de negocio son importantes.

- O sea que todo va por parte de los tomadores de requerimientos.

Claro, porque al usuario no lo vas a cambiar. Ahora, los usuarios han ido cambiando en el tiempo. Se han ido acercando a la informática, se han ido adecuando a las metodologías, etc., pero es el informático es el que tiene que adecuarse.

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

Cuando se utiliza una metodología, con las normas que se aplican y los documentos que se utilizan, los instrumentos que se utilizan son siempre cuestionables. Yo no puedo cerrar los ojos y decir: “esta es la norma de la empresa” y por lo tanto la aplico a toda costa. Yo tengo que estar constantemente cuestionando la metodología. Yo soy partidario de mirar la metodología, aplicarla y en el camino ir adaptándola, siempre, siempre. Yo no puedo usar la misma metodología, no puedo usar las mismas técnicas de entrevista o de captura de requerimientos ante situaciones distintas, escenarios distintos. Ahora, las normas de la empresa dirán: “ojo, usted tiene que terminar la reunión, hacer una minuta y dejarla en el directorio tanto el proyecto”. Bueno, eso tengo que cumplirlo igual, pero a lo mejor, la minuta tiene un nombre, se llama proyecto-minuta-003. Yo podría decir:”cambiemos la denominación de minutas”, porque en realidad no sirve para nada esa denominación, es mas como esto otro, o en el formato de la minuta aparece, a veces, información que es irrelevante: “cambiemos ese formato”. Entonces, es todo cambiable en el tiempo. Insisto, esa es la calidad. La calidad se ve como si fuera contínua. La calidad se definió y quedó para siempre ahí. Yo tengo que estar permanentemente analizando.

Entrevista al Ingeniero Rodrigo Riquelme

2007-11-07T13:53:00.000-03:00

Descarga la entrevista en audio

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 ser 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 esta haciendo considerado, esta 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 esta 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 Quienes 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 mi y me decía “oye Rodrigo esta pasando esto…” y ahí tenia 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 si.

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

Entrevista a la Ingeniera Karen Díaz

2007-11-04T20:37:00.000-03:00

Descarga la entrevista en audio

1. Identificación del problema

1.1 ¿Cuáles son los principales problemas que posee el proceso y de dónde provienen dichos problemas.

Los problemas básicos que tenemos nosotros son la comunicación. La comunicación de nosotros con el usuario. El hecho que nosotros tenemos, tal vez, un lenguaje mucho más técnico que el usuario, eso provoca que a veces el usuario no nos entienda y al revés, como usan un lenguaje demasiado “light”, nosotros también entendemos muy “light” el requerimiento.

Por otra parte, el tema de la documentación, cuando se hace la documentación y se le entrega al usuario, la verdad es que para ellos debe ser una lata revisar el documento completo y no lo hacen a conciencia. En general, el país tiene una mala comprensión lectora entonces eso perjudica también que el tema sea bien llevado.

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

Esto es como una bola de nieve. Tenemos un requerimiento que si quedo mal definido desde un inicio, va ir agrandándose, agrandándose, hasta llegar a la etapa de diseño que no queda bien definida tampoco y después al requerimiento que al final el usuario te va a decir: “esto no fue lo que te pedí”. Entonces es un efecto que si no queda bien definido en la primera etapa en detalle, entonces las consecuencias pueden ser bastante graves.

- ¿Usted participa en el proceso en que interactúan con el usuario o solamente en la primera etapa?

- ¿Durante el proceso de...?

- Durante el proceso de construcción

Hace poco se implementó una metodología. Lo que pasa es que en informática no hay muchas metodologías al respecto, son más bien artesanos al principio. Entonces en esta compañía hace menos de un año se comenzó a trabajar en serio. Antes se hacían cosas a pedido por correo. Tan informal como eso. Ahora ya existe una metodología para enfrentar el tema y se hace participar al usuario de todas las etapas del proyecto.

- ¿Existen, a veces, cambios en los requerimientos por parte del usuario durante el proceso de desarrollo?

Siempre, hasta en la etapa de prueba. ¿Y por qué sucede esto? Bueno, el usuario no tiene muy claro lo que quiere pedir. Segunda cosa, nosotros le entendemos una cosa y el a lo mejor quería decir otra y lo cambia. Después se da cuenta que... “ah no, no era eso. Mira mejor así”. O si no simplemente él ve el producto ya terminado y ya de ahí le empieza a picar el bichito de la ambición, entonces dice: “mm si, pero podríamos hacer esto además, agreguémosle esto otro...”, y así es un cuento de nunca acabar.

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?

Nosotros tenemos el área de tecnología, que esta dividida como desarrollo de software e infraestructura. Hay un área paralela a nosotros, que no pertenece al área de tecnología y que es de calidad. Entonces son esas tres unidades enfocadas a dar apoyo al desarrollo de software.

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

El proceso, como te decía, esta normado por una metodología que se implementó hace menos de un año y que ahora esta en evolución. Entonces, hay un comité de arquitectura o de normativa. Ellos van evolucionando el versionamiento de la metodología. Pero, quien controla el cumplimiento de los plazos, tenemos algo que se puede llamar PMO. No sé si has escuchado ese concepto.

- No.

La PMO es Proyect Management Office. La PMO... son varios niveles de PMO, así como los de CMM. El objetivo de esto es controlar el avance de los proyectos y no sólo controlar, además se coordina y apoya e incentiva el desarrollo de nuevos proyectos. Nosotros estamos en el nivel más básico de la PMO que es sólo controlar plazos. Ellos nos controlan que cumplamos la carta Gantt, mandan un informe y esto es permanente, son todos los días. Una vez a la semana se lleva un informe en que dice en que estado está el proyecto, si se cumplió o no el plazo y si los documentos asociados están o no.

2.3 ¿Quién o Quienes son sus clientes?

Mi cliente es el área de marketing y el área de operaciones de la compañía. Lo que pasa es que en este minuto estamos desarrollando una Intranet. Un sitio colaborativo. Entonces, en este momento tengo a la gerencia de administración y finanzas; y marketing por el tema de la página Web.

3. Rich Picture

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

Yo creo que es burocrático para el cliente. Él tiene la sensación de que es burocrático. Hay pasos que nosotros, por ejemplo exigimos una solicitud de proyecto. Cuando él dice: “ah, pero yo puedo mandar un mail y decir quiero que en la página Web halla un botón tal”. Nosotros le exigimos una solicitud de proyecto. Lo obligamos a escribir eso. ¿Por qué?, porque en las organizaciones se tiende a tirar mail y mandar ideas y todos corren para ese objetivo y después ni siquiera se preguntan que beneficios le trae hacer ese desarrollo. Muchos desarrollos quedan a la mitad o se terminan y después no se usan.

- ¿Una especie de contrato con lo que fijan ustedes y el cliente?

Si, para decir “eso es lo que yo quiero”, y en ese contrato entre comillas, también tiene que decir: “mira, esto aportará tales beneficios a la compañía”. Porque si los beneficios no están claros ¿Tiene sentido hacer el proyecto?

- En caso de que esos beneficios no estén de acuerdo al proyecto que está pidiendo, ¿ustedes evalúan y dicen que no va a dar tales frutos?

Si. Se le cuestiona el tema a nivel de gerencia. Pero, si el tipo insiste en que si va a ganar 15 millones de pesos, entonces se le dice: ya ok, pero es su responsabilidad. Tú dijiste que al tanto tiempo iba a haber 15 millones de pesos. Nosotros vamos a hacerlo, pero ahí ves tú.

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

Es buena, pero hay varias patas, porque ahí uno tiene que tener varias habilidades interpersonales, de las que nosotros como informáticos, no estamos muy dados. Cuando uno sale de la universidad, uno tiene que aprender a adquirir el tema de la comunicación y ponerse en el lugar del otro, eso también nos cuesta mucho. Hay que hacerlo para entenderlo porque el otro no entiende nada de nuestro mundo, entonces hay que tratar de explicarle y tratar de entregarle la información lo más clara posible.

- Usted como jefe de proyecto, ¿cree que es una buena líder?

Hay distintos tipos de liderazgo. Hay distintos tipos, sobre todo acá en la compañía. Hay liderazgos que son así como duros, o sea, como patrón de fundo y hay un liderazgo con el que yo me inclino que es más consensuado. En realidad a mi me gusta que la gente trabaje conmigo mas por compromiso, por compartir objetivos, que por susto. Entonces, yo creo que si. A mi me gusta que trabajen de esa manera así.

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

Algunas veces entregan tareas de investigación. Por ejemplo, el año pasado, a mi me tocó hacer una sobre PMO. Que sería como una labor extra. A otro este año le tocó ver el tema de arquitectura con el Proyect Server. Entonces, de repente te dan tareas anexas. Ahora, si complica la labor, cuando estas haciendo gestión, te complica por salirte de la asunto, porque pierdes el hilo muy fácilmente y no puedes coordinar a las demás personas.

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

Siempre y sobretodo lo último. Poca claridad de lo que quiere el usuario y por otro lado también hay un factor súper importante que es cuando el proyecto abarca múltiples áreas, abarca múltiples usuarios. Ahí se designa un usuario líder, pero ese usuario líder tal vez no tiene el expertise, más que en su propia área, entonces ahí también hay un tema. Una cosa es el usuario líder, que coordina, pero no necesariamente es el experto del tema. Hay que indagar y asegurarse que el usuario líder se esta asesorando por los usuarios expertos para sacar los requerimientos.

- En caso que cambien los requerimientos durante el proceso de desarrollo, ¿como resuelven esos problemas?

Hay unos documentos que se llaman control de cambios. El usuario entrega el documento y se le tiene que decir que significa para el proyecto: el atraso por construcción, pruebas, etc. y eso aumenta las lucas.

- En caso que hay cambio en el diseño, han tenido que reinventar de nuevo el proceso o generan prototipos genéricos y luego los van adaptando. ¿Cual es la estrategia en ese caso?

Cuando tenemos un cambio de diseño, tratamos de chutearlo y decir versión 2.

4. Sistemas sociales y políticos

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

Nosotros estamos orientándonos más al cliente, a conocer el proceso de negocio, porque eso es importante. Conocer el proceso de negocio, para nosotros no es sólo ser capturadores de requerimientos, además poder sugerir mejoras a los procesos que ellos están tratando solucionar. Porque algunas veces la problemática no va por lo que ellos están visualizando si no que con una solución mucho mas fácil y que nosotros técnicamente la podemos proveer de manera mucho mas rápida. Entonces, mas allá de listar las cosas, tenemos que empaparnos de la problemática del cliente para poder entregar una mejor solución.

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

El reglamento que nosotros tenemos es una metodología. Esta metodología se basa en el desarrollo estándar de software, el de cascada, y una combinación de la PMO enlazado con una metodología de desarrollo de proyectos que se llama, que esta enlazada por el Proyect management institute, que es un ente que entrega una metodología para el desarrollo de proyectos, pero es muy genérica, que nosotros la hemos ido adaptando a nuestra realidad.

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?

¿Por que no se han realizado? Bueno, nosotros, en nuestro equipo de trabajo, se ha renovado últimamente y llevamos muy poco siendo más rigurosos dentro de la organización. Entonces nosotros en este minuto estamos creciendo en cuanto a metodologías, estándares desde el punto de vista de desarrollo de software, arquitectura de hardware, etc. Entonces, ¿cuales mejoras tenemos?, infinitas. Tenemos para crecer mucho. Imagínate que hoy establecimos un estándar para todos los proyectos que tiene tales etapas. Ahora estamos en una mejora de la metodología, donde se van a exigir otro tipo de documentos. Después de exigir los entregables, hay que meterse en el detalle de los documentos. ¿De verdad me sirve tener (te voy a inventar) separados los requerimientos en 1,2, 3 y una lista? A lo mejor hacer necesito hacer casos de uso, que no los tenemos. Y empezar a mejorar, digamos, la documentación y la forma de entrega al cliente.

-O sea que antes de toda esta etapa no se realizaba...

No, aunque te parezca increíble.

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

La compañía en general. Se esta tendiendo a que los jefes escuchen a sus subalternos. Entonces aquí lo que esta pasando es que tu detectas algún problema, lo llevas a tu jefe y de eso se presenta como una mejora. Acá son súper abiertos a las sugerencias. En tanto eso puede ir modificándose en el tiempo tantas veces como uno proponga una mejora. Pero esto, tú la propones y eso va a una mesa de arquitectura donde está el gerente... Lo analizan y ven si se hará o no y cuando.

- ¿Y usted puede modificar el proceso en caso de?

No. Yo soy parte del área de tecnología que tiene varios grupos, digamos de trabajo, y esos grupos son los que usan la metodología. Entonces no puedo yo llegar y tomarme esa atribución. La que tiene la atribución, digamos mas cercana a mi, seria el subgerente de tecnología. A todos los equipos de trabajo, tendría que entregarles esa modificación.

- Dentro del área que usted trabaja hay varios equipos de trabajo.

Claro. Esta el subgerente y después están las áreas de trabajo que atienden a las distintas subgerencias de la compañía. Yo veo lo que es Web e Intranet. Hay otra persona que ve todo lo que es créditos hipotecarios y de consumo. Hay otra persona que tiene que ver con todo lo que es seguros, y cosas así. Estamos divididos por líneas de negocios.

- ¿UD cree que esta segmentación de personal, en tantos grupos, tiene algún problema en el sentido de comunicación?

Claro que tiene, porque resulta que hay gente que, o sea, la gente que ve seguros, que es el problema que yo tengo. Yo soy Web y por tanto, ahora todo quieren entregárselo al cliente a través de la página. No se, ponte tu, hacen un desarrollo en crédito hipotecario. Ahora estamos entregando la cartola en las aplicaciones de crédito hipotecario para las ejecutivas. Entonces llega el usuario y dice entreguémoslo también en la Web. Entonces sacan desarrollos, desarrollos, desarrollos, y yo estoy mirando a la Internet pero no me entero de todos los desarrollos que ellos hacen, hasta que el cliente dice “ya, pero llevémoslo a la Web”. Y ahí hay que correr, porque tiene que estar acá con la ejecutiva y a la vez tiene que estar en la Web.

Entrevista al Ingeniero Luis Berrios

2007-11-04T20:21:00.001-03:00

Descarga la entrevista en audio (parte 1)
Descarga la entrevista en audio (parte 2)

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 esta 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 Quienes 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 ultimo 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 tu ya sabes quien 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 esta 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, mas 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.

Entrevista al Usuario Eduardo Pedraza

2007-11-04T19:38:00.000-03:00

Descarga la entrevista en audio

1. Identificación del problema

1.1 ¿Cuáles son los principales problemas que posee el proceso y de dónde provienen dichos problemas?.

Cuando nosotros hablamos del proceso, nos estamos refiriendo a la problemática que puede existir en la creación de un sistema de información, sea un sistema de información en general o sea un área en específica. Como mi área obedece a la parte financiera y contable nos vamos a referir fundamentalmente a esta área. A ver.., los problemas que se puedan originar en una mediana empresa, que es un tema muy vigente y característica ahora, es que primero existe poco personal, segundo la gente tiene una seria de tareas asociadas que no le permiten tener una visión integral de esta situación, tercero la comunicación es muchas veces deficiente entre los distintos niveles jerárquicos, cuarto podríamos agregar que suele ocurrir que en algunas empresas por abaratar costos el nivel de la gente, nivel de conocimiento, el nivel de preparación académico de la gente no es el más adecuado. Si bien es cierto la gente puede tener algunas fortalezas en términos de experiencia, pero también hay un marco conceptual que no maneja. Entonces estas características me van a generar dificultades en la implementación de un sistema de información, y estas dificultades están relacionadas fundamentalmente en la comunicación, ehh un poco débil, poco fluida con quién esta realizando la labor del punto de vista externo. Muchas veces no existe en las empresas, y suele ocurrir en las empresas medianas no existe manuales de proceso, no existe manuales de funcionamiento, de requerimientos y captura de información, es decir, hay una serie de elementos que son necesarios en el proceso administrativo que no están definidos, que no están expresados de una manera clara por escrito y una forma categórica. Hay un conocimiento tácito y el hecho de llevar de ese conocimiento tácito al conocimiento expreso nos genera una serie de dificultades.

¿Como nos relacionamos con el ente externo, que en este caso puede ser un Ingeniero de Sistemas? Fundamentalmente a través de entrevistas. Primero va a tener una visualización del problema y de los requerimientos reales de información a objeto de poder programar y planificar todas sus actividades. Ahora estas reuniones, dada la diversidad de actividades, que se realizan dentro de un departamento de contabilidad por ejemplo, donde el número de personal es reducido me genera dificultades de comunicación reitero en términos de que no dispongo a veces del tiempo, no se dispone del tiempo para dedicar a proporcionar la información que el Ingeniero requiere o que el analista de sistema requiere para desarrollar dicho sistema. Generalmente hay una reunión con los mayores ejecutivos y ellos quieren un sistema de información, va a depender del nivel de preparación académico que tengan los ejecutivos, porque suele ocurrir en el caso de empresas familiares que hay muy buena disposición, hay muy buenas ideas, pero falta un conocimiento específico y esta carencia les lleva a ellos a delegar en gente de mando medio una serie de aspectos a considerar en la preparación de este sistema; y como señalaba anteriormente esto me genera problemas de tiempo en términos de proporcionar la información para el desarrollo del sistema. Ahora bien, si la persona que viene en forma externa tampoco trae una planificación, una programación adecuada a objeto de capturar información que le permita ir cada cierto tiempo relacionándose con la gente para ver el estado de avance de este futuro sistema es algo que también hay que considerar. Entonces recapitulando el problema surge de la falta de comunicación producto de muchas tareas a realizar por la gente interna y a veces me imagino que en los menos casos la falta de programación y la falta de experiencia de quién esta abordando este tema.

Entrevistador: Con respecto a lo mismo. ¿Usted cree que la culpa es compartida tanto de los Ingenieros como de las personas a quienes ellos entrevitas?.

Entrevistado: A ver, fíjate que el concepto de culpa no me es muy agradable, porque para mi tiene una connotación negativa, aparece como un término un poco coercitivo, yo creo que las responsabilidades son compartidas en términos de lo que señalaba anteriormente, ya que si no somos capaces de preparar un programa de trabajo con fechas, utilizando herramientas de la administración como lo son una carta gannd, un sistema per, hay una serie e herramientas que me van a permitir establecer el grado de avance o realizar actividades paralelas en términos de programación de trabajos; en la medida de que yo no ocupe bien esas herramientas claro que si me va a generar un problema y va a ser un problema, tanto del ente externo, como también del funcionario dado que de acuerdo al marco que se definió de una mediana empresa, donde hay poco personal y es poca la preparación de la gente, la persona encargada va a tener que distraer mucho de su tiempo en este trabajo que por cierto es un tema delicado y requiere de un conocimiento bastante preciso, puesto que en este trabajo la teoría me dice que va a desarrollarse un sistema que me va a facilitar la gestión de la empresa, me va a facilitar la gestión del departamento contable puntualmente. Pero como te vuelvo a reiterar no es necesario utilizar el término de culpa, sino que de asignación de responsabilidades, asignaciones de tareas de trabajo, asignaciones de metas y

claridad por cierto de los objetivos que me van a permitir desarrollar el proceso administrativo hablando de una planificación, de una organización, de una dirección, de un control y un feed-back que es necesario, que nos va a permitir cada cierto tiempo ir corrigiendo las desviaciones que van a aparecer en relación a lo planificado. Así que hay responsabilidades compartidas, ahora puede que el nivel de empatía que hay entre los dos entes sea bastante bueno y eso me va a permitir grados de avances mayores que lo normal.

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

A ver me afectan en términos de cumplimiento, porque esto se va a relacionar con mi actividad interna y el hecho de poder orientar mis esfuerzos, de orientar mi tiempo a la preparación de este sistema que por cierto me va a repercutir en mi actividad interna y eso me va llevar a redefinir actividades, requerir el apoyo de otras personas para que, tanto lo interno, como lo externo, en este caso la creación de este sistema, tengan una marcha relativamente normal y se cumplan los plazos establecidos porque tú tienes que pensar de que todo esto tiene un costo asociado. Existe un costo de oportunidad, en términos de entrega de información a nivel interno para la toma de decisiones y también hay un costo asociado en términos financieros a si la gente no puede entregar por ejemplo el sistema en el periodo acordado; hay que partir de la premisa de que hay contratos firmados anteriormente en el que se establece un programa de trabajo, y en muchos casos se va a pagar contra el grado de avance que exista en el desarrollo de los sistemas y si no respetamos la fecha también hay un sistema de multa que va a afectar a la empresa externo, es decir, si yo programe un trabajo para tres meses, no le voy a pagar a esta entidad si me lo entrega al año después, entonces esas razones son también necesarias de considerar.

2. Rich Picture

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

Esto va a depender de la estructura primero de la empresa, porque va a ser expedito en la medida de que yo tenga definido bien la carga de trabajo y pueda reasignar esta carga de trabajo a objeto de entregar tiempo en cuanto a cantidad y calidad necesario para relacionarme con el ente externo; y te vuelvo a insistir va a depender mucho de la programación de trabajo que ha hecho la empresa externa y esto me va a definir en cierta medida lo expedito o lo burocrático.

En el caso de haber burocracia significa que mi estructura interna no es de la más adecuada, que mis sistemas que estoy utilizando en este minuto son bastantes deficientes, a lo mejor los recursos tecnológicos existentes no los estoy utilizando de forma adecuado y eso me va a generar burocracia, porque me va acumular trabajo interno si yo oriento mis esfuerzos a la parte externa.

Entrevistador Pero desde su experiencia ¿Cómo podría clasificar este proceso, cómo burocrático o expedito?

Entrevistado: Te reitero, va a depender mucho de la estructura organizacional y de la cultura organizacional que exista al interior de una empresa, porque hay una serie de elementos a considerar como los son: personal idóneo, personal capacitado que se adhiere a las políticas de la empresa, que hay una buena comunicación en términos estructurales al interior de la empresa en relación a ejecutivos y sus subordinados, existe un ambiente grato de trabajo, es decir, el capital humano que existe es de buen nivel, las relaciones industriales en este caso que es un tema muy importante, las relaciones entre el personal y los empresarios son de buen nivel va a permitir que el desarrollo de estos sistemas sea un trabajo expedito, porque la gente va a vislumbrar los mejoramientos, a lo mejor una modificación de la carga de trabajo, es decir, se aliviana la cantidad de horas a trabajar, el hecho de incorporar nueva tecnología va a significar a la gente poder capacitarla y eso va a redundar en mejores remuneraciones, por lo menos la teoría dice que es así.

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

La experiencia que he tenido ha sido de una relación relativamente fluida. Te vuelvo a señalar los tópicos anteriores, esto depende mucho del grado de capacitación de las personas a objeto que podamos utilizar un lenguaje que sea común para todos. Pero en términos generales, existiendo un ambiente grato de trabajo facilita mucho la gestión interna y externa.

Entrevistador: Con respecto a los mismo ¿Sus necesidades se adecuan a la de los otros funcionarios de la empresa?.

Entrevistado: En términos generales si, porque si nos abocamos al tema de un desarrollo de un nuevo sistema de información, en el área contable puntualmente, facilita el hecho de tener una buena relación con ellos, facilita el hecho de sentirse parte de, y eso va a contribuir a que la gente vea todo esto desde una perspectiva positiva, donde ellos son participes, donde nos estamos relacionando de buena forma y va a redundar en un mejoramiento de la eficiencia y de la efectividad.

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

Claro, las labores al interior de una empresa en mi caso puntual como contador general, son diversas debido a que hay distintas áreas dentro de la parte contable que nos afectan a nosotros como contador general, en este caso como contador auditor, áreas por ejemplo en la parte tributaria que no necesariamente están a asociadas a este sistema de información contable; la parte de desarrollo organización que si bien es cierto en alguna medida se puede topar con lo que nosotros estamos pensando en lo referente a sistemas de información, tiene una visión un poco más integradora, más amplia en la parte laboral, en la parte estrictamente previsional, en la parte estrictamente que dice relación con las remuneraciones, son otras de las diversas áreas que me permiten desarrollar mi actividad. Pero por cierto en el área de desarrollo de sistemas, uno como contador auditor está muy involucrado puesto que una de las actividades nuestra es la evaluación de los sistemas de información.

Entrevistador: Entonces a su juicio, debido a que tiene otras labores que realizar, reiteradas interrupciones por parte de los Ingenieros afectan su trabajo?

Entrevistado: Esto va a afectar el trabajo en la medida en que no seamos capaces de ponernos de acuerdo, en la medida en que no seamos capaces de tener mucho sentido de la empatía en términos de programarnos, asignar tiempos, asignar días, asignar horarios. En la medida que el trabajo, no sea planificado ni organizado, por cierto que me va a generar dificultades, pero como estamos hablando a un nivel profesional, yo creo que debe existir la voluntad necesaria para ponernos de acuerdo y para que esto nos lleve a un feliz termino.

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

Esto tiene mucha relación con lo que ya hemos conversado, en la medida de que el trabajo sea programado, sea conversado, sea evaluado en conjunto con la parte externa se me va a facilitar todo tipo de actividades en lo referente a requerimientos, entonces yo creo que lo importante es partir por ahy, es decir, una buena planificación de trabajo, claridad en los objetivos (por cierto) de modo que me permita organizar un proceso de retroalimentación o feed-fack que me permita ir corrigiendo las desviaciones en el minuto, en el tiempo ya, es decir, no dejar pasar un tiempo de espera.

4. CATWOE, HAS

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

Las mejoras están orientadas a conocer de la gerencia los programas de desarrollo que hay para la empresa, desarrollo organizacional por ejemplo, a objeto de que uno pueda en el tiempo planificar la cantidad de horas, de días, de semanas o de meses que va a asignar para un proyecto determinado, como es el caso de éste, un desarrollo de sistema de información contable. Entonces en la medida que yo tenga claridad en eso, me va a permitir realizar mejoras en términos de proporcionar información de una manera expedita, de una manera oportuna al Ingeniero que esta o al grupo de profesionales que esta a cargo del desarrollo de este sistema, que ellos tengan una fluidez en recibir la información que requieren y también tengamos una fluidez en términos de que podamos juntarnos cada cierto tiempo a evaluar las desviaciones que se pueden suscitar en la realidad puesto que tú bien debes saber que la planificación generalmente resulta perfecta, pero la realidad n términos prácticos me dice muchas otras cosas. Hay imponderables que a veces no están previstos, situaciones eventuales que me van alterar mi normal desarrollo de actividades y eso de por cierto me va a repercutir en el trabajo con los asistentes, con los profesionales externos en términos de poder reunirnos con la periodicidad y con la cantidad de tiempo necesario.

Entrevistador: Para finalizar, se puede inferir que una solución que usted propone es que exista una adecuada comunicación y planificación, tanto entre el Ingeniero, como con las personas que se encuentran involucradas en este proceso?

Entrevistado: Por cierto que si, es necesario establecer un programa de trabajo, donde las partes involucradas tengan una participación activa, esto quiere decir que a la empresa determinada este el gerente y una persona que secunda al gerente, como es el caso de un contador auditor que estén presente en la preparación de ese programa de trabajo a objeto que puedan existir las flexibilidades necesarias para manejar situaciones eventuales y eso nos permita ponernos de acuerdo desde un principio de cómo nos vamos a relacionar, en cuanto tiempo, de que forma entregamos la información para que ellos la puedan procesar rápidamente y también ver planes alternativos ante situaciones eventuales que se produzcan al interior de la empresa como también a la empresa que nos esta asesorando externamente