Entrevista Nº1

Nombre: Ana María Soto.

Titulo: Ingeniero Ejecución en Informática.

Años de Experiencia en Toma de Requisitos: 2 Años.

Trabajo: actualmente Profesora Inacap (se desempeño como jefe proyectos Plus Consulting).

e-mail:

Escuchar Entrevista

¿Cómo es el proceso de toma de requerimientos de un Sistema Informático?

Primero se entrevista al cliente, si es informática interna en la empresa se van apagando incendios. El analista se encarga de tomar los requerimientos. La base para tomar requerimientos es mediante entrevistas y encuestas. Es importante que la persona que tome los requerimientos vaya informada del tema, tiene que tener conocimientos (si es un desarrollo a terceros) acerca del mercado en que se maneja el usuario, el rubro de la empresa, hay que realizar un marco contextual acerca del usuario. Si se desea crear un software estándar hay que realizar un análisis acerca del entorno.

¿De qué manera participa el informático a cargo de este proceso en él?

El jefe de proyecto se debe hacer cargo de este proceso en forma activa. En el caso de la empresa que me desempeñé, debido a que era una empresa pequeña, en donde era jefe de proyecto, realizaba de todo, desde realizar entrevistas para tomar requisitos, pasando por el desarrollo de los programas, hasta dirigir proyectos.

¿En qué empresa se desempeñó?

Plus Consulting, empresa de cobranzas, que tiene como clientes a empresas como Cencosud. Trabajé en informática interna.

¿En la empresa que se desempeña (ó) se seguía alguna metodología especial para crear un sistema informático? ¿Podría hablarnos acerca de ella?

No se sigue una metodología específica, el que sigue el desarrollo usa su propia metodología, debido a que se requieren las cosas en poco tiempo, pero se podría decir que usamos prototipado evolutivo, en donde se presenta un avance, y de ahí se sigue, es lo que más se usa, debido a que el usuario pide soluciones inmediatas.

¿Cuál es su rol en el proceso de toma de requerimientos?

La empresa el área informática estaba dividida en soporte y desarrollo, había 4 personas en soporte y yo solamente estaba en desarrollo, estaba a cargo en realidad de las dos áreas. Se restringía a veces los permisos para realizar ciertas cosas, por lo que retrasaba el desarrollo de sistemas.

Mi rol especifico, por el cual me contrataron en un comienzo era para sacar informes de un sistema por medio día. Empecé a proponer proyectos los cuales me aceptaron y llegué a ser jefe proyectos.

¿Se realiza un estudio de factibilidad para verificar si el sistema contribuye a los objetivos del negocio? ¿Cómo se realiza este proceso?

Ninguno, no se trabaja tampoco en grandes proyectos. Otra cosa es que rara vez terminábamos los sistemas en el tiempo que se había establecido.

¿Qué acciones concretas realiza usted para extraer todo el conocimiento a los usuarios y a la organización para la cual esta diseñando un Sistema Informático?

Encuestas y Entrevistas, y tal vez una investigación previa, el analista se encarga de eso, aunque yo también jugaba ese rol por así decirlo.

¿Cómo enfrenta la situación en que al tomar los requerimientos de una persona que se vea directamente relacionado con el sistema no maneje demasiado o no exprese de buena forma lo que necesita?

Hay una tendencia, que cuando uno no tiene mucha experiencia, soluciona lo que quiere solucionar. Uno trata de analizar lo que quiere el cliente, pero uno trae como una idea previa. Con la experiencia uno se va dando cuenta lo quiere realmente el negocio. Hay que estudiar mucho, uno debe aprender acerca de los negocios a los cuales va a realizar un sistema.

¿Se realiza una división entre especificación de los requerimientos, es decir, se realiza una distinción de requerimientos en que se señalen servicios, requerimientos que detallen servicios y sirvan para contrato, y requerimientos que sirvan para el desarrollo?

¿O alguna otra división de requerimientos que ayude a entender a los diferentes tipos lectores de los requerimientos, a los cuales le corresponde intervenir en el desarrollo de este?

Todo depende del negocio del cliente, esto no se pone en práctica, nunca hay tiempo para esto. Generalmente se pregunta al cliente que quiere y se comienza a programar. Creo que falta gente que sepa trabajar con los tiempos, gente que logre eso va a ganar mucha plata. En la teoría se logra eso, pero en la práctica es muy diferente. Tal vez cuando uno es nuevo le complica este cambio. Hay muy poca gente que esta dispuesta a invertir en investigación.

¿Al cliente le importa la calidad, o solamente que cumpla el sistema con su objetivo?

Al cliente le gustan las pantallitas bonitas, los botoncitos. En la marcha blanca va todo bien con el sistema, pero con el tiempo cuando empiezan a requerir otras cosas, tal vez se dan cuenta que se debería haber invertido más tiempo en determinar todas las funcionalidades que se requerían del sistema.

¿Existe una buena interacción con el cliente o es la falta de tiempo?

El problema es que uno le dice si, si, si, a todo. No sabemos poner los límites, los contratos son mal hechos, existen muchos tratos de palabra. No se si falta una buena interacción, pero es como cuando el profesor está en la clase y uno esta si, si, si, todo el rato, y si el profesor pregunta lo mismo que había explicado recién uno no es capaz de responderle porque no proceso bien. Uno quiere ganar plata también, entonces si uno le pone muchas trabas, existe una competencia enorme a donde ir.

¿Cómo detallaban los documentos de requerimientos?

No existe una formalidad, no hay un sistema estándar, se usa casos de uso, UML, etc.

¿Qué pasa si existe ambigüedad en los documentos de requerimientos?

La gente no entiende, uno le muestra un diagrama y los pares no entiendes lo que quiere expresar, no se si esta mal hecho el diagrama o es que solo los clientes quieren ver una pantalla nada más. Separaba los requerimientos en funcionales, no funcionales, en módulos, y se los hacia llegar a los desarrolladores.

¿Usa alguna herramientas CASE para apoyarse en el trabajo de toma de requerimientos?

Power Designer, Process Analysis, Data Architect, sirve mucho sobre todo para hacer base de datos. La gente diagrama cualquier cosa, el que lleve el proyecto es el que decide como llevar a cabo este proyecto.

¿Cómo definiría su habilidad comunicativa, su inteligencia emocional y su capacidad de adaptación?

Tengo la habilidad pero tengo un defecto, conduzco a la gente a donde quiere, no soy objetiva. La habilidad comunicativa es vital, pero el informático no tiene esa habilidad.