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.




Descripción de la problemática

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



No hay comentarios: