Nombre: Rodrigo Gálvez.
Titulo: Ingeniero Civil en Informática.
Años de Experiencia en Toma de Requisitos: 7 Años.
Trabajo: consultora Polo Sur (esta hace tres años realizando trabajos en D&S, por parte de Polo Sur).
e-mail: rodrigo.galvez@polosur.cl
Nombre: Juan Pablo Castro.
Titulo: Ingeniero Ejecución Informática.
Años de Experiencia en Toma de Requisitos: 7 Años.
Trabajo: consultora Polo Sur (esta hace tres años realizando trabajos en D&S, por parte de Polo Sur).
Se agradece a Felipe Bustamante y Francisco Pavez por facilitarnos las fotos de estos dos ingenieros (Grupo 2 CHT).
¿Cómo es el proceso de la toma de requerimientos de un Sistema Informático?
En la universidad siempre se decía que hay que seguir un procedimiento, había que hacer documentos, como OMT++, que creo era súper buena, pero al momento de entrar a trabajar no se ve nada de eso. Acá existe un procedimiento, cada empresa sigue uno a su manera. (Contestado por Rodrigo)
¿Qué rol ha tenido en cada empresa que ha estado?
Consultor de SAP, dentro de esto soy desarrollador, mi rol básicamente es recibir requerimientos y programarlos, o capturar yo mismo los requerimientos y programarlos.
Cada empresa sigue sus procedimientos a través de alguna norma, tal vez una norma de auditoria, no siempre de una norma de ingeniería. (Contestado por Rodrigo)
¿Ha trabajado siempre en empresas grandes?
Si, yo pertenezco a Polo Sur (consultora externa), a nosotros nos mandan a empresas, las cuales siempre me ha tocado que sean grandes (Contestado por Rodrigo)
¿Los roles de estas empresas son bien especificados?
En empresas grandes siempre van a tener recursos para tener gente que ocupe las funciones que correspondan, al contrario de las empresas medianas y chicas que no tienen los recursos necesarios para tener mucha gente. Existen empresas que contratan consultoras externas, como en el caso de nosotros que realizamos esos servicios.
En la universidad enseñan teoría, en donde se tienen que seguir ciertos pasos, pero cada empresa tiene su estilo. Cuando uno es consulto externo, se da el caso que también tenga que ejercer roles además del que corresponde, el cual es desarrollar. (Contestado por Juan Pablo)
¿Tienen que haber distintos roles para realizar un Sistema Informático?
No existen roles específicos, en teoría debería ser así, pero el rol es un poco distribuido, a veces los requisitos los tomo yo, o en otras ocasiones lo toma otra persona, depende de las necesidades. Depende de si la persona es experta en alguna situación, puede hacerse cargo de ella, no necesariamente necesita tener un cargo especial para ejecutar esa tarea. (Contestado por Rodrigo Gálvez)
¿Existe un lenguaje especial para comunicarse con el usuario, una forma particular en como abordarlo para capturar los requisitos?
Si hay un lenguaje, pero hay una experiencia que sirve para esto. (Contestado por Rodrigo Gálvez)
A veces cuando se requiere un sistema en forma rápida, no hay tiempo para realizar una especificación de requerimientos (documentación). Ocurre muchas veces que primero se realiza el sistema, y luego se lleva a cabo la documentación, netamente por el tiempo. Si hubiera, tal vez, una buena especificación de requerimientos, no existirían a lo mejor problemas en el desarrollo. (Contestado por Juan Pablo)
¿En la empresa que se desempeña se sigue alguna metodología especial para crear un sistema informático? ¿Podría hablarnos acerca de ella?
Nos basamos en la norma SOX (se adjunta la documentación acerca de la norma), nosotros tenemos que emitir varios documentos durante el desarrollo, tiene que emitirse una solicitud de requerimiento (se adjunta documento) con el cual se empieza el proceso. (Contestado por Rodrigo)
¿Se realiza un estudio de factibilidad para verificar si el sistema contribuye a los objetivos del negocio? ¿Cómo se realiza este proceso?
Si se realiza, se verifica si se puede llevar a cabo un sistema en un tiempo determinado. Se tiene que evaluar si es costoso el sistema. (Contestado por Rodrigo)
Si no es factible realizar un sistema, ¿se desecha?
No, surgen alternativas, generalmente el requerimiento no es desechable. Existen requerimientos que son muy necesarios (como las restricciones legales), en donde pueden surgir alternativas. (Contestado por Rodrigo)
¿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?
La forma de abordar al usuario lo da la experiencia, si uno se queda con la primera cosa que dice el usuario, al final a medida que se realiza el proyecto van a surgir muchos problemas, al no encajar ciertas cosas con este. (Contestado por Juan Pablo)
¿Cómo usted determina los puntos de interés del usuario?
Viendo que es lo que hace y que es lo que necesita fundamentalmente (contestado por Juan Pablo)
(El jefe de proyecto emite las solicitudes que se captan de los usuarios.)
¿Existe un contacto permanente con el usuario durante el proceso de desarrollo?
No directamente con el usuario final, porque existen muchas sucursales por todo Chile, en donde estas están repartidas por todo el país (DyS), existe un intermediario, al que se le llama KeyUser, que también se le denomina usuario funcional. Existen por lo tanto tres tipos de roles en el desarrollo, los desarrolladores (nosotros), los KeyUser que entienden del manejo del negocio (la lógica del negocio), y los configuradotes que participa en ciertas partes del proyecto. (Contestado por Rodrigo)
¿Los roles están bien enlazados, se complementan bien?
Si, pero los roles tal vez no se determinan por personas, ya que las personas pueden ejercer varios roles. (Contestado por Rodrigo)
A veces con la experiencia, no es necesario preguntar ciertas cosas al funcional, uno como desarrollador ya va manejando ciertas cosas. (Contestado por Juan Pablo)
Algo que afecta mucho en la toma de requerimientos es el usuario final que se tenga, tal vez este tenga miedo ante algún cambio, ya que si le cambian el sistema que ya maneja, por alguno que tal vez le cueste acostumbrarse, puede ser que piense que lo van a echar. Debido a esto, el no va a querer entregar toda la información necesaria, quizás el va a querer que más se demoren en terminar el sistema. Entonces uno tiene que hacerles entender que si ellos aportan, y a medida que vayan aprendiendo a usar el sistema, se van a dar cuenta que son una pieza importante para la empresa. (Contestado por Juan Pablo)
Existe una resistencia al cambio, tal vez en forma natural o por miedo. (Contestado por Rodrigo)
Uno tiene que exigir una cierta disponibilidad para tomar los requerimientos al usuario, pasa que el usuario se dedica a hacer todas sus cosas, en donde si le llega a quedar un tiempo libre ayuda. En resumen si se asigna en un 100% a la persona que es usuario, en ayudar en la toma de requerimiento va a resultar un buen sistema. Tal vez el usuario, además, tenga que tener horas extras para ayudar en la toma de requisitos, va a tener que venir los Sábados, va a estar cansada, y quizás sea la persona clave en el levantamiento del sistema informático. (Contestado por Juan Pablo)
¿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 que guiarlos, ayudarlos. (Contestado por Juan Pablo)
Tal vez el usuario sabe lo que quiere, pero no sabe expresarlo, por lo tanto es deber del informático guiarlo y enseñarle las posibles soluciones, en donde se debe llegar a un punto en común. (Contestado por Rodrigo).
¿Si existen distintos puntos de vista, como se llega a un consenso?
Se llega a un consenso, al fin y al cabo, todos quieren llegar a lo mismo. (Contestado por Juan Pablo.
¿Siempre le dicen “si” al cliente?
No, depende de la situación.
¿Cómo se enfrenta a la situación de que el cliente crea que maneja todos los detalles técnicos acerca de su área?
No hay tanto problema en eso, todo se lleva a términos de uno, uno directamente pregunta. (Contestado por Juan Pablo)
Hubo un seminario que se llamaba Reactiva `97. Un presentador hizo una pregunta parecida, “¿Cómo nos enteramos de las necesidades de un cliente?” Le conteste, “bueno se le pregunta como funciona su proceso”. El responde, “claro pero al cliente no le interesa como funciona su proceso, porque el sabe como funciona”.
Es decir, si yo no se como funciona el proceso, tengo que averiguarlo, tal vez, no sea directamente con el usuario. Me ha tocado clientes, en donde por ejemplo me dicen: “hay que modificar esto”. Y yo le pregunté “¿En donde se realiza esa modificación?”, yo estaba enterado que la persona sabía, pero me dijo: “no se, tu eres el desarrollador”. Fui a hablar con el líder de desarrollo, que incentiva a realizar ciertas cosas en el proyecto, al contrario del jefe de proyecto, que solo lleva un control de
En lo antes mencionado, se ve que hay un problema de organización, que rara vez se da, en donde siempre se da el problema con la misma persona, por lo tanto, hay que acudir a otra persona, ya que siempre hay muchas personas que manejen un tema en especial. Si no me entiendo con una persona, voy por otro camino. (Contestado por Rodrigo)
¿Y si la persona conflictiva, es la única que maneja un tema en especifico?
Ahí existe un problema, es una mala práctica, no debería ser así. Tal vez no pase por el hecho de que la persona no quiera cooperar, tal vez se encuentre de viaje.
En Sony me pasó que realicé un sistema, pero el cliente me dijo está malo, le dije no de acuerdo a los requerimientos que capturé. Aquí hubo un problema de entendimiento, por lo tanto esa persona fue expulsada del proyecto. (Contestada por Rodrigo)
¿Afecta la toma de requerimientos a un sistema?
Sin duda, he visto en otras empresas, programas súper parchados, justamente por un mal levantamiento de requerimientos. (Contestada por Juan Pablo)
Pasa a veces que uno no entiende la jerga de un cliente, debido a la cultura (tanto social o de nacionalidad), uno debe pedir ayuda, ya que existe un problema de comunicación. (Contestada por Juan Pablo)
¿Qué rol juega la ética en su trabajo?
Es muy importante, si me piden hacer algo en contra de mi ética, no lo hago simplemente aunque me cueste el puesto.
Aunque manejamos información confidencial, tenemos ciertas restricciones, y además nosotros vemos todo los datos como “un simple String”, sólo pasa la información. Tal vez hay gente que no le interese divulgar información, o ocupa la información para su propio bienestar, pero obviamente eso constituye un delito.
En cualquier momento te pueden pedir algo que va en contra de tu ética. (Contestada por Rodrigo y Juan Pablo)
En resumen, ¿Cuáles son los pasos necesarios para una buena toma de requerimientos?
Como comentario final, se debe mantener un método a través del tiempo, no es bueno como practica, y a veces en forma legal, cambiar un método.
Como manual para tomar requerimientos, es como primera cosa el tener un método, regido por alguna norma. Siempre documentar documentar las cosas y hacer un manual de uso.
Para ver como enfrentarse al cliente, lo da la experiencia, pero aún así es una pregunta muy difícil. A veces uno pregunta cualquier lesera, uno creyendo que es sensato. Hay que preguntar todo lo que uno no conozca, pero con la mayor sensatez posible, cosa que uno crea que sirva para el sistema debe preguntarlo. (Contestada por Rodrigo y Juan Pablo)
No hay comentarios:
Publicar un comentario