Bienvenidos

Este espacio tiene por finalidad exponer el trabajo que estamos realizando, junto con otros compañeros de la Universidad de Santiago de Chile, para el ramo Comportamiento Humano en el Trabajo (CHT) cuyo objetivo es establecer una lista de competencias y habilidades que debe poseer un Ingeniero Informático para realizar una adecuada toma de requerimientos. Dicha lista se basa en las experiencia de Ingenieros Informáticos dedicados al área en cuestión (toma de requerimientos).
Es de esperar que este sitio sea de su agrado y utilidad.




Entrevista al Ingeniero Luis Berrios


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.

No hay comentarios: